Does anyone have an issue with the "I'll know it when I see it" idea brought up in this thread? I don't think I've seen any explicit disagreement to that one.
1 Like
The problem with your question is that it addresses a very small audience: those who are focused on Rust feature development – thus are reading this forum – and who care enough about the problem to be reading this thread. A poll of Rustaceans at large would be needed to get a fair answer to your question.
2 Likes
I do have an issue with the criteria. Is there any evidence that enforcing these would have a meaningfully positive impact? Has anyone volunteered to help enforce the rules?
1 Like
I think this is mischaracterises the issue some people have. There are crates that a) contain no usable code and b) whose authors are not contactable. And both conditions have been true for years.
I don't know if this is a major issue or merely an annoyance but either way it's unhelpful to overstate what people are saying or speculate about perceived motives.
3 Likes
NPM is a VC-funded startup company with a full-time staff who are paid to work on these problems.
Crates.io receives some community resources, but the people who work on it day-to-day are largely (maybe even entirely?) volunteers.
I'll also note I'm still very interested in collaborating on end-to-end cryptographic security for crates, and this kind of mechanism is one it'd be really nice to add after such a security mechanism is in-place, rather than before:
It's still supportable, and in fact a built-in mechanism of the proposed solution in that link (threshold signatures), but it's one it'd be nice to have from the start, rather than trying to retrofit cryptographic security around an established anti-squatting process.
1 Like
What is the proof this is not scalable?
To clarify, by that "not scalable" I've meant it's tolerable if few crates do this, but not if most crates do this. I've shown a mockup of how top crates-io crates would look like if everyone used "nokogiri"-like naming scheme. To me this mockup looks shockingly bad.
because someone isn't using the crate in the way you want
That's an overly broad characterization. The issue is about a specific kind of misuse.
NPM has infinitely more packages than crates.io (or any other package repository) and name-squatting is not a problem that is brought up with the same frequency
Exactly. That's because npm has an anti-squatting policy, and enforces it!
npm has more resources to throw at the problem, so crates-io can't commit to do the same. But I'm very disappointed that crates-io takes the completely opposite position of giving up and condoning squatting. You don't need millions in VC money to write "Please don't squat" in the rules. The community can't help writing tools and volunteering to enforce the policy if the crates-io team doesn't agree that's a problem worth addressing in the first place.
16 Likes
This is a bad rule. My first ever crate leveldb is effectively unmaintained, yet used in quite some production systems, such as vector. It has seen no released for longer stretches, but it being an glue layer above leveldb-sys (which also does not see updates but a build system fix here and there), this is also okay.
Being done does not constitute squatting.
This is an equally useless rule. Being unreachable does not constitute squatting.
Software, especially crates, should be allowed to become unmaintained and legacy and remain accessible to the users. If I became unreachable (for whatever reason) and someone were to argue the crates.io team into handing over access to my crate, this is a serious attack vector into some infrastructure systems.
9 Likes
The NPM squatting policy not very fleshed out and applied manually, so yes, you do need a support team to decide.
The same rule applies to crates.io already: the crates.io maintainers reserve the right to remove packages.
The squatting policy of NPM also isn't a particularly good example: The Disputes Policy refers to the Terms of Use: npm Open-Source Terms | npm Docs The Terms of Use then refer back to the Acceptable Use Policy for Details: Dispute Resolution | npm Docs With the final rule being: "You can send us an email, we may do stuff" That's a very elaborate way of writing that ;).
I also don't agree with your framing of "team vs. community", but YMMV.
3 Likes
But both of those criteria depend on the crates also being:
leveldb, for example, has public exports.
It's easy to imagine that a "done" crate will become sub-optimal after a certain time. It can be new language idioms, bug fixes to compiler may make crate uncompilable, an upstream dependency may break and influence downstream code, etc.
With the current policy after maintainer disappearance crates are left to rot for eternity, which I don't think is healthy for the ecosystem in a long run.
This problem can be easily solved by restricting versions which can be published after crate transfer, i.e. the reciever will not be able to publish patch/minor updates to existing crate versions, so cargo update will not pull versions managed by a new owner without manually editing Cargo.toml. This was discussed briefly in my proposal.
No, it does not. crates.io team only uses it for crates with malicious code and potentially for complying with trademark complaints, while NPM also uses this right to fight with unhealthy squatting. Python world also sees rotting packages as a problem, see PEP 541.
1 Like
Basically that ends up being eRFC: Crate name transfer by dtolnay · Pull Request #2614 · rust-lang/rfcs · GitHub.
3 Likes
I am aware, this still doesn't provide what benefit there would be to taking these crates.
Tooling will not solve a fundamentally human problem, and neither would volunteers, the best an outside volunteer could do is flag a crate, which still leaves the work and responsibility to another member. All of these "solutions" require more work, yet they don't address where the time for this work will come from. Creating these policies are very easy when you're not the person who will actually be responsible for implementing, maintaining, and responsible for it when there is disputes. Why should crates.io team who volunteer their time stretch themselves thinner, and handle more moderation work for little to no reward?
For any kind of policy to succeed it needs to come with the collaboration of the crates.io team.
5 Likes
Which is a fair criticism. And of course the flip side of that is what cost/benefit there is to allowing a small number of crates.io users to act as ad-hoc gatekeepers to a large number of crate names.
But my main issue is that if this conversation is to be at all productive it does need to stay on topic and not argue against things that are not being proposed. Otherwise everyone ends up talking past each other.
I don't think I was clear: all of those criteria would need to match, not just one. So if the owner could be reached and declined a transfer, that would be the end of it, even if it's otherwise relatively clear. Like I said, this is a baseline.
1 Like
I strongly disagree. If the maintainer decides to transfer ownership, that's one thing. However, I don't think we should allow takeover of existing crates by (essentially) arbitrary third parties. I frequently run cargo upgrade, but this change would require me to verify that all of my dependencies haven't been transmuted into completely different crates.
I think the benefits of having crates not change out from under people's feet vastly outweigh the benefits of making certain crates names accessible.
6 Likes
Do you use for breaking upgrades as well? If crate had a breaking release (e.g v0.1.0 -> v0.2.0 or v1.0.0 -> v2.0.0), you should check changes in the crate either way. And with the mentioned restrictions on versions which can be published after crate transfer you will notice it, so crates with this proposal will not "change out from under people's feet".
If you still think such measures are insufficient, we also could add additional barriers for using crate after transfer, e.g. we could add owner field without which you will not be able to use post-transfer versions:
foo = { version = "0.7", owner = "new_owner" }
And what if the current owner cannot be reached, the crate is empty, and has been so for a period of time? There's zero risk of breakage there.
1 Like
Personally, I'd be fine with that, as long it was never possible to have actually used the crate. What I object to is changing the ownership of existing non-empty crates (e.g. a crate which someone could actually have used) without involving the owner.
Just so you know, that's my original proposal 
3 Likes
We haven't really got deep into discussing solutions and their costs, because the mere idea of doing anything gets shot down quickly. And not-yet-presented solutions are shot for having too large cost on crates-io team, without even knowing what that is!
So here's one zero-cost solution: Change crates-io policy to say that squatting is frowned upon. Literally just a wording change in one doc.
Currently, a large portion of squatted crates is taken by well-meaning people (these "please contact me if you want this" crates). They're unlikely to be stubborn rule-breakers running a sophisticated trolling-for-profit operation. They've just grabbed a bunch of names, because that is explicitly allowed by crates-io, very easy to do, and has no downsides for the squatter. And solution to this may be as simple as politely asking them not to do that.
edit: changed that to Proposal for crates-io crate name reservation
10 Likes