La plateforme de développement collaboratif décentralisée Radicle 1.5 est maintenant disponible

La version 1.5 de la plateforme P2P Radicle a été lancée, visant à créer un service décentralisé de co-développement et de stockage de code, similaire à GitHub et GitLab, mais sans attache à des serveurs spécifiques, sans censure et fonctionnant avec les ressources des participants au réseau P2P. La plateforme prend en charge des éléments typiques de l'interaction sociale des développeurs, comme les issues, les patches et les revues de code. Les composants du projet sont écrits en Rust et distribués sous les licences Apache 2.0 et MIT. Des versions sont disponibles pour Linux et macOS. Un client de bureau, une interface web et une interface en ligne de commande sont également en développement.

Radicle permet de ne pas dépendre des plateformes et des entreprises centralisées pour le développement et la distribution de code, avec les risques additionnels qu'elles impliquent (point de défaillance unique, l'entreprise peut fermer ou changer les conditions d'utilisation). Pour la gestion du code, Radicle utilise Git, enrichi par des outils pour définir des dépôts dans le réseau P2P. Toutes les données sont d'abord sauvegardées localement (concept local-first) et sont toujours disponibles sur l'ordinateur du développeur, quel que soit l'état de la connexion réseau.

Les participants donnent accès à leur code et aux artefacts associés, tels que les patches et les discussions sur les corrections d'erreurs (issues), qui sont sauvegardés localement et répliqués sur les nœuds d'autres développeurs intéressés, connectés au réseau P2P décentralisé commun. Un dépôt Git décentralisé mondial se forme ainsi, dont les données sont répliquées et dupliquées sur différents systèmes des participants.

Pour identifier les nœuds voisins dans le réseau P2P, le protocole Gossip est utilisé, et pour la réplication des données entre les nœuds, le protocole Heartwood, basé sur Git. Étant donné que le protocole repose sur Git, la plateforme s'intègre facilement avec les outils existants pour le développement avec Git. Pour identifier les nœuds et vérifier les dépôts, une cryptographie basée sur des clés publiques est utilisée, sans recourir à des comptes. L'authentification et l'autorisation se font sur la base de clés publiques sans autorité de certification centralisée. serveurs.

Chaque dépôt dans un réseau P2P possède son propre identifiant unique et est auto-certifié, c'est-à-dire que toutes les actions dans le dépôt, telles que l'ajout de commits et les commentaires sur les issues, sont validées par le propriétaire à l'aide d'une signature numérique, permettant ainsi de vérifier l'exactitude des données sur d'autres nœuds sans utiliser de centres de certification centralisés. Pour accéder au dépôt, il suffit qu'au moins un nœud en ligne possède sa copie répliquée.

Les nœuds dans le réseau P2P peuvent s'abonner à des dépôts spécifiques et recevoir des mises à jour. Il est possible de créer des dépôts privés, accessibles uniquement à certains nœuds. La gestion et la propriété d'un dépôt utilisent le concept de « délégués ». Un délégué peut être un utilisateur individuel, un bot ou un groupe, liés à un identifiant spécial. Les délégués peuvent accepter des patchs dans le dépôt, fermer des issues et définir des droits d'accès au dépôt. Plusieurs délégués peuvent être associés à chaque dépôt.

Les dépôts Radicle sont stockés sur les systèmes des utilisateurs sous forme de dépôts git ordinaires, qui contiennent des espaces de noms supplémentaires pour stocker les données des pairs et des forks avec lesquels le travail actuel est effectué. Les discussions, les patchs proposés et les composants pour l'organisation de la révision sont également conservés dans le dépôt git sous forme d'objets collaboratifs (COB - Collaborative Objects) et sont répliqués entre les pairs.

Dans cette nouvelle version :

• Le support des dépôts bare, qui ne contiennent pas de répertoire de travail avec une copie des fichiers du projet mais stockent uniquement l'historique des modifications et des métadonnées telles que des branches et des tags, a été amélioré. Une option « —bare » a été ajoutée à la commande « rad clone », permettant de cloner un dépôt en mode sans répertoire de travail. La commande « git-remote-rad » a amélioré le traitement des dépôts bare lors de l'utilisation des commandes « git push » et « git fetch » vers un serveur rad externe.
• Une nouvelle option « patch.branch » a été ajoutée, pouvant être utilisée avec l'outil git-remote-rad ( « git-remote-rad -o patch.branch[=<name>] ») lors de l'ajout d'un patch pour créer automatiquement une branche dans le dépôt upstream, sans avoir besoin d'utiliser la commande « rad patch checkout ».
• La sortie de la commande « rad patch show » a été améliorée, montrant désormais la version d'origine du patch, qui était précédemment affichée uniquement avec l'option « —verbose ». Toutes les révisions sont désormais présentées dans une chronologie unique, sans séparation entre les modifications de l'auteur d'origine et celles des autres participants.
• La possibilité d'afficher les journaux dans un format structuré a été ajoutée, activable via les options « —log-logger structured » et « —log-format json ».

Source : opennet.ru