2 points par GN⁺ 2024-03-06 | 1 commentaires | Partager sur WhatsApp

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

 
GN⁺ 2024-03-06
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.

    Bonjour, Hacker News. Je suis le cofondateur de ce projet. Si vous êtes curieux de comprendre comment le protocole fonctionne en interne, commencez ici : Documentation Radicle. Cela dit, la documentation est encore en chantier.

  • 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.

    Ce projet semble bien conçu pour son objectif, mais git lui-même est déjà open source et P2P. Sans installer de binaire supplémentaire, on peut se connecter à un autre serveur git et récupérer ou fusionner du code directement avec les commandes git. Ce qui manque à git, ce sont les issues de code, les wikis, les discussions, les pages GitHub, et surtout le réseau de profils développeurs. Il faut un moyen d’inclure les métadonnées du projet dans .git. Il faudra peut-être des références indépendantes, comme avec git notes. Documentation git-notes

  • 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.

    Observer l’évolution de Radicle au cours des 5 dernières années a été passionnant. J’ai assisté à un workshop lors de Protocol Berg 2023, et je pense qu’ils ont construit quelque chose de très puissant et de nouveau. Ce qui m’intéresse le plus, c’est que l’aspect collaboratif du protocole est lui aussi conçu en local-first : on peut soumettre des patchs et des issues même sans Internet, et les équipes ne sont pas affectées quand GitHub a 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 ?

    Je me demande pourquoi vous utilisez à la fois les licences MIT et Apache. Ce n’est pas une critique, et je me trompe peut-être, mais la licence MIT ne permet-elle pas de contourner les obligations supplémentaires offertes par la licence Apache ? En particulier la clause d’octroi de licence de brevet. La licence MIT ne dit rien sur les brevets, donc pourquoi ne pas utiliser simplement la licence MIT ?

  • Question sur la facilité avec laquelle le grand public peut découvrir ces dépôts. L’absence de fichier robots.txt semble 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.

    Je me demande à quel point ces dépôts sont faciles à découvrir pour le grand public. Il ne semble pas y avoir de fichier robots.txt, donc les moteurs de recherche devraient pouvoir les crawler, et en effet, si on cherche sur Google et DDG, des résultats apparaissent. Ils ne sont pas encore très bien classés, mais cela pourrait s’améliorer sans utiliser de filtre de site. Des outils intégrant le support de la CI (intégration continue) seraient aussi intéressants. Il faut de meilleurs outils pour restreindre les pushes à des identités de confiance. Enfin, il est aussi question d’un dépôt d’artefacts, mais Radicle n’a pas besoin de tout résoudre. En particulier, le partage de gros binaires via un réseau distribué pourrait rapidement être utilisé à des fins 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.

    Félicitations pour le lancement ! C’est vraiment enthousiasmant d’avoir suivi ce projet et de voir à quel point il a gagné en maturité. Comment peut-on migrer les projets actuellement sur GitHub ? Existe-t-il un mode miroir pendant la phase de test ?

  • 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.

    La documentation indique 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 afin d’éviter d’initialiser des identités de dépôt en double. Mais il est probable que les gens ne lisent pas la documentation ou n’y prêtent pas attention, et ignorent donc cette demande. La page d’accueil explique comment pousser du code, mais cette consigne importante n’apparaît 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.

    J’aimerais que les gens définissent précisément des termes comme "peer to peer" ou, plus souvent, "distributed". Ces termes 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.

    Félicitations pour le lancement ! Cela me fait penser à un projet similaire, nest.pijul.com, qui utilise pijul au lieu de git.

  • Remarque hors sujet évoquant NESticle.

    Petite remarque hors sujet : cela me fait penser à NESticle. Wiki NESticle