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 publish),
The reserved name won't appear as a crate in search results until cargo publish makes 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 lib.rs/main.rs that is byte-for-byte exactly like cargo new template, 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 publish does, but not meant to stop intentional squatters)
Costs/benefits:
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.
I think the most useful piece of this proposal is the idea of marking crates as reserved. Because then users could at least filter them out of search results. Other than that this doesn't prevent anyone from name squatting; it just makes it so they have to run a con job once a month to make sure they don't let their ownership lapse.
It also doesn't stop people from publishing dummy packages that "look" real enough.
Other than that this doesn't prevent anyone from name squatting; it just makes it so they have to run a con job once a month to make sure they don't let their ownership lapse.
Note that the expiry was described as optional. The primary thrust of the idea is semantically separating actual crates from reserved ones.
It also doesn't stop people from publishing dummy packages that "look" real enough.
But it does give solid grounds for identifying something as abusing the service if they're actively ignoring the reservation feature in favour of publishing dummy crates, should the crates.io people want to do so.
I hope that the fact that a GitHub account is required to publish on crates-io is considered to be a limitation that would ideally be lifted, rather than a permanent feature.
I certainly think crates-io shouldn't be outsourcing questions about whether an individual should be banned to GitHub.
Currently crates-io doesn't send any e-mails. Once it has such capability and a way to manage reminders, then this could be added.
It's allowed, and will likely remain allowed, because it's not something that can be enforced automatically. Crates-io doesn't want to have policies that create manual labor for them.
But if someone reserves lots of crate names with an intent to sell them, that's still less bad than publishing lots of garbage crates for the same purpose.
…or GitLab, or Gmail, or Fastmail, or their chosen OpenID provider, or they decide to close their crates-io account. The point is that users come and go, but (non-fake) crates are supposed to be available forever. There's definitely more to be done around account management, but it's a whole another problem.
As a member of the crates.io team but only expressing my opinion, not that of the team: in general, I'm not opposed to this idea if someone wants to send in the code for it. I'm not sure that the problem it solves is particularly important to people compared to other problems people have with crates.io, but I'd be fine with this.
Thank you for putting in the work to narrowly define an incremental solution that doesn't increase the amount of manual work that the crates.io team will need to do on an ongoing basis!
Today, if I want to check if a crate name is available, I search for the name I want. If I'm reading this correctly, with this change, I could do a search for a crate name, not get any results, and then I'd go to use the crate name and get an error message on publish that the crate name isn't available because it's been reserved (and does that error message say who has reserved it?)
So I think this proposal could use some more detail around how someone would go about finding out if a crate name is taken, reserved, or available, and some more detail about what the error messages will say.
Yeah, I think this is exactly right -- I came up with a very similar idea when reading the other thread. I do think reservations should lapse by default after some time, especially if we have the means to send an email some time before that will happen. (Maybe do some cascading scheme, where the reservation will lapse after 6 months but can be extended once or twice for 3 more months.)
In addition to the other excellent suggestions to solve this, I would say that a reserved crate should not be hidden if it's name exactly matches the search query. It should just be colored and/or labeled differently.
That makes sense, but you don't want to risk confusing first-time visitors if you can avoid it, so I'd go beyond just coloring/labeling it differently and use a different template for its entry. Something visibly more minimal to acknowledge the fact that it's just a reservation.
Would something like this be enough? Granted, you'd want to add a blurb next to the Displaying 1-10 of 349 total, something like (including 15 reserved crates) along with a checkbox to control whether you display reserved crates or not, maybe labelled hide reserved crates, that could be saved as a user/cookie preference?
While the solution seems ok in theory, I fear this feature may be too confidential to be actually useful. Most of the people may keep publishing empty crates, just because they don't know about the reservation feature.
There should be some kind of warning for users who try to publish a nearly empty crate. It would advise them to reserve the name instead.
Thanks for the feedback. I've updated the proposal:
Displaying reservations on exact match seems useful for people who want to check if a name is available, while still not polluting searches for keywords, substrings, etc. The matched name could be less prominent than a real matching crate, but that's a design detail that can be tweaked.
Blocking of the laziest cargo new && cargo publish could be a good reminder to use this feature, and may also catch a few hello world crates from novice users who are just playing with cargo and looking what the commands do. I'd rather keep it simple, because generalized detection of "empty" crates is like spam detection, and it'd be an endlesss cat and mouse game.
I think this "reservation" idea is a good one and a minimal step in the right direction. I myself, "reserved" a number of names on crates.io for an idea I had, but, I haven't been able to get to it the way I wanted. I somewhat regret having "reserved" them. I do believe what I reserved is friendly to the ecosystem in that I reserved a whole set of names all beginning with the same "mybigprojectidea-" prefix, so, I don't think it actually pollutes crates.io.
That being said, if this feature had existed when I did that, I'd have preferred to use it.
So it seems like this thread is full of support for adding this. And we can have it if somebody takes the time to implement it? Has anybody started working on this?
