[JonathonW]

I'd like to see a package registry with (1) Github-style author-namespaced packages, and (2) package signing (i.e. if an author starts signing packages with a different key, I'd like to know about it). Maybe integrate the latter with Keybase to help users decide if they should trust a key.

I don't know how you gain any kind of critical mass trying to compete against a well-established registry like npmjs, though.

[colanderman]

Package signing by the author helps, but not if (a) the author's key is compromised, or (b) the author acts in bad faith. With npm-style package registries, the risk of such an event increases with the number of dependencies your project has.

Better to (a) ship your code with explicit version and content dependencies (e.g. a SHA-256 of the package you expect to exist), or (b) delegate trust in upstream packages to fewer, more well-vetted, authorities (i.e. distro-style).

[hyperpape]

(1) has the consequence that names are associated with the original creator long after they may no longer be involved.

Package signing I can't tell if it's a good idea or not. It would require you to accept a new key in this case, but that is going to happen super frequently with NPM, inducing alert fatigue, and it doesn't do anything to prevent the authors' publishing credentials getting stolen.

[philipwhiuk]

(1) big projects just get moved over time.

e.g. philipwhiuk/gnome moves to gnome/core and there's a version published to philipwhiuk/gnome that pulls in gnome/core

[sitkack]

I'd also like a bunch of checks applied to my use of that registry.

1. only packages > nK downloads 2. only packages with tests 3. only packages with publicly available code that is same that I am downloading 4. only packages with > nnn stars, forks, issues, pull requests

All are just proxies for being a valid node in a dependency graph.

And like to know if any transitive dep violates my inclusion rules.