undefined | Better HN

0 pointskelnos1d ago0 comments

There's just so much prior art here, though. Docker hub has username-based and org-based namespaces (as well as a "blessed package" root with no namespace). Maven central uses reverse-DNS as a namespace (and Maven central/OSSRH requires that you prove you own the domain before you can publish to it). Even npm, probably the poster child for doing things wrong, has user- and org-based namespaces.

This isn't a particularly difficult problem, and other package ecosystems have solved it many times in the past.

0 comments

3 comments · 1 top-level

stymaar1d ago· 2 in thread

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.

echelon1d 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/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.

stymaar1d 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.

j / k navigate · click thread line to collapse