The release of the Radicle 1.5 P2P platform has been introduced, aiming to create a decentralized service for collaborative development and code storage, similar to GitHub and GitLab, but not tied to specific servers, censorship-resistant, and utilizing resources from participants in the P2P network. The platform supports standard elements of developer social interaction, such as issues, patches, and code reviews. The project is developed in Rust and is distributed under the Apache 2.0 and MIT licenses. Builds are prepared 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:
- Improved support for bare repositories, which do not contain a working directory with a copy of project files but only store the history of changes and metadata such as branches and tags. The 'rad clone' command has added the '--bare' option, allowing cloning of a repository into a state without a working tree. The 'git-remote-rad' utility has been enhanced to work better with bare repositories when using 'git push' and 'git fetch' commands while accessing an external rad server.
- A new configuration setting 'patch.branch' has been added, which can be used in the git-remote-rad utility ('git-remote-rad -o patch.branch[=<name>]') when adding a patch to automatically create a branch in the upstream repository without needing to use the 'rad patch checkout' command.
- The output of the 'rad patch show' command has been improved, now displaying the original version of the patch, which was previously only shown when the '--verbose' flag was specified. All revisions are now displayed in a unified chronology without separating changes from the original author and other participants.
- The ability to output logs in a structured format has been added, enabled through the options '--log-logger structured' and '--log-format json'.
Source: opennet.ru
