Introduction 🔗

Radicle is a peer-to-peer/decentralized code forge for Git. In other words, it is an alternative to systems such as GitHub and GitLab. Instead of having a centralized server (in the sense of the client-server model), Radicle relies on a gossip protocol and Conflict-Free Replicated Data Types (CRDTs).

I spent a bit of time playing with it. While I didn’t go too deep, I do have some thoughts on Radicle.

Using Radicle 🔗

Radicle provides these three main features:

• Code: where we push and pull code.
• Issues: similar to GitHub issues.
• Patches: similar to GitHub pull requests.

Instead of creating an account tied to an email address or a phone number, a Radicle identity is a cryptographic key pair, which signs all the actions done on Radicle.

At the moment, the official way to interact with Issues and Patches is through the CLI/TUI. However, I believe that nothing is stopping us from building a GUI for it. Beyond that, Issues and Patches are similar to their centralized counterparts. Of course, instead of sending them to a centralized system, Radicle Code, Issues, and Patches are sent to the decentralized protocol that I think most people do not have to worry about.

Thoughts 🔗

I believe that Radicle is a very cool piece of tech. Decentralization is always difficult, hence, what the team has achieved is very impressive.

However, I am not (yet) convinced that it is the right solution for the vast majority of cases because decentralization almost always comes with a set of very difficult usability problems while providing only minimal marginal gains on top of centralized solutions. For one, since identity is established by a cryptographic key pair, we now have to worry about issues such as key exchange and account recovery.

Let’s first consider the alternatives. To address the elephant in the room, Git is technically already decentralized, but only for the Code portion. Issues and Patches can also be decentralized over emails, as the Linux Kernel project does. Unfortunately, we know that this is not a super common way to collaborate.

Instead, I believe that a better solution is to use one of the open-source self-hosted forges such as Gitea (which I self-host), Forgejo, and Gogs. A common concern with these self-hosted forges is that contributors have to create yet another account on yet another service. Furthermore, we will have to learn yet another UI and yet another slightly different way of working. These concerns are all valid. But they apply to decentralized solutions too.

I would prefer seeing efforts being put into making these self-hosted forges interoperable. GitLab has added support for ActivityPub. I don’t know how well it works yet, but I am more bullish on that model. Building on open standards allows everyone to participate. Furthermore, there are many tools out there that already work with ActivityPub. At the same time, open standards do not preclude decentralized solutions such as Radicle.