Uhmm it is a tradeoff. a few years later we might end up with a huge pile of abandoned crates which means that most names will be taken and we have to resort to namespacing.

The only downside being is that users might get confused and use a new crate thinking its the old (especially for more common names) but we can come up with a way of “deprecating a crate” (and ammending the “no delete policy” to allow deletes for abandoned crates).

Let’s enumerate kinds of problems that we’re potentially dealing with.

  1. Malicious squatting — someone takes names without intention of using them for their own projects (e.g. to annoy people, block someone’s project, make crates-io less useful, or to have collection of names with hope of some future control or profit).

  2. Malware/typosquatting — taking popular or confusingly similar name with goal of tricking people into installing the code. e.g. tokyo-tls instead of tokio-tls.

  3. Spam — a garbage crate that is abusing readme or metadata to get crates-io users to visit/buy something, or some misguided SEO, rather than providing useful Rust code.

  4. Reserved in good faith — someone may hope to work on some project in future. They may eventually publish some code, or they may never get to it.

    4a: Reserved as a defense against typosquatting.

  5. Abandoned trivial projects — there’s a chunk of abandoned crates on crates-io that appear to be someone’s “hello world” or some first attempt at making a crate. These are usually unfinished crates v0.0.1 that someone published as a test and never came back.

  6. Abandoned real projects — crates that were useful, had users, but are no longer maintained. Possibly bitrotten.


That’s what namespacing is about. The problem is you end up having a redundant namespace especially for organisations (e.g. uuid/uuid). If you make it optional there is a bit of inconsistency

You could link up the organization/namespace with a default (sub)crate, making “uuid” a “symlink” to “uuid/uuid”.

Further allowing e.g. “uuid/sys” as, well, that…

1 Like

Better the inconsistency than no namespacing.

For example, allow both rand and rand/core (and rand/chacha etc.); I feel the confusion is out-weighed by the advantages.

1 Like

I don’t see why that shouldn’t be permitted.


I just don’t see this as clear cut as you seem to. You’re saying, “We can all agree that…” but, I don’t think that is necessarily the case and can’t be taken as a given.

1 Like

Wouldn’t it be: rand,core/rand, chacha/rand? So, whoever registers a top-level name, like for example tokio, they would then be the only person/organization able to create crates beneath that like, tokio/net, tokio/disk, tokio/fs etc.

While namespaces do provide one way out of this problem, the policy has always been that namespacing would introduce problems of its own. Since improving on the squatting problem does not require namespacing, I feel discussion of any namespacing avenues in this thread (about squatting) is basically off-topic for this thread. If you want to pursue some variant of namespacing, please do so in a separate thread.


I think before you say what is and what is not an appropriate solution to the problem you must first clearly define the problem. To me, “Squatting” isn’t clearly defined yet. That needs to happen first before you can have a reasonable discussion about what is and what is not the appropriate solution to the problem.


Full disclosure: I myself have one crate in the fourth category. Someone on reddit suggested a time-limited reservation system: release version 0.1 within X months or you lose the name. Of course, this doesn’t prevent problem types 1-3 because you could just put in random code, but it may provide motivation for people reserving names in “good faith”.

I’m also not sure where things like @carllerche squatting tokio-* fall in your taxonomy. If @withoutboats is correct that some of them are reserved without the intention of writing a crate, I don’t understand the motivation behind that.

I totally understand the motivation. It is a symptom of the fact that does not support name-spacing. Because of this, if you want to prevent a bunch of closely named crates that could be published for malicious or misleading purposes to associate with the “brand” of the crate, you have to reserve variations/sub-names to ensure others don’t use the name recognition of “tokio” to either push unrelated or malicious crates.

1 Like

I get that part. But it’s bad for users. If I have an idea for doing something involving tokio and compression, I might search for “tokio deflate”. As of today there are two results: squatted tokio-deflate and a crate involving websockets that seems irrelevant. The existence of this squatted crate gives a user no indication of whether tokio-deflate is being worked on, has any intention of being worked on, is feasible at all, etc.

There’s a separate question of whether @carllerche has a “right” to the tokio-* prefix at all, but let’s not discuss namespacing here, it’s even more of a dead-end then a squatting policy.

Yeah, I don’t think namespaces are the solution. They help in one case, but the rest is “meh”:

  1. If arbitrary namespaces are allowed, they don’t solve malicious squatting at all. Instead of squatting crate names, the battle is now for good namespace names.
    If namespacing is “outsourced” to GitHub (or DNS or someone else) that solves the problem only in the sense of making it someone else’s problem and squatting happening on someone else’s site first.

  2. Typosquatting is partially solved, but still possible, so tokyo/tls can be done. tokio/tsl is prevented.
    If namespaces are based on usernames, typosquatting may get worse, since it’s harder to remember spelling of username than just projectname (e.g. winapi crate).

  3. Namespaces don’t do anything for spam (I’m assuming spammers want traffic or SEO, so they can still keyword-stuff their namespace names and drive traffic to namespaced garbage).

  4. People may still want to reserve namespaces in case their personal project grows big, or to have something nicer (project-name/project-name rather than my-silly-username123/project-name).

  5. It would help a lot for trivial/toy projects that would be dormant under someone’s personal namespace.

  6. Not very helpful for abandoned real projects. It’s still a good name(space) taken.


But, what if the “No Name-Spacing” policy is inadvertently encouraging and proliferating “squatting”? Then, doesn’t it need discussed in reference to “squatting”? I would think so. Separating the two issues seems fraught with problems because it is my contention that the “No Name-Spacing” policy feeds the “Squatting” beast.


I would call this a BIG IMPROVEMENT™. For example, spot the typos that might be typo-squatted maliiciously:


Now, how hard is it to verify you haven’t inadvertently included a typo crate name when tokio:: is reserved to one owner vs tokio- being open to anyone or anything (as below)?


With a quick scan of the above lists, where tokio:: is reserved to one person/organization and tokio- is open to the world, how sure are you you haven’t made a typo that will give you a typo-squatted crate?

My contention is, that in the first case, it is easy for you to scan the list for outliers (and it can even reasonably be linted against) whereas in the second it is somewhat of an ordeal to verify.

1 Like

I would contend that they do. They force “spammers” to register a top-level name (which can be limited as I’ve described in an earlier comment through an increasing fee-schedule) which can then be easily revoked/banned if they are found to be “spamming” and meanwhile, their “spam” isn’t associated with a legitimate crate “brand”.

NOTE: That because the first few “Top-Level” names are free to anyone and you can create any number of sub-name-spaces of a top-level name-space yourself, legitimate users will likely never need to pay a dime.

Yes, and there should be nothing wrong with that, within reason. Hence the possibility of an increasing fee schedule for more top-level names registered to the same person/organization.

This problem will always exist. At some point, it will likely become necessary to define “abandoned” and a policy for reclaiming the name-space.

Making accounts paid would dramatically lower ROI on spam, but that’s the payment part helping, not the namespace part helping. You can still ban all crates by a spammer by banning the account (and limit account registration as much as namespace registration), even if that account name is not part of the crate name.

I assume deletion of garbage spam crates is uncontroversial, so even if spammers take good names/namespaces, these could be reclaimed, so that’s not a big worry from perspective of squatting, as long as crates-io team is willing to act on this.

That’s my point.

OK, under name-spacing, you would name your crate: “oneofyournamespaces::subnamespace::subnamespace::tokiocompression” (or something like that). You wouldn’t need to worry about “searching for an available name that was appropriate”. You’d just create it.

1 Like