Live data from Hacker News

The lack of namespaces on crates.io is a feature

samsieber.tech

111–120 of 198 posts

Re: The lack of namespaces on crates.io is a feature

#111
post #47
post #17

Earlier quoted context omitted.

Agree, Go went a similar route as Java and I think that's good as well. The new tools.deps in Clojure actually is moving to disallow collapsed names for similar reason and will force iglu/iglu. Here's a rationale from them: > The groupId exists to disambiguate library names so our ecosystem is not just a race to grab unqualified names. The naming convention in Maven for groupId is to follow Java’s package naming rule…

Can I get a link to the quoted document? The quote raises more questions than it answers. Who determines that someone applying for a qualified name is the owner of that trademark (presumably this is a full-time employee; who pays their salary?), and what is the process? Trademarks are not a universal namespace--even within a single legal jurisdiction you can have the same name legally owned by different people due to…

The quote is from: https://insideclojure.org/2020/07/28/clj-exec/ under section "Deprecated unqualified lib names".

That said, ya this is best intentions unfortunately. I'm guessing if you own a real trademark, you could actually sue people using your trademark as their group-id.

Otherwise in general they recommend using a registered web domain name. Someone else could take over your domain name as theirs, but I think the registry owner, like maven-central, if you contacted them and could show you own that domain, they might be able to take actions against the impersonator. Same for a github user.

Actually, thinking about this, I feel it be great if the repository owner like maven-central required a form of proof of ownership of the domain or the github id. That could add a lot of trust to the whole process.

Re: The lack of namespaces on crates.io is a feature

#112
post #44
post #38

Earlier quoted context omitted.

"It's not a bug it's a feature" is the phrase I usually see thrown about for things like this.

That's the 'gold standard' but it leaves it open to interpretation. Some people mean it with very little sense of irony. Do you think Sam is being ironic with that title, or sincere? His intro is telling us how he's going to calmly explain to us dumb hicks and newbies that we wouldn't know a feature if it bit us on the ass (which it most definitely will, at some point). The rest of the article doesn't (quite) follow…

The intro says that Sam is laying out the advantages of no-namespacing because typically only the disadvantages are discussed. Sam also makes clear that they're "summarizing points raised across the various proposals I’ve read".

The rest of the article follows through on the intro's promise.

Re: The lack of namespaces on crates.io is a feature

#113

Earlier quoted context omitted.

> The only alternative to arbitrating your own identity layer is to tie yourself to some other preexisting identity layer (e.g. GitHub, DNS) Devolving identity down to DNS has been a really good decision for Go. I'm not sure why everyone doesn't do it. It's like XML namespaces, but actually useful.

> Devolving identity down to DNS has been a really good decision for Go If it works for go, the because go is not old enough. Domain registrations lapse quickly and then someone else can buy them. That's very close to the worst that can happen for trust in packages.

Ok, then how about Maven Central? They give you publishing rights to a particular group ID by verifying your ownership of the corresponding DNS names. They've been around long enough, I think, even if Go hasn't.

Re: The lack of namespaces on crates.io is a feature

#114

Earlier quoted context omitted.

That's orthogonal with the naming scheme. In fact the Go team eventually implemented a way to decouple the storage of a copy of the package from the name of the package, namely the goproxy. How they got there was admittedly a bit clumsy, but it proves that it's possible

Sort of; you can still delete github repos and the proxy doesn't keep a copy forever, right?

That's an implementarion choice of the proxy. You can run a private proxy that inplementa whatever policy you want.

If crates wants a policy that stores crates forever then just store crates forever. What I'm talking about just affects how new crates and new versions of existing crates get "uploaded".

Imagine you call your crate foo.com/bar. In order to push your crate the crates server needs to verify that you actually own the foo.com/bar URL.

There are many ways to do that. A simple one is to just have the crates server pull code from that URL instead of pushing it. If you want to push (e.g. to work around reachability issues such as firewalls) it's just the matter of devising one or more ways to prove that you "own" that handle. For example by serving some challenge response in a html meta tag

Re: The lack of namespaces on crates.io is a feature

#115

Earlier quoted context omitted.

Haha, that's not my real first name. You know, like how Ronaldinho's actual first name is Ronaldo? Like that. The actual name.

Sure, and that's why I said I was assuming, but my (poorly communicated) intent was to question how unique your first name is, and how someone is squatting on it if it's a real account and maybe they have that name too? I mean, it's probably not a big deal in this case. But if I had a github account that someone wanted and github just gave out my (personal?) info, I might feel a bit betrayed by them. I know, I should…

