Compared with GitHub, Radicle is designed for market-style collaboration. There is no single “master” branch for contributors to merge, but many upstream remote exchanges of patches.
Original Title: “Explaining Radicle: Code Collaboration Infrastructure for Decentralized Community”
Written by: DAOrayaki
Radicle is a decentralized code collaboration network built on the open protocol Radicle. It enables developers to collaborate on code without relying on trusted intermediaries. Radicle aims to provide a platform or function similar to a centralized code collaboration while retaining the point-to-point nature of Git, aiming to achieve strong distributed version control. Radicle also uses Ethereum (opt-in) to obtain a unique global name, DAO code base, and some financing-related agreements to help maintainers maintain their open source work.
How does it work?
The network is driven by a peer-to-peer replication protocol based on Git, called Radicle Link. Radicle Link spreads data through a process called “gossip”, extending Git with peer-to-peer discovery. In other words, the participants in the network share and disseminate the data they are “interested in” by keeping redundant copies locally and sharing (also known as “copying”) their local data with selected peers. By using Git’s intelligent transfer protocol, Radicle Link maintains the efficiency of Git 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 peers on the network, developers can share and collaborate on Git repositories without relying on intermediaries such as hosting servers.
What’s the difference with GitHub?
Collaboration on Radicle is slightly different from collaboration on centralized code collaboration platforms such as GitHub and GitLab.
- Radicle collaboration is open source from top to bottom. There are no “closed” components. Each component of the Radicle collaboration is auditable, modifiable and extensible.
- Radicle is completely built on an open protocol. There are no “special servers”, privileged users or companies to control your collaboration.
- Radicle is based on a peer-to-peer architecture, not a client-server model.
- Radicle is not global by default. Instead, the social graphs of the peers and projects you follow determine what you see, interact with, and copy.
- Radicle is designed for bazaar-style development. This means that in the project, there is no single master branch for contributors to merge and use. Instead, peers maintain their own project views, and other peers can acquire and merge through patches.
- Radicle uses decentralized organizations on Ethereum to replace the functions of centralized institutions and their hierarchical management models.
- 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 Ethereum.
how to use?
The easiest way to use Radicle is to use 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 field of blockchain and distributed point technology. He has worked with Oscoin, Secure Scuttlebutt, and most recently Clovers Network.
Prior to this, he worked as a data analyst and later joined the SoundCloud data infrastructure team for about 5 years. In 2017, he started to actively research the blockchain field at the Strelka Institute in Moscow, where he led the development of the energy project Phi.
- Co-founder of Eleftherios Diakomichalis
Eleftherios Diakomichalis is the co-founder of Oscoin, a decentralized network and cryptocurrency that is cooperated and incentivized by OSS. In addition, he is an early employee of SoundCloud and previously served as its vice president, leading the data science team. His interests lie in network science and statistics, with a focus on online communities.
- Co-founder of Abbey Titcomb
Abbey Titcomb is currently the director of strategy at Onward Labs. Before that, she worked at UnderscoreVC, researching encryption economic model and system design based on collaboration.
detail intruduction:
Why use Radicle?
In the past decade, open source has become a standard for software development. Free and open sharing of code has greatly reduced the cost of software development and made it easier, and technological innovation has therefore surged.
Code hosting and collaboration platforms like GitHub and GitLab have made great contributions to the development of open source by substituting open source into the mainstream audience. They defined standard vocabulary and behaviors, enabled more people to access git, enhanced social coding capabilities, and created a global developer community. An undeniable fact is that they have completely changed the way people write code.
These platforms also host the largest open source development repositories, including not only code, but also questions, pull requests, and comments. Even social relationships — celebrities, likes, and following — exist on these platforms.
However, these platforms are owned by the company. They are bound by company law and have the right to define their terms of service. They can implement user bans, such as the current bans on GitHub accounts in Iran, Syria, and Crimea, in response to pressure from the US government. They are vulnerable to censorship and corporate and national goals, which are often inconsistent with the goals of the free and open source community.
In a world where almost all software depends on open source, maintaining the resilience and health of a free and open source ecosystem is more important than ever. This is why we believe that relying on centralized hosting platforms and companies to distribute critical open source infrastructure is unsustainable. The reliance on this centralized service contradicts the value of a free and open source ecosystem.
Radicle is considered a substitute. Its goal is to eliminate intermediaries and build a robust, powerful and secure P2P ecosystem. There must be a conscious change, giving preference to alternatives to decentralized code collaboration that conform to the principles of free and open source software.
alternative plan
There are alternatives to GitHub, from platforms like SourceForge and GitLab, to more mature collaboration methods such as 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 and cannot enter the global developer network. A viable alternative is alliances. Proposals such as ForgeFed and GitLab are a step in the right direction, but the implementation is not perfect. In addition, alliances rely on domain names, and domain names may often be seized by the government.
Other mature open source projects, such as the Linux kernel, have adopted more market-oriented and accessible development environments that are not limited to a single platform, such as mailing lists. These are all feasible, but problems arise when they are required to meet the usability standards established by platforms like GitHub.
Peer-to-peer protocols like Scuttlebutt provide us with alternative solutions for sharing and hosting information. These protocols can work offline without relying on servers, but applications built on them lack the ability to allow users to coordinate easily on a global scale. This is not too much of a problem for blog or social network use cases, but when it comes to software collaboration, in order to meet the usability and discoverability standards of today’s centralized platforms, a standardized global registry is necessary. Anyone can contribute to any open source project no matter where they are. This is necessary to cultivate a truly free and open network.
Principles of Design
When we set out to build alternatives, free and open source code collaboration is an indispensable value. We have developed the following list of guidelines:
- It must prioritize user freedom
- It must be accessible and censorship resistant
Anyone should have the freedom to use this software to collaborate with others. Neither party can prohibit users from accessing the system, nor can it prohibit content sharing. It must be auditable and transparent. In addition, users should have the freedom to control their interactions and what they see on a personal basis.
- It must be user friendly
The software must be easy to use and do not expect huge changes in user behavior. Responsiveness and functionality must meet the standards established by the current platform.
- It must be offline first
It must not require an internet connection, DNS or online portal to operate. There must be no single point of failure, and it must always be available.
- It must not compromise on security
There must be no need to trust a third party or intermediary when using it. Every artifact of the system must be certified with a cryptographic signature and verified.
Let’s look at hosting 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 such as Gitea, Phabricator, or Gogs, they are free, censorship-resistant, and user-friendly. However, they are not easily accessible due to the gate-keeping and isolation environment: Users deployed by Phabricator cannot communicate with each other. This is the case with all the self-hosted solutions currently available that we have seen. They also have a single point of failure and need an Internet connection to interact with the system most.
Assume that a federated GitLab can meet all requirements, but the federated service cannot be offline priority, nor can it provide sovereignty over user identity. Users are tied to a specific instance, so there are the same shortcomings as centralized services.
Bazaar solutions like the Linux kernel mailing list are successful in almost all the principles outlined, but are limited in terms of user-friendliness. It is difficult to compare the availability of email threads with the complex workflows that can occur on platforms such as GitHub and GitLab.
Radicle: A peer-to-peer stack for code collaboration
Radicle adopts the Scuttlebutt social coverage paradigm, and builds a point-to-point replication layer on top of the distributed version control system, first of all, git. User accounts and logins were replaced by public key encryption technology, escrow issue trackers were replaced by local peer-to-peer replication, and the idea of a single specification upstream was replaced by patch-based peer-to-peer or “mart” models.
To supplement the replication layer, we introduced a selection registry built on Ethereum, which holds canonical project metadata. This allows the project to anchor important information-such as the status of the project and the person in charge of the repository-and guarantee its global availability and immutability.
The three main themes that need to be emphasized are: focusing on a point-to-point code collaboration model, establishing replication on the underlying distributed version control system, and adopting a protocol-first approach.
Revisit the “Bazaar”
“Cathedral and Bazaar” describes two ways of developing free software. The cathedral mode, taking projects such as Emacs as an example, releases the version publicly, but allows the so-called “personal wizard” to develop exclusively. On the other hand, the bazaar model is promoted by Linus Torvalds and verified by the great success of Linux. It requires completely open development, frequent and early releases, authorization in the entire community, and as much “eyeball” attention to the code as possible. As long as there are enough eyes, all mistakes are simple.
The peer-to-peer network makes it easier for developers and maintainers to develop projects that are not only shared, but also based on actual source code and secure peer-to-peer identities. Through peer-to-peer replication, patches become more comprehensive because they are tied to local issues, comments, and reviews during the development process. With more comprehensive patches, market development can maintain its flexibility while supporting more complex workflows. This is why Radicle replaced the idea of a single model with a peer-to-peer model familiar to open source hackers in the 1990s and early 2000s. It makes market-style development easier and better.
This potential led Radicle to choose gossip-based “social coverage”, which is built on a distributed version control system that is free and always available, without the need for self-hosting or trusting companies that own user data.
Git gossips advantages
The next design decision comes from the results of our experiments on decentralized storage. After building the first version of Radicle on IPFS, we encountered performance and functionality issues. The main realization is that copying git repos point-to-point on the storage layer leaves us no choice but to lose the packfile protocol, which is one of the reasons git can be fast. This approach makes the source code a second-class citizen-which makes storing historical big data impractical.
When thinking about the above question, an almost obvious idea emerged: Why not use git itself to distribute data? Storing cooperation results (questions, pull requests, comments…) in git has been done before, and the data structure in git can meet all our needs. Paired with the gossip layer, git becomes a necessary condition for storing, copying, and distributing code and collaborative artifacts.
By building a peer-to-peer overlay on top of git, we not only found a high-performance solution, but also a more suitable solution for code collaboration. Questions, comments, and comments become local artifacts, encrypted and signed and interact offline.
Agreement, not platform
The story of large-scale code hosting platforms coincides with the general transformation of the Internet from open protocols to private platforms. Today, most social coding platforms actually utilize open protocols (git, mercurial, ssh), but have established closed gardens.
Radicle’s approach is aimed at focusing on the concept of agreement first, and rejecting data collection and isolation by intermediaries. This is reflected in the decision to build and extend git. Use it as a link for replication based on its advantages and decentralized nature. Providing questions, pull requests, and comments locally provides developers with tools to manage and design workflows without locking them in a new “experience.” Although any front-end interface will be built, the most important thing about Radicle is to exist as an open protocol—not as a platform.
Radicle design
Radicle Link is a point-to-point gossip protocol with a universal distributed version control backend. Its goal is to be versatile enough to be used on systems such as pijul or mercurial, although its initial implementation mainly supports Git.
The protocol spreads the Git repository through gossip-based replication, so that the hosting and sharing of the repository does not depend on a central server. Repositories on the Radicle network are called “projects” and gossip is performed by “companions”.
In Radicle.
- Peer tracking other peers
- Companions track the items they are interested in
- Point-to-point chat about the project. This means copying updates from the companions they are following and the items they are interested in.
- These interactions created a “trusted” social graph of peers and projects, which became the basis for Radicle’s internal cooperation.
Radicle Link supports a market-style cooperation model, in which there is no single “main” branch for contributors to merge, but a large number of upstreams exchange patches remotely.
Identity overview
Radicle Link distinguishes two types of identities: personal and project. The former describes the actors (peers) in the system, while the latter describes the software project (warehouse) in which one or more actors collaborate.
The concept of “identity” in Radicle Link simply means that there is an identity file in a regular location in the Git repository, which is subject to certain verification rules. The hash value of the initial file is considered its stable identifier and is encoded as a Uniform Resource Name (URN) in the form of rad:git:$HASH (for Git repositories). The URN should be able to resolve to the top-level Git repository ($HASH.git) with the same name on the Internet. If the repository contains the identity file and the file passes the verification rules, the repository is valid.
Data model
Our model for maintaining data consistency in the repository is based on the Update Framework (TUF), which is conceived as a means of securely distributing software packages. Our approach is to establish a proof of ownership that is linked to the network identity of a peer or a group of peers, so that the project’s views can be replicated based on the trust relationship between the peers (“tracking “).
Revision is a cryptographic hash value of the content of a file, so that the file can be content-addressed in the storage system through this hash value.
Replaces refers to the previous revision of the file, if it is the first revision, it refers to none.
The payload is an extensible, forward and backward compatible data type that contains metadata about the repository defined by the application. 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 the new revision of the document. The authorization format depends on the type of identity being established.
Git implementation overview
Radicle basically treats Git as a database. This means that everything is stored in a single Git monorepo and read and written via the Upstream client. Our Git implementation is to incentivize seeders to provide all necessary data to solve and verify a warehouse, while reducing latency by eliminating gossip queries and git fetches as much as possible.
Overview of peer discovery and replication
Radicle Link extends Git through peer-to-peer network discovery through a process called gossip. This means that peers in the network share and disseminate the data they are “interested in” by keeping (replicating) redundant copies locally and sharing the increments with peers. Using Radicle, we replicate data in connected repositories based on the “social graph” of nodes and projects, thereby disseminating source code and change sets according to usage and value: the more nodes that are interested in a project, the more usable the project Project production to the network.
Copy model
The repository is the basic unit of replication in Radicle. To publish a repository to the web, it must first be initialized as a project. The project combines source code, issues, and proposed changes under one umbrella, with a unique, shareable 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 identity of the project. In the background, according to the convention rad/id, the project identity document is created in the predetermined disjoint branch of the repository. This file contains important metadata such as the name of the project, a list of maintainers, and any related links.
The unit of replication is a repository, identified by the PeerID in the context of the project document (see the data model). The holder of the corresponding DeviceKey is called the maintainer of the repository. Repositories belonging to the same project are represented locally as a single repository and are identified by Radicle URN (or Radicle ID in the upstream client). In the context of the project, the maintainer of the repository can choose to track the repository of other peers (this is called 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 the tracking of these remote repositories, up to n degrees.
Therefore, the project on Radicle retains the delivery information of its remote node (that is, which tracked PeerID is used to track another PeerID).
track
Tracking is the foundation of collaboration because it facilitates the exchange of projects and their artifacts. In Radicle, peers track other peers and projects they are interested in. This happens when a peer clones another peer’s project or adds them as a remote to their project via Upstream to directly track a peer.
Since peers represent independent devices in the network, each of them has their own view of the network. Each peer keeps track of views of items, identities, and data from connected peers in its own monorepo.
When a node tracks another node in the context of an item—for example, if it clones another node’s item—it sets the intent to get and gossip another node’s view of the item. This means including project metadata, all work branches and commits, and the change set will be copied and stored in the monorepo that tracks the peer so that it can be accessed and collaborated.
Direct tracking
The way one 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, monorepo creates a new entry in the git configuration. Any updates from the tracked peer can be similarly obtained and applied to the monorepo that tracks the peer.
The Manage Remotes function in Upstream uses the track function to directly add a remote peer to the project.
The Social Graph
In the case of multiple peers copying, any peer tracking the project will also implicitly track its maintainer. This means that when any peer on the network clones a project, all maintainers of the project will eventually appear in the remote list of that peer. Since the maintainer of the project is working on the specification view of the project, this automatic tracking function can ensure the running status and consistency of the project when it is distributed throughout the network.
This also means that for a single PEER_ID, we have a subgraph with more PEER_IDs—whether they are the maintainers of the project or other tracked peers. Whenever a peer is copied, part of their subgraph will also be copied, up to 2 degrees.
This means that every time you track peers, you not only add them as remotes, but also their remotes, as well as their remotes. This ensures that the project is always available throughout the network without having to rely entirely on the project’s maintainer or original tracking peer.
verification
In order to ensure the integrity and authenticity of the data, when a working copy of a project is created, it is obtained before all other repository contents based on the proof history of the remote peer, and a verification program is run on it. If this does not produce a verified state, the clone will be aborted. The resulting warehouse status must include at least a quarter of the representative’s proof history based on the remote peer’s view of the identity document. In Git, before getting the contents of the warehouse, you can check the published remote references to determine whether this is the case. If these prerequisites are not met, the cloning will be aborted and the data already acquired will be pruned
Seeding
In order to improve data availability, participants in the network can choose to act as seeds. This is similar in concept to the bar in Secure Scuttlebutt. A seed node is an “always-on” node that runs on a public IP address and provides data for any connected peers. By joining a seed node, it will automatically track you and share your data in other connected users’ networks. This improves the availability of your data throughout the network, and it also makes it easier to find other people’s data.
Seeds may track large repositories of a given item, so cloning from seeds will greatly increase the connectivity of the tracking graph. Also note that by tracking seeds, upstream maintainers can increase the number of paths back to them, so that even contributions from participants who are not in the maintainer’s tracking repository set can flow back.
The official Radicle seed node is pre-configured upstream to guide your connection. If you delete the default seed node, you can add it again at any time by following the steps in Adding a seed node.
Collaboration model
The Identity we built from git commit allows multiple ids to describe the same revision of the document (and therefore equally valid). This means that the history of individual representatives may differ in their submission history, but they will still agree on the validity of document revisions that have been proven.
This means that there is no single specification branch (or master) in the upstream, because the peers are all maintaining their own upstream of the same project. However, due to the data model of the Radicle identity, there is always a “canonical” view of the project associated with the maintainer. Maintainers can follow a leader-based workflow in which they merge the history of contributing nodes into their main branch. Since their views are verifiable and tracked implicitly when their peers follow the project, their peers can ensure that they are copying the project’s specifications and updating the view.
In addition, the way Radicle Link works has a certain impact on the collaboration experience of end users:
Your social graph determines the type of content you see, interact with, and copy.
Assuming that you have discovered an item of interest in the Radicle network (discoverability will be detailed later), the first thing you must do to interact with it is to track it. Tracking the project expresses interest, and design means tracking the maintainer of the project, so copy the data in their social graph.
In the context of the project, the maintainer of the repository can choose to track the views of other owners (this is called 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 and trace these remote repositories, up to N degrees can be configured (currently under development).
Spam and content review are naturally handled by the peer’s social graph
Although this may seem confusing at first, it is actually more natural (it actually imitates real-life communication), and it solves problems such as spam and content review through design, which are naturally caused by peer social graphs. deal with.
Patches or issues by spammers will never be tracked by actual maintainers, so the rest of the network will not see them (unless tracked explicitly). Similarly, if you are not interested in the views of your peers or contributions to the project, you can simply unfollow them, stop copying, view their data, and interact with them.
In the same project, two colleagues may have different views.
The above design also means that even in the same project, peers have subjective (and often divergent) views.
At the very least, your views on the project will be 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 the replication settings so that you can also track other remote parties other than N degrees from the peer you are following (ie, the peer of the peer/the remote party of the remote party).
This design also solves an important problem of decentralized systems that rely entirely on distributed ledger technology, that is, the problem of “blockchain poisoning”. This refers to someone deliberately adding illegal content to the only append source, hoping to cause legal problems with the only behavior of the copy project, as Konstantin Ryabitsev of the Linux Foundation correctly pointed out about the previous version of Radicle that relies on IPFS.
Token
The Radicle project has two main goals.
- Develop flexible cooperation infrastructure, respect the freedom of users, and do not rely on credible gatekeepers, companies or countries.
- Use newly developed sovereign financial infrastructure (Bitcoin, Ethereum, DeFi) to create new value streams for developers and develop digital public domains.
In order to achieve these two goals, there has always been a prerequisite: to allow Radicle to be self-sustaining.
The Radicle project has published more than 1,000 projects on the Internet, and has grown by an average of 8% per week in its public beta. The Radicle project is ready to decentralize the network in its community and begin to seek self-sustainable development.
Why choose tokens?
Although the arguments for sovereignty and censorship resistance continue to strengthen, the reasons for decentralization go beyond technology. In the current era of closed-source networks, users have given up control over their privacy and software freedom in order to freely and conveniently access the open Internet. Now, they are looking for alternatives, as our global social platform has deteriorated due to social pressure, lack of innovation, and ruthless exploitation to meet the needs of stakeholders.
In this reality, building Radicle in a traditional paradigm, such as SaaS or open core companies, will force users to maintain customer/company relationships, making them vulnerable to final extraction. In addition, if Radicle is to become a flexible collaboration infrastructure that truly respects the freedom of users, it needs to be developed while minimizing trust, so that anyone in the world can access it, while remaining adaptable in a large and well-funded market And competitiveness-the company. The only way to get rid of this model is to build a self-sufficient and community-owned free and open source network.
Under these constraints, Radicle sees the token-based sustainability model as the most promising way forward. More specifically, it is the emergence of governance primitives in encrypted networks that provide a new design space for open source protocols and networks owned by the engineering community. These primitives provide the foundation for a truly “open” open source world without being bound by arbitrary walls.
For these reasons, the Radicle project will move forward as an open source, community-led, and self-sustaining software collaboration network. Radicle’s Ethereum integration will realize this vision, a set of open protocols that complement the Radicle peer-to-peer network. Its smart contract system supports a unique global name, decentralized organization and experience, helping maintainers maintain their open source work. The integrated smart contract system will be decentralized using Radicle tokens-this is a governance token that can realize the collective governance and long-term sustainability of the Radicle network.
How does it work?
Radicle Token (RAD) is designed as a governance token that supports many Ethereum-based functions as well as the public ownership, collective governance and long-term sustainability of the Radicle network.
In short, the economic model of Radicle tokens will charge users when they interact with certain Ethereum-based protocols, unless they are members (token holders). By buying (or getting rewards) and holding a certain amount of tokens, users can avoid (or discount) fees and participate in network governance. Members maintain management control over all Ethereum-based smart contracts, and most importantly, the Radicle Treasury, which has more than 50% of the total supply of tokens.
Anyone can become a member by buying and holding a certain amount of Radicle tokens in exchange for the following benefits:
- You can enjoy discounts or no charges when interacting with Radicle’s Ethereum-based protocol.
- The right to participate in the governance of the Radicle 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 establish a new paradigm for public ownership of digital open source infrastructure. If for any reason they are dissatisfied with the network, they can “express” their concerns by participating in governance, or they can “exit” by selling tokens to the market.
Governance
The Radicle governance module is a compound fork that gives owners the right to participate in the governance of the Radicle smart contract system. Specifically, 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 undergone actual combat tests, audits, and balances execution rights and community participation through its mobile authorization 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) chosen by the token holder:
- Owners own wallets, if they want to vote for themselves.
- Another user’s wallet, if they want another user to vote on their behalf.
- No wallet, if they don’t want to vote.
Anyone who delegates 1% of the RAD to its address can propose governance actions. Recommendations are executable code, not recommendations implemented by the team or the foundation. All proposals have a 3-day voting period, and any address with voting rights can vote for or against the proposal.
treasury
Similar to other decentralized protocols, choosing to join some of Radicle’s Ethereum features will incur network costs. These fees are accumulated in the Radicle treasury, which is a smart contract that accounts for 50% of the entire token supply.
The Ministry of Finance is fully controlled by Radicle token holders through Radicle DAO. Members will coordinate the supply and distribution of warehouses through community plans and initiatives to support the long-term sustainability of the network. These community projects (for example, developer mining, contributor rewards, grants, etc…) will appear organically through the Radicle community, because Radicle members use the treasury to continuously support the growth and resilience of the network.
The network’s code and asset libraries are publicly managed, allowing any developer to contribute to the project and influence the development direction of the project, making Radicle an experiment in collective governance.
Token distribution and release schedule
100 million Radicle tokens (fixed) have been minted at the time of creation and will be granted within 4 years.
- 50% community funds (ownership for more than 4 years)
- 19% of the team (owned for 4 years from the day of joining, locked for 1 year from the creation of the world)
- 20% 早期支持者（1 年锁定期）
- 5% 基金会（1 年锁定期）
- 2% 种子计划（1 年锁定期）
- ~4% 流动性引导池
问答
在Radicle 上进行协作与在GitHub 上协作有何不同？
与集中式代码协作平台相比，Radicle 专为集市式协作而设计。 在Radicle 网络上，内容通过称为gossip 的过程进行点对点分发。 这意味着同级可以控制他们的社交互动，因为他们自托管自己的内容以及他们感兴趣的任何同级的内容。这也意味着在项目中，没有贡献者合并到一个单一的主分支。 每个peer 都使用其变更集和分支维护项目的视图。 这些观点会被其他对这些变化感兴趣的同行gossip。
Radicle 如何比中心化平台更安全？
Radicle 网络是点对点的，建立在公钥密码学基础上。 首先，这意味着无需依赖第三方来访问或使用Radicle 网络。 由于没有失败的中心点，并且可以抵抗公司和国家的捕获和审查，因此更难取缔。 此外，Radicle 网络上的所有数据都经过加密签名和验证，因为它在peer 之间进行gossip。 虽然中心化平台依赖用户界面组件和关键预言机来表示用户与用户之间的信任，但Radicle 已将信任设计为协议的核心。
Radicle 如何与Git 交互？
Radicle Link-为Radicle 网络提供动力的协议建立在Git 上。 所有Radicle 数据都存储在您机器上的单个Git monorepo 中，通过上游客户端读取和写入。
Radicle 如何获得许可？
Radicle 是完全免费和开源的。 它在GNU 通用公共许可证(GPLv3) 的第3 版下使用Radicle Linking Exception 获得许可。
问题和PR 将如何运作？
社交协作功能（即错误报告、补丁、讨论等）都在Radicle 路线图上。 它们的工作方式与我们现在的体验非常相似，但将是本地优先和加密签名的。 这意味着问题、PR 和讨论将更加安全，可离线使用，并作为git 对象存储在您的机器上-而不是在中央服务器上！
我可以在Radicle 上备份GitHub 项目吗？
Yes it is!将代码库发布到Radicle 是创建存储库点对点备份的好方法。在Radicle 上维护一个项目的镜像就像推送到另一个遥控器一样简单。阅读有关创建项目的更多信息。
我可以用Radicle 替换GitHub 吗？
如果你想！虽然我们的Beta 版本将只有基本的协作功能（即代码托管、共享、签出和推送/ 拉取），但我们计划引入可以支持与GitHub 类似的日常代码协作体验的功能。它们将包括错误报告，补丁，代码审查和讨论。
话虽如此，虽然我们认为减少对中央托管平台的依赖通常是一个好主意，但我们也相信代码协作解决方案为不同的人服务于不同的目的。 Radicle Upstream 将支持社交协作，但其首要任务是提供安全的，本地优先的，对等代码协作-而不是确切的GitHub 副本。
我的数据存储在哪里？
在Radicle 网络上，内容通过称为gossip 的过程进行点对点分发。 这意味着对等点在他们的机器上本地的Git monorepo 中自行托管他们自己的内容——以及他们感兴趣的任何对等点的内容。 这也意味着无论何时您的数据发布到网络，它都可以被复制并存储在另一台对等机器上。
我可以在Radicle 上创建私有存储库吗？
不，还没有-但是将来！ 具有端到端加密的私人项目在我们的路线图上。 同时，请务必注意，放置在Radicle 上的所有内容都可以公开获得。
什么是remote？
远程是指你的项目由另一个人维护的项目版本。要在Radicle 上与其他人合作，你必须添加并关注其他人的remote 才能从他们那里获取更改。 你可以在项目页面上管理remote。
什么是Radicle ID？
Radicle ID 是在Radicle 网络中识别项目的独特方式。 您可以在项目页面或种子节点仪表板上找到它。
什么是设备ID？
设备ID 是绑定到特定设备的peer 公钥的编码。 未来人们将能够管理多个设备ID，但目前每个身份只能有一个设备ID。
我可以在多个设备上使用Radicle 吗？
可以，但是目前没有。 尽管还没有多设备支持，但是您仍然可以在不同的设备上创建帐户，但是它们不会被链接到一个上游用户帐户下。
我如何确保没有其他人知道我的显示名称？
你还不能…… 我们将很快引入独特的名称。
我可以删除项目吗？
目前，此功能不受支持，但已在路线图中，并将包含在即将发布的版本中。在此之前，您只能从本地机器上删除您的项目，从而限制了可以找到和复制您的项目的对等点数量。您不能从其他peer 的本地机器上删除项目，因为他们保留对其本地数据的控制权。
为什么我只连接到一个对等点？
默认情况下，上游客户端连接到Radicle 操作的种子节点。虽然我们支持流行病广播来寻找并连接到其他对等点，但我们目前不支持打孔，这将阻止两台计算机之间的稳定连接。
合约
Radicle Token: 0x31c8eacbffdd875c74b94b077895bd78cf1e64a3
Governance: 0x690e775361AD66D1c4A25d89da9fCd639F5198eD
Timelock: 0x8dA8f82d2BbDd896822de723F55D6EdF416130ba
Genesis: 0x6838f63899728816f602B3e9bF73952e2bD6dc35
Registrar: 0x37723287Ae6F34866d82EE623401f92Ec9013154
