First, a foreword: The squatting problem overlaps with many areas, such as:
- security — typosquatting, changes of ownership,
- identity — associating crates with an org… namespace,
- spam/abuse — malicious users who will put huge amount of effort into working around any boundaries, and
- backwards compatibility — any changes have to deal with the 30K existing dependencies and stable Rust.
It's not possible to agree on one solution that fixes all of them at once. We've tried! Many times! A solution that solves only spam is shot down, because it doesn't solve security or identity at the same time, and vice-versa. Trying to fix all things at once creates megathreads that go in circles. So I'm proposing a partial solution that takes a small bite of the problem, and intentionally doesn't touch the others. Fixing one side of the problem does not prevent fixing other sides of the problem in other proposals.
Some people want to reserve a name for their next project before releasing it. That's seems like a reasonable thing to do, especially when there's a risk someone else could squat that name in the meantime. However, the current method of reserving a name by publishing an empty crate has negative side effects:
- If the owner decides not to use the name, there's no nice way to give up the name. Publishing "contact me if you want it" depends on the owner being contactable and handing it over manually.
- A dummy crate is still treated like a real crate, which pollutes the search results, index, etc.
- "Recycling" of such crates requires manual work, which the crates-io team has no capacity for.
- It's risky to delete or change of ownership of published crates.
I think this particular problem can be solved by adding an explicit name reservation feature. On crates-io there would be a form "register a crate", which:
- Marks a given name as taken and belonging to the user (technically: not a crate, but a separate postgres table, checked before
- The reserved name won't appear as a crate in search results until
cargo publishmakes it a real permanent crate.
- If the search query exactly matches a reserved name, the page may show "reserved by $user"
- In the dashboard user can click a button that deletes the reservation, freeing up the name (it applies only to reservations, can't be done after publishing the crate).
- Optionally: there could be a "dead man's switch". The name is reserved for X (6 or 12?) months. At any time the user may click "I still need it" to extend it for further X months. But if the reservation expires, the name becomes available again.
- Optionally: opening a crate page of a reserved name directly could display "reserved by $user", so the current convention of "contact me if you want this name" is preserved.
- Optionally: if user publishes a crate that has
main.rsthat is byte-for-byte exactly like
cargo newtemplate, then reject it and suggest reserving the name instead (this is meant only to help discovering the reservation feature, and catch a mistake of novice users who don't know what
cargo publishdoes, but not meant to stop intentional squatters)
- Cooperative users who just want to hold on to a desirable name can do so, without causing negative side-effects.
- The site doesn't get polluted (as much) with dummy crates.
- In case users are banned from crates-io or GitHub, it's safe to delete their reservations. That won't break any dependencies and has no risk of any supply-chain attack.
- If reservations have an expiration date, a user grabbing lots of names and disappearing won't be a problem.
- It gives an officially sanctioned way to "squat" crates. Squatting is hard to define, but this creates an implementation-defined definition. No need to ask the crates-io team about what is permissible: if the reservation form allows it, it's allowed. Initially, I'm not proposing adding any limits (like max names per user), but if reservation gets abused, it'll be possible to address such abuse in a programmatic way.
- It's scalable. In terms of work for the crates-io team it's closer to O(1) than O(n), as it doesn't require any per-crate moderation, dispute resolution or crate cleanups.
- It does need code to be developed. It's mostly a one-time cost, which may be done with help of outside volunteers.
- Like all code, it will have an ongoing marginal cost of keeping it running. Hopefully, it's a simple enough CRUD feature that this won't be a big burden.