My point about suggesting to use Radicle is not as a “magic” way to avoid having to setup a self-hosted forge to host your open source work. As I mentioned in the post, the first thing I did when considering Radicle seriously, was to setup my own always-on node.
The key difference is that, with a traditional forge, if you depend on somebody else’s code hosted on their forge, then when their node is down, your project won’t build, so you have an incentive to fork, but then your fork is only usable by you in your own project. And even then, when your server is down, fresh builds of your project will fail.
Radicle essentially turns this setup into a self-healing network where one node going down (temporarily or permanently) can be compensated by leveraging somebody else’s fork of it.
So I setup my own node for Zine and I will seed my dependencies entirely for selfish reasons (I want Zine to keep building), but in turn all my dependencies are made more resilient even for people that want them outside of the context of my project.
In other words, my argument is that Radicle is similar to self-hosting, but yields significantly higher availability given the same number of nodes/self-hosted instances running.
Just adding a data point that I would happily self host some Radicle node. I prefer this than hosting a full fledge mirror, because it relieves me of the pression of having it always up, as well as being able to host it on hardware I already have.
Personally, I prefer the idea of bittorrent protocol because it’s been around longer and less… crypto financed, but whatever solves the problem of centralized source repositories is a win in my book.
the package torrenting idea, as expressed in that issue, restricts the high availability to only the package manager, and not to general collaboration
radicle also gives you an improvement over TOFU (trust on first use) because once you have a radicle id that you can trust, then you can verify that you got what you expected to receive also when fetching the repo for the first time.
torrenting from your pc alone does have the issues mentioned by @xeubie, meaning that without an always-on presence, less popular packages will go offline for long-ish periods of time. that’s fine when you’re downloading 1500 episodes of one piece, but not when you’re trying to build a project. Radicle has an already-figured-out system to avoid this problem.
How does Radicle ensure persistence and availability of repositories when nodes go offline?
Repositories are replicated across multiple peers on the network, so they remain available as long as at least one seeding node is online. Users have fine-grained control over which repositories they personally host and seed.
Additionally, certain nodes on the network act as seed nodes - always-on public nodes - that ensure a certain level of data availability.
It seems that they don’t have a more figured-out system.
To be clear, I have a personal bias against Radicle because of their use of LLMs, “agent-scale” marketing, and relation to cryptocurrency. So it’s harder for me to be completely rational
it’s about the first time when you do zig fetch --save, that’s when you do TOFU.
Not sure what you mean, it’s the same as doing self-hosted forgejo plus the ability to leverage other people’s “forks” as mirrors. Of course if all copies of a repo go offline, then you won’t be able to fetch it, but the same is true with traditional forges, with the difference that in Radicle seeds are significantly more fungible than forks.
I think of it this way: finally the crypto people have figured out a way to put their knowledge of applied cryptography to good use. I think the concept is solid in its own right and anything bad ever happens, we can fork, either at the tooling level, or at the protocol level.
Fair point regarding the choice between running your own radicle seed node or running your own forge instance. But I’m not sure Radicle guarantees object availability after a repo author rebases and force pushes to remove a commit you are relying on.
On Github, I have forked/mirrored dependencies even though they’re already on Github. I did this because the original dependency could nuke the commit I relied on, and after Github runs gc on the repo it will no longer be available.
I don’t know a lot about radicle, but based on the code it seems they’re running git gc after every fetch (and even if they didn’t, new seeders will certainly never receive the nuked commit object). I also don’t believe their gossip protocol allows you to specifically query for seeders that have a certain object; it works at the granularity of entire repos.
If this is true, then an explicit fork (or checking in zig-pkg) is probably a better guarantee of availability than seeding the repo on radicle. If I am wrong about how it works please let me know.
I should have said a more figured-out system than torrenting. I don’t see anything on their website about improving the latency or unavailability compared to torrenting.
Agreed. Would you say a zig build --watch seeder is equivalently fungible to Radicle seeds?
To me, the bad thing has already happened but it’s good that they’re popularizing decentralization.
You can make your own branch (based off the authoritative default branch) if you want to ensure that it stays immutable, that would be essentially the concrete act of forking a branch.
Yes, but that only prevents the object from being GC’ed on your own node. Would other seeders of that repo also seed your branch, if you aren’t the author of the repo? Based on the docs it looks like only seeders with scope: all would, and that isn’t the default. It’s understandable why it isn’t default, since that would let any arbitrary user store any objects they want on your seed node.
Yes, not all, but some will, that’s how your issues and patches can be seen by other people. In the blog post I mentioned wanting to setup my own Radicle node for Zine precisely because that node will be guaranteed to pick up other seeds of Zine (i.e. other people’s changes) which is necessary for collaboration to happen.