Federated cargo


#1

Cargo should support foo@example.org dependencies, in addition to the default foo@crates.io dependencies. Crates.io should allow crates with non-@crates.io dependencies.

Y’know, so we all can have different opinions but still be on the same community.


Namespacing on Crates.io
#2

#3

More specifically, we should allow projects like gtk-rs to run their own crate repository, and crates.io should accept crates that depend on gtk-rs’s official repository.

If there’s ever a pure-Rust sqlite, it should also have an official repository.

Big projects like these can run their own repos. We should let them. We should encourage them to do so.

crates.io should retrieve those crates for availability reasons. if the cargo can’t retrieve them directly, it should do so through crates.io (or whatever the default registry is set to) instead.

(Yes, this is literally against what the RFC stands for. That’s intentional.)


#4

I strongly disagree with this. Having crates.io depend on external crates is the path to breakage. Specifically, within crates.io its curators can ensure that dependencies stay put after uploading (modulo yanking already broken crates). With external dependencies this guarantee disappears like snow on a hot summer’s day.


#6

You’re mixing up high availability with self hosting. They are two different concepts.

First, high availability is most efficient if there are mutual trust in the cluster. Federating is more costly, because you can’t rely on a particular host to behave correctly.

Second, self hosting is often expensive. In the case of Mastodon, it requires considerable amount of memory. And many people can’t afford to install the ElasticSearch component as well.

Plus, federating doesn’t mean it’s regulation free. While it’s namespaced, you can still mass spam events (like crate update) to the fediverse.

In the case of Mastodon, decentralisation makes sense because Twitter was actually doing evil practice including tracking ads, feature/API removal and account termination. However, in the case of a package registry there’s nothing we could gain, apart from HA. Federation is expensive and complicated to code as well, and I don’t think that’s something that is demanded currently.


#7

Uh… pleroma? It runs on a Pi…