DAOrayaki Research |Radicle：Code Collaboration Infrastructure for Decentralized Communities — P2P Decentralized Github

DAOrayaki

27 min readJun 9, 2021

DAOrayaki DAO Research Grant：

Fund Address: 0xCd7da526f5C943126fa9E6f63b7774fA89E88d71

Voting Result：DAO Committee yes

Grant Amount：200u

Category: (P2P decentralized Github, DECENTRALIZED CODE COLLABORATION, open-source work, GIT, bazaar-style )

Contributor：黑白QB, DAOctor@Daorayaki

Launch time：The project started in 2018 and launched on the mainnet of Ethereum in February 2021

Token：RAD （2021–02–26 LBP）ERC-20

Token Value：$6.09（2021–05–31）

Market Value：$35,281,520.00 （2021–05–31）

Chinese Version:https://daorayaki.org/xiang-jie-radicle-qu-zhong-xin-hua-she-qu-de-dai-ma-xie-zuo-ji-chu-she-shi/

What is Radicle?

Radicle is a decentralized code collaboration network built on open protocols 🌱. It enables developers to collaborate on code without relying on trusted intermediaries. Radicle was designed to provide similar functionality to centralized code collaboration platforms — or “forges” — while retaining Git’s peer-to-peer nature, building on what made distributed version control so powerful in the first place.

Radicle also leverages Ethereum (opt-in) for unique global names, decentralized organizations, and protocols that help maintainers sustain their open-source work.

How it works

The network is powered by a peer-to-peer replication protocol built on Git, called Radicle Link. Radicle Link extends Git with peer-to-peer discovery by disseminating data via a process called gossip. That is, participants in the network share and spread data they are “interested” in by keeping redundant copies locally and sharing, otherwise known as “replicating”, their local data with selected peers. By leveraging Git’s smart transfer protocol, Radicle Link keeps Git’s efficiency when it comes to data replication while offering global decentralized repository storage through the peer-to-peer networking layer.

Since all data on the network is stored locally by peers on the network, developers can share and collaborate on Git repositories without relying on intermediaries such as hosted servers.

How is Radicle different from GitHub?

Collaborating on Radicle is slightly different than collaborating on centralized code collaboration platforms like GitHub and GitLab.

The Radicle stack is open-source from top to bottom. There are no “closed” components. Every component of the Radicle stack is auditable, modifiable, and extendable.
Radicle is built entirely on open protocols. There are no “special servers”, privileged users or companies in control of your collaboration.
Radicle is based on a peer-to-peer architecture instead of a client-server model.
Radicle is not global by default. Instead, the social graph of peers and projects you track determines what content you see, interact with, and replicate.
Radicle is designed for bazaar-style development. This means that within projects, there isn’t a single master branch that contributors merge into. Instead, peers maintain their own views of projects that can be fetched and merged by other peers via patches.
Radicle replaces the Org functionality of centralized forges and their hierarchical admin models with decentralized organizations on Ethereum
Radicle is a self-sustained and community-owned network — not a corporation. It’s governance is organized by a token called RAD that lives on Ethereum.

How do I use Radicle?

The easiest way to use Radicle is with Upstream, a desktop client developed by the founding team of the Radicle project. With Upstream, you can create an identity, host your code, and collaborate with others on the Radicle network.

Founding Team

Cory Levinson Co-Founder

Cory Levinson is an independent analyst, software developer, and data scientist at Clovers Network. He is an active contributor to various projects in the blockchain and distributed point technology space, having worked with Oscoin, Secure Scuttlebutt, and most recently Clovers Network, respectively.

Previously, he worked as a data analyst and later joined the SoundCloud data infrastructure team for about five years. in 2017, he started active research in the blockchain space at the Strelka Institute in Moscow, where he led the development of the energy project Phi.

Eleftherios Diakomichalis Co-founder

Eleftherios Diakomichalis is the co-founder of Oscoin, a decentralized network, and cryptocurrency inspired by the OSS partnership. In addition, he was an early employee of SoundCloud and previously served as its VP, leading the data science team. His interests lie in network science and statistics, with a focus on online communities.

Abbey Titcomb Co-Founder

Abbey Titcomb is currently the Head of Strategy at Onward Labs. Previously, she worked at UnderscoreVC on collaboration-based crypto-economic models and system design.

Details Introduction

1 Why Radicle?

