The Radicle Code Collaboration Model

This is a post on Radicle, a peer-to-peer stack for code collaboration.

When coming to Radicle from a centralized code collaboration network like GitHub or Gitlab, users might be puzzled by Radicle's unique social model at first. In contrast to centralized code collaboration platforms, on Radicle:

a) Peers are in control of their social interactions

b) Each peer effortlessly self hosts their own content and the content of the peers they follow that they are interested in

c) Peers have subjective views over the projects they follow

This post attempts to contextualize the Radicle social model, the trade-offs it makes, and how it differs from the models of well-known centralized platforms.

The Web 2.0 Social Model

In most Web 2.0 social networks:

In exchange you get:

  1. A "privately owned public space", where you can discover & interact with any public piece of content or user on the network, as long as it is allowed by your service provider.
  2. Convenience, as spam filtering & content moderation is mostly done for you (email and gmail are the best example of spam filtering, while the global feeds of Facebook and Twitter are examples of content moderation at scale)

When it comes to code collaboration, the former has proven to be significant to the growth of free and open-source sofware, as any user can a) consume any (public) project within centralized code collaboration networks and b) interact with any project within the network, by submitting patches or issues, creating branches or participating in the discussion (commenting).

The Radicle Social Model

In contrast to the common Web 2.0 model of collaboration described above, Radicle prioritizes different concerns:

  1. People being in control of their identity
  2. People being in control of their content
  3. People being in control of their social interactions

Designing Radicle Link, the peer-to-peer protocol behind Radicle, to satisfy these constraints led us to a new model for collaboration that might be familiar to the free and open-source hackers of the 90s and early 2000s — one that is radically different from that presented by well-known Web 2.0 platforms.

Protocol design

Radicle Link is a peer-to-peer gossip protocol with a generic distributed version control backend. It aims to be general enough to be used on top of systems such as pijul or mercurial, though its initial implementation is focused on supporting Git.

The protocol disseminates Git repositories via gossip-based replication, enabling the hosting and sharing of repositories without reliance on central servers.

In practice, Radicle Link distinguishes between two types of identities: personal and project. The first describes an actor in the system, while the second describes a (software) project on which one or more actors collaborate.

In Radicle:

  1. peers follow other peers.
  2. peers track projects they are interested in.
  3. peers gossip about projects. This means tracking and replicating objects from the peers they follow, about the projects they are interested in.

If you have already interacted with other decentralized social networks, this model might remind you of Secure Scuttlebutt In fact, Radicle is heavily inspired by secure scuttlebutt's design but diverges from SSB in a few ways, mainly a) Radicle is operating on DAGs, not a single linear feed and b) the Radicle "identity" is not just the public key associated with that feed, but a delegation scheme that allows you to talk about N projects and M persons. To learn more about how Radicle Link works, see https://docs.radicle.xyz.

Implications for end-user experience

The way Radicle Link disseminates data has certain implications for the end-user experience:

But what about the "public square"?

While the above design addresses critical problems around user sovereignty, censorship resistance, and spam & content moderation, new challenges emerge.

Specifically, the main challenges that arise from the above design are 1) discoverability, and 2) the ability to contribute to any project within the network. Both have proven to be very important to the growth of free and open-source software, so it's important to ensure they are taken into account.

Discovery

While Radicle is not designed to be global by default for the reasons explained above, we complemented Radicle Link's design with opt-in solutions that can enhance any peer's ability to discover new projects and other users within the network. In order to do so, we've introduced two additional concepts:

  1. Seed nodes

Seed nodes are always-on nodes that ensure data-availability in the network by serving content over the gossip protocol. Anyone can run a seed node and have it serve the content they choose. Seed nodes are just regular nodes without a user identity.

If they have a stable network address, they serve as entry nodes to the network. Many models of running a seed are imaginable: shared "home servers" (a la fediverse), commercial services, pinning nodes and more.

2. an Ethereum-based registry

To complement the replication layer we designed an opt-in registry which holds canonical project metadata. This allows projects to anchor important information—such as project state and repository head—with the guarantee of global availability and immutability.

As a peer, you will be able to create an account within the Radicle Registry, attest your Radicle Link identity and anchor project information there. (Our Ethereum integration will be covered in detail in an upcoming post, as it enables many more things beyond project anchoring)

Contributing to projects within the network

As explained above, when you are contributing to another project within Radicle, your contributions (patches, issues, branches etc.) might not be visible to the project's maintainers or other contributors, if no-one in their network is following you.

While this model for collaboration is desirable for some — controlling the visibility & interactivity of content is actually a growing trend even within Web2 platforms (see recent changes on twitter and instagram) — we realize that it might be a limitation for others.

For maintainers of projects who are interested in allowing contributions from peers outside their social graph, all they have to do is to follow seed nodes that promote policies conducive to their preferences. While it's unclear what kind of seed node policies will emerge over time, combining seed node functionality with the Ethereum radicle registry (that has the benefit of sybil resistance) has the potential to serve multiple models and needs for collaboration, all within the same network.

Finally, it's important to note that you will be able to see if a project you're interested in contributing to accepts contributions from only the maintainers' social graph or from other peers within the network. This empowers maintainers to adjust the preference of their projects accordingly to guide & support their contributors.c