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 Web2 Social Model
In most Web2 social networks:
- Your content is global by default
- Your service provider is in control of your content (what you post), your identity, and your access
- Your service provider is in control of your social interactions. Practically, this means your service provider can determine what is spam and who you are allowed to interact with.
In exchange you get:
- 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.
- 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 Web2 model of collaboration described above, Radicle prioritizes different concerns:
- People being in control of their identity
- People being in control of their content
- People being in control of their social interactions
You can read more about why we consider these concerns a priority here.
Designing our protocol, Radicle Link, 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 Web2 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:
- peers follow other peers.
- peers track projects they are interested in.
- 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:
-
Your social graph determines what type of content you see, interact with, and replicate.
Assuming you have discovered a project of interest within the Radicle network, then the first thing you have to do in order to interact with it is to track it. Tracking a project signals interest, and by design implies tracking the project’s maintainers, therefore replicating the data within their social graphs.
In the context of a project, maintainers of a repository may choose to track the views of other owners (this is called a remote in Git terminology: a named reference to a remote repository). If the remote repository is found to track other remotes, the tracking repository shall also transitively track those, up to a configurable N degrees out (currently in the works).
-
Spam and content moderation is naturally handled by the peer’s social graph
While this might appear confusing at first, self-moderation is a far more natural model for moderation as it actually mimics real-life communication. By design, it addresses the issues of Web2 content moderation, which are currently handled by biased algorithms or dependent on central hosting.
On Radicle, a spammer’s patches or issues will never be tracked by the actual maintainers and as a result, they won’t be seen by the rest of the network (unless explicitly tracked). Similarly, if you are not interested in a peer’s views or contributions to a project, you can simply un-follow them, which stops replication, and ensures you (or your connected peers!) don’t have to view and interact with their data.
-
Within the same project, two peers might have diverging views.
The above design also means that even within the same project, peers have subjective (and often diverging) views.
At a minimum, your view of a project becomes the sum of the views of the people you follow, plus the views of the maintainers of the project. In addition, you can expand your perspective by configuring your replication settings to also transitively track other remotes N degrees out from the peers you follow (i.e. peers of your peers / remotes of your remotes) (currently work in progress).
This design also addresses the significant problem with decentralized systems relying exclusively on distributed ledger technology, sometimes referred to as “blockchain poisoning”. This is when someone deliberately adds illegal content to an append-only source in hopes to make the sole act of replicating the project legally problematic, as correctly pointed out by Konstantin Ryabitsev of the Linux foundation with regards to a previous version of Radicle that was relying on IPFS.
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:
- 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.