Throughout the last decade, open source has become a standard for software development. Sharing code freely and publicly has made it drastically cheaper and easier to build software — and tech innovation is surging as a result.

Code hosting and collaboration platforms like GitHub and GitLab have contributed heavily to the growth of open source by bringing it to a mainstream audience. They defined standard vocabulary and behaviors, made git accessible to a greater audience, empowered social coding, and created global communities of developers. It is an undeniable fact that they have completely changed the way people write code.

As the status quo for code collaboration, these platforms also host the largest repositories of open source development made up of not just code, but issues, pull requests, reviews, and comments. Even the social relationships — stars, likes, follows — exist solely within these platforms.

These platforms, however, are owned by corporations. They are subject to corporate law and have the right to define their terms of services. They can implement user bans — like those currently in place against Iranian, Syrian, and Crimean GitHub accounts in response to pressure from the U.S. government. They are vulnerable to censorship as well as corporate and state ends, which are often misaligned with the goals of free and open source communities.

In a world where nearly all software relies on open source code, maintaining the resilience and health of the free and open source ecosystem is more important than ever. That’s why we believe that dependence on centrally hosted platforms and corporations for the distribution of critical open source infrastructure is unsustainable. Reliance on such centralized services contradicts the values of the free and open source ecosystem and threatens its well-being.

Radicle was conceived as an alternative. Its goal is to eliminate intermediaries and create a peer-to-peer ecosystem that is robust, functional, and secure. There must be an intentional shift in narrative to prioritize the adoption of decentralized alternatives for code collaboration that abide by the principles of free and open source software.

Exploring alternatives

Alternatives to GitHub exist ranging from platforms like SourceForge and GitLab, to more established methods of collaboration such as mailing lists. Platforms like Gitea or Gogs offer self-hosted and open source solutions for code collaboration that have low platform risk but leave developers in isolated environments with no access to the global network of developers. One proposed alternative is federation. Proposals such as ForgeFed and federated GitLab are a step in the right direction, but implementations are underdeveloped or lacking. In addition, federation is dependent on domain names which can and are regularly seized by governments.

Other well-established open-source projects such as the Linux kernel adopt more bazaar and accessible development environments that aren’t confined to single platforms, such as mailing lists. These work, but they falter when held to the usability standard that platforms like GitHub have established.

Peer-to-peer protocols like Scuttlebutt have provided us with alternative solutions to share and host information. These protocols are able to work offline without reliance on servers, but applications built on them lack the ability for users to easily coordinate on a global scale. This isn’t too much of an issue for a blogging or social networking use case, but when it comes to software collaboration, a canonical global registry is necessary to meet the usability and discoverability standards of centralized platforms today. The ability for anybody to contribute to any open source project no matter where they are is necessary to cultivate a truly free and open network.

Designing by principles

As we set out to build an alternative, we started by thinking about the values that we recognize as integral to free and open source code collaboration. With that said, we developed the following list of guiding principles:

It must prioritize user freedom In the words of the free software movement:
It must be accessible and uncensorable

Anyone should have the freedom to use the software to collaborate with others. No single party should be able to ban users from accessing the system, or content from being shared. It must be auditable and transparent. In addition, users should have the freedom to control their interactions and the content they see on an individual basis.

It must be user-friendly

The software must be easy to use and not expect tremendous change in behavior from the user. Responsiveness and functionality must meet the standards established by current platforms.

It must be offline-first

It must not require internet connectivity, DNS or online portals to function. There must be no single point of failure and it must be always available.

It must not compromise on security

Trust in a third party or intermediary must not be required for use. Every artefact of the system must be attested with cryptographic signatures, and verified.

Let’s look at hosting platforms like GitHub or GitLab in the context of this framework: they succeed by being user-friendly and accessible, but since they are centrally controlled, they are censorable, and do not prioritize user freedoms. If we look at self-hosted solutions like Gitea, Phabricator or Gogs, they are free, uncensorable, and user-friendly, however, they are not easily accessible due to gate-keeping and isolated environments: users across Phabricator deployments cannot interact with each other. This is the case for all currently available self-hosted solutions we’ve looked at. They also present single points of failure and require internet connectivity for most interactions with the system.

Hypothetically, a federated GitLab could fill all the requirements, however, federated services cannot be offline-first and don’t offer sovereignty over user’s identity. Users are tied to specific instances and thus subject to some of the same drawbacks as centralized services.

