Le Réseau des Pairs

Collaboration P2P, delegates, passerelles GitHub et écosystème Radicle

Workflow d'équipe sur Radicle

Sur GitHub, la collaboration passe par un serveur central : tu forks, tu push, tu ouvres une PR. Sur Radicle, il n'y a pas de serveur central. Le workflow est fondamentalement différent.

Le workflow pair-à-pair

# Workflow classique GitHub :
# 1. Fork le dépôt (sur le serveur)
# 2. Clone ton fork
# 3. Push ta branche
# 4. Ouvre une Pull Request (sur le serveur)
# 5. Le mainteneur merge (sur le serveur)

# Workflow Radicle :
# 1. Clone le projet : rad clone rad:z...
# 2. Crée ta branche et code
# 3. Propose un patch : rad patch create
# 4. Le mainteneur revoit et merge : rad patch merge
# 5. Tout le monde synchronise : rad sync

La différence fondamentale : sur Radicle, chaque pair possède sa copie complète du projet, incluant les patches, issues et métadonnées. Il n'y a pas de "source de vérité" unique sur un serveur. La source de vérité est le consensus entre les delegates du projet.

Un scénario concret

Imagine trois développeurs - Alice, Bob et Carol - qui travaillent ensemble sur un projet Radicle :

# Alice crée le projet
# (sur la machine d'Alice)
rad init
rad push

# Bob clone le projet
# (sur la machine de Bob)
rad clone rad:z2e7R...

# Bob propose une amélioration
git switch -c ajout-tests
# ... code ...
git commit -m "Ajouter les tests unitaires"
rad patch create

# Alice revoit le patch de Bob
# (sur la machine d'Alice)
rad sync                          # Récupère le patch de Bob
rad patch list                    # Voit le patch
rad patch show <id>              # Examine les changements
rad patch comment <id> --message "Approuvé !"
rad patch merge <id>             # Fusionne

# Carol synchronise pour avoir la dernière version
# (sur la machine de Carol)
rad sync
git pull

Gestion de projet - delegates et permissions

Sur un projet Radicle, la gouvernance repose sur le concept de delegates (délégués). Ce sont les personnes de confiance qui ont le pouvoir de fusionner des patches et de prendre des décisions sur le projet.

Les delegates

Quand tu crées un projet avec rad init, tu deviens automatiquement le seul delegate. Tu peux ensuite en ajouter d'autres :

# Voir les delegates actuels du projet
rad inspect

# Modifier les delegates du projet
rad id edit

Le threshold (seuil)

Le threshold définit combien de delegates doivent approuver un changement pour qu'il soit considéré comme valide. Par défaut, le threshold est de 1 (un seul delegate suffit).

# Avec 3 delegates et threshold=2 :
# Il faut l'accord de 2 delegates sur 3 pour merger un patch
# C'est un système de vote à la majorité

# Modifier le threshold (via rad id edit)
rad id edit

Ce mécanisme est puissant : il permet de créer une gouvernance démocratique sans aucune autorité centrale. C'est similaire aux systèmes de multi-signature en cryptographie.

Visibilité du projet

Un projet Radicle peut avoir différents niveaux de visibilité :

• Public : tout pair qui connaît le RID peut cloner et contribuer. C'est le comportement par défaut
• Privé : seuls les pairs explicitement autorisés peuvent accéder au projet. Utile pour les projets d'entreprise ou les travaux en cours

Revue de patches en équipe

La revue de code est aussi importante sur Radicle que sur GitHub. Les outils sont différents, mais le principe reste le même : relire, commenter, améliorer.

Examiner un patch

# Lister les patches en attente
rad patch list --state open

# Voir le détail d'un patch (titre, auteur, commits)
rad patch show <patch-id>

# Voir le diff du patch
rad patch diff <patch-id>

Commenter et discuter

# Ajouter un commentaire général
rad patch comment <patch-id> --message "Le code est propre, mais il manque la gestion d'erreurs."

# Les commentaires sont signés et propagés à tous les pairs
# Chaque contributeur peut voir la discussion complète

Réviser formellement

# Approuver un patch (revue positive)
rad patch review <patch-id> --accept

# Demander des modifications
rad patch review <patch-id> --reject --message "Il faut corriger les tests avant de merger."

Le cycle de vie d'un patch

# 1. Création       : rad patch create        (état: open)
# 2. Discussion     : rad patch comment       (état: open)
# 3. Revue          : rad patch review        (état: open)
# 4a. Acceptation   : rad patch merge         (état: merged)
# 4b. Rejet         : rad patch close         (état: closed)
# 5. Mise à jour    : rad patch update        (l'auteur pousse de nouveaux commits)

Passerelles avec GitHub

Le monde ne va pas migrer vers Radicle du jour au lendemain. La plupart de tes collègues et des projets open source utilisent GitHub. Heureusement, Radicle et GitHub peuvent coexister.

Pourquoi des passerelles ?

• Transition progressive : tu peux commencer à utiliser Radicle sans abandonner GitHub
• Redondance : ton code existe à la fois sur GitHub et sur le réseau Radicle
• Accessibilité : les contributeurs qui ne connaissent pas Radicle peuvent toujours passer par GitHub

Mirroring bidirectionnel

Le mirroring consiste à synchroniser un dépôt entre GitHub et Radicle dans les deux sens :

# Ton dépôt a deux remotes :
git remote -v
# origin     git@github.com:ton-user/ton-projet.git (GitHub)
# rad        rad://z2e7R... (Radicle)

# Push vers les deux en même temps
git push origin main
rad push

