{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibutry7cmyvvydcmpr6fgdjx7xmva2fkw336gqpc45vggyn3ky2wm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkiiidih6bc2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=2#post_24",
  "publishedAt": "2026-04-27T15:25:55.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io",
    "FUSE",
    "fuse",
    "SANE",
    "sane",
    "SLEIGH",
    "sleigh",
    "Maven Central (Java's package registry) also uses DNS for namespace verification"
  ],
  "textContent": "Disclaimer: I am on the crates.io team, but this comment is my personal thoughts. I need more information and the team needs to discuss before making any official decisions.\n\nWhen I look at namespace proposals, the way I approach it is trying to determine if the problems the proposal solves are substantially greater than the problems the proposal creates (because every solution involves tradeoffs). I'm not yet sure my thoughts on this particular proposal; I'm open to being convinced either way, and I would like some more information.\n\njmillikin:\n\n> The whole point of adding namespaces is to allow multiple packages with the same crate name to co-exist on the crates.io registry.\n\nIt sounds like this is the primary problem this proposal is aiming to solve; please correct me if I've misunderstood. You cite some examples:\n\njmillikin:\n\n>   * I've written an implementation of FUSE, but I can't publish it on crates.io because there is already a FUSE library published (fuse).\n>   * I've written an implementation of the SANE ABI and network protocol, but I can't publish it on crates.io because there is already a library for something called SANE (sane) which appears to be an unrelated project.\n>   * I am currently working on a pure Rust implementation of SLEIGH, which I won't be able to publish on crates.io because there is already a binding to the Ghidra implementation of SLEIGH published (sleigh).\n>\n\n\nCould you elaborate on why you would rather have namespaces as proposed here, over publishing these crates to crates.io as something like `jmillikin-fuse`, which is possible today?\n\njmillikin:\n\n> > While it's not _likely_ that the domains will lapse, it is definitely something that needs to be considered as an inevitability for _something_ .\n>\n> I think the exact details of the policy for guarding against lapsed domains for major projects would make for a great section in the eventual RFC, if this thread ever gets to the point where an RFC gets written.\n\nThe details of how lapsed domains are handled by this solution are going to influence my assessment of this proposal. Having two crates `example.com/foo` and `example.com/bar` potentially be completely unrelated because at the time of crate creation, the domain was owned by different entities seems difficult to communicate and ripe for confusion.\n\nMaven Central (Java's package registry) also uses DNS for namespace verification. Could you summarize how and why your proposal differs from what Maven Central does?",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}