Bazaar-style solutions like the Linux Kernel mailing list succeed at almost all outlined principles, but are limited in terms of user friendliness. It’s hard to compare the usability of email threads to the sophisticated workflows possible on platforms like GitHub and GitLab.

Radicle: A peer-to-peer stack for code collaboration

Radicle adopts the Scuttlebutt social overlay paradigm by establishing a peer-to-peer replication layer on top of distributed version control systems, starting with git. User accounts and login is replaced by public key cryptography, hosted issue trackers are replaced by local peer replication, and the idea of a single canonical upstream is replaced by a patch-based peer-to-peer or “bazaar” model.

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

The three major themes to highlight are the decisions to focus on a peer-to-peer code collaboration model, to build on the underlying distributed version control system for replication, and to adopt a protocol-first approach.

Revisiting the Bazaar

The Cathedral and the Bazaar describes two approaches to free software development. The cathedral model, exemplified by projects like Emacs, makes releases open and available but keeps development exclusive to so called “individual wizards”. On the other hand, the bazaar model — popularized by Linus Torvalds and validated by the massive success of Linux, calls for completely open development with frequent and early releases, delegation throughout communities, and as many “eyeballs” on the code as possible. Given enough eyeballs, all bugs are shallow.

Peer-to-peer networking makes it far easier for developers and maintainers to develop not just a shared, but a trusted representation of project state grounded in actual source code and secure peer identities. With peer replication, patches become more comprehensive because they are tied to local issues, comments, and reviews connected to the development process. With more comprehensive patches, bazaar-style development can retain its flexibility while supporting more sophisticated workflows. This is why Radicle replaces the idea of a single canonical upstream with a peer-to-peer model familiar to the open source hackers of the 90s and early 2000s. It makes bazaar-style development easier and better.

This potential is what caused Radicle to settle on a gossip-based “social overlay” built on distributed version control systems that is free and always available without the hassle of self-hosting or trusting companies with user data.

Git gossips well

The next design decision came as a result of our experimentation with decentralized storage. After building the first version of Radicle on IPFS, we ran into performance and functionality issues. The major realization was that replicating git repos peer-to-peer on the storage layer left us no choice but losing the packfile protocol, one of the things that makes git fast. This approach would make source code a second-class citizen — making it impractical to store repositories with large histories.

When reflecting on the above, the almost obvious thought returned: why not use git itself to distribute data? Storing collaboration artifacts (issues, pull requests, comments, …) in git has been done before and the data structures available in git satisfy all our needs. Paired with a gossip layer, git becomes exactly what’s necessary to store, replicate and distribute code and collaboration artifacts.

By building a peer-to-peer overlay on top of git, we find not only a performant solution, but one that is better adapted for code collaboration. Issues, comments and reviews become local artifacts that are cryptographically signed and interacted with offline.

Protocols, not platforms

The story of the big code hosting platforms coincides with the general shift of the internet from open protocols to privately-owned platforms. Most social coding platforms today actually leverage open protocols (git, mercurial, ssh) but have built up closed gardens.

Radicle’s approach is meant to return to the protocol-first philosophy by focusing on building code collaboration primitives instead of user experiences, and to reject data collection and siloing by intermediaries. This is reflected in the decision to build on and extend git. Having it as the nexus of replication builds on its strengths and decentralized nature. Having issues, pull requests, comments, and reviews locally gives developers the tools to manage and design their workflows without locking them into a new “experience”. Despite any front-end interface that will be built, Radicle exists foremost as an open protocol — not a platform.

2 How it Works

Overview

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 it’s 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. Repositories on the Radicle network are called ‘projects’, which are gossiped by ‘peers’.

In Radicle:

Peers track other peers
Peers track projects they are interested in
Peers gossip about projects. This means replicating updates from the peers they track and the projects they are interested in

These interactions create a “trusted” social graph of peers and projects that become the foundation for collaboration within Radicle.

Radicle Link supports a bazaar-style collaboration model in which there is no single canonical ‘master’ branch that contributors merge into, but a multitude of upstreams exchanging patches via remotes.

Identities

Overview

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

