It enables developers to collaborate on code without relying on trusted intermediaries. radicle aims to provide a centralized code collaboration platform or functionality similar to Git, while retaining the peer-to-peer nature of Git and aiming for strong distributed version control. radicle also leverages ethernet (opt-in) to obtain a unique global name, DAO code base, and a number of funding-related protocols Radicle also uses ethereum (opt-in) to get a unique global name, DAO codebase and some funding-related agreements to help maintain its open source work.
How does it work?
The network is driven by a peer-to-peer replication protocol built on Git, called Radicle Link. radicle Link extends Git with peer-to-peer discovery by propagating data through a process called “gossip”. that is, participants in the network extend Git by keeping redundant copies locally and sharing (also called ” replication”) of their local data, thereby sharing and disseminating data of their “interest”. By leveraging Git’s intelligent transport protocol, Radicle Link maintains Git’s efficiency in data replication while providing a globally distributed repository through a peer-to-peer network layer.
Since all data on the network is stored locally by peer-to-peer points on the network, developers can share and collaborate on Git repositories without relying on intermediaries such as hosting servers.
The difference with GitHub?
Collaboration on Radicle is slightly different from collaboration on centralized code collaboration platforms like GitHub and GitLab.
1) Radicle collaboration is open source from top to bottom. There are no “closed” components. every component of Radicle collaboration is auditable, modifiable, and extensible.
2) Radicle is built entirely on open protocols. There are no “special servers”, privileged users or companies to control your collaboration.
3) Radicle is based on a peer-to-peer architecture, not a client-server model.
4) Radicle is not global by default. Instead, the social graph of peers and projects you track determines what you see, interact with, and replicate.
5) Radicle is designed for bazaar-style development. This means that there is no single master branch in the project for contributors to merge into. Instead, peers maintain their own view of the project, which other peers can access and merge via patches.
6) Radicle replaces the organ function of a centralized institution and its hierarchical management model with a decentralized organization on Etherpad.
7) Radicle is a self-sustaining and community-owned network, not a company. Its management relies on a token called RAD, which is mainly used on Ether.
How can I use it?
The easiest way to use Radicle is to use Upstream, a desktop client developed by the Radicle project’s founding team. With Upstream, you can create an identity, host your code, and collaborate with others on the Radicle network.
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 5 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.
For more information.
- Why use Radicle?
Over the last decade, open source has become a standard in software development. Sharing code freely and openly has made software development much cheaper and easier, and technological innovation has proliferated as a result.
Code hosting and collaboration platforms like GitHub and GitLab have contributed significantly to the growth of open source by generating it into a mainstream audience. They have defined standard vocabulary and behaviors, made git accessible to a wider audience, empowered social coding, and created a global developer community. It is an undeniable fact that they have completely changed the way people write code.
These platforms also host the largest repository of open source development, including not only code, but issues, pull requests, comments. Even social connections – stars, likes, followers – exist in these platforms.
However, these platforms are owned by companies. They are bound by corporate law and have the right to define their terms of service. They can impose user bans, such as the current ones against GitHub accounts in Iran, Syria and Crimea, in response to pressure from the U.S. government. They are vulnerable to censorship and to corporate and national purposes that are often at odds with the goals of the free and open source community.
In a world where almost all software relies on open source, maintaining the resilience and health of the free and open source ecosystem is more important than ever. That’s why we believe that relying on centrally hosted platforms and companies to distribute critical open source infrastructure is unsustainable. The reliance on such centralized services contradicts the value of the free and open source ecosystem.
Radicle is seen as an alternative. Its goal is to eliminate intermediaries and create a robust, powerful and secure P2P ecosystem. There must be a conscious change to prioritize decentralized code collaboration alternatives that are consistent with free and open source software principles.
Alternatives to GitHub exist, from platforms like SourceForge and GitLab, to more mature collaboration methods like mailing lists. Platforms like Gitea or Gogs provide self-hosted open source solutions for code collaboration with low platform risk, but leave developers in an isolated environment with no access to a global network of developers. A viable alternative is federation. Proposals such as ForgeFed joining forces with GitLab are a step in the right direction, but the implementation is not yet complete. In addition, federations rely on domain names, which can often be seized by governments.
Other established open source projects, such as the Linux kernel, use more marketable and accessible development environments that are not limited to a single platform, such as mailing lists. These are viable, but problems arise when they are required to meet the usability standards established by platforms like GitHub.
Peer-to-peer protocols like Scuttlebutt offer an alternative solution for sharing and hosting information. These protocols are able to work offline without relying on servers, but the applications built on top of them lack the ability to allow users to easily coordinate on a global scale. This is not too much of an issue for blogging or social networking use cases, but when it comes to software collaboration, a regulated global registry is necessary to meet the usability and discoverability standards of today’s centralized platforms. The ability for anyone to contribute to any open source project, no matter where they are, is necessary to foster a truly free and open network.
Principles of design
When we set out to build alternatives, freedom and open source collaboration were integral values. We developed the following list of guiding principles.
- It must prioritize user freedom.
- It must be accessible and censorship-resistant
Anyone should have the freedom to use the software to collaborate with others. No party should be able to prohibit users from accessing the system or sharing content. 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 dramatic changes in user behavior. The responsiveness and functionality must be in line with the standards established by the current platform.
- It must be offline first
It must not require an Internet connection, DNS or an online portal to come to life. It must have no single point of failure and must always be available.
- It must be uncompromising in terms of security
It must be used without the need to trust third parties or intermediaries. Every artifact of the system must be proven with a cryptographic signature and verified.
Let’s look at hosted platforms like GitHub or GitLab in this framework: their success lies in user-friendliness and accessibility, but because they are centrally controlled, they are censorable and do not prioritize user freedom. If we look at self-hosted solutions like Gitea, Phabricator, or Gogs, they are free, censorship-resistant, and user-friendly, however, they are not easily accessible due to gate-keeping and isolated environments: users deployed across Phabricator cannot communicate with each other. This is the case with all currently available self-hosted solutions that we have seen. They also have a single point of failure and require an Internet connection to interact with the system for the most part.
Assuming a federated GitLab would meet all the requirements, however, the federated service cannot be offline-first or provide sovereignty over user identities. Users are tied to specific instances and thus suffer from the same drawbacks as centralized services.
Radicle: a peer-to-peer stack for code collaboration
Radicle takes the Scuttlebutt social overlay paradigm and builds a peer-to-peer replication layer on top of a distributed version control system, starting with git. user accounts and logins are replaced by public key cryptography, hosted issue trackers are replaced by local peer-to-peer replication, and the idea of a single specification upstream is replaced by a patch-based peer-to-peer or “bazaar ” model was replaced by a patch-based peer-to-peer or “bazaar” model.
To complement the replication layer, we introduce a registry of choices built on ethereum that holds canonical project metadata. This allows projects to anchor important information – such as project status and repository principals – and guarantees their global availability and immutability.
Three key themes to emphasize are the focus on a peer-to-peer code collaboration model, building on an underlying distributed version control system for replication, and adopting a protocol-first approach.
Revisiting the “Bazaar”
Cathedrals and Bazaars” describes two approaches to free software development. The cathedral model, exemplified by projects such as Emacs, distributes versions publicly but allows exclusive development by so-called “individual wizards”. On the other hand, the bazaar model-promoted by Linus Torvalds and validated by the enormous success of Linux-requires completely open development, frequent and early releases, licensing within the entire community, and as much “eyeballs” on the code as possible. With enough eyes, all mistakes are superficial.
Peer-to-peer networks make it easier for developers and maintainers to develop projects that are not only shared, but based on actual source code and a secure peer-to-peer identity. With peer-to-peer replication, patches become more comprehensive because they are tied to local issues, comments, and reviews during development. With more comprehensive patches, bazaar-style development can maintain its flexibility while supporting more complex workflows. That’s why Radicle replaced the idea of a single model with the peer-to-peer model familiar to open source hackers in the 90s and early 21st century. It made bazaar-style development easier and better.
This potential led Radicle to opt for a gossip-based “social overlay” built on a distributed version control system that is free and always available, without the need to self-host or trust the company that owns the user’s data.
Git gossips Benefits
The next design decision came as a result of our experiments with distributed storage. After building the first version of Radicle on IPFS, we ran into performance and functionality issues. The main realization was that replicating git repos peer-to-peer on the storage layer left us with no choice but to lose the packfile protocol, which is one of the reasons git can be fast. This approach would make the source code a second-class citizen – which makes it impractical to store big historical data.
In thinking about the above, an almost obvious idea emerged: why not use git itself to distribute the data? Storing collaboration results in git (issues, pull requests, comments ……) It’s been done before, and there are data structures in git that meet all our needs. Paired with the gossip layer, git becomes essential for storing, replicating, and distributing code and collaboration artifacts.
By building a peer-to-peer overlay on top of git, we not only found a high-performance solution, but one that was better suited for code collaboration. Issues, comments and reviews become local artifacts, are cryptographically signed and interacted with offline.
Protocols, not platforms
The story of large code hosting platforms coincides with the general shift of the Internet from open protocols to private platforms. Today, most social coding platforms actually leverage open protocols (git, mercurial, ssh), but have created closed gardens.
Radicle’s approach aims to do this by focusing on a protocol-first philosophy and rejecting the data collection and isolation of intermediaries. This is reflected in the decision to build and extend git. Using it as a nexus for replication builds on its strengths and decentralized nature. Providing issues, pulling requests, and comments locally gives developers the tools to manage and design workflows without locking them into a new “experience”. While any front-end interface will be built, Radicle exists most importantly as an open protocol – not a platform.
- Radicle Design
Radicle Link is a peer-to-peer gossip protocol with a common distributed version control backend. It aims to be generic enough to be used on top of systems such as pijul or mercurial, although its original implementation focused on supporting Git.
The protocol propagates Git repositories through gossip-based replication, allowing repositories to be hosted and shared without relying on a central server. repositories on the Radicle network are called “projects” and are gossip-ed by “peers”.
1) Peers keep track of other peers
2) Peers track the projects they are interested in
3) Peer-to-peer gossip about items. This means replicating updates from the peers they are tracking and the items they are interested in.
4) These interactions create a “trusted” social graph of peers and projects that becomes the basis for collaboration within Radicle.
Radicle Link supports a bazaar-style collaboration model where there is no single “master” branch for contributors to merge, but rather a multitude of upstreams that exchange patches via remote.
Radicle Link distinguishes between two types of identities: individual and project. The former describes actors in the system (peers), while the latter describes software projects (repositories) in which one or more actors collaborate.
The concept of “identity” in Radicle Link simply implies the existence of an identity file in a regular location in the Git repository that is subject to certain authentication rules. The hash of the initial file is considered to be its stable identifier and is encoded as a Uniform Resource Name (URN) of the form rad:git:$HASH (for Git repositories). This URN should resolve on the network to the top-level Git repository of the same name ($HASH.git), which is valid if the repository contains the identity file described and if the file passes the authentication rules.
Our model for maintaining data consistency in repositories is based on the Update Framework (TUF), which is envisioned as a means of securely distributing packages. Our approach is to create a proof of ownership, linked to the network identity of a peer, or a set of peers, so that the view of the project can be replicated (“tracked”) based on the trust relationship between the peers.
Revision is a cryptographic hash of the contents of a file, such that this file can be addressed within the storage system by this hash for its contents.
replaces refers to the previous revision of the file, or none if it is the first revision.
payload is an extensible, forward- and backward-compatible data type containing application-defined metadata about the repository. The protocol explains some of these properties, as described in Doc Payload.
delegation contains the public key of the key owner who is authorized to publish and approve new revisions to the file. The delegation format depends on the type of identity being created.
Git Implementation Overview
Radicle basically treats Git as a database. This means that everything is stored in a single Git monorepo and is read and written to via the Upstream client. Our Git implementation is designed to incentivize seeders to provide all the necessary data to resolve and validate a repository, while reducing latency by eliminating gossip queries and git fetches as much as possible.
Peer-to-Peer Discovery and Replication Overview
Radicle Link extends Git through peer-to-peer network discovery via a process called gossip. This means that peers in the network share and propagate data of “interest” to them by keeping (replicating) redundant copies locally and sharing increments with peers. With Radicle, we replicate data in connected repositories based on a “social graph” of nodes and projects, thereby propagating source code and changesets based on usage and value: the more nodes that are interested in a project, the more available that project becomes.
The repository is the basic unit of replication in Radicle. To publish a repository to the network, it must first be initialized as a project. A project combines source code, issues, and proposed changes under one umbrella with a unique, sharable peer-to-peer identifier. The entire project data and metadata, including social artifacts such as comments, are stored in the repository. To create a project, the owner of the repository defines the project identity. In the backend, following the convention rad/id, a project identity document is created in the repository’s predefined disjoint branch. This document contains important metadata, such as the project name, a list of maintainers, and any relevant links.
A replication unit is a repository identified by a PeerID in the project document context (see Data Model). The holder of the corresponding DeviceKey is called the maintainer of the repository. Repositories belonging to the same project are locally represented as a single repository, identified by the Radicle URN (or Radicle ID in the upstream client). In the context of a project, the maintainer of a repository can choose to track other repositories at other peer points (this is called a remote in git terminology: a named reference to a remote repository). If a remote repository is found to track other remote repositories, the tracking repository will also pass on tracking those remote repositories for up to n degrees.
As a result, items on Radicle retain information about the passing of their remote nodes (i.e., by which tracking PeerID another PeerID is tracked).
Tracking is the foundation of collaboration because it facilitates the exchange of projects and their artifacts. In Radicle, peers keep track of other peers and projects they are interested in. This happens when a peer clones another peer’s project or tracks a peer directly by adding them to their project as a remote via Upstream.
Since peers represent separate devices in the network, they each have their own view of the network. Each peer keeps track of the view of projects, identities, and data from connected peers in its own monorepo.
When a node tracks another node in the context of a project – for example, if it clones another node’s project – it sets the intent to get and gossip another node’s view of that project. This means that the project metadata, all working branches and commits are included, and that the changeset is copied and stored in the tracking peer’s monorepo so that it can be fetched and collaborated on.
The way a point can track another point is to explicitly tell its monorepo to track a specific PEER_ID. using the track function with the PEER_ID of interest, the monorepo creates a new entry in the git configuration. Any updates from the tracked peer can be similarly fetched and applied to the monorepo tracking the peer.
The Manage Remotes function in Upstream uses the track function to add directly to the project as a remote peer.
The Social Graph
In the case of multiple peer replications, any peer that tracks a project will also implicitly track its maintainer. This means that when any peer on the network clones a project, all maintainers of that project will end up in that peer’s remote list. Since the maintainers of a project work on a canonical view of the project, this automatic tracking feature ensures the operational status and consistency of the project as it is scattered throughout the network.
This also means that for a single PEER_ID, we have a subgraph containing more PEER_IDs – whether they are the project’s maintainers or other tracked peers. Any time a peer is copied, a portion of their subgraph is also copied, up to 2 degrees.
This means that every time you track peers, you not only add them as remotes, but also their remotes, and the remotes of their remotes. This ensures that the project is always available throughout the network without having to rely entirely on the project’s maintainer or the original tracking peer.
To ensure data integrity and authenticity, when a working copy of a project is created, a proof history based on the remote peer is fetched before all other repository content, and a validation process is run against it. If this does not produce a validated state, the clone is aborted. The resulting repository state must include a proof history for at least a quarter of the representatives based on the remote peer’s view of the identity file. In Git, the claim that this will be the case can be determined by examining the published remote reference before fetching the repository contents. If these prerequisites are not met, the clone is aborted and the data already acquired is clipped
To increase data availability, participants in the network can choose to act as seeds. This is conceptually similar to the bars in Secure Scuttlebutt. A seed node is an “always-on” node running on a public IP address that provides data to any connected peer. By joining a seed node, it automatically tracks you and shares your data across the network of other connected users. This increases the availability of your data across the network and makes it easier to find other people’s data.
The seed may track a large number of repositories for a given project, so cloning from the seed will greatly increase the connectivity of the trace graph. Note also that by tracking seeds, upstream maintainers can increase the number of paths back to them so that contributions can flow back even if they come from participants that are not in the maintainer’s set of tracking repositories.
The upstream is pre-configured with an official Radicle seed node to direct your connections. If you delete the default seed node, you can always re-add it by following the steps in Adding a Seed Node.
The Identity we build from git commit allows multiple ids to describe the same revision of a document (and therefore be equally valid). This means that individual delegates may differ in their commit history, but still agree on the validity of proven document revisions.
This means that there is no single branch (or master) of the specification upstream, as peers are all maintaining their own upstream of the same project. However, because of the Radicle identity data model, there is always a “specification” view of the project associated with the maintainer. Maintainers can follow a leader-based workflow in which they blend the history of their contribution nodes into their master branch. Since their view is verifiable and tracked implicitly as peers follow the project, peers can be sure they are replicating the project’s specification and updating the view.
Beyond that, the way Radicle Link works has an impact on the end user’s collaboration experience.
Your social graph determines the type of content you see, interact with, and replicate.
Assuming you have found an item of interest in the Radicle network (more on discoverability later), the first thing you must do in order to interact with it is to track it. Tracking items indicates interest, and by design means tracking the maintainers of the item and therefore replicating data in their social graph.
In the context of the project, the maintainer of the repository can choose to track another owner’s view (this is called a remote in Git terminology: a named reference to a remote repository). If a remote repository is found to track other remote repositories, the tracking repository should also pass on tracking those remote repositories up to a maximum of N degrees (currently under development).
Spam and content auditing is naturally handled by peer’s social graph
While this may seem confusing at first, it is actually more natural (it actually mimics real-life communication) and addresses issues such as spam and content auditing by design, which are naturally handled by peer’s social graph.
Spammers’ patches or issues are never tracked by the actual maintainers, so the rest of the network doesn’t see them (unless they are explicitly tracked). Similarly, if you are not interested in a peer’s perspective or contribution to a project, you can simply unfollow them, stop copying, view their data, and interact with them.
Two peers may have different perspectives on the same project.
The above design also means that peers have subjective (and often divergent) views, even within the same project.
At the very least, your view of the project will be the sum of the views of the people you follow plus the views of the project maintainers. In addition, you can extend your view by configuring the replication settings so that you can also pass on tracking other remote parties beyond N degrees from the peer you are following (i.e., the peer’s peer/remote’s remote party).
This design also solves an important problem with decentralized systems that rely entirely on distributed ledger technology, namely the problem of “blockchain poisoning”. This is where someone deliberately adds illegal content to an append-only source in the hope of making the sole act of copying the project legally problematic, as Konstantin Ryabitsev of the Linux Foundation correctly pointed out regarding a previous version of Radicle that relied on IPFS.
The Radicle project was created with two main goals in mind.
1) Develop a resilient cooperative infrastructure that respects the freedom of users and does not rely on trusted gatekeepers, nor on corporations or countries.
2) To leverage newly developed sovereign financial infrastructures (Bitcoin, Ether, DeFi) in order to create new value streams for developers and develop digital commons.
In order to achieve these two goals, there has always been a prerequisite: making Radicle self-sustainable.
With over 1,000 projects already published on the network and an average weekly growth of 8% in its public beta, the Radicle project is ready to decentralize the network among its community and start looking for self-sustainability.
While the arguments for sovereignty and censorship resistance continue to strengthen, the case for decentralization transcends technology. In the current era of closed-source networks, users have relinquished control over their privacy and software freedom in order to freely and easily access the open Internet. Now they are looking for alternatives as our global social platforms deteriorate due to social pressures, lack of innovation, and relentless exploitation to meet stakeholder needs.
In this reality, building Radicle in a traditional paradigm, such as SaaS or Open Core, will force users to maintain customer/company relationships, leaving them vulnerable to eventual extraction (extraction). Furthermore, if Radicle is to be an elastic collaboration infrastructure that truly respects user freedom, it needs to be developed with trust minimization in mind, allowing anyone in the world to access it while remaining adaptable and competitive in large, well-funded markets-companies. The only way to move away from this model is to build self-sufficient and community-owned free and open source networks.
Within these constraints, Radicle sees a token-based sustainability model as the most promising way forward. More specifically, it is the emergence of governance primitives in crypto networks that provides a new design space for engineering community-owned open source protocols and networks. These primitives provide the basis for a truly “open” open source world, unencumbered by arbitrary walls.
For these reasons, the Radicle project will move forward as an open source, community-led and self-sustaining software collaboration network. This vision will be realized with Radicle’s Ethereum integration, a set of open protocols that complement Radicle’s peer-to-peer network. Its smart contract system supports unique global names, decentralized organizations and experiences to help maintainers sustain their open source efforts. The integrated smart contract system will be decentralized using Radicle tokens – a governance token that enables collective governance and long-term sustainability of the Radicle network.
How does it work?
The Radicle token (RAD) is designed as a governance token that supports many of the Ether-based features as well as the public ownership, collective governance, and long-term sustainability of the Radicle network.
In short, the economic model of the Radicle token charges users when they interact with certain Ethernet-based protocols, unless they are members (token holders). By purchasing (or receiving a reward) and holding a certain number of tokens, users can avoid (or discount) fees and participate in network governance. Members maintain administrative control over all Ether-based smart contracts and, most importantly, own more than 50% of the total supply of tokens in the Radicle vault.
Anyone can become a member by purchasing and holding a certain number of Radicle tokens in exchange for the following benefits.
1) Discounts or no fees for interacting with Radicle’s Ether-based protocols.
2) The right to participate in the governance of Radicle’s smart contract system (through voting and proposals).
By providing Radicle users with a functional reason to hold tokens, they can experience the benefits of governance and begin to build a new paradigm for public ownership of digital open source infrastructure. If, for any reason, they are unhappy with the network, they can “voice” their concerns by participating in governance, or they can “opt out” by selling tokens to the marketplace.
The Radicle governance module is a composite fork that gives owners the right to participate in the governance of the Radicle smart contract system. Explicitly, this means that members can control and parameterize their membership experience – whether by changing fees, upgrading contracts or introducing new experiences.
The Compound governance module was chosen because it has been field tested, audited and balances enforcement rights with community engagement through its fluid licensing scheme.
Similar to Compound, each RAD token equals one vote and voting is enabled by delegating voting rights to an address (or multiple addresses) of the token holder’s choice to.
1) The owner’s own wallet, if they want to vote themselves.
2) Another user’s wallet, if they want another user to vote on their behalf.
3) No wallet, if they do not want to vote.
Anyone who delegates 1% of the RAD to their address can propose a governance action. Proposals are executable code, not proposals implemented by teams or foundations. All proposals have a 3-day voting period, and any address with voting rights can vote for or against the proposal.
Similar to other decentralized protocols, opting in to some of Radicle’s Ethereum features incurs network fees. These fees accumulate in the Radicle treasury, a smart contract that accounts for 50% of the overall token supply.
The treasury is fully controlled by Radicle token holders through the Radicle DAO. Members will coordinate the allocation of the treasury’s supply through community programs and initiatives, thus supporting the long-term sustainability of the network. 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 continually support the network’s growth and resilience.
The network’s code and asset repository is 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
100 million Radicle tokens (fixed) have been minted at creation and will be awarded over 4 years.
1) 50% community funding (vesting over 4 years)
2) 19% Team (vests 4 years from date of joining, locked in 1 year from creation)
3) 20% Early Backers (1 year lock-in)
4) 5% Foundation (1 year lock-in)
5) 2% Seed Program (1 year lock-in)
6) ~4% Liquidity Guidance Pool
How is collaborating on Radicle different from collaborating on GitHub?
Radicle is designed for bazaar-style collaboration as opposed to a centralized code collaboration platform. On the Radicle network, content is distributed peer-to-peer through a process called gossip. This means that peers can control their social interactions as they self-host their own content as well as any content of interest to them from their peers. It also means that no contributors in the project are merged into a single master branch. Each peer maintains a view of the project using its changeset and branches. These views are gossip by other peers who are interested in these changes.
How is Radicle more secure than centralized platforms?
The Radicle network is peer-to-peer and built on public key cryptography. First, 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 it is resistant to capture and censorship by companies and countries. Additionally, all data on the Radicle network is cryptographically signed and verified as it gossip between peers. While centralized platforms rely on user interface components and key prophecy machines to represent user-to-user trust, Radicle has designed trust to be at the heart 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 and is read and written to by upstream clients.
How is Radicle licensed?
Radicle is completely free and open source. It is licensed under version 3 of the GNU General Public License (GPLv3) using Radicle Linking Exception.
How will issues and PR work?
The social collaboration features (i.e. bug reports, patches, discussions, etc.) are all on the Radicle roadmap. They will work very similar to what we experience now, but will be locally-first and cryptographically signed. This means issues, PRs, and discussions will be more secure, available offline, and stored as git objects on your machine-not on a central server!
Can I back up my GitHub projects on Radicle?
Yes! Publishing your codebase to Radicle is a great way to create peer-to-peer backups of your repository. Maintaining an image of a project on Radicle is as easy as pushing it to another remote. Read more about creating a project.
Can I replace GitHub with Radicle?
If you want to! While our Beta release will only have basic collaboration features (i.e., code hosting, sharing, checkout, and push/pull), we plan to introduce features that can support an everyday code collaboration experience similar to GitHub. They will include bug reports, patches, code reviews, and discussions.
That said, while we believe that reducing reliance on a central hosting platform 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 its top priority is to provide secure, locally-first, peer-to-peer code collaboration-not an exact copy of GitHub.
Where is my data stored?
On the Radicle network, content is distributed peer-to-peer through a process called gossip. This means that peers host their own content – and the content of any peers they’re interested in – locally in a Git monorepo on their machine. It also means that whenever your data is published to the network, it can be replicated and stored on another peer machine.
Can I create a private repository on Radicle?
No, not yet – but in the future! Private projects with end-to-end encryption are on our roadmap. In the meantime, please be sure to note that everything placed on Radicle is publicly available.
What is remote?
A remote is a version of your project that is maintained by another person. To collaborate with others on Radicle, you must add and follow other people’s remotes in order to get changes from them. You can manage remotes on the project page.
What is a Radicle ID?
A Radicle ID is a unique way to identify a project in the Radicle network. You can find it on the project page or on the seed node dashboard.
What is a Device ID?
A device ID is an encoding of the peer public key that is bound to a specific device. In the future people will be able to manage multiple device IDs, but currently there is only one device ID per identity.
Can I use Radicle on multiple devices?
Yes, but not at the moment. Although there is no multi-device support yet, you can still create accounts on different devices, but they will not be linked under an upstream user account.
How do I make sure no one else knows my display name?
You can’t yet …… We will be introducing unique names soon.
Can I delete items?
This feature is not currently supported, but is on the roadmap and will be included in an upcoming release. Until then, you can only delete your project from your local machine, thus limiting the number of peers that can find and copy your project. You cannot delete projects from other peers’ local machines, as they retain control of their local data.
Why do I only connect to one peer?
By default, the upstream client connects to the seed node of the Radicle operation. While we support epidemic broadcasting to find and connect to other peers, we currently do not support punching, which would prevent a stable connection between two machines.
Radicle Token: 0x31c8eacbffdd875c74b94b077895bd78cf1e64a3
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/explaining-radicle-code-collaboration-infrastructure-for-decentralized-communities/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.