- Radicle Heartwood est la troisième implémentation du protocole Radicle et fournit une stack de collaboration et de publication de code en pair à pair, sans forge de code centralisée
- Le dépôt inclut l’outil en ligne de commande
rad utilisé directement par les développeurs, ainsi que le démon réseau radicle-node
- Le projet est conçu comme un remplacement des forges de code comme GitHub et GitLab, avec comme objectifs principaux la sécurité et la décentralisation, ainsi que la préservation de la souveraineté des utilisateurs
- L’environnement requis est Linux ou un système de type Unix, avec Git 2.34 ou supérieur et OpenSSH 9.1 ou supérieur incluant
ssh-agent
- L’installation est possible via binaire ou depuis les sources Rust, mais les retours envoyés par e-mail sont automatiquement publiés sur un canal Zulip public, ce qui peut exposer le nom et l’adresse e-mail
Ce que propose Radicle Heartwood
- Heartwood est la troisième itération du protocole Radicle et constitue une stack complète pour la collaboration et la publication de code en pair à pair
- Le dépôt contient les principaux composants nécessaires à l’implémentation de Heartwood
rad : une interface en ligne de commande convivialeradicle-node : le démon réseau
- Radicle est conçu comme une alternative aux forges de code telles que GitHub et GitLab
- Son objectif est de préserver la sécurité, la décentralisation, ainsi que la souveraineté et la liberté des utilisateurs
- Des informations générales sont disponibles sur la page d’accueil de Radicle
- Les échanges autour du projet ont lieu sur le chat Zulip
- Le fonctionnement de Radicle est détaillé dans le Guide du protocole
Installation et exécution
- Les prérequis d’installation sont les suivants
- un système d’exploitation Linux ou de type Unix
-
Git 2.34 ou supérieur
- OpenSSH 9.1 ou supérieur avec
ssh-agent
- L’installation des binaires nécessite
curl et tar, et la dernière version se récupère avec la commande suivante
curl -sSf https://radicle.dev/install | sh
- Les binaires peuvent également être téléchargés depuis la page [download](https://radicle.dev/download)
- Pour installer depuis les sources, il faut disposer de la **toolchain Rust** et exécuter les commandes suivantes dans le dépôt
cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle
- Il est aussi possible d’installer directement depuis un seed node
cargo install --force --locked --root ~/.radicle \
--git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
crates/radicle-cli crates/radicle-node crates/radicle-remote-helper
- Les fichiers **systemd unit** pour le nœud se trouvent dans le dossier `/systemd` et peuvent servir de point de départ pour des personnalisations supplémentaires
- Pour une exécution en mode debug, voir [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md)
Retours, contribution, licence
- Les retours peuvent être envoyés via
rad issue, Zulip, ou feedback@radicle.dev
- Les retours envoyés par e-mail sont automatiquement publiés dans le canal public #feedback de Zulip
- Lors de cette publication, l’en-tête
From est rendu public et contient généralement le nom et l’adresse e-mail
- Les consignes de contribution sont disponibles dans CONTRIBUTING.md et HACKING.md
- Radicle est distribué sous les termes des licences MIT et Apache License 2.0
- Les détails sont disponibles dans LICENSE-APACHE et LICENSE-MIT
1 commentaires
Commentaires sur Hacker News
Je suis le cofondateur de Radicle. Si vous êtes curieux du fonctionnement interne du protocole, le mieux est de commencer par la documentation : https://docs.radicle.xyz/
La documentation est encore en cours de rédaction.
Si, au fond, c’est une application de partage de fichiers P2P, je me demande à quel niveau du protocole les abus sont gérés. Sinon, je ne vois pas bien ce qui la distingue des applications de partage de fichiers de la génération précédente, comme BitTorrent ou Winny, qui servaient à diffuser librement des contenus protégés comme des films, de la musique ou des logiciels. J’ai l’impression qu’une petite minorité malveillante pourrait tout gâcher, et je me demande aussi s’il est possible d’isoler des réseaux « privés » pour être sûr de ne pas participer à des activités illégales.
Crunchbase indique 12 millions de dollars levés, donc j’imagine qu’il y a un plan de monétisation.
Pour le type de projets sur lesquels j’interviens, cela peut être rédhibitoire. Le code semble être en Rust, donc je me demande s’il existe un projet de prise en charge de MS Windows. J’imagine que Mac OS entre dans la catégorie Unix, non ? Même sans support officiel de Windows, je serais curieux de savoir si un port MSYS2 est envisageable.
Pour donner un peu de contexte, je ne suis pas en position de prendre des décisions du type choix de prestataire, mais je suis lié à une organisation parapublique qui héberge une base de code open source importante sur GitHub. J’ai parfois l’occasion de proposer certaines idées, mais je n’ai pas le pouvoir de décider de leur adoption. Cette organisation est très motivée par l’idée d’être résiliente face aux politiques des fournisseurs privés, et de faire aussi des « bonnes choses » comme la durabilité ou l’accessibilité large. Organisation gouvernementale européenne typique, elle voit GitHub comme quelque chose qui entre en conflit avec ce type de politique.
D’autres organismes publics s’occupent de l’archivage ou du support réseau, mais ils manquent souvent de compétences ou restent bloqués dans des approches anciennes, et tombent régulièrement dans les pièges tendus par les fournisseurs. Par exemple, un service d’archivage a adopté DataBricks à grande échelle sans même savoir qu’il s’agit d’un produit commercial fermé et propriétaire. Donc j’ai peu d’espoir qu’ils tirent réellement parti d’une solution auto-hébergée, et une approche distribuée me paraît plus prometteuse. En revanche, un outil qui ne fonctionne pas sur les principaux environnements PC grand public ne sera pas utilisable.
Je me demande aussi quel niveau d’adoption vous anticipiez au début, puis maintenant, et si les résultats réels ont correspondu à ces attentes.
C’était intéressant de voir comment Radicle a évolué au cours des cinq dernières années environ. J’ai assisté à l’atelier Protocol Berg 2023, et j’ai l’impression qu’ils ont construit quelque chose de vraiment puissant et nouveau.
Ce qui est particulièrement intéressant, c’est que même les fonctions de collaboration sont local-first. On peut soumettre des patches et des issues sans connexion Internet, et toute l’équipe n’a plus besoin d’être collée à HN chaque fois que GitHub a un problème.
Ça semble être un bon projet pour son objectif, mais je considère que Git lui-même est déjà open source et P2P. Pas besoin de récupérer des binaires via
sh <(curl): il suffit de se connecter à un autre serveur Git et de récupérer ou fusionner directement le code avec les commandes Git.Ce qui manque à Git, ce sont les issues, les wikis, les discussions, GitHub Pages, et surtout le réseau de profils développeurs. Il faudrait un moyen de mettre les métadonnées du projet dans
.gitlui-même, pour que les commits de code ne soient pas mélangés avec le wiki ou les issues. Des références indépendantes commegit notespourraient peut-être convenir.https://git-scm.com/docs/git-notes
Par exemple, quand je fais un
git clone, je n’ai aucun moyen de vérifier que le dépôt reçu est bien celui que j’ai demandé. Je dois donc cloner depuis une source de confiance, autrement dit un serveur connu. Ce n’est pas compatible avec un P2P réellement pratique.Radicle résout ce problème en attribuant au dépôt un identifiant stable et vérifiable localement[0], ce qui permet à des entités non fiables d’héberger le dépôt.
[0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
Sur mobile, on peut voir l’onglet de suivi des issues et celui des pull requests, entre autres, en appuyant sur les boutons au bas du lien source.
Il me semble que Gerrit stockait autrefois les revues de code dans Git.
La documentation indique qu’il est « important de ne publier que les dépôts dont on est propriétaire ou mainteneur, et de communiquer avec les autres mainteneurs afin d’éviter de créer des identifiants de dépôt en doublon ».
J’ai déjà vu des gens reprendre mon code et le mettre sur GitHub, et j’ai souvent constaté que même lorsqu’on affiche dans la documentation produit ou dans l’interface intermédiaire un message du type « s’il vous plaît, ne faites pas X, cela pose des problèmes aux autres utilisateurs », personne ne le lit, n’y réfléchit ni n’y prête attention, et ils font immédiatement X. Du coup, j’ai l’impression que beaucoup de gens ne respecteront pas cette demande de la documentation, d’autant plus que la page d’accueil explique seulement comment pousser du code, tandis que cette demande « importante » se trouve dans le guide utilisateur que presque personne ne lit.
Au final, il est assez inquiétant qu’un comportement qui paraît raisonnable — simplement pousser du code open source en cours de travail en suivant les instructions de la page d’accueil — puisse, avec le temps, perturber ou embrouiller quelque chose d’important à cause du protocole et du mode de stockage
Sur GitHub, on peut gagner en crédibilité grâce au nombre d’étoiles, et sur Radicle l’équivalent est le nombre de seeds d’un dépôt donné
En général, on voit des dizaines d’indications au cours d’une journée passée sur ordinateur, et on utilise aussi des dizaines d’outils. Si l’on pense au temps qu’il faudrait pour tout lire et pour parcourir minutieusement la documentation de chaque outil, ce serait bien trop long.
Il vaut donc bien mieux ne pas tout lire et utiliser des heuristiques. Par exemple, si l’on ferme un document avec des modifications non enregistrées, on sait qu’une boîte de dialogue demandera « abandonner ? », donc il n’est pas nécessaire de la lire. Et c’est une bonne chose.
La conclusion, c’est qu’il faut concevoir les logiciels en partant du fait que les gens se comportent ainsi. En général, c’est possible. S’il y a des exemples concrets, on pourra sans doute proposer une meilleure solution qu’une approche consistant à « demander et espérer que les gens lisent »
Félicitations pour le lancement. Je suis ce projet depuis un moment, et c’est vraiment enthousiasmant de voir à quel point il a gagné en maturité. Je me demande quelle est la meilleure façon de migrer un projet actuellement sur GitHub. Je me demande aussi s’il existe un mode miroir pour l’essayer
cronqui récupère depuis GitHub chaque heure puis pousse vers Radicle.git pull github mastergit push rad masterJe me demande à quel point ces dépôts seront découvrables pour les utilisateurs ordinaires. Il ne semble pas y avoir de https://app.radicle.xyz/robots.txt, donc les moteurs de recherche semblent autorisés à les indexer, et en pratique on obtient bien des résultats sur Google et DDG avec
site:app.radicle.xyz.Ils ne remontent pas encore en haut des résultats sans filtre de site, mais leur classement pourrait s’améliorer.
Il serait aussi utile d’avoir des outils d’intégration avec le support CI. Au final, ce sera peut-être juste une boucle comme
while true; do wait_repo_update; git pull && ./run_ci.sh; done, mais il faudrait une forme meilleure permettant de limiter cela aux pushes provenant d’identifiants de confiance.Enfin, il faudra aussi un dépôt pour les artefacts. Cela dit, Radicle n’a peut-être pas besoin de tout résoudre. En particulier, un réseau distribué de partage de gros binaires risque assez vite d’être utilisé à des fins indésirables
app.radicle.xyzdevraient probablement permettre aux crawlers d’indexer l’ensemble des dépôts du réseauJ’aimerais que les gens définissent clairement ce que signifie exactement « P2P » ou, plus couramment, « distribué ». En ce moment, c’est devenu un buzzword vague au point de pouvoir vouloir tout et n’importe quoi
Donc, un système P2P est un système dans lequel tous les participants ont des « privilèges équivalents au sein du réseau ». En général, cela signifie aussi que tous exécutent le même logiciel.
[0]: https://en.wikipedia.org/wiki/Peer-to-peer
Voir des instructions d’installation du type
curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh, c’est le genre de truc qui fait immédiatement retomber tout enthousiasme face à cette cochonnerie de curl-bashCe mode d’installation est un signal fort de développement irréfléchi. Si ce projet décolle, on risque d’assister à une catastrophe de sécurité. J’espère qu’un jour sortira une « alternative open source P2P à GitHub » qui ne commencera pas par la pire méthode d’installation possible
Beaucoup de gens connaissent bien les risques des installateurs exécutés via pipe. Avec cette logique, il faudrait aussi rejeter Homebrew [1](GitHub avec plus de 38 k étoiles), PiHole [2](plus de 46 k étoiles), Chef [3], RVM [4] et les innombrables projets open source qui utilisent un installateur automatique en une étape pipé vers
bashUne réaction plus raisonnable serait de travailler avec les développeurs pour proposer des méthodes d’installation alternatives dans la documentation, ou mieux expliquer les risques, plutôt que de tout incendier pour un problème limité
[1] https://brew.sh/
[2] https://github.com/pi-hole/pi-hole
[3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
[4] https://rvm.io/rvm/install
Concernant le problème d’interruption du transfert, le script est sûr à moins que votre système ne contienne des commandes dangereuses correspondant à
^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?)Une fois ce point réglé, je me demande bien quelle différence cela fait entre fournir uniquement le script et fournir aussi la commande pour l’exécuter. Si vous voulez l’examiner, vous pouvez télécharger le script et l’exécuter séparément. Il me semble qu’il existait un moyen de détecter la différence entre un script pipé et un script téléchargé, mais cela ne fonctionnerait probablement pas pour un script aussi petit
[0] https://files.radicle.xyz/latest/
[1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
J’ai l’impression d’entendre parler de Radicle à chaque fois que le marché crypto repart à la hausse. Il y a vraiment des gens qui l’utilisent sérieusement ?
Wow, ça a été downvoté en un instant. Je pose la question sérieusement : j’aimerais savoir quel budget a été consacré à Radicle, combien de personnes ont travaillé dessus et qui l’utilise
Je travaille dans le secteur crypto et j’ai eu la même impression. La dernière fois que j’ai entendu parler de Radicle, c’était pendant le précédent marché haussier, et pendant le marché baissier c’était le silence. Tout le monde dit que le marché baissier est le moment de construire, et Radicle est clairement un outil pour développeurs, donc c’est assez étrange
Je me demande s’il est prévu de prendre en charge des cas d’usage où l’on ne fournit les dépôts qu’à un ensemble spécifique de nœuds. J’imagine qu’il y a des gens qui ne veulent pas être sur GitHub mais qui veulent quand même faire de la collaboration privée
En revanche, ils ne sont pas chiffrés au stockage, donc ils ne peuvent pas être stockés sur des nœuds intermédiaires qui ne font pas partie de l’ensemble de confiance