The notion of “identity” in Radicle Link simply means the presence of an identity document at a conventional location within a Git repository, where the document is subject to certain verification rules. The hash of the initial document is considered its stable identifier and encoded as a uniform resource name (URN) of the form rad:git:$HASH (for Git repositories). The URN is supposed to be resolvable on the network into a top-level Git repository of the same name ($HASH.git), which is valid if it contains said identity document, and the document passes the verification rules.

Data Model

Our model for maintaining consistency on repository data, is based on The Update Framework (TUF), which was conceived as a means of securely distributing software packages. Our approach is to establish an ownership proof, tied to the network identity of a peer, or a set of peers, such that the views of a project can be replicated according to the trust relationships between peers (“tracking”).

Revision is a cryptographic hash of a document’s contents, such that this document is content-addressable by this hash within the storage system.

replaces refers to the previous revision of the document, or none if it is the first revision.

payload is an extensible, forwards- and backwards-compatible datatype containing application-defined metadata about the repository. The protocol interprets some of the properties, as described in Doc Payload.

delegations contains the public keys of key owners who are authorised to issue and approve new revisions of the document. The delegation format depends on the type of identity being established.

Git Implementation

Overview

Radicle basically uses Git as a database. This means everything is stored in a single Git monorepo that is read and written from via the Upstream client. Our Git implementation was devised to create an incentive for the seeder to provide all data necessary to resolve and verify a repository, while reducing latency by eliminating gossip queries and git fetches as much as possible.

Peer Discovery & Replication

Overview

Radicle Link extends Git with peer-to-peer network discovery via a process called gossip. This means that peers in the network share and spread data they are “interested” in by keeping (replicating) redundant copies locally and sharing deltas with peers. With Radicle, we replicate data across connected repositories according to a “social graph” of peers and projects, enabling source code and changesets to be disseminated according to use and value: the more peers who are interested in a certain project, the more available this project is made to the network.

Replication Model

Repositories are the base unit of replication in Radicle. To publish a repository to the network, it must first be initialized as a project. Project combine source code, issues and proposed changes under a single umbrella, and carry a unique, shareable peer-to-peer identifier. The entirety of the project data and metadata, including social artefacts such as comments, are stored within the repository. To create a project, the owner of a repository defines a project identity. In the background, a project identity document is created in a predetermined disjoint branch of the repository, by convention rad/id. This file contains important metadata such as the project name, list of maintainers, as well as any related links.

