Child Thread: Survey of organizational ownership designs for Cargo and Crates.io

[epage]

Some of this post is relevant to this thread

@kornel

Indeed, that's another axis in the design space. The indicators of ownership/authenticity/grouping don't have to be exactly the same thing as unique identifiers of packages at the protocol level. There could be additional metadata available in the registry or crates-io API, to be used as part of the user interface of crates.io, Cargo, and by 3rd party supply chain tooling, without package identifiers themselves having to carry all that information.

For example, cargo add @epage/clap could be interpreted as "add the clap crate, but only if it's owned by epage", and maybe save that requirement in Cargo.{toml,lock} like clap = { version = "4", but-update-it-only-if-still-published-by="epage#id6743" }. So you could have ownership-representing "namespace" at the UI level, explicitly locked provenance for cargo update, but without anything having to change in registry URLs or Rust identifiers (there are still other reasons to have more controlled naming, but the point is that the crate naming scheme alone doesn't have to be the solution to all the use cases).