Ever published a Rust crate on crates.io?
If you have, you’ve probably hit the most frustrating part of the process — naming. You want http. Taken. You settle for http-client. Also taken. http-client-v2? Still taken. You end up with hyper-http-client-lite and stare at the name wondering where your life went wrong. A recent pre-RFC in the Rust community wants to solve this with DNS domain names.
The crates.io Naming Bottleneck
crates.io uses a flat namespace. Every Rust developer in the world shares a single name pool — first come, first served. Same logic as the .com domain land rush.
This worked fine when the Rust ecosystem was small. Few developers, plenty of good names, single-word crates everywhere. serde, tokio, rayon — short and memorable.
But Rust isn’t a niche language anymore. crates.io now hosts over 150,000 crates, with roughly 2,000 new ones every month. The cracks are showing:
Words like wasm, oauth, parser, metrics — long gone. The good names are taken.
What’s worse, some crates were registered years ago with nothing but a skeleton — never even hit version 0.1. The name is locked. Nobody else can use it.
Developers resort to prefixing, suffixing, and hyphenating their way to something unique. The result? cool-http-client-async-v2-tokio-edition — a name nobody can remember.
npm Stepped on This Rake. Rust Is About To.
This isn’t uniquely a Rust problem. Every package manager ecosystem hits this wall once it’s big enough.
Node.js’s npm also started with a flat namespace, and it got worse — JavaScript’s ecosystem exploded earlier and at larger scale. In 2015, a developer famously unpublished the left-pad package from npm, breaking builds for thousands of projects overnight.
npm later introduced the @scope/package namespace mechanism — @angular/core, @babel/parser — using organization names as prefixes. It solved most of the conflict problem.
Go used domain-based package paths from day one. github.com/gin-gonic/gin — the import path carries the hosting location, sidestepping the problem entirely. Java has been running reverse-domain names (com.google.gson) for over two decades.
crates.io remains fully flat in 2026. It’s starting to feel out of place.
DNS Namespaces: Use Your Own Domain as a Prefix
A pre-RFC has surfaced in the Rust community. The idea is straightforward:
If you own a domain, you own a namespace on crates.io.
Say you own mycompany.com. You could publish crates like:
mycompany.com/auth-sdk
mycompany.com/config-loader
mycompany.com/logger
The domain is the namespace prefix. Everything after the slash is yours to name freely.
Individual developers aren’t left out. Got a yourname.github.io? That works:
yourname.github.io/base64
yourname.github.io/awesome-tool
Think of it as upgrading from “one street where every business needs a unique name” to “a city with street names and building numbers.” A noodle shop on Chang’an Road and a noodle shop on Nanjing Road — no conflict.
How Cargo Handles It: The Compiler Doesn’t Need to Know
There’s a clever design detail in this proposal.
Cargo strips the domain prefix before passing the crate name to rustc. So mycompany.com/base64 arrives at the compiler as just base64.
rustc doesn’t need to understand domains or namespaces. It sees ordinary crate names. The change is scoped to crates.io registration and Cargo’s dependency resolution — no language-level changes needed. If a project depends on both the global base64 and mycompany.com/base64, Cargo’s existing rename mechanism handles the disambiguation.
Think of it like apartment delivery: the building number (domain prefix) matters to the courier (Cargo). Once you’re inside the apartment (the compiler), it’s just “kitchen” and “bedroom” — no matter which building you’re in.
.well-known Verification: Proving You Own the Domain
The ownership verification scheme is worth calling out. No complex DNS TXT records, no blockchain signatures. You just put a JSON file on your domain:
https://mycompany.com/.well-known/rust-lang.org/package-namespace.json
This file declares who has publishing rights for that namespace. crates.io checks it once when you first register the namespace.
Choosing .well-known URLs over DNS records has a practical upside: you don’t need a standalone domain. A username.github.io GitHub Pages site is enough — if you can put a file there, you pass verification.
This keeps the barrier low for individual developers. Namespaces aren’t just for companies.
What the Proposal Deliberately Doesn’t Do
What I appreciate most about this proposal is its restraint.
It doesn’t try to stop anyone from registering cool-wasm in the flat namespace, even if you already own cool.com/wasm. It doesn’t promise to resolve every naming dispute. It doesn’t mandate domain prefixes for everyone.
It does exactly one thing: gives you an optional, verifiable, structured way to organize your crates.
This level of restraint is rare in infrastructure proposals. Most die from overreach — trying to solve naming conflicts, ecosystem quality, and trust chains all at once, spreading themselves too thin to do any of it well.
The Aesthetics Debate
There’s pushback, of course.
Some Rust developers find domain prefixes ugly. mycompany.com/base64 doesn’t read as elegantly as plain base64. There’s concern this will make Rust’s package management feel “enterprise-y” like Java’s.
The aesthetic preference is understandable. The Rust community has a tradition of valuing simplicity and elegance, and flat namespaces genuinely worked well in the early days.
But the ecosystem has scaled, and the definition of “works well” scales with it. When a three-year-old empty crate is squatting the name you need, elegance stops being the priority.
npm had the same complaints about @scope/package syntax years ago. Nobody wants to go back to fully flat now.
What Rust Developers Should Pay Attention To
If you’re a Rust developer, how this proposal affects you depends on your context:
Publishing your own crate? Domain namespaces give you a path around naming conflicts. Check what domains you have (GitHub Pages counts), decide if you want to use one as a namespace.
Building enterprise Rust projects? This is almost pure upside for teams — company domain prefixes avoid conflicts and build recognizability.
Just using other people’s crates? Little changes for you in the near term. If the proposal lands, your Cargo.toml might gain a few domain-prefixed dependencies. Usage stays the same.
Want to join the discussion? Now’s a good time. The pre-RFC stage means the community is actively collecting feedback. Developers with opinions on package management should speak up while the window is open.
Found this useful? Follow us on WeChat: 「全栈之巅-梦兽编程」for weekly Rust and AI programming content.
Also check out Mengshou Programming AI Coding Assistant to bring AI coding tools into your real production workflow.
FAQ
Has this proposal been officially accepted?
Not yet. It’s currently in the pre-RFC stage — a “proposal before the proposal” — mainly for gathering community feedback. There’s still a long road to formal RFC status and eventual implementation. But a working proof of concept already exists.
How do I write Cargo.toml with domain-prefixed crates?
Something like this:
[dependencies]
base64 = "0.22" # global namespace base64
"mycompany.com/base64" = "1.0" # domain-namespaced base64
If both appear in the same project, use Cargo’s package rename mechanism to disambiguate.
Are only .com domains allowed?
No. Any domain you can prove ownership of works — .io, .dev, .cn, .rs, even username.github.io. Verification uses .well-known URLs, which are independent of the top-level domain.