Crates.io squatting

tools and infrastructure
108

Isn't that desirable? So someone reserves some names and doesn't use them. Then Rust becomes really popular and some organization wants one of those names and that person offers to sell it to them. Is that so horrible? I'm not able to envision a scenario where it effects me in any meaningful way. So, I want to name my crate "super-duper-scooper", but, someone has that name reserved. I decide to ask them for it. They say no, but, say they'll sell it to me. If I have trademark on "super-duper-scooper" I can take them to court and get the name that way (most likely). If I don't, I have no more right to that name than anyone else. If I really want, and that person is willing to sell it to me, and I"m willing to buy it, what's the problem?

Now, in MY case, I'd just pick a different name, like: "uber-duper-scooper" or "superty-duperty-scooper" and be done with it. What care do I have that someone else has a similar name reserved.

All that being said, I'd still prefer if we could register a "Namespace" and then be able to create as many packages/sub-packages within that "Namespace" without having to worry about similarly named top-level only names.

So, to me, focusing on "Squatting" is not really anything useful. Focusing on "namespacing" seems much more useful.

2 Likes
109

That depends on one's political (i.e. socialism, ...) inclinations and IRLO isn't the forum for discussion those...

110

I'm not certain how you can separate out something like this. The whole term "squatting" is a value judgement and not much else. It's 100% about how you view the rightness/wrongness of it. There is little to be said one way or the other from a technical perspective. I just don't see how you have have a thread called "Crates.io squatting" where it is being debated whether there should be overseers who police the allocation of names on crates.io without getting into the politics and morals of the issue. Just because things are sometimes uncomfortable to discuss does not make them "inappropriate". In fact, ending a debate based on that seems "inappropriate" (to my mind).

That being said, I understand where you are coming from and I'm definitely not in favor of this becoming a huge moral/political/philosophical debate. I guess that's why I argue that focusing on "squatting" (a value judgement by its nature) puts emphasis on the wrong thing. Better to focus on "name-spacing".

Just my 2 cents. Please don't take anything I've said to be intended to be in ANY way dismissive of others' concerns.

1 Like
111

I think you cannot separate the two wherefore my inclination is that crates.io should continue to not have any policy against "squatting" annoying as it may be sometimes.

I'm not saying one should never discuss political or ethical matters in tech. In fact, the CoC is such a political document that establishes a baseline of ethics for the Rust community, but even arriving at that document was not uncontroversial (but a good decision), and is frequently ridiculed / questioned today.

The morality of squatting seems to me a much more difficult question where if we would discuss the politics behind it, political questions (such as the morality of profiting out of no work..) would arise which would divide the community up too much in my opinion.

1 Like
112

Leaving aside any other policies about squatting, I donā€™t think it would be particularly difficult to have a policy stating that holding a crate name with the intention of charging for transferring it is not allowed.

8 Likes
113

Examining someone's "intentions" become precarious pretty quickly. To me, the juice isn't worth the squeeze. Better to focus on making Crates.io naming as useful as possible without trying to figure out someone else's internal thoughts, feelings, and motivations. Not to say someone can't be judged, they can, but, there are better things to spend time on. Again, just and opinion.

114

Replying to a request for the crate name with a request for money would make that rather clear, as might the crate description, etc. Iā€™m talking about clear-cut cases here.

15 Likes
115

Some numbers to show the economics of these names:

  1. They have no inherent value, you can't trade them for food etc.

  2. Counting alphanumeric and underscore words up to length 8, there are 27 ^ 8 = 282_429_536_481 crate names.

  3. From the oxford dictionary site:

    The Second Edition of the 20-volume Oxford English Dictionary contains full entries for 171,476 words in current use, and 47,156 obsolete words. To this may be added around 9,500 derivative words included as subentries.

    So there are (171_476 + 47_156) ^ 3 = 10_450_598_979_731_968 three-word crate names.

Just saying that however many names you squat, a physicist will still round it to 0 :stuck_out_tongue:.

4 Likes
116

In my experience, things that are "Clear Cut" in theory tend to be quite complicated and messy in practice when it comes to judging people's intentions, motivations, etc. It's why we have judges and not automated algorithms for justice (however imperfect that may be). I like @derekdreery's point: The number of crates that can be squatted meaningfully is a rounding error. I would agree. Better things to spend resources, time, and intellectual effort on.

118