The unit of replication is a repository, identified by a PeerID in the context of a project document (See Data Model). The holder of the corresponding DeviceKey is referred to as the maintainer of the repository. Repositories belonging to the same project are represented locally as a single repository, identified by a Radicle URN (or Radicle ID in the Upstream client). In the context of a project, the maintainer of a repository may choose to track the repositories of other peers (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 will also transitively track those, up to n-degrees out.

Therefore, a project on Radicle preserves the transitivity information of its remotes (i.e. via which tracked PeerID another PeerID is tracked).

Tracking

Tracking is the backbone of collaboration as it drives the exchange of projects and their artifacts. In Radicle, peers track other peers and projects that they are interested in. This happens when a peer clones another peer’s project or tracks a peer directly by adding them as a remote to their project via Upstream.

Since peers represent seperate devices in the network, they each have their own view of the network. Each peer tracks this view of projects, identities, and data from connected peers in its own monorepo.

When a peer tracks another peer in the context of a project — say, if it clones another peer’s project — it sets the intention to fetch and gossip the other peer’s view of that project. This means includes the project metadata, all working branches and commits, and changesets will be replicated and stored in the tracking peer’s monorepo, so that it can be fetched and collaborated on.

Direct Tracking

The other way a peer can track another peer is by explicity telling their monorepo to track a specific PEER_ID. Using the track function with PEER_ID of interest, the monorepo creates a new entry in the git config. Any updates from the tracked peer can be similarly fetched and applied the tracking peer’s monorepo.

The Manage Remotes feature in Upstream uses the track function to add peers as remotes directly to the project.

The Social Graph

In the case of multiple peer replications, any peer that tracks a project will implicitly track it’s maintainers as well. This means that when any peer on the network clones a project, all of said project’s maintainers will end up in that peer’s remote list. Since maintainers of the project work on the canonical view of the project, this automatic tracking ensures the health and consistency of a project as it’s gossiped across the network.

This also means that for a single PEER_ID, we have a sub-graph that consists of more PEER_IDs — whether they be the maintainers of the project or other tracked peers. Any time a peer is replicated, a portion of their sub-graph is replicated as well, up to 2 degrees out.

This means that everytime you track a peer, you are not only adding them as a remote, but also their remotes, and the remotes of their remotes. This ensures that a project is consistently available across the network without a total reliance on the maintainers of the project or the original tracked peer.

Validation

To ensure data integrity and authenticity, when creating a working copy of a project, the attestation history according to the remote peer is fetched before all other repository contents, and the verification procedure is run on it. If this does not yield a verified status, the clone is aborted. The resulting repository state must include the attestation histories of at least a quorum of the delegates as per the remote peer’s view of the identity document. In Git, the claim that this will be the case can be determined before fetching the repository contents by examining the advertised remote refs. If these preconditions are not met, the clone is aborted, and already fetched data is pruned.

Seeding

To improve data availability, participants in the network can choose to act as seeds. This is similar in concept to a pub in Secure Scuttlebutt. Seed nodes are “always-on” nodes running on public IP addresses that serve data to any connected peers. By joining a seed node, it automatically tracks you and shares your data across its network of other connected users. This increases the availability of your data throughout the network, while making it easier to find other’s data as well.

A seed may track a large number of repositories for a given project, so cloning from a seed will greatly increase the connectedness of a tracking graph. Also note that, by tracking a seed, upstream maintainers can increase the number of paths leading back to them, such that contributions can flow back up even if they come from participants not within the set of tracked repositories of a maintainer.

Upstream is preconfigured with an official Radicle seed node to bootstrap your connectivity. If you have removed the default seed node, you can always re-add it later by following the steps in Adding a seed node.

Collaboration Model

Our construction of the Identity from a git commit allows for multiple ids to describe the same revision of the document (and thus be equally valid). This means that the respective delegates’ histories may diverge in their commit histories, but still converge to an agreement on the validity of the attested document revision.

This means that there isn’t a single canonical branch (or master) in Upstream, as peers are all maintaining their own upstreams of the same project. However, due to the data model of Radicle idenities, there will always be a ‘canonical’ view of a project associated with its maintainers. Maintainers can follow a leader-based workflow in which they are converging histories of contributing peers into their main branch. Since their view is verifiable and implicitly tracked whenever a peer follows a project, peers can ensure they are replicating a canonical and updated view of a project.

In addition to this, the way Radicle Link works introduces certain implications for end-user collaboration 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 (more on discoverability later), 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, in fact its far more natural (it actually mimics real life communication) and by design addresses issues like spam and content moderation, which are naturally handled by the peer’s social graph.

A spammer’s patches or issues will never be tracked by the actual maintainers and as a result they wont 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, stopping to replicate, 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 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).

This design also addresses a significant problem with decentralized systems relying exclusively on distributed ledger technology, the problem of “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.

3 TOKEN

The Radicle project was established with two main objectives:

Develop resilient collaboration infrastructure that respects users freedoms, without a reliance on trusted gatekeepers nor on corporate or state overlords.
Use the newly developed sovereign financial infrastructure (Bitcoin, Ethereum, DeFi) in order to create new value flows for developers and grow the digital commons.

To accomplish both objectives there has always been one prerequisite: make Radicle self-sustainable.

With over 1000 projects already published to the network and an average growth of 8% week-to-week in its public beta, the Radicle project is ready to decentralize the network among its community and begin the quest towards self-sustainability.

Why a token?

While the arguments for sovereignty and censorship-resistance continue to strengthen, the case for decentralization goes beyond the tech. In the current era of the closed-source web, users have relinquished control of their privacy and software freedoms for a free and convenient gateway into the open Internet. Now, they are looking for alternatives as our global social platforms deteriorate due to societal pressure, lack of innovation, and the relentless extraction necessary to satisfy stakeholders.

In this reality, building Radicle within the traditional paradigm, as for example a SaaS or open-core company, would force users to remain in a customer/corporation relationship, leaving them vulnerable to eventual extraction. Additionally, if Radicle is to be resilient collaboration infrastructure that truly respects user freedoms, it needs to be developed with trust-minimization in mind, be accessible to anyone in the world, all while remaining adaptive and competitive in a market with well-funded mega-corporations. The only way out of this pattern is to build free and open source networks that are self-sustaining and community owned.

