{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibpmdrozr4xbp2e4zai65jsuwhhqkevms2axnskbyfiht45b65kdi",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkkllz6ne7p2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=2#post_36",
  "publishedAt": "2026-04-28T10:38:21.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "> I 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\nI'm having trouble parsing this, sorry. I don't think my implementation would be counted as the reference implementation, that's why it would be under my namespace and not `kernel.org`.\n\nThe namespace represents the identity of the author, the crate name represents its purpose. If a library's purpose is to implement the FUSE protocol then `fuse` is a good name for it.\n\n> This 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` .\n\nIt would sure help when trying to figure out which one to use, though. I've mostly been getting by with the `json` crate, but I've never been able to figure out which HTTP library is the standard so I've just used Go whenever I need to do a project that involves HTTP.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}