But that's exactly what people offered to be in what you originally quoted:

119

It affects me by thousand cuts:

  • Squatting takes away short, recognizable, meaningful names, so users are forced to use longer, less memorable names. To me there is a value in the libc crate being called libc, and not thereallibc or something else.

  • Squatting forces users to keep a mental mapping between what crate they want, and crate they have to install. If someone squatted futures, users would have to remember that to use futures they have to install futures-rs or async-futures or futures2 or alexcrichton/futures.

  • Squatting creates traps where install of the obvious crate, and exact match search on crates-io, gives undesirable result. If I needed to parse XML I'd expect the xml crate to do a decent job, and not be a dud or malware. For bindings, I expect $libraryname-sys to work and not be squatted.

  • Squatting is undesirable for companies supporting Rust. If a company has a brand Foo, they'd want the foo crate, and not have to pick something else that is a quirk to be taught and documented. They would be extra unhappy if foo was garbage making their brand look bad.

  • Coming up with a great name, and finding the name can't be used for no good reason is disappointing and discouraging.

  • Garbage crates come up in crates-io search and category pages, making them less useful. These are fixable problems, but if squatting is not recognized as a problem, it won't be fixed.

  • I'm afraid it casts doubts on quality of Rust's ecosystem as a whole if users keep finding non-working crates. It's doubly bad when the official position is that crates-io just doesn't care.

30 Likes
120

I see your points, but, I would have a slightly different take on things:

So, this argues for there being a "blessed" crate that gets the short, "meaningful" name for whatever concept is being modeled and all competitors get some non-short, non-meaningful name. I'm not sure that is desirable.

Hmmm....same point, same issue to my mind.

Again, there is only 1 XML parsing crate that is the blessed crate? Same issue to my mind.

Lack of name-spacing (to my mind) is the issue here. If someone is squatting a company's trademarks, there are legal remedies for that. Nothing that Rust needs to concern itself about. There is well-established law and legal remedies that are the only legitimate way to sort that out.

Short, simple, one-word names that are basically just the concept being modeled are hardly creative endeavors. Also, coming up with a "good name" and starting work on a project (but not ready to release) and then finding the name taken when you get ready to release, requiring a complete rename of your project is even more discouraging I would say. So, If someone starts a project, they shouldn't be allowed to "reserve" the name they thought of whilst working on it? That doesn't seem useful.

Again, I'd argue the issue is not squatting, it's lack of name-spacing. Focusing on "squatting" is solving the symptom rather than the problem (to my mind).

I'm not in agreement with that, but, other's would definitely have their own opinion on it. I'm not sure it is the slam-dunk you see it as though.

To me, the symptom is "perceived and/or real squatting", but, the problem is "lack of name-spacing". Fix the problem, don't just treat the symptom.

That's my take anyway. I may be completely off-the-mark though. I definitely consider this to be a very subjective area where opinions on the matter are mostly all there really is. I definitely don't consider you wrong on this issue any more than I'm right.

4 Likes
121

The actual situation is not entirely one vs all competitors, because Rust ecosystem is so far mainly open-source and cooperating in good spirit, so people can contribute to the "blessed" crate instead of competing with it.

It's true that the second person who decides to make a competing project has to find another name, but I argue it's still better than letting squatters have the best name.

As a trademark owner, whose trademark is squatted on several services, I strongly disagree with this.

  1. The law doesn't protect squatted names. The name has to be used, and has to be used in a specific way covered by the scope of the trademark, and not covered by exceptions in the law.

  2. For small businesses it's time consuming and prohibitively expensive.

  3. For individual employees or teams within a large organization litigation is also unlikely to be an option, because of the amount of internal bureaucracy involved, and making noise by getting Legal Dept involved, usually on top of sticking neck out to use Rust in the first place, is just too much.

I care about nice namespace names as much as I care about nice crate names. To me namespaced crates-io with namespace squatting problem would also be bad.

As soon as crates-io gets namespaces I'll start "crates.io namespace squatting" thread, because for my Foo project I want to have the foo/* namespace.

4 Likes
122

Shouldnā€™t the namespaces be based upon another namespace that we donā€™t control? That way itā€™s someone elseā€™s problem. For example, we could make it your username on GitHub or somethingā€¦

FWIW, I think that adding a namespace like that is the right solution here. It allows people to use obvious names like futures if they want to and it also solves squatting.