Operating by these constraints, Radicle recognizes token-based sustainability models as the most promising path forward. More specifically, it’s the emergence of governance primitives within crypto-networks that present a new design space for engineering community-owned open-source protocols & networks. These primitives provide a foundation for a truly “open” open-source world, not one bound by arbitrary walls.

For these reasons, the Radicle project will be moving forward as an open-source, community-led, and self-sustaining network for software collaboration. This vision will be realized by Radicle’s Ethereum integration — a set of open protocols that complement the Radicle peer-to-peer network. Its smart contract system enables unique global names, decentralized organizations, and experiences that help maintainers sustain their open-source work. The integration’s smart contract system will be decentralized with the Radicle token — a governance token that will enable the collective governance and long-term sustainability of the Radicle network.

How it works

The Radicle token (RAD) is designed as a governance token that enables a number of Ethereum-based features as well as the communal ownership, collective governance, and long-term sustainability of the Radicle network.

In short, the economic model of the Radicle token subjects users to fees when they interact with certain Ethereum-based protocols, unless they are members (token-holders). By buying (or being rewarded) and holding an amount of tokens, users can avoid (or have discounted) fees and participate in the governance of the network. Members maintain governing control over all Ethereum-based smart contracts and most importantly, the Radicle Treasury which holds more than > 50% of the total token supply.

Anyone can become a member by buying and holding an amount of Radicle tokens, in exchange for the following benefits:

Discounted or no fees when interacting with Radicle’s Ethereum-based protocols.

The right to participate in the governance (through voting and proposals) of the Radicle smart contract system.

By giving Radicle users a functional reason to hold the token, they can experience the benefits of governance and start establishing a new paradigm for the communal ownership of digital open-source infrastructure. If, for any reason, they are unhappy with the network, they can “voice” concerns by participating in governance or they can “exit” by selling their tokens to the market.

Governance

The Radicle governance module is a Compound fork and gives owners the right to participate in the governance of the Radicle smart contract system. Explicitly, this means members can control and parameterize their membership experiences — whether it’s by changing fees, upgrading contracts, or introducing new experiences.

The Compound governance module was chosen because it’s battle tested, audited, and balances executive power with community participation through its liquid delegation scheme.

Similar to Compound, each RAD token is equal to one vote and voting is enabled by delegating voting rights to the address (or addresses) of the token holder’s choice:

The owner’s own wallet, if they would like to vote on their own.
Another user’s wallet, if they would like the other user to vote on their behalf.
No wallet, if they don’t want to vote.

Anybody with 1% of RAD delegated to their address can propose a governance action. Proposals are executable code, not suggestions for a team or foundation to implement. All proposals are subject to a 3-day voting period, and any address with voting power can vote for or against the proposal.

Radicle Treasury

Similar to other decentralized protocols, opting-in to some of Radicle’s Ethereum features incurs network fees. These fees accrue in the Radicle Treasury, a smart contract where 50% of the overall token supply exists.

The Treasury is entirely controlled by Radicle token holders via the Radicle DAO. Members will support the long-term sustainability of the network by coordinating the distribution of the Treasury’s supply via community programs and initiatives. These community programs (e.g. developer mining, contributor rewards, grants etc…) will emerge organically through the Radicle community as Radicle members use the Treasury to continuously support the growth and resilience of the network.

The network’s code and treasury of assets are publicly managed, allowing any developer to contribute to and influence the direction of the project, making Radicle an experiment in collective governance.

Token Allocation and Release Schedule

100M Radicle tokens (fixed) have been minted at genesis and will be vested over the course of 4 years.

50% Community Treasury (vesting over 4 years)
19% Team (4 year vesting from join date, 1 year lock-up from genesis)
20% Early Supporters (1 year lock-up*)
5% Foundation (1 year lock-up)
2% Seeders Program (1 year lock-up*)
~4% Liquidity Bootstrapping Pool**

4 FAQ

How is collaborating on Radicle different than GitHub?

In contrast to centralized code collaboration platforms, Radicle is designed for bazaar-style collaboration. On the Radicle network, content is distributed peer-to-peer via a process called gossip. This means that peers are in control of their social interactions as they self-host their own content and the content of any peers they are interested in. This also means that within projects, there isn’t a single master branch that contributors merge into. Each peer maintains a view of a project with their changesets and branches. These views are gossiped around to other peers that are interested in those changes.

How is Radicle more secure than centralized platforms?

