Namespacing on


Registration of prefixes is a different operation than publishing of a crate, so they could still have different rate limits.


Organization name. Re GitHub antispam:

Yes, beyond mere rate limiting, GitHub actively monitors for all sorts of suspicious behavior including spam, and will flag/lock accounts which appear to be doing spammy behaviors. While could probably benefit from a system (or failing that, exponential backoff rate limiting), GitHub gives it to you for free today, along with many other features.

GitHub already provides all of the functionality for organization membership management, which is ultimately an access control function. From a security perspective, outsourcing this functionality to a “tried and tested” system is much less risky than trying to greenfield it all.

The set of members of any organization is sourced as OAuth users from GitHub, so any system that manages organization membership for is ultimately building on top of GitHub’s user model anyway.

I understand and sympathize with concerns about centralized systems, but has already gone down that road, and that’s unlikely to change any time soon.


Use of GitHub login and ability to give crate ownership to a GitHub Org already gives this spam protection and user management.

But GitHub is kept one level of abstraction away from crates and their dependencies, so crates-io can add support for other account types, and even migrate off GitHub if that turned out to be necessary.


I think it’s possible to retain this property for organizations sourced from GitHub as well


I’d consider that a deal-breaker with respect to immutability of crates/name-spaces.


Renaming a GitHub organization does not necessarily require a corresponding change on the side.


A general suggestion to everyone working out the details of a namespacing proposal – you should create an FAQ in whatever RFC becomes of this. This discussion here is quite long and high-velocity, making is difficult to keep up with all the changing details.

I would guess the most commonly ask questions would involve existing crates with hyphens in their name.


The minute you do this, people will start complaining and (rightfully) demand that other IdP are also accepted.

So your system would turn from

cratename // global namespace


somegithuborg-cratename // your proposal



in no time.

When we have arrived at that … what’s exactly the difference to doing the simple, obvious thing … and using domain names from the start?

I think it’s not that onerous to send a HTTP GET request to some host and check the reply.


A similar idea that would allow other uses to continue publishing using any name they can today is [Pre-RFC]: Packages as Namespaces.


GitHub has already been the IdP for for several years.

See the third bullet point in this post (where I contrasted using GitHub Organizations vs DNS names):

Sourcing organizations from GitHub as IdP provides organization membership “for free”.

Now don’t get me wrong, I think domain names are a good option too, and for me they’re probably my number two preferred option after GitHub orgs.


The fact that GitHub doesn’t care about names and allows renames means it’s infeasible for cratesio to track names on GitHub. It can perform a one-time copy of the name and then associate GitHub org id with that name.


  1. Register GitHub org “foo”
  2. Register cratesio namespace “foo”
  3. Rename GitHub org “foo” to “bar”
  4. Cratesio can’t handle renames, so it keeps the name “foo”, but still has to allows the “bar” org to manage it. It’d be silly if rename on GitHub locked org out of their packages, and matching by name would be insecure because someone else could rename to “foo”.

And there’s a question whether renamed “bar” org on GitHub is going to be allowed to register “bar” namespace on cratesio. It’s using that name on GitHub, but if it can register more, then that’s one org to many namespaces mapping. If not, then the “bar” they want is impossible to register.

So in the end it seems that the best cratesio can do is to have the same level of indirection between GitHub orgs and namespaces as it has between crates and GitHub orgs: the namespace, like crate, is an independent entity living on cratesio, and GitHub orgs can be added to it to manage it.


Sounds ok to me.


Just for clarity:

In this model, can an individual user be registered as a crates org?

I think it might be useful to create “Corgo” that translates a [] into “real” (git? path?) Cargo dependencies as a proof of concept. It’d be useful to have something to point to and say “hey this scheme actually works”. (If my “pun” name isn’t desired, cargo org or similar works too, ofc.)


This seems all to be extremely over-complicated, especially compared to the domain-based approach:

Basic task: I want to publish my dirs crate under the

  1. I add organization = "" to my Cargo.toml.
  2. I run cargo publish.
  3. The command prints the following text to the console: couldn’t verify that you own soc.github.ui. To prove ownership, place a file named “domain-owner” with the following text at your domain root: ZG2ioiTY3tMgwDYfmb6p

  4. I place the file “domain-owner” with the randomly generated string at `
  5. I rerun cargo publish. checks that the string matches and publishes the crate under the namespace.

That’s it. Super simple. No dependency on any specific service, no fancy IdP stuff, no “how to organize organizations” problems. Everything keeps working exactly as it is now – the setup is even simpler than cargo login.


To be explicit:

Then, after the first crate publish, would there be any further check of the domain?

I just realized that this could be a one-time check. At first cargo-publish of the crate, that crate is created on crates-io, iff ownership of is confirmed.

After initial publish, this org key is only used to identify the crate in question, and the accounts with publish permission is handled as it is today. The domain ownership key can even be removed, as its only use was the one-time association.



I would check it on every cargo publish to make changes in domain ownership both seamless and very obvious.


Also, tying each random string to a specific user account means that in projects where different developers work on different crates, each developer could have publish rights only for his own projects.

And individual permissions to publish under some domain could easily be granted or revoked (by adding/removing that developers’ generated random text string in the domain-owner file).


How do you manage which other users are members of your organization?


So you can add other publishers to the file on the domain, and publishers for a published crate are handled as they are today.

(EDIT: Discourse didn’t show this the way I wanted so let’s do it manually)


“is a member of an organization” == “can publish to a domain” == “has an entry in the domain-owner file”


My understanding of your proposal is you’re suggesting users do the following to register an organization:

  • Register a domain
  • Configure a web server (for the following two items below)
  • Perform AuthN against via what is effectively X.509 DV
  • Publish organization membership via a file served from the domain (via HTTPS I assume? so they’ll need an X.509 certificate as well)

Regarding your earlier comments above complexity, the above seems relatively complicated to me, especially when the user’s goal is merely “create a organization and publish a crate”.

Furthermore this provides relatively poor UX, and additional attack surface versus just using the IdP already uses (i.e. GitHub).

Where GitHub provides a point-and-click experience with strong authentication (e.g. U2F) and active monitoring for suspicious activity, the method you’re describing requires a lot of backend sysadmin work solely for the purposes of authenticating an identity with

I would personally prefer the point-and-click experience.