{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreicnkvcvwy2rajou66zq56ifyj5fuouj6dlhcs2ceax7fq4ueagewm",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkklm6txfry2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=2#post_35",
  "publishedAt": "2026-04-28T10:33:01.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "jmillikin:\n\n> My package is an implementation of FUSE, and therefore it is called `fuse`. If I had forked the FUSE protocol into my own personal variant, then I would publish the library as `jmillikin_fuse`.\n\nThis is a very strict and specific interpretation of the crate name.\n\nI don't see why your own implementation would count as the `fuse`. Isn't the reference implementation by Linux kernel folks more deserving of being _the_ `fuse`? If your implementation isn't a fork or a drop-in replacement for the reference FUSE implementation, why would it be the `fuse` and not your take on it, like `jmillikin_fuse`? (or something like `jmfuse`)\n\nIf the crate needs to meet some criteria to deserve using a certain name, it seems almost like flipping the namespace the other way: there is some `fuse` that's _the_ true FUSE project/protocol/api/spec, and there are conforming implementations of it. So it should rather be a `fuse.org/jmillikin` where the FUSE controls the namespace and decides that your implementation its a valid `fuse` not a personal variant, while not-true-FUSE libraries would have to pick another namespace `fuse-plus-plus.fork/jmillikin`\n\nThis doesn't seem to be a problem on crates.io. `serde_json` is accepted as being for the real JSON, despite not being published as the `json` crate. There's `http` crate, but also `httparse`, `hyper`, `reqwest`, and a bunch of others that are arguably an implementation of HTTP, but they don't all have to be called `*/http`.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}