[Pre-RFC]: Author Attached Crates-io Names

This Pre-RFC summarizes and is inspired by existing discussions on crates-io crate namespaces. It extends existing ideas to allows crate owners to attach author identifiers prior to project names, to avoid name collision with existing crates. The new naming system may coexist with the present one for backward compatibility. The document also declares how crates should be quoted as dependencies in cargo-toml configurations.

RFC expects to solve possible software security issues and name rush-register problems, and expects to help developers choose high quality crates.

Rendered: https://github.com/luojia65/rfcs/blob/author-attached-crates-io-names/text/0000-author-attached-crates-io-names.md

This is such well trodden territory that i was able to make a long list of other related posts the last time I saw it


Any new proposals should say why this solves problems that previous proposals didn't (note: I didn't read the RFC, so this may have been done this time)


If it's not a huge problem on domains level (not huge enough to change something), it's not enough big problem for creating issues on crates.io level.

Every "Pre RFC" about crates names brings proposals to create some additional requirements, some issues, some fences and obstacles. Most sensitive to them are new Rust users, so I always vote against any fences in this field. Rust have enough issues for newbies.

Can you explain how this is better than the domains-as-namespaces proposal?

I think this one fails the requirement of "does not expect that crates.io maintainers to do more work".

Also, it assumes that – given a "brand name" – there is only one company that could demand it (which is obviously not the case).


I couldn't find how you handle handover of crates. Like when moving crates from your personal account to a group of maintainers.

I think it's something I really want to have. The name conflict I think should be finally a serious problem. Once instance for this is:

The crate jemalloc is a low quality wrapper for jemalloc, undocumented and not maintained. And the first time I want to use jemalloc allocator, I just add that crate and not working. But the correct crate should be import is jemallocator which isn't a good name for it in my opinion.

In long term, I believe this would finally become a problem if there's nothing to prevent people occupying meaningful name meaninglessly.

There are a lot of well-known term which is squatted by meaningless crate already, I don't think the long term solution should be leave them there forever.

I do really think it's better to make all crate have user::crate namespace and some community adopted crate can have a top-level alias. And the top-level alias is maintained and reviewed by the crates.io team. (And I believe this is what Docker Hub is doing)

Another benefit would be people can have their own fork of some existing crate published under their own name. But currently it's very hard to have that.

But the problem is this will fundamentally break to most of existing code and introducing extra maintenance burden.

What I am saying is not suggesting any change, but I think there would be some issue in the future if the community keep growth.


Is this particular issue perhaps a problem with crates.io emphasizing exact matches for crate names? For example, compare and contrast:

One fix for crates.io might be to still put some emphasis on an exact match but allow a few other crates to appear above it if they rank higher.

1 Like

Searching is one thing, but naming is another problem. Although people can find what they need by having well maintained crate index. However, the name loss its self-documenting function is really a bad thing.

If jemalloc is the exact crate to use jemalloc, I can just add it to manifest file without any crate hunting step. The concern isn't people can't find it, but people have to use bad name for their high quality crate. I am quite sure people who see jemallocator can easily guess what it's used for, but I mean this is an additional burden to developer, ideally this should be avoid.


Personally, I like the idea of user/name crates by default and a curated top level for recognizable and widely adopted libraries (that either are a canonical implementation with the generic name and some promise of continuing support, or a "brand name" for noncanonical crates). The code level actually wouldn't see a difference, just the metadata.

However, this just won't work for crates-io. Why? Because of legacy crates and forwards/backwards compatibility. The current crates would need to keep their top level name, and would gain an unfair position given their "curated" position without actual curation.

Plus, it adds a whole new "attack surface" and community cost to the actual curation of top-level names.

For the immutable registry that crates-io, the first-come-first-served naming policy is actually a very decent local maximum. Unfortunately, we might be stuck with its drawbacks because the effort involved in finding another local maximum and transitioning to it is more than the crates team can afford at the moment.


I thought about this, there might be a workaround for this actually.

We can actually introduce a new configuration in the Cargo.toml which defines the "default user". Let's say cargo will find the crate under "default user" before actually find under the root. And we can have a virtual user which is mirror of the entire site. And by default the default user is set to the virtual user, thus any existing code still compiles with the new system. However, the newly added code can gradually adopt the new pattern and finally we can deprecate the virtual user.

I think that might be one possible workaround.

I'll admit that pulling in crates without researching them at all is something that didn't even occur to me so it took me awhile to grasp the concept.

I think that Cargo should ideally do something to dissuade this practice. Does it not already require a valid version?

You can use wildcard for the version for sure unless you publish it. But this requirement actually this is one reason why cargo-edit exists - You don't need to go to crates.io to check what is the latest version is.

1 Like

Yes I'd love the idea with Docker Hub. Top level crates are convenient for users to find but should be handpicked by the community and the Rust team.

I think this will work well for you:


awesome-library = { package = "luojia65-awesome-library", version = "0.1"}

Or modify the lib name in your crate:


name = awesome-library

And then other developers will have exactly 0 motivation to create something else even if they know how to do it better. We should have a competition, it's vital for quality.

I don't get the point, why motivation is related to putting their name as namespace for their own crate?

In your case, people can actually use a name different its competent and push hard to make it a global alias. Because of the higher bar for the global name, it's actually more option for the later comer to adopt a proper name. Currently a lot of name is used by squatters and I don't think this gives people any motivation to make better crates. But this do gives people motivation for squatting names for later use. (And I personally did a little bit of this, since I have my own project specify crates that I may be publish later but now I have to squat it unfortunately) And this doesn't give me any motivation to make anything better

Actually, people is motivated to make community adopted crates in this case and the Rust team have more control on if we should give the community more stimulation by adjusting the admission bar of the global alias.

Making things out of control isn't a solution that make people motivated.

Because when there is already existing "community elected" crate, it creates inequality - people will use what is "community elected" and give not enough attention to alternatives.

But this is happening anyway right? Adding author name to crate doesn't actually change this. Today you can still see a lot of dominant crates. If the Rust team lower the bar for global alias admission, there would be quite a lot crate is eligible for the global namespace.

For early stage crate even today there's a visibility issue. Plus if the global alias exist, I am quite sure high quality crate would quickly get the ticket to the root namespace and have even better visibility. However, for today's situation, some awesome new crate is soaking in a ocean of randomly created, never maintained crates. And I think this is the number one inequality for all serious crate authors.

From the RFC:

There could be methods to protect names, but trademark or patent protection may only apply to project author names, but not project names.

That's not how I understand trademark to work, and we don't have the power to change that.

For the idea overall, if you want to name your crates yourusername-yourpackagename, as @jmjoy suggested, there's nothing stopping you from doing that today.

Furthermore, transferring of crates from one person to another, as @proc mentioned, would need to be addressed. I see the "alias" section, which covers publishing, but how would I know one crate was an alias for another if I'm looking at crates.io?

This also doesn't take into account that today, crates.io accounts require GitHub accounts, but might support signing in with other accounts in the future.

I think the "Downsides" section contains great points, but I don't see justification for why those downsides are acceptable in relation to the downsides of leaving crates.io the way it is currently.

No, right now there is no any "community elected" badge or global namespace privilege.