The release of the Radicle P2P platform version 1.7 has been announced. This platform aims to create a decentralized collaborative development and code storage service similar to GitHub and GitLab, but without the need for specific servers, making it resistant to censorship and utilizing the resources of participants in a P2P network. The platform supports common elements of social interaction among developers, such as issues, patches, and code reviews. The project's codebase is written in Rust and is distributed under the Apache 2.0 and MIT licenses. Builds are available for Linux and macOS. Additionally, a desktop client, web interface, and console interface are under development.
Radicle allows developers to work on and distribute code independently from centralized platforms and corporations, which can introduce additional risks such as a single point of failure, and the company might shut down or change its terms of service. Code management in Radicle uses the familiar Git, enhanced with tools for identifying repositories in a P2P network. All data is primarily stored locally (a local-first concept) and is always accessible on the developer’s computer, regardless of the status of the network connection.
Participants grant access to their code and related artifacts, such as patches and discussions about bug fixes (issues), which are stored locally and replicated on the nodes of other interested developers connected to the shared decentralized P2P network. As a result, a global decentralized Git repository is formed, with data replicated and duplicated across various participants' systems.
To identify neighboring nodes in the P2P network, the Gossip protocol is used, while data replication between nodes is managed by the Heartwood protocol, based on Git. Since the protocol is based on Git, the platform can be easily integrated with existing Git development tools. For node identification and repository verification, cryptography based on public keys is utilized, without the use of accounts. Authentication and authorization are carried out based on public keys without centralized authorities. servers.
Each repository in the P2P network has its own unique identifier and is self-certifying, meaning all actions in the repository, such as adding commits and leaving comments on issues, are validated by the owner with a digital signature, allowing verification of data integrity on other nodes without the use of centralized certificate authorities. To access the repository, it is sufficient for at least one node containing its replicated copy to be online.
Nodes in the P2P network can subscribe to specific repositories and receive updates. It is possible to create private repositories accessible only to certain nodes. The concept of 'delegates' is used for managing and owning a repository. A delegate can be an individual user, a bot, or a group tied to a specific identifier. Delegates can accept patches into the repository, close issues, and set access permissions for the repository. Multiple delegates can be associated with each repository.
Radicle repositories are stored on users' systems as regular git repositories, which include additional namespaces for storing peer and fork data that are currently being worked on. Discussions, proposed patches, and components for organizing reviews are also stored within the git repository as collaborative objects (COB) and are replicated among peers.
In the new release:
- The implementation of signed references (sigrefs) has been revamped to include protection against signature replay. The old repository structure allowed replacing code with an older version by reusing an old valid signature. To block this issue, the new implementation includes a pointer to the previous entry covered by the current signature, forming a continuous chain of changes, the integrity of which can be traced back to the root.
- The node blocking capabilities have been expanded, now blocking at the connection management level. Previously, only data reception was blocked without restricting the node connection itself; now, blocking is applied at the connection setup stage with a blocked node and upon receiving a connection from a blocked node.
- Any links to external Git objects are now allowed, except for temporary branches. Previously, only links to external branches, tags, Radicle metadata, notes, and collaborative objects were permitted.
- The informativeness of error messages when attempting operations for which the user lacks permissions has been enhanced.
- The input/output efficiency has been improved. Developers found that on long-running nodes, the combination of settings 'journal_mode = WAL' and 'synchronous = FULL' in the SQLite database used for storing local state leads to a high volume of input/output operations. To reduce the load, the 'synchronous' parameter is now set to 'NORMAL' by default, and the Radicle configuration file has been updated to allow users to modify these parameters.
- A vulnerability has been eliminated, and information about it will be disclosed on March 23. Currently, it is reported that the development team has scanned all publicly available Radicle repositories and found no evidence of exploitation of this issue.
Source: opennet.ru
