{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidfivrlhl3fmnhnvlp7hinjh2v2lgp26ou3fdhutcwidj7l7mpnkm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml5j2mpvkxr2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=4#post_64",
  "publishedAt": "2026-05-05T23:21:54.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "jmillikin:\n\n> If I were to publish a package `https://crates,io/crates/jmillikin-serde-json` then the only obvious choice for the name that's exposed to `rustc` is `jmillikin_serde_json`. If I were to set `lib.name` to `serde_json` then that would be confusing -- it's different from what users expect, and there's no way to predict it. There's no mechanical transformation that can be applied to the string `\"jmillikin-serde-json\"` to produce `\"serde_json\"` without generating incorrect results for similar names.\n\nThat's true, but the confusion can be fixed in other ways (and since the confusing feature already exists and can't be removed due to backward compat, it needs a fix regardless).\n\nFor example, crates.io could display the install boilerplate as:\n\n\n    serde_json = { package = \"jmillikin-serde-json\", version = \"1.0.0\" }\n\n\nThis overrides `lib.name`, so it works even if you choose a different dependency name locally.\n\n* * *\n\nHowever, I don't agree with the premise that different packages implementing the same thing should have the same name. It matters which (whose) implementation is it, and not only when picking packages, but while using them too.\n\nFor example, we have `openssl`, `boring`, `aws-lc`, `libtls` and `ring`. They're all derivatives of `openssl`, but they're not the same \"`ssl`\" library. There are differences in their APIs and feature sets. There's also `rustls`, `native-tls`, `schannel`, `security-framework`, and `superboring` and smaller pieces overlapping with RustCrypto crates.\n\nMaking code use `ssl::` for all APIs of all of these libraries regardless of the implementation removes important context from the code, because ultimately it's not the same `ssl` library.\n\nReplacing specific strictly-typed identifier in code with a generalized name that only broadly describes their purpose is incorrectly modeling the domain. They all being identifiable as an implementation of SSL is a job of a `keyword` in the metadata, not a Rust identifier. The code isn't referring to SSL as a concept, it's referring to a single specific implementation with its own API that is independent from the other `ssl` APIs.\n\nThat design error is counter-productive, because it obfuscates a specific name with abstract label, making it harder to find the real identity required to use the specific implementation correctly.\n\nOut of all reasons for namespaces, this seems the weakest one to me. So weak, it has a negative value for me.\n\nI would be genuinely annoyed if the same `ssl` was used for `sfackler.github.io/ssl`, `sfackler.github.io/ssl` and `sfackler.github.io/ssl` (AKA `openssl`, `native-tls` and `security-framework` in the global namespace - the same author created more than one SSL library). I'm also switching between projects using `cloudflare.com/ssl` and `sfackler.github.io/ssl` (some of which is now `kornel.ski/ssl`) and sometimes `aws.amazon.com/ssl`. Keeping so many similar-but-different interfaces in my head is already annoying, and it would be much worse if they were all cloaked behind the same vague `ssl::` identifier.\n\nSo even if library-renaming namespacing was possible, it'd be annoying, and I'd advocate for keeping library names unique anyway, like `aws.amazon.com/aws-lc`, `sfackler.github.io/native-tls`, `openssl.org/openssl`, etc. There are some benefits to having extra identity and flexibility in naming, but ability to remove distinction between implementations is not a benefit, but a confusing downside of the proposal.\n\ncrates.io can add categories or more distinctive keyword tagging to help find which crates are for SSL and which ones for JSON. crates.io can more prominently display ownership and surface library renaming. Packages as namespaces or prefix reservations can let authors publish packages in their own namespace without making crate/library names so heavily generic and context-dependent.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}