{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidca4hnalaruobjzj3sayticih6tqxdchbaihxdxtyxmmgu3jiidq",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkq6lu2hfs22"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=3#post_53",
  "publishedAt": "2026-04-30T17:32:12.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "jmillikin:\n\n> I'm not sure I follow, sorry, though that might be because I'm used to the left-to-right order used by other package managers, Rust `mod` hierarchy, XML namespaces, and so on. Every sort of scoping/namespacing system I know of is big-endian.\n>\n> If you were looking at a group of dependencies, wouldn't you normally want them ordered as `(namespace, name)` instead of `(name, namespace)`?\n\nI agree that this is the way namespaces are typically handled; however, in the case where the semantic name of the crate is `xml` and the \"namespace\" is just a disambiguating tag. There is no important relationship between `example.com/xml` and `example.com/http` for any purposes except a dependency audit to view your attack surface for supply chain vulnerabilities. (But in that case you want to group by crates.io owner, not by domain name space.)\n\nBy contrast, `xml` and `example.com/xml` are very closely related: they're two crates doing the same thing! Similarly `http` and `example.com/http`. It seems to me that in most lists, it makes more sense for `example.com/xml` to appear with `xml` and `example.com/http` to appear with `http`, which is the claim I was making.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}