[Pre-RFC] DNS domains as package namespaces

It sounds like [multiple packages with the same crate name] is the primary problem this proposal is aiming to solve; please correct me if I've misunderstood. You cite some examples:

Yep, that's correct.

Could you elaborate on why you would rather have namespaces as proposed here, over publishing these crates to crates.io as something like jmillikin-fuse , which is possible today?

My package is an implementation of FUSE, and therefore it is called fuse. If I had forked the FUSE protocol into my own personal variant, then I would publish the library as jmillikin_fuse.

Note that if I had done so, and I had published jmillikin_fuse, then I would not want to prevent someone else from publishing their take on that idea. They should also be able to publish their jmillikin_fuse library if they wanted it to do something different than mine.

In other words, I do not view the current crates.io package names as conveying information about the identity of the author.

There are many crates (random 3 from a quick search: google_maps, amazon-spapi, microsoft-directx) where the format is {organization}-* but the author has no relationship with those organizations. I think this is fine and normal, because package names do not currently contain information about the author.

The details of how lapsed domains are handled by this solution are going to influence my assessment of this proposal. Having two crates example.com/foo and example.com/bar potentially be completely unrelated because at the time of crate creation, the domain was owned by different entities seems difficult to communicate and ripe for confusion.

My own personal instinct is to be very strict about this. If I had authority to dictate the rules, they would be:

• Namespaces are crates.io entities, like crates. There is a database table of namespaces.
  • Each namespace has a set of owners authorized to make administrative changes.
  • They also have a set of users authorized to publish new crates.
  • Finally, they have a set of users authorized to publish updates to existing crates if and only if those users are also an owner of the crate in question.
• When a package is published, new or update, the domain is queried to verify that the current owners of the crates.io namespace retain control over the domain.
• Publishing a package to a namespace requires 2FA.

If a domain expires or otherwise transfers control then the new owners will not be able to publish crates to that namespace. They would need to request intervention from the crates.io admins, which would be a similar process to someone asking to take over a crate.

However, I also recognize that my instincts are in complete opposition to how crates.io currently behaves and what the community expects regarding friction in the publishing process. Thus compromises like only verifying on crate creation.

Maven Central (Java's package registry) also uses DNS for namespace verification. Could you summarize how and why your proposal differs from what Maven Central does?

My understanding is that:

• Maven has fewer concerns about mutable usernames on third-party hosting. As noted in the thread they allow io.github.* group IDs, along with several other hosting providers with mutable usernames.
• They're willing to have higher friction on the publishing path, which changes the threat model regarding domain verification/expiration.
  • Cargo authentication is just a bearer token, and if I understand correctly then crates.io has no way to upload a GPG pubkey or enroll a YubiKey or anything that can be used to mitigate an account takeover.
• Java culture prefers large libraries. Packages like org.apache.commons.compress would be split into ten or more Cargo packages, all of which would be by different authors.
  • The expectations around maintenance and reputation are different than in an ecosystem with lots of small packages like Rust, Go, or JavaScript.
• Java existed before Maven Central and there's well-established ways to move .jar files around without Maven, so they don't have the same absolute ecosystem dominance as crates.io does.
  • If someone doesn't publish their .jar on Maven Central then it doesn't really matter, support for directly fetching from arbitrary hosting is well-supported.

As for the minor technical differences (TXT records vs HTTPS, com.example.www vs www.example.com) I don't think there's much difference.