"Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow."

From this, I can't tell how it's any different to just plain self-hosted Git. A well written introduction should tell the reader immediately what the software actually does. If it's meant to be an alternative to something like gitea / forgejo then say that, with a brief summary of features that build on top of Git.

From the FAQ:

> For one, [git] has no way of verifying that the repository you downloaded after a git clone is the one you asked for, which means you need to clone from a trusted source (ie. a known server). This isn’t compatible with peer-to-peer in any useful way.

> Radicle solves this by assigning stable identities to repositories that can be verified locally, allowing repositories to be served by untrusted parties.

What does this mean, in practice? At first glance this sounds like Radicle is turning a service trust problem into a PKI-shaped problem, which is more of a transmutation than a solution.

Or more precisely: how do I know which stable repository identities to trust, and how is that trust distributed to parties in the network?

And that got me to thinking about Usenet and how a ton of software (usually pirated) and images (usually pornography) were posted to it.

And people often posted stupid stuff they said (usually because they were young and dare I say afflicted by a moment of dumb).

I think one of the problems with p2p distributed systems is how do you handle "mistakes". Things you want deleted.

What if someone accidentally posts their address and phone number?

What if you post a communication system with encryption methods, but then the government passes a law that is criminal? Maybe in some regimes that puts you on a list for arrest? Look at what is happening with HAM radio operators and Belarus...

https://www.niemanlab.org/reading/ham-radio-operators-in-bel...

To me, none of this raises above the idea that distributed p2p content should not be used. It is just that it has some issues.

Also, unrelated, but I think the plethora of "How does this compare to XYZ" type comments are not very helpful. It is too easy to write that kind of post, but much harder to answer.

——

How does Radicle deal with potential abuse, illegal content sharing etc. on the network?

Each node is free to choose which repositories to host (seed) using configured policies. Nodes can block specific repositories or peers exhibiting abusive behavior.

Is there a way to host private repositories on Radicle?

Yes, Radicle supports private repositories that are only shared among a trusted set of peers, not the entire network. These are not encrypted at rest but rely on selective replication and are thus completely invisible to the rest of the network.

https://radicle.xyz/faq

The pitch is compelling; if the project home page shows that index, I can see a world where this takes the reigns from Github. Otherwise I don't see it.

We need better forges and they need to be p2p to survive. p2p is the only viable future for the web.

You can put your node behind Tor if you’re worried about demand letters, by the way.

Also, wouldn't storing everything about the repo make it very large? Even when cloning large git projects, it is from time to time necessary to make a "shallow clone" to avoid downloading hundreds of megabytes per repo. I imagine with all discussions it would be worse.

Hopefully it will scale well and be ergonomic for collaboration.

ISPs will try to block use of IPV6 for serving content, but eventually I think users will win because ultimately it should be a right to share information.

But this seems excellent for code, a thing that (to the extent you can or should be) is mostly apolitical.

> Synchronization is handled by Git.

> Causal dependencies can be modeled as commit parent-child relationships.

And there we have the problem. Git does not guarantee these things. Git is no CRDT. A proper replication protocol would, but git not. Git requires manual intervention to resolve coflicts. You end up with hourly conflicts, which need to be resolved manually, or not. Leading to inconsistencies all over when two people merge and resolve conflicts differently. Let not people merge, the system must handle this automatically. As in all online collaboration tools. Like Google Wave eg. If CRDT or as with databases PAXOS or single owner.

I know it sounds crazy, against the whole purpose. But all I want is to patch it into ArgoCD in my homelab k8s cluster...