# Crate name limits RFC

- Feature Name: crate_name_limits
- Start Date: 2021-04-02
- RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
- Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)

# Summary
[summary]: #summary

Crates.io is a shared community resource with a first-come-first-served policy for crate names. The
community values one-word crate names (without any hyphens or underscores) more highly than
multi-word crate names. Allowing people to take large numbers of one-word crate names isn't a fair
distribution of the shared resource. Each user account will be limited to `N`* one-word crate names
unless there are extentuating circumstances that sufficiently motivate a user being allowed to have
more than that.

\* `N` to be filled in before finalizing this RFC. See [Alternatives][#rationale-and-alternatives]
for discussion on various values of `N`.

# Motivation
[motivation]: #motivation

The Crates.io team is made up of volunteers with limited time. While using automated tools to
reserve crate names is [already against Crates.io policies][policies], it takes volunteer time
to detect, stop, and clean up when someone reserves large numbers of crates. It would save time to
have limits enforced automatically that limit the damage someone can do to the shared resource,
without limiting legitimate use of Crates.io.

[policies]: https://crates.io/policies

If someone has a project that has a large number of related crates, those crates should share a
common prefix like the [`rand` crates][rand] all start with `rand_`. The community sees such names as "less
valuable" than one-word names, so limiting the number of multi-word crate names that each person
has would limit legitimate use and not protect the common resource of valuable names from abuse.

[rand]: https://github.com/rust-random/rand

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

Draft of the text that would be added to the Crates.io Policy page:

> As a user of Crates.io, the Rust community package registry, you may have up to `N` crates that
> are named with one word (that is, the name doesn't contain any hyphens (`-`) or underscores
> (`_`)). If you try to publish more than `N` crates, you will get an error message that you are
> over your limit of one-word crates. Please choose a name containing hyphens or underscores,
> especially if you are publishing many related crates: many projects that are made of multiple
> crates start all the crates with the same prefix to indicate they're related.
>
> If you have `N` crates with one-word names and need an exception to this policy, email
> `[e-mail]` with your circumstances to discuss possible options.

Draft of the error message you would get if you try to publish `N + 1` one-word crates:

> Crates.io users are limited to `N` crates that are named with one word. You have reached this
> limit. Please change the name of your crate to include a hyphen (`-`) or underscore (`_`) to
> be allowed to publish your crate, or email [e-mail] to discuss a possible increase to the
> number of crates you may have.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

There are always users who try to push limits and will obey precise rules but not the spirit behind
these rules. For example, if we were to enact this, a person could create multiple GitHub accounts
and have each account publish N one-word crate names, which would still claim many "high-value"
names. We would reserve the right to lock accounts of users who appear to be engaging in this
allowed-but-disruptive behavior.

If someone emails `[e-mail]` to request more crate names, we would look at the `N` crates the
person has already posted and see if they are generally useful crates with substantial code,
reverse dependencies, and significant downloads, or if they are merely "hello world" crates used to
claim the names. We would be likely to increase the limit for people with `N` useful crates, and
likely to deny an increase of the limit for people with several "hello world" crate reservations. Those
people could use multi-word names or repurpose a name they already own. We would have to implement
a way to override the name limit on a per-account basis.

People emailing `[e-mail]` because they're over the limit might like to give up some one-word
crate names they're not using. There's not a great mechanism right now, but a workaround would be
to transfer the crate to a member of the Crates.io team with a description that the crate name is
up for grabs to the first person who asks us for it. We could also create an account specifically for this purpose, much like GitHub's `ghost` account to represent deleted users. This is an ad-hoc mechanism that we've been
using that has been working well enough for now; we may want to separately consider adding a
mechanism for abandoning crates and claiming abandoned crates to make this process less labor
intensive. It's relevant to think about in this RFC because the crate name limit might increase
these requests.

This limit would only apply for crates the account owns as a user; this would not apply to crates
an account has access to by virtue of being on a team (team membership is currently managed by
GitHub). Crate owners can only be changed by user owners, not team owners, so each crate must be
counted under at least one user owner. In other words, you would not be able to claim a bunch of
crates and then transfer them to a team you're on; that would remove your access to manage that
crate's owners (and the last user owner can't be removed).

We would not take any crates away from users who already own over N one-word crates at the time of
implementation, but they would immediately not be allowed to publish any more one-word crates.

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this?

- Emails to `[e-mail]` may increase
- Even reserving `N` one-word crate names may be disruptive to the registry
- Some people see limits as invitations to test those limits, so we may see an increase in the
number of one-word crates being reserved
- We'd be outsourcing duplicate account creation to GitHub. GitHub does a pretty good job at
detecting when one person is trying to create multiple accounts, but if we add other ways of
authenticating to Crates.io, that could open more avenues for someone to claim more names
even if this policy is enacted.

# Rationale and alternatives
[rationale-and-alternatives]: #rationale-and-alternatives

- Set N = 10, something very low, to further limit the amount of one-word crate names that it's
fair for one person to have. However, this may increase the number of requests to
`[e-mail]` to give up crates or get an exception to the limit, which takes up volunteers'
time. Also, the number of people immediately over the limit would be large. If we set N = 100,
there are currently only 7 users who would immediately be over this limit.
- Set the limit to N *per an interval of time*, such as 10 crates per calendar year. If you
published 1 crate in a year, the remaining 9 would not "roll over" to the next year; older
accounts would have no advantage over newer accounts. This may lower the number of requests we
get for increases to the limit, as it's like giving everyone an automatic increase every year. I
have a hunch that crate publishing is "bursty" though-- that people publish a bunch of crates at
the same time and then no crates for a long time-- so I'm not sure how well this limit would fit
with legitimate Crates.io usage. It would also probably cause unintended side effects like a
"land grab" on New Year's Day, which may not be what we want. I would want to do more study of
current crates.io behavior before implementing this.
- Implement the ["Packages as Optional Namespaces"
RFC](https://github.com/Manishearth/namespacing-rfc) (not yet an official RFC), which may help
with the problem of valuable names being used up, as it also encourages people to name related
crates with some separator. Nothing prevents us from implementing both this RFC and that RFC,
though!
- Implement namespaces in some form, which brings a lot of complexity to the ecosystem and to
Crates.io. Depending on the exact implementation, this would likely move the target of what is
"valuable" to the names of namespaces rather than the names of crates, thus not actually solving
the problem. Namespaces have been discussed many times before and any discussion on this RFC about
introducing namespaces as an alternative solution to this problem will be marked as off-topic.
Please keep discussion on this RFC to why this would or would not be a good proposal or suggestions of
solutions that have not been explored previously.

- instead rate limit any new crate publish
- leave open exact value of N, leave it up to our discretion

# Prior art
[prior-art]: #prior-art

I am not aware of any other package registry site that implements exactly this restriction.

- [NPM](https://www.npmjs.com/) introduced [namespaces, called "scopes"(https://docs.npmjs.com/about-scopes/), but does not place a restriction on the number of unscoped packages of any kind a person may have.
- [Rubygems](https://rubygems.org/) does not have namespaces or restrictions of the sort proposed here, and has successfully existed for about 10 years longer than Crates.io has.

# Unresolved questions
[unresolved-questions]: #unresolved-questions

- What should `N` be?

# Future possibilities
[future-possibilities]: #future-possibilities

- The ["Packages as Optional Namespaces" RFC](https://github.com/Manishearth/namespacing-rfc) would
be a way to make related crate naming more ergonomic and thus encouraged. It would fit well with
this RFC.