{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihp4fzrp2icddbdrrn4b3fass2nrrusmnrxeav2aagrxj7ics5poy",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mfdfjo4yb2h2"
  },
  "path": "/t/child-thread-survey-of-alternative-identifier-designs-for-cargo-and-crates-io/24029#post_1",
  "publishedAt": "2026-02-20T22:22:18.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "Survey of organizational ownership and registry namespace designs for Cargo and Crates.io",
    "Child Thread: Survey of alternative identifier designs for Cargo and Crates.io",
    "Child Thread: Survey of registry namespace designs for Cargo and Crates.io",
    "Crates.io",
    "PackagingCon: Julia's Pkg – Design & Rationale (2021)",
    "cargo#15887",
    "advice",
    "crates.io",
    "Internals: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)",
    "Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)",
    "Internals: Pre-RFC: unique crate names (2019)"
  ],
  "textContent": "For background context and links to other threads, see Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. This thread assumes that one has been read.\n\n**This thread is for summarizing approaches for avoiding squatting by changing how we identify packages.** Other general approaches include:\n\n  * Child Thread: Survey of alternative identifier designs for Cargo and Crates.io\n  * Child Thread: Survey of registry namespace designs for Cargo and Crates.io\n\n\n\n**Debating which proposal Cargo andCrates.io should go with is off-topic for this thread. Please create your own thread.**\n\n## Prior art\n\n_Those relevant for this thread_\n\n### Julia Pkg UUID\n\nEach package has a name, version, and UUID.\n\nThe dependency name is the Julia namespace used for the package. `Project.toml` maps the dependency name to the UUID which is then used to identify the package.\n\nAs a parallel to `cargo add`, you can add dependencies with the REPL. Users can pass the package name to the `add` command.\n\nTODO:\n\n  * If names are used on the command-line, how are they resolved?\n  * Presumably, packages can be renamed, so how do they deal with `pkg> add foo` changing meaning over time?\n\n\n\nMotivations:\n\n  * Changing names without breaking people\n  * A shared, flat namespace between local packages and registries when resolving dependencies\n\n\n\nReferences:\n\n  * PackagingCon: Julia's Pkg – Design & Rationale (2021)\n\n\n\n## Potential solutions\n\n### Unreserved prefixes (no-op)\n\nMaintainers could name their package `<namespace>-<name>`.\n\nFor brevity in code, maintainers can drop the namespace within Rust by setting `lib.name = \"name\"` or users can rename the package in their `dependencies` table.\n\nCompared to use cases:\n\n  * No trust in the namespace as anyone can publish in it\n  * Not friendly to renames or namespace transfers\n\n\n\nCompared to requirements:\n\n  * If using the `lib.name` trick, how to reference the package in Rust code is unclear though that is an existing issue for renames and kebab case (cargo#15887)\n  * Without the `lib.name` trick, access within Rust is verbose\n\n\n\nFuture possibilities:\n\n  * Encode this in the ecosystem by adding to `.cargo/config.toml` a `cargo-new.prefix = <string|bool>` with a default of `$USER` for packages not being added to workspaces\n    * advice will be given for changing this\n    * Users can always disable with `cargo-new.prefix = false`\n    * Repos that want to default to their Rust namespace can set `cargo-new.prefix = \"namespace::\"`\n  * Resolve cargo#15887, making discovery of Rust namespace more discoverable\n\n\n\n### Package-level `extern` name\n\nIn effect, this is promoting `lib.name` to a package level property that is used in the UX for Cargo and crates.io. We are renaming this from 'Package \"display name\"s' as that implies this is for UX purposes only and does not have an impact on compatibility.\n\nUsers manually manage conflicts in their naming of the package but can also set a package-level `extern` name for what they desire should be shown. As an `extern` name, this is the name it is referenced by in Rust code. The main way the user interacts with the package name is in dependency declarations.\n\nCompared to use cases:\n\n  * No trust in who published the package\n  * Communication of packages will be difficult\n  * Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency\n\n\n\nCompared to requirements:\n\n  * No correlation between the dependency and the namespace in Rust\n  * Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.\n  * Confusing having to interact with two different names\n\n\n\nReferences:\n\n  * Internals: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)\n\n\n\n### UUIDs as package identifiers\n\nLike \"Package-level `extern` name\" but deprecating `package.name` in favor of a unique ID.\n\nCompared to use cases:\n\n  * No trust in who published the package\n  * Communication of packages will be difficult\n  * Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency\n\n\n\nCompared to requirements:\n\n  * UUIDs in dependencies would be meaningless to the user\n  * No correlation between the dependency and the namespace in Rust\n  * Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.\n\n\n\nReferences:\n\n  * Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)\n  * Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)\n  * Internals reply: Crates.io “first-come, first-served” for plain crate names - why and how should it be changed? (2023)\n\n\n\n### Unique suffixes\n\nLike Discord’s DiscordTag, usernames are assigned a server-side suffix that is used to qualify which package of that name it is.\n\ne.g.\n\n\n    [dependencies]\n    \"libc#9274\" = \"0.3\"\n\n\nIt is presumed that the suffix is dropped when used in Rust code.\n\nUsers will need to pre-register their packages and update their packages to use the suffix. The RFC said that this could be done at publish time but there needs to be a way to know which suffix is intended. It can't be `(package-name, publish-owner)` as there can be multiple publish owners and one could have a prior version of the package or want to fork it short term.\n\nCompared to use cases:\n\n  * No trust in who published the package\n  * Typo squatting becomes easier as harder-to-remember numbers are used and typo squatting monitoring doesn't help as easily-typoed names is an intended use case\n  * Communication of packages will be difficult\n  * Users will be prone to depend on the display name, not the package name, pulling in the wrong dependency\n\n\n\nCompared to requirements:\n\n  * A package cannot be published to multiple registries as its suffix may be different\n  * Numeric suffixes will be difficult for users to distinguish packages\n  * Technically, how to reference the package in Rust code is not 1:1 with the package name but dropping the suffix is likely an easy thing to pick up along the same lines as switching kebab-case to snake_case (cargo#15887)\n  * Import collisions are possible which impacts usability. Like with multiple semver-major versions, users can rename the package.\n\n\n\nReferences:\n\n  * Internals: Pre-RFC: unique crate names (2019)\n\n",
  "title": "Child Thread: Survey of alternative identifier designs for Cargo and Crates.io"
}