{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib5hujyleocupcakthm2lzjusp5hyj3fbplic2hm3rj75kxxr77ie",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml5qfb2lvjs2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=4#post_65",
  "publishedAt": "2026-05-06T01:43:55.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "kornel:\n\n> However, 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>\n> For 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\nThe full name matters when you're doing a dependency audit and want to find out if `tls::` is OpenSSL v3.6, OpenSSL v3.6.1, or BoringSSL v0.20260413.0, but for normal everyday programming it's nice to be able to look at some code and know that `tls::` is a TLS library (vs being required to intuit that from `superboring::`.\n\nkornel:\n\n> I 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).\n\nThis wouldn't be possible because the package names would be in conflict. You'd have to do something like `sfackler.github.io/ssl` and `sfackler2.github.io/ssl` -- the library names are non-unique, but package names _are_ unique, otherwise there's no way for the registry to map the package name to a `(urls, checksum)` tuple (which is the whole point of a package registry).\n\nkornel:\n\n> So 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.\n\nFor some domains, such as cryptography, the quality of the implementation matters enough that users might insist on branding. You can always just decide to refuse to use dependencies that have names you think are too generic. As long as I'm allowed (as a package author) to publish a package, I don't really care if some subset of people don't use it for non-technical reasons.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}