Radicle se présente comme un réseau de collaboration de code décentralisé. Radicle s'appuie sur la familiarité de GitHub et de GitLab en tant que référentiels centralisés pour la collaboration sur le code, en tirant parti de toutes les fonctionnalités du système de contrôle de version Git et en y ajoutant la décentralisation, tout en intégrant également un certain nombre de fonctionnalités d'identité Web3.Vous pouvez démarrer un projet Radicle en clonant un élément stocké dans un dépôt Git. Ainsi, si vous utilisez déjà Git, mais que vous souhaitez vous éloigner de l'un des référentiels centralisés, l'expérience d'intégration est assez transparente. Vous pouvez voir dans la démonstration de la vidéo que l'interface en ligne de commande vous semblera familière. Une différence fondamentale entre le modèle centralisé de GitHub et l'approche de Radicle pour le contrôle de version est qu'il n'y a pas un seul master immuable dans lequel les contributeurs fusionnent - chaque pair maintient une version ramifiée du projet avec les changements qu'il est intéressé à maintenir.
Pourquoi Radicle ?
La plupart des projets open-source sont généralement hébergés sur GitHub ou d’autres alternatives comme GitLab. Bien que ces plateformes offrent de nombreux avantages et fonctionnalités (sans parler de la visibilité potentielle), elles présentent également des inconvénients. Par exemple, le projet youtube-dl a été retiré par Microsoft suite à une demande de retrait DMCA. Avec une approche centralisée, vous n’avez pas un contrôle total et votre vie privée peut être compromise.
Comment ça marche ?
Le protocole réseau Radicle se concentre sur la localisation, la réplication et la vérification des référentiels dans un réseau d'hébergement de code peer-to-peer. Son approche décentralisée garantit l'accès aux référentiels, quel que soit leur emplacement ou leur nombre de répliques.
Au cœur de Radicle se trouve un Gossip Protocol (un algorithme distribué dans un réseau informatique pair à pair pour propager l'information à tous les agents du réseau) pour l'échange de métadonnées entre les nœuds, identifiés par des clés publiques. Les nœuds diffusent des informations sur le référentiel pour créer des tables de routage qui facilitent la découverte et la réplication du référentiel.
En tirant parti de Git, Radicle permet un transfert de données efficace et offre une compatibilité avec les flux de travail existants.
Caractéristiques de Radicle
- Possibilité d'ajouter plusieurs pairs distants
- Gérer plusieurs pairs
- Fonctionnalité pour suivre un projet d'un pair spécifique
- Partagez votre projet en utilisant un identifiant unique
- Ne dépend pas des serveurs centraux
- Pas de censure
- Un réseau interconnecté avec ses pairs
- Possibilité de travailler hors ligne
- Problèmes et correctifs locaux
- Construit sur Git pour le rendre simple et confortable pour la plupart des développeurs
- Votre infrastructure
- Possibilité de recevoir des financements de vos supporters (Ethereum)
- Gérer les bases de code ensemble
Radicle Stack
Radicle fonctionne comme un protocole peer-to-peer dans lequel chaque utilisateur du réseau exécute un logiciel identique, connu sous le nom de Radicle Stack. Cette pile se compose principalement d'une interface de ligne de commande et d'un service en réseau appelé Radicle Node.
Les nœuds échangent des données via un protocole de potins, formant un réseau résilient et tolérant aux perturbations.
Les utilisateurs peuvent également choisir d'exécuter le client Web Radicle et le démon HTTP, offrant une expérience Web familière pour une accessibilité et une commodité améliorées.
D'accord mais est-ce utile ?
Le projet semble intéressant, en tout cas pour l'objectif qu'il vise.
Git est de loin le système de contrôle de version le plus largement utilisé aujourd'hui. Git est un projet open source avancé, qui est activement maintenu. Par sa structure décentralisée, Git illustre parfaitement ce qu'est un système de contrôle de version décentralisé (DVCS). Plutôt que de consacrer un seul emplacement pour l'historique complet des versions du logiciel comme c'était souvent le cas dans les systèmes de contrôle de version ayant fait leur temps, comme CVS et Subversion (également connu sous le nom de SVN), dans Git, chaque copie de travail du code est également un dépôt qui contient l'historique complet de tous les changements.
Github, quant à lui, est un service en ligne qui permet entre autre d’héberger des dépôts Git. Il est totalement gratuit pour des projets ouverts au public mais il propose également des formules payantes pour les projets que l’on souhaite rendre privés.
Github propose également de nombreux autres services très intéressants comme par exemple:
- Partager du code source avec d’autres développeurs.
- Signaler et gérer les problèmes ou bugs de votre code source via les issues.
- Partager des portions de code via les Gists
- Proposer des évolutions pour un projet opensource.
- Et bien plus encore
Alors est-ce que Radicle apporte une plus-value ?
Bien que Git soit conçu d’une manière ou d’une autre pour les interactions peer-to-peer, aucun déploiement ne fonctionne de cette façon. Tous les déploiements utilisent le modèle client-serveur car Git ne dispose pas de fonctionnalités permettant d'être déployé tel quel dans un réseau peer-to-peer. De plus, difficile de vérifier que le référentiel que vous avez téléchargé après un « clone git » est celui que vous avez demandé, ce qui signifie que vous devez cloner à partir d'une source fiable (c'est-à-dire un serveur connu). Une situation difficilement compatible avec P2P.
Radicle résout ce problème en attribuant des identités stables aux référentiels qui peuvent être vérifiés localement, permettant ainsi aux référentiels d'être servis par des parties non fiables.
La partie qui nous intéresse dans la documentation de Radicle est celle sur la « confiance grâce à l'autocertification » :
Contrairement aux forges centralisées telles que GitHub, où les dépôts sont considérés comme authentiques en fonction de leur emplacement (par exemple https://github.com/bitcoin/bitcoin), dans un réseau décentralisé comme Radicle, l'emplacement n'est pas suffisant. Au contraire, nous avons besoin d'un moyen de vérifier automatiquement les données que nous obtenons à partir de n'importe quel endroit. En effet, dans un réseau décentralisé, les pairs peuvent être malhonnêtes. L'approche de Radicle repose sur la nature auto-certifiante de ses référentiels, ancrée dans le document d'identité du référentiel.
Branches canoniques
Lorsque les dépôts sont hébergés dans un endroit connu et fiable, la mise à jour de la branche canonique du dépôt (par exemple, master) est simplement une question de pousser vers la branche de ce dépôt. L'autorisation de pousser est accordée à un petit groupe de responsables, et n'importe lequel d'entre eux est autorisé à mettre à jour la branche.
Dans Radicle, en l'absence d'un emplacement central où les dépôts sont hébergés, la branche canonique est établie dynamiquement sur la base du seuil de signature défini dans le document d'identité du dépôt. Par exemple, si un seuil de deux délégués sur trois est défini, avec la branche par défaut définie comme master, et que deux délégués ont poussé le même commit vers leurs branches master, ce commit est reconnu comme l'état autorisé et canonique du référentiel.
Note : Actuellement, seule la branche spécifiée dans l'attribut defaultBranch du document d'identité est définie automatiquement sur la base d'un seuil de signature. À l'avenir, d'autres branches pourront être prises en charge.
Référentiels auto-certifiants
Ensemble, le RID [ndlr. Repository Identifier] d'un référentiel et son document d'identité créent une preuve cryptographique qui sert de base à la vérification de tous les états du référentiel jusqu'à son état actuel. C'est pourquoi nous disons que les référentiels Radicle sont auto-certifiés : le processus de vérification ne nécessite aucune entrée autre que le référentiel lui-même.
Pour que les référentiels soient auto-certifiés, les délégués authentifient chaque modification apportée aux données et métadonnées du référentiel par le biais de signatures cryptographiques. Cela inclut toutes les références Git publiées sur le réseau.
Ensemble, le RID [ndlr. Repository Identifier] d'un référentiel et son document d'identité créent une preuve cryptographique qui sert de base à la vérification de tous les états du référentiel jusqu'à son état actuel. C'est pourquoi nous disons que les référentiels Radicle sont auto-certifiés : le processus de vérification ne nécessite aucune entrée autre que le référentiel lui-même.
Pour que les référentiels soient auto-certifiés, les délégués authentifient chaque modification apportée aux données et métadonnées du référentiel par le biais de signatures cryptographiques. Cela inclut toutes les références Git publiées sur le réseau.
Et vous ?
Quelle est votre opinion sur la centralisation des plateformes de développement collaboratif comme GitHub ? Pensez-vous que les projets open-source devraient explorer davantage les alternatives peer-to-peer comme Radicle ? Pourquoi ou pourquoi pas ? Comment percevez-vous l’importance de la censure dans les plateformes de développement ? Radicle, en tant qu’alternative, offre-t-il une meilleure protection contre la censure ? Avez-vous déjà utilisé Radicle ou envisagez-vous de l’essayer pour vos projets ? Quelles sont vos attentes ? Quels autres avantages ou inconvénients voyez-vous dans l’utilisation de Radicle par rapport aux plateformes traditionnelles ?