[Pre-RFC] DNS domains as package namespaces

jmillikin:

• One prefix per account (GitHub model)
  • One less obvious drawback to this is that a user would only be able to have a single package with any given crate name. It's not obvious that someone would want to be the owner of multiple yaml crates, but maybe they've got some personal circumstances that have lead them to such a situation.
• One prefix per crate, which is common in some ecosystems that use UUIDs for package identity, but UUIDs have already been ruled out by the requirements.
  • Random per-crate prefixes would also interefere with mirroring/replication of crates between registries.
• Some external source of truth for prefixes, which get associated with a crate in an N:M graph.
  • Of course the obvious answer when asked "globally unique human-readable identifier" is a DNS domain name.

This seems to missing "multiple prefixes per account"—which is in fact arguably also GitHub's model. GitHub allows accounts to create organizations, which serve as (among other things) namespaces for repositories independent of the user which created them.

The crates.io equivalent would be to allow users to create namespaces which they own, tied to their accounts, and then publish packages under those namespaces. This has a key disadvantage over domains which is that you would need anti-squatting/impersonation moderation to ensure that if Google wants to own the google namespace they can, but it seems worth at least mentioning as an alternative (especially since it slots in naturally with the existing system of "first come, first served" names managed by crates.io).

(You would presumably limit the number of namespaces a user can create and, e.g., allocate more if their crates actually get used by somebody; I'm unsure what the relevant policies are but they necessarily already exist for crates themselves, presumably as part of the anti-squatting rules you mention.)

jmillikin:

These requirements (summarized), if combined together, are in conflict with the concept of namespaces:

• Packages may not be renamed.
• Namespaces should be human-meaningful, not an opaque identifer.
• It should be possible to transfer ownership of a package.
• The name of a package should not misrepresent the owner of a package.

jmillikin:

There is no possible identity that is immutable, human-meaningful, accurately represents the legal identity of the author, and does not change when ownership of the package is transferred.

Whether namespaces are human-meaningful is entirely irrelevant here—the relevant part of your UUID example is that you never have a many-one relationship between crates and namespaces. If you used meaningless namespaces but continued to allow multiple crates under one namespace you would have the exact same problems.

While it is true that these are not literally reconcilable, the more specific issue is that you cannot:

• Couple crates permanently to a specific namespace (such that the namespace is part of its immutable name).
• Either of:
  • Allow transfer of ownership of crates tied to a namespace without transferring ownership of the namespace as a whole.
  • Couple namespace to the identity of the owner (legal or otherwise) and allow transfer of ownership at all (from the perspective of crates.io anyway; if the owner is an organization then ownership of the owner can change, but that happens independently of and invisibly to crates.io).

In particular, one thing which you could do in the case of "namespaces are just a thing you register with crates.io" is say that you can transfer ownership of namespaces as a whole, but not move crates between namespaces. This works naturally for something like cranelift but less naturally for people who want to publish their own xml library as {name}/xml.

I think moving between namespaces should be thought of as renaming[1], not merely transfer of ownership, but regardless, I wanted to narrow the specific contradiction.

Finally, I want to remark that I think you're trying to solve 3 loosely related problems:

• The cranelift/umbrella project example where multiple crates—possibly with versions updated independently, etc., rather than in lockstep, are nonetheless closely coupled under one umbrella project and, further, it's useful to distinguished crates which are officially part of the project and third-party integrations.
• "I want to publish my library called xml but xml already exists" (note that in this case, I would argue xml@example.com is actually more "natural" than example.com/xml; rather than breaking lexicographical search it is exactly placing the relevant part—that it is an xml crate—first and the irrelevant disambiguation that it happens to come from somebody called example.com second.
• "My name is Google and I would like people to know that" (Google may also want the second usecase too).

I think the first case is more accurately referred to by the term "namespace"—a namespace is a name prefix which is fundamentally part of the name and just comes with a canonical way to split it into a prefix and an abbreviation for cases where there are multiple things with the same prefix.

It is possible that one sufficiently clever feature can address all of these cases, but:

• one is for hierarchical projects where the namespace is semantically more significant than the specific module (lexicographically first),
• one is for deconflicting the global namespace by adding some arbitrary extension to a crate you wish could just be called xml, where the "namespace" is semantically less significant (and so should be lexicographically second), and
• one is about prominently displaying owner identity and doesn't actually need the "namespace" anywhere in the name, though it's probable that Google would also want to not worry about conflicting names.

The fact that the first case "wants" the namespace to be lexicographically first as namespaces typically are while the second case "wants" it to be lexicographically last bodes ill for the existence of a "sufficiently clever feature" that addresses everything.

1. It seems like perhaps Cargo should support "migration notices" where—with all the same authority as needed to publish a new version—you can publish a notice that future updates to the crate will happen under a different name. This would be mildly annoying since it may create situations where you want to say "crate foo with a version between X and Y" but crate foo was renamed to bar between X and Y and now you're either out of luck or need the ability to say "[crate foo > X OR crate bar < Y] as foo". Regardless, this addresses the issue of renaming rather which is only relevant insofar as the addition of namespaces may create more demand for renaming crates. ↩︎