3 ms·

Arbitrary user-based or org-based namespace have many drawbacks: to name a few it makes discoverability much worse, and as such makes it easier to sneak in a ma

by stymaar 4mo ago

Arbitrary user-based or org-based namespace have many drawbacks: to name a few it makes discoverability much worse, and as such makes it easier to sneak in a malicious dependency, and it requires much more work on the package manager side to make sure that orgs are actually related to the company they use the name from (i.e. how do you make sure that the org "Google" in your package manager does indeed belong to GOOG), and a litigation process to resolve conflict (what if someone had created an Anthropic user name back in 2016?). And on the flip side nobody has ever been able to articulate (that is, not in a hand-wavy fashion) what do those actually bring on the table to make those extra costs worth it.

echelon 4mo ago
> much more work on the package manager side to make sure that orgs are actually related to the company In a world without namespaces, how does anyone know google-foo belongs to Google? At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. > (what if someone had created an Anthropic user name back in 2016?) https://github.com/anthropic https://github.com/anthropic https://github.com/anthropics https://github.com/anthropics Lol. The world seems to be moving along just fine. I don't think the problems you list are problems at all. Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge. There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$. It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.
- stymaar 4mo ago
  > In a world without namespaces, how does anyone know google-foo belongs to Google? It doesnt. And nobody believes it does. That's the key difference. > At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time. > Lol. The world seems to be moving along just fine. You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one? > There are much bigger problems to worry about than this. The thing is that mandatory namespaces don't provide meaningful benefit at all. > It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.

by stymaar 4mo ago

echelon 4mo ago

> much more work on the package manager side to make sure that orgs are actually related to the company In a world without namespaces, how does anyone know google-foo belongs to Google? At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. > (what if someone had created an Anthropic user name back in 2016?) https://github.com/anthropic https://github.com/anthropic https://github.com/anthropics https://github.com/anthropics Lol. The world seems to be moving along just fine. I don't think the problems you list are problems at all. Meanwhile, the benefits of knowing everything under a user/org namespace belongs to a user/org are huge. There are much bigger problems to worry about than this. Such as if a popular crate owner sells out to malware for $$$. It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. The org can uniformly control permissions to all member crates without having one go rogue.

stymaar 4mo ago
> In a world without namespaces, how does anyone know google-foo belongs to Google? It doesnt. And nobody believes it does. That's the key difference. > At least if you establish "@google" belongs to Google, then you can be fairly confident "@google/foo" is theirs. In practice nobody “establishes” that, they just trust the platform for vetting the orgs (and they are right, because they usually do), so if you package manager uses the same formalism without the same guarantees, you're setting yourself for a bad time. > Lol. The world seems to be moving along just fine. You've just shown an example that it doesn't! If you have two packages "anthropic/claude-code" and "anthropics/claude-code" how is the user supposed to know that the scammy-looking second option is the legitimate one? > There are much bigger problems to worry about than this. The thing is that mandatory namespaces don't provide meaningful benefit at all. > It's also much easier to control ownership and auditing of @tokio/xyz than it is tokio-xyz. This is covered by the accepted “crate as namespace” proposal. It has the benefit of keeping a flat namespace by default and providing an optional namespace for open source projects like that.