a Decentralized Alternative to GitHub for Web3 – InApps Technology 2022

ETHAmsterdam took place over the weekend, closing out the week-long Devconnect happening in Amsterdam. The schedule was packed with sessions covering a broad range of Web3 topics. One session that caught my eye was a Friday session presented by Alexis Sellier of Radicle, entitled “Peer-to-peer code distribution with Radicle”.

You can watch the session in the YouTube video below. My thoughts on the presentation follow.

What Is Radicle?

Radicle bills itself as a decentralized code collaboration network. They’ve basically taken the familiarity of GitHub and GitLab as centralized repositories for code collaboration, leveraging the full features of Git’s version control system, and added decentralization — while also integrating a number of Web3 identity features.

You can start a Radicle project by cloning something stored in a Git repository. So if you’re already using Git, but want to move away from one of the centralized repositories, the onboarding experience is pretty seamless. You can see from the demo in the video that the command line interface will feel familiar. One fundamental difference between the centralized GitHub model and Radicle’s approach to version control is that there isn’t a single immutable master that contributors merge into — each peer maintains a branched version of the project with whichever changes they are interested in maintaining.

Identities and Radicle

There are two types of identities within the Radicle network, and both are used by the Radicle Link peer-to-peer gossip protocol. There are individual identities, which are basically equivalent to having a username on GitHub — but instead, they are identity generated as a key pair in the Radicle CLI. Projects are a second type of identity, and can be acted on by one or more individuals.

Unlike the centralized models on GitHub and GitLab, where you sign up for a user account, Radicle has you create an identity with a key pair from the CLI. This identity persists as part of the project when it is published to one or more of the seed nodes in the Radicle network. One benefit of this approach is that you can see the full history of an identity and know that identity is the same across all projects it participates in — much like wallet reputation can be determined from blockchain participation over time.

Radicle also integrates with ENS, so that you can directly associate a .eth domain with a Radicle identity — which further allows for linking participation in code projects to other on-chain behaviors.

Pushing Changes

Pushing changes is also familiar because you’re still leveraging “git add” and “git commit”. When you submit changes, these are published to a default seed node that you select when setting up the project. This could be a seed node you self-host and use the Radicle Link gossip protocol to share with other peers, or you could rely on one of the nodes maintained by the Radicle foundation.

Projects can have multiple approved signers that can be delegated to sign for the project. If there are multiple delegates, you effectively get a multi-signature type of support, where more than one delegate needs to approve changes to the project.

Projects can also be viewed in a browser with a web frontend for the Radicle network. Any seed node can act as a backend to the web frontend, depending on where the project was pushed. There was an audience question in the presentation about whether you lose your code if the seed node goes down. Right now the assumption is that you either also maintain a local backup of the code, or potentially push to more than one seed node. Once Radicle has fully built out its peer-to-peer replication, there will be additional redundancy in the network.