# Ou configure un alias pour pousser partout
git config alias.push-all '!git push origin main && rad push'
git push-all

radicle-ci-broker

Le radicle-ci-broker est un outil qui connecte les patches Radicle à des systèmes de CI existants. Quand un patch est créé sur Radicle, le broker peut déclencher un pipeline GitHub Actions ou GitLab CI :

# Principe du CI broker :
# 1. Un patch arrive sur Radicle
# 2. Le broker détecte le nouveau patch
# 3. Il pousse le code vers GitHub (branche temporaire)
# 4. GitHub Actions exécute les tests
# 5. Le résultat est reporté sur le patch Radicle

C'est un pont entre le monde décentralisé et les outils de CI existants. À terme, Radicle développe ses propres solutions de CI, mais en attendant, le broker permet de ne rien perdre.

L'interface web Radicle

Radicle est avant tout un outil en ligne de commande, mais il existe des interfaces web pour ceux qui préfèrent le navigateur.

app.radicle.xyz

app.radicle.xyz est l'interface web officielle de Radicle. Elle permet de :

• Parcourir les projets publics du réseau
• Voir le code source, les commits, les branches
• Consulter les patches et les issues
• Découvrir de nouveaux projets

radicle-explorer (auto-hébergé)

Tu peux aussi héberger ta propre interface web avec radicle-explorer. C'est une application web qui se connecte à ton nœud local :

# Installer radicle-explorer (nécessite Node.js)
# Le code source est disponible sur GitHub :
git clone https://github.com/radicle-dev/radicle-explorer.git
cd radicle-explorer
npm install
npm run build

# Lancer en mode développement
npm run dev
# Ouvre http://localhost:3000

L'explorer se connecte à l'API HTTP de ton nœud Radicle et affiche les projets, patches et issues dans une interface web élégante.

Matrice de décision - quel outil choisir ?

Radicle n'est pas la réponse à tout. Voici une matrice pour t'aider à choisir l'outil adapté à chaque situation :

L'écosystème Radicle

Heartwood - le protocole

Heartwood est le nom du protocole qui fait tourner Radicle. C'est le "cœur de bois" - la fondation technique sur laquelle tout repose. Heartwood définit :

• Comment les pairs se découvrent et se connectent
• Comment les données sont répliquées entre les nœuds
• Le format des patches, issues et autres objets collaboratifs
• Le système d'identité basé sur les DIDs

Heartwood est écrit en Rust, un langage reconnu pour sa performance et sa sécurité mémoire. Le protocole est ouvert et documenté - n'importe qui peut implémenter un client compatible.

Les composants de l'écosystème

La roadmap

Radicle est en développement actif. Voici les axes d'évolution :

• Amélioration de l'UX : interface web plus riche, meilleure intégration IDE
• CI/CD natif : exécution de pipelines directement sur le réseau Radicle
• Notifications : être alerté des nouveaux patches et commentaires
• Performance : réplication plus rapide, meilleure gestion des gros dépôts
• Interopérabilité : passerelles améliorées avec GitHub, GitLab et Forgejo

Exercice pratique - Simuler une collaboration P2P

export RAD_HOME=~/.radicle-alice    # Premier profil
rad auth
export RAD_HOME=~/.radicle-bob      # Second profil
rad auth

# Crée deux dossiers de travail
mkdir -p ~/radicle-exercice/alice
mkdir -p ~/radicle-exercice/bob

# En tant qu'Alice
cd ~/radicle-exercice/alice

# Crée un dépôt Git
git init -b main projet-commun
cd projet-commun

# Crée du contenu
cat > README.md <<EOF
# Projet Commun
Un projet collaboratif sur le réseau Radicle.

## Contributeurs
- Alice (créatrice)
EOF

git add README.md
git commit -m "Initialisation du projet commun"

# Initialise Radicle
rad init
# Note le RID qui s'affiche : rad:z...

# En tant que Bob
cd ~/radicle-exercice/bob

# Clone le projet d'Alice
rad clone rad:z<le-rid-du-projet>
cd projet-commun

# Bob crée une branche et ajoute sa contribution
git switch -c ajout-contribution-bob

cat >> README.md <<EOF

## Fonctionnalités prévues
- Synchronisation pair-à-pair
- Revue de code décentralisée
- Issues sans serveur central
EOF

git add README.md
git commit -m "Ajouter les fonctionnalités prévues"

# Bob propose un patch
rad patch create

# De retour en tant qu'Alice
cd ~/radicle-exercice/alice/projet-commun

# Synchronise pour recevoir le patch de Bob
rad sync

# Voir les patches
rad patch list

# Examiner le patch
rad patch show <patch-id>

# Commenter
rad patch comment <patch-id> --message "Excellente contribution, Bob !"

# Merger le patch
rad patch merge <patch-id>

# Côté Alice - voir le résultat
cd ~/radicle-exercice/alice/projet-commun
git log --oneline
cat README.md

# Côté Bob - synchroniser
cd ~/radicle-exercice/bob/projet-commun
rad sync
git pull
git log --oneline

# Bob crée une issue
cd ~/radicle-exercice/bob/projet-commun
rad issue create --title "Ajouter un fichier LICENCE" \
                 --description "Le projet n'a pas encore de licence open source."

# Alice voit l'issue
cd ~/radicle-exercice/alice/projet-commun
rad sync
rad issue list

# Alice résout l'issue
echo "MIT License - Copyright $(date +%Y)" > LICENSE
git add LICENSE
git commit -m "Ajouter la licence MIT"
rad push

# Alice ferme l'issue
rad issue close <issue-id>

Récapitulatif