Limit the number of crates one user account can own, with per-user overrides

[carols10cents]

Currently, a user can theoretically own an infinite number of crates, as long as they stay under the new crate publish rate limit.

We could limit the blast radius of some spamming by limiting all user accounts by default to a concrete number of crates. We should look at the number of crates users currently own and pick a value that covers something like 99% of current users.

Before enforcing this, we should have a per-user-account mechanism to set a higher limit for particular users (the 1% that would currently be over the limit, although we could leave those as-is and they just would immediately be prevented from creating more crates, this needs to not cause any errors though), like we have for max upload size and new crate burst increases so that people with legitimate needs could contact us and explain the situation to get an increase.

[LawnGnome]

I quickly threw together some numbers for users (for now, I'm excluding teams).

No huge shocks in terms of what the distribution of the number of crates owned by a user looks like:

Percentiles of the number of crates owned by a user:

25th percentile: 1
50th percentile: 2
80th percentile: 4
90th percentile: 8
99th percentile: 42

Raw numbers of users with at least n crates:

Number of users with at least 20 crates  :  975 (3.4% of all users)
Number of users with at least 50 crates  :  205 (0.7% of all users)
Number of users with at least 100 crates :   66 (0.2% of all users)
Number of users with at least 200 crates :   20 (0.1% of all users)
Number of users with at least 500 crates :    3 (0.0% of all users)

I'd probably suggest setting the initial limit at 50?

[Eh2406]

(I am not on a crates.io team, but) I would suggest that the limit could in fact be lower than 50. Some of those 200 users are spam accounts that have since been shut down, others are users who should be given a exception from the very beginning no matter what limit we pick. Now that I've said that I see the critical word initial, 50 seems like a good place to start to see if all the systems are working correctly with plans to lower it after initial testing.

[ToBinio]

I don't know if I am the only one, but publishing something on crates.io already feels kinda "scary". simply because of the permanent nature of crates.io.
I do believe adding another limitation and making every single publish be even more important feels very uncomfortable.
simply because the rust-std library is very small and so rust heavily requires active crates development. Making the entry border for such development harder could in my opinion harm the ecosystems.

Don't get me wrong, I am 100% pro doing something against crate-spamming.

but maybe there should be some possibility for removing a crate you already publish so it does not count toward the limit. I am not talking about a 100% deletion system but maybe you can mark a crate as "free to take" and then anybody who wants the name could take it. this would create some sort of second-hand shop for crate names.

[carols10cents]

@LeoniePhiline Please report these to help@crates.io; this is not the appropriate venue. Thanks!

[epage]

rust-lang/rfcs#3452 would take a tiny bit of pressure off of crate counts.

With rust-lang/rfcs#3243, would the cap be for top-level names?

[carols10cents]

With rust-lang/rfcs#3243, would the cap be for top-level names?

Exactly, with crates-as-namespaces, we'd make the top-level name cap pretty low and then sub-crates very high or unlimited.