1 Like
123

@kornel I tend to agree, but I can see a lot of merit in crates.io remaining unopinionated given its status as ā€œuniversal infrastructureā€. Back when the namespacing issue first got raised, years ago, I was almost tempted to argue that if youā€™re not going to enforce any kind of name hygiene you may as well not bother with names at all; just use GUIDs instead:

  • Squatting becomes a non-issue (including typosquatting, since nobody thinks they can type GUIDs from memory).
  • No admin needed.
  • May not be friendly, but most of the friendly names have gone already anyway.
  • Can still specify a friendly name, but not as an identifier, just a not-necessarily-unique aide-memoire when reading manifest dependencies or imports. A bit like the common URL pattern of using a GUID or integer id plus an irrelevant but human-readable slug.

On the downside, it may traumatize people who remember COM. (Which was solving a different problem, the lack of any central registry.)

@mark-i-m Yes, this was discussed earlier in this thread, e.g. here.

4 Likes
125

One of my worries is that the situation could easily and quickly get much worse. How long would it take for one person with a script to claim every single dictionary word, for example? I donā€™t like being in the situation where it takes only one bad actor to make life annoying for everybody. And since weā€™ve already had a number of users publish hundreds of empty crates, Iā€™m not confident that we wonā€™t see more extreme efforts in the future.

Of course the admins could always decide to intervene after the fact if they decide a line has been crossed. But I would suggest some relatively simple technical measures could prevent some of the worst-case abuses before they happen. For example, limiting each user to 500 crates by default. This could be done without any major changes to the system, and is easy to reverse if it causes problems.

7 Likes
126

There are already legitimate users approaching this limit. And of course GitHub teams are allowed to own crates too. Would it really be surprising if the servo team someday owned more than 500 crates? What about other teams heavily invested in Rust (e.g. what if Google put fuchsia on crates.io)? I definitely think there are tons of legitimate reasons for hundreds or even thousands of crates to be owned by a single entity.

Not to mention that the source of truth for crates.io users - GitHub user accounts and teams - is not exactly hard to get more than one of.

However, I personally think some kind of rate limiting new crate publication would be perfectly reasonable and I wouldn't be surprised if the crates.io team would accept a PR.

4 Likes
127

A limit like that doesnā€™t need to be a hard rule, just a default. Users and groups who legitimately need that many crates could apply for an exception (which would probably only be denied if they were obviously squatting on names they donā€™t intend to use.) However, rate-limiting might cause automation headaches that could be much harder to work around. There are legitimate reasons to mass-rename and publish a whole mess of crates at once, too.

5 Likes
128

On the specific issue of company name and trademark, I would point that there is a much larger issue:

  • there are different jurisdictions but a single (central) crates.io.
  • it is possible for two companies in different domains to have the same name.

My current company fought for years trying to acquire the <company>.com domain name simply because another company with the same name had registered it first and was not keen on selling it away. And from research, there appeared two other companies trying to acquire it too.

Which one would you give the crate name too? All four have good reasons to vie for the name.

I would note that even namespacing doesnā€™t ā€œsolveā€ the issue; the four companies would have fought for the same namespace much like they fought for the same domain name.

2 Likes
130

This forum weā€™re currently using requires a certain reputation rank before allowing certain privileges. Why not reserve certain crate naming privileges to authors of high enough reputation?

Based on the discussion, it appears that Crates is failing to provide a means to add a reputational score to crates and crate authors. Crowdsourcing crate reputation as a means to separate the good from the bad is a proven system (tripadvisor, Amazon ratings, etc.).

Personally Iā€™m not a fan of any statement containing the words ā€œit cannot be doneā€ or its equivalent. Yes it can, you just donā€™t want to (which can be ok, perhaps).

a) Add reputation to authors and crates, reserve specific crate naming conventions to higher reputation authors, also in a graded system (higher reputation can register more names, more freedom in naming)

b) allow user reviews and ranking of crates (helps solve discoverability problems of crates too)

c) Beef up the search systems to filter out low reputation crates (only 3 stars+).

d) Provide tooling to inspect the included crates and their reputation, and warn if low reputation crates are used anywhere in the dependencies (these are bad for security if nothing else).

e) try experimental techniques like AI to suggest relevant crates for a project or finding deviant behaviour. And try allowing for paid-for crate curation lists. The sky is the limit, try stuff and see what works.