The Radicle network is peer-to-peer and built on public key cryptography. To start, this means that there is no need to rely on third parties to access or use the Radicle network. It is harder to take down because there is no central point of failure, and is resistant to corporate and state capture and censorship. In addition, all data on the Radicle network is cryptographically signed & verified as it’s gossiped between peers. While centralized platforms rely on user interface components and key oracles to signal trust from user to user, Radicle has designed trust into the core of the protocol.

How does Radicle interact with Git?

Radicle Link-the protocol that powers the Radicle network is built on Git. All Radicle data is stored in a single Git monorepo on your machine that is read from and written to via the Upstream client.

How is Radicle licensed?

Radicle is completely free and open-source. It’s licensed under version 3 of the GNU General Public License (GPLv3) with the Radicle Linking Exception.

How will issues and PRs work?

Social collaboration features (i.e. bug reports, patches, discussions etc…) are all on the Radicle roadmap. They will work very similarly to the experiences we have now, but will be local-first and cryptographically signed. This means issues, PRs, and discussions will be more secure, available offline, and stored on your machine as git objects -not on a central server!

Can I backup a GitHub project on Radicle?

Yes! Publishing a codebase to Radicle is a great way to create a peer-to-peer backup of your repositories. Maintaining a mirror of a project on Radicle is as simple as pushing to another remote. Read more about creating projects.

Can I replace GitHub with Radicle?

If you want! While our Beta release will have only the basic collaboration features (i.e. code hosting, sharing, checking out, and pushing/pulling), we plan to introduce features that could support a similar day-to-day code collaboration experience to GitHub. They will include bug reporting, patches, code review, and discussions.

That being said, while we believe that reducing one’s reliance on centrally-hosted platforms is generally a good idea, we also believe that code collaboration solutions serve different purposes for different people. Radicle Upstream will support social collaboration, but it’s priority will be delivering secure, local-first, peer-to-peer code collaboration — not an exact GitHub replica.

Where is my data stored?

On the Radicle network, content is distributed peer-to-peer via a process called gossip. This means that peers self-host their own content — and the content of any peers they are interested in — locally on their machine in a Git monorepo. It also means that whenever your data is published to the network, it can be replicated and stored on another peer’s machine.

Can I create private repositories on Radicle?

No, not yet — but in the future! Private projects with end-to-end encryption are on our roadmap. In the meantime, be sure to note that everything you put on Radicle will be publicly available.

What is a remote?

A remote refers to a version of your project that is maintained by another person. To collaborate with others on Radicle, you have to add and follow other their remotes to be able to fetch changes from them. You can manage remotes on your project page.

What’s a Radicle ID?

A Radicle ID is a unique way of identifying projects in the Radicle Network. You can find it on a project’s page or on the seed node dashboard.

What’s a Device ID?

A Device ID is the encoding of a peer’s public key that is tied to a specific device. People will be able to manage multiple Device IDs in the future, but for now you can only have one Device ID per identity.

Can I use Radicle with multiple devices?

Yes and no. While there isn’t multi-device support yet, you can still create accounts on different devices, they just won’t be linked under one Upstream user account.

How do I make sure nobody else has my display name?

You can’t…. yet. We will be introducing unique names soon.

Can I delete a project?

Currently, this feature is not supported but it is on the roadmap and will be included in an upcoming release. Until then, you can only remove your project from your local machine, thus limiting the number of peers who can find and replicate your project. You can not delete a project from another peer’s local machine, as they retain control over their local data.

Why am I only connected to one peer?

By default, the Upstream client is conecting to a seed node operated by Radicle. While we support epidemic broadcast to find and connect to other peers, we don’t have support for hole punching just yet, which will prevent a stable conenction between two computers.

Contracts

Radicle Token: 0x31c8eacbffdd875c74b94b077895bd78cf1e64a3

Governance: 0x690e775361AD66D1c4A25d89da9fCd639F5198eD

Timelock: 0x8dA8f82d2BbDd896822de723F55D6EdF416130ba

Genesis: 0x6838f63899728816f602B3e9bF73952e2bD6dc35

Registrar: 0x37723287Ae6F34866d82EE623401f92Ec9013154

5 Contact Information

Twitter：https://twitter.com/radicle_xyz?ref=block123

Blog：https://radicle.xyz/blog/

Community：https://radicle.xyz/community.html

Code：https://github.com/radicle-dev

Official website：https://radicle.xyz/