Protocole & stack Radicle Heartwood
- Radicle Heartwood est la troisième version du protocole Radicle, une stack de collaboration et de publication de code entre pairs.
- Ce dépôt contient l’implémentation complète de Heartwood, y compris une interface en ligne de commande conviviale (
rad) et le démon réseau (radicle-node).
- Radicle est conçu pour remplacer des forges de code comme GitHub et GitLab, en tant qu’alternative sûre, distribuée et robuste qui préserve la souveraineté et la liberté des utilisateurs.
Prérequis d’installation
- Un système d’exploitation Linux ou de type Unix est requis.
- Git 2.34 ou version ultérieure est requis.
- OpenSSH 9.1 ou version ultérieure ainsi que
ssh-agent sont requis.
Installation à partir des binaires
curl et tar sont requis.
- Pour installer la dernière release binaire, exécutez la commande suivante :
sh <(curl -sSf https://radicle.xyz/install)
Installation depuis les sources
- La toolchain Rust est requise.
- Depuis l’intérieur de ce dépôt, vous pouvez installer la stack Radicle depuis les sources en exécutant les commandes suivantes :
cargo install --path radicle-cli --force --locked
cargo install --path radicle-node --force --locked
cargo install --path radicle-remote-helper --force --locked
- Vous pouvez aussi l’installer directement depuis le seed node :
cargo install --force --locked --git https://seed.radicle.xyz/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \ radicle-cli radicle-node radicle-remote-helper
Exécution
- Des fichiers d’unité Systemd pour le démon système et le démon HTTP sont fournis dans le dossier
/systemd. Ils peuvent servir de point de départ pour des personnalisations supplémentaires.
- De plus, des
Dockerfile sont inclus dans les deux crates.
- Pour savoir comment l’exécuter en mode debug, consultez
HACKING.md.
Contribuer
- Pour une introduction à la manière de contribuer à Radicle, consultez
CONTRIBUTING.md et HACKING.md.
Licence
- Radicle est distribué selon les termes de la licence MIT et de l’Apache License (Version 2.0).
- Pour plus de détails, consultez
LICENSE-APACHE et LICENSE-MIT.
Avis de GN⁺
- Radicle est une plateforme distribuée de collaboration sur le code qui vise à renforcer la souveraineté des utilisateurs sur leur code en tant qu’alternative aux services centralisés d’hébergement de code. Cela représente une valeur très importante pour les développeurs en leur donnant le contrôle de la propriété de leurs données et de leur vie privée.
- Le réseau distribué proposé par Radicle présente l’avantage de ne pas dépendre d’un serveur central, ce qui le rend plus résilient face aux interruptions de service et à la censure. En revanche, cela peut affecter la stabilité et la vitesse du réseau, avec un impact potentiellement négatif sur l’expérience utilisateur.
- Radicle est un projet open source qui continue d’évoluer grâce aux contributions de la communauté des développeurs. Cela offre l’avantage de pouvoir réagir rapidement à la résolution de problèmes techniques ou à l’ajout de nouvelles fonctionnalités.
- Avant d’adopter Radicle, il faut prendre en compte la compatibilité avec les services centralisés existants, les exigences de sécurité du projet, ainsi que les freins potentiels à son adoption au sein de l’équipe.
- Parmi les autres projets offrant des fonctionnalités similaires, on peut citer la version auto-hébergée de GitLab ou des alternatives open source comme Gitea, qui permettent aux utilisateurs de gérer leur code sur leur propre serveur.
1 commentaires
Avis Hacker News
Salutations de la part d’un cofondateur du projet, avec un lien expliquant le fonctionnement interne du protocole. La documentation est encore en cours de rédaction.
Le projet semble bien correspondre à son objectif, mais l’idée est que git est déjà open source et P2P. Avec git, on peut déjà se connecter à un autre serveur et récupérer ou fusionner du code sans binaire supplémentaire. Ce qui manque à git, ce sont les issues, les wikis, les discussions, les pages GitHub, et surtout le réseau de profils développeurs. Il faudrait un moyen d’inclure les métadonnées du projet dans
.git, éventuellement via des références séparées pour ne pas confondre wiki et issues.Il est très intéressant de suivre l’évolution de Radicle. Après avoir assisté à un atelier lors de Protocol Berg 2023, l’impression est qu’ils ont construit quelque chose de très puissant et nouveau. L’aspect le plus intéressant est que la collaboration du protocole est elle aussi pensée en local-first : on peut soumettre des patchs et des issues sans Internet, et l’équipe n’est pas affectée quand GitHub rencontre des problèmes.
Question sur la raison d’utiliser à la fois les licences MIT et Apache. Interrogation sur le fait que la licence MIT ne permette pas de contourner les obligations supplémentaires prévues par la licence Apache, en particulier la clause d’octroi de licence de brevet. Comme la licence MIT ne mentionne pas les brevets, pourquoi ne pas utiliser uniquement la licence MIT ?
Question sur la facilité avec laquelle le grand public peut découvrir ces dépôts. L’absence de fichier
robots.txtsemble permettre l’indexation par les moteurs de recherche. Des résultats apparaissent bien sur Google et DDG, mais pas encore très haut. Cela pourrait s’améliorer. Des outils intégrant le support CI seraient aussi intéressants. Il faudrait de meilleurs outils pour limiter les pushes à des identités de confiance. Enfin, mention d’un dépôt d’artefacts. Radicle n’a pas besoin de tout résoudre, surtout que le partage de gros binaires via un réseau distribué peut vite être détourné vers des usages indésirables.Félicitations pour le lancement, avec enthousiasme à voir le projet mûrir. Question sur la manière de migrer des projets actuellement sur GitHub et sur l’existence éventuelle d’un mode miroir pendant les tests.
La documentation précise qu’il est important de ne publier que les dépôts que l’on possède ou administre, et de communiquer avec les autres mainteneurs pour éviter d’initialiser des identités de dépôt en double. Mais il est probable que certains ignorent cette consigne faute de lire la documentation attentivement. La page d’accueil explique comment pousser du code, alors que cet avertissement essentiel n’est visible que dans le guide utilisateur, ce qui peut poser problème.
Souhait que des termes comme "peer to peer" ou "distributed" soient définis avec précision, car ils deviennent très vagues lorsqu’ils sont utilisés comme buzzwords.
Félicitations pour la sortie, rappelant un projet similaire,
nest.pijul.com, qui utilise pijul au lieu de git.Remarque hors sujet évoquant NESticle.