They don't give you access to the account. They tombstone the old one and assign its handle to yours. So you get the other GitHub handle but your account retains its repos, its keys, etc and doesn't get mixed in with the other account.

Of course, if they just let you login to the other one that would be crazy business. You'd know the other guy's email for starters. But they don't.

It's all perfectly kosher. You just get the namespace.

Re: The lack of namespaces on crates.io is a feature

#116

Earlier quoted context omitted.

Sort of; you can still delete github repos and the proxy doesn't keep a copy forever, right?

That's an implementarion choice of the proxy. You can run a private proxy that inplementa whatever policy you want. If crates wants a policy that stores crates forever then just store crates forever. What I'm talking about just affects how new crates and new versions of existing crates get "uploaded". Imagine you call your crate foo.com/bar. In order to push your crate the crates server needs to verify that you actua…

Right, but then you're back to the exact same issues we're talking about. The choices made by that proxy is the same discussion we're having here, and also means you can't totally rely on the external authority for identity, because you have to manage the mutability in their service. There are many ways to do it, and that in fact is the exact issue at stake here.

All of the existing services it would make sense to delegate to are more mutable than we wanted for our system.

Re: The lack of namespaces on crates.io is a feature

#117

Earlier quoted context omitted.

We did look and learn; a lot of crates.io was informed by several of us having experience with CPAN, RubyGems, and npm. Both the good and the bad. And also by the experience of going through GitHub hosting a RubyGems server and all the fallout that happened there.

I have less experience with CPAN and RubyGems but npm's namespacing system has two very serious problems: 1. It was introduced very late, meaning the community had already formed patterns of contribution around a flawed flat system. This is a problem of the flat system, not of the namespaced one. 2. It is still to this day entirely optional (for understandable backward compat. reasons). This gives namespaceless packa…

Add a "legacy" namespace and move all existing packages there. Allow for a transition period where tooling will add "legacy" to instances where no namespace is given. Add a mechanism for legacy packages to indicate their new namespace so that transitioning could be mostly automatic for package users.

Not effortless, but not necessarily very costly either.

Re: The lack of namespaces on crates.io is a feature

#118
post #70

Earlier quoted context omitted.

> They're wrong; full stop, no qualifications, no asterisk, no footnote, they are totally wrong on this and it is inevitable that their opinion will change. This sentence takes the place of a reason. You could have offered a reason why you were right or a rational argument about the matter. Instead, you basically yelled "I'm right, they're wrong! I'm right, they're wrong!".

I am not arguing that this should happen; I am asserting that this will happen. The reasons why it should or shouldn't happen don't matter when it will happen. If you'd like to: Go back and re-read my comment, but re-read it in the mindframe that I'm against the change. It still holds. I didn't provide reasons why they should make the change, because I don't have a stance on whether they should or shouldn't. I am not…

Just because they will do it eventually doesn't mean they are wrong now. It's entirely possible that a flat namespace is reasonable decision for a small registry with few resources, but a bad decision for a well funded registry of an ecosystem that had a few more years to develop.

Re: The lack of namespaces on crates.io is a feature

#119

Earlier quoted context omitted.

Sure, and that's why I said I was assuming, but my (poorly communicated) intent was to question how unique your first name is, and how someone is squatting on it if it's a real account and maybe they have that name too? I mean, it's probably not a big deal in this case. But if I had a github account that someone wanted and github just gave out my (personal?) info, I might feel a bit betrayed by them. I know, I should…

They don't give you access to the account. They tombstone the old one and assign its handle to yours. So you get the other GitHub handle but your account retains its repos, its keys, etc and doesn't get mixed in with the other account. Of course, if they just let you login to the other one that would be crazy business. You'd know the other guy's email for starters. But they don't. It's all perfectly kosher. You just…

Ah, they gave the account name. When you said "asked them for the guy" and "they just gave it to me", I was interpreting it as the guy's contact info and them just giving it to you, which is what was raising red flags for me. Yeah, it's much less problematic if they just let you use the name of a discontinued account (as long as the github single-sign-on stuff keys off an ID and not a name, which I assume it does).

Re: The lack of namespaces on crates.io is a feature

#120
post #5

I remember when this came up because of the following user: https://crates.io/users/swmon

Why is he not banned / moderated?

Crates.io is run by a couple volunteers, they (sadly) don't have the time to start playing cat-and-mouse with squatters.
Post reply on HN