{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihedr3jxm6rtzsbynd7qdt4smw7bbs5rwrr5cicww4z35hkjl2pou",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3ml4zqonustx2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=4#post_62",
  "publishedAt": "2026-05-05T20:19:19.000Z",
  "site": "https://internals.rust-lang.org",
  "textContent": "Clearer responsibility of each part, I'd say.\n\nWhen it is just the allowing of the `/` character, you come into the discussion where you might (or not) want users to be able to \"take\" prefixes to fill the requirement of grouping crates, for example for organisational purposes. If you wouldn't, then I could publish a `google.com/json` crate, which seems bad. Say that you'd allow the claiming of prefixes in crate names, then the prefix part of a crate name can only be indicative of the identity of the publisher by convention. It is just as easily possible that you have prefixes indicative of functionality, such as `http-`, where now only one entity can publish crates that start with `http-` and those sound mighty official (I know they aren't).\n\nBut if you have the concept of a namespace as part of the crate name, the namespace is the clear link to the identity of the publisher. Both approaches could result in a `jarrovgit/json` package, but only if I was smart/fast enough to claim the `jarrovgit/` prefix in case we'd go with allowing the character+prefix claiming option.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}