I don’t want oauth providers I want public keys. 
There are differences in opinion in how crates.io should be moderated, but I feel this is doing a disservice to both the crates.io team and to the majority of the community, who I believe understand that running a service like crates.io has challenges and that the team is doing a great job, given the circumstances. I don't speak for the community, as your post suggests you do, but I think this is a common sentiment.
I may be misunderstanding some detail here, but if crates.io refuses to host a crate, because for example it violates the ToS, why would it alias and cache it for a custom registry. I don't understand how this proposal distances you from crates.io any more than for example, hosting your own git instance (this gets you away from GitHub too :P) and getting your users to use path = {...}.
I also don't understand how it gets around names being unavailable. If potato is published on crates.io and I want to make my own potato, can I? How do I specify to use mine in my Cargo.toml? If someone else just adds potato = "*" to theirs, what happens? I feel like all of these would need to be detailed in the RFC for this to make progress. Your other comments suggest you envisage this being implemented along with a namespacing scheme - is this proposal still possible if those RFCs don't get passed?
4 Likes
federation is also a namespacing scheme. it doesn’t depend on a namespacing scheme because it defines one.
if potato is on crates.io, it’s actually potato@crates.io, so yes you can make your own potato@whatever.
by default dependencies come from crates.io, so not qualifying the name gets it from crates.io, proxied through whatever registry you’re using. you can ofc set a new default in your Cargo.toml. it’s also possible to override your dependencies’ dependencies as with normal (current) cargo.
and if crates.io refuses to host a crate it can also refuse to cache it. I don’t see the problem there? personally nothing I do will break crates.io’s TOS, I just wanna get away from the mod team.
I would consider this a key point to the proposal; I think you need to go back and flesh out the RFC text a little more to explain exactly what you're proposing. This seems like it could have more potential than just the "I don't like the mods" justification that's been given so far, but it's difficult for people to see the appeal of your ideas if you don't present them clearly.
4 Likes
Updated, I think?
I’d generally agree that some individuals in the community have hinted that crates.io could be done differently. I think that if someone wants to do it differently, they should be allowed to try.
So how about crate blacklisting? If I decide that crate xyz has poor quality code in it, but the mods of crates.io couldn’t be bothered, can I make it so that crate xyz will be blocked from being used if users opt to use my registry? The use case is for curating a “secure crates” registry that prevents unvetted code from being used.
Does every package in my own registry get added to crates.io by default, or only if I specifically chose to have it added? If it’s not added to crates.io, then it means that any crate that relies on it as a dependency can’t default back to crates.io, which may weaken the reliability of the ecosystem.
1 Like
Yes! The main feature is being able to get rid of unethical crates (crates with abusive lead developers etc)! (the Rust CoC doesn't apply to crates and that's an issue)
Yes, they get added by default - unless crates.io doesn't like your server or your server doesn't like crates.io.
Then I like it 
The code of conduct does apply to crates. We don’t actively look for violations but if they were reported we would act on them.
It’s in the policy thread.
I’m pretty sure the code of conduct doesn’t care about how ppl are treated on the crate’s repository’s issue tracker…? I do know it applies to crate content, tho - that much is obvious (altho questionable).
Yes, it’s not about issue trackers.
questionable
Sure, as I said, we don’t go poking around for violations. And this probably wouldn’t be one either; it’s more like “package name is a racial slur”.
1 Like
Blacklisting is not a viable strategy from a security standpoint. This would keep the worst offenders out from a moral point of view, but from a security point of view its like throwing sponge bricks.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.