Tangled - plateforme de collaboration Git basée sur atproto

• Tangled est une plateforme de collaboration Git avec des fonctionnalités sociales basée sur l’AT Protocol, conçue pour permettre aux développeurs de conserver une propriété totale de leur code tout en laissant les communautés open source s’auto-organiser
• Elle adopte une architecture de collaboration de code distribuée qui combine les avantages du modèle fédéré centré sur ActivityPub (Forgejo) et du modèle entièrement P2P de Radicle
• Le concept central, « Knot », est un serveur Git headless léger, compatible à la fois avec le self-hosting individuel et les environnements multitenant à l’échelle d’une communauté
• App View (tangled.sh) fournit une vue unifiée des dépôts sur l’ensemble du réseau, permettant d’explorer, cloner et contribuer facilement à des dépôts hébergés sur différents Knot
• Actuellement en bêta, la plateforme s’appuie sur les principes clés de propriété des données, de faible barrière à l’entrée et de préservation de l’expérience utilisateur, avec pour ambition de construire à terme un écosystème Git distribué totalement ouvert

---

Présentation de Tangled

• Tangled est une nouvelle plateforme qui offre aux développeurs un environnement de collaboration Git avec interactions sociales, tout en leur permettant de conserver la propriété de leur code et de leur identité
• Basée sur l’AT Protocol, elle applique une architecture d’application sociale décentralisée à la collaboration Git
• Son objectif est de redonner à la collaboration sur le code un caractère ouvert et agréable

Modèle distribué et AT Protocol

• Les modèles existants de collaboration de code distribuée reposent notamment sur les approches suivantes
  • Forgejo (ActivityPub) : collaboration via la fédération entre serveurs
  • Radicle : architecture entièrement P2P (peer-to-peer)
• Tangled combine les atouts de ces deux modèles et adopte atproto, qui permet une gestion centralisée de l’identité
• Les utilisateurs peuvent ainsi conserver une structure cohérente d’identifiants et d’authentification même au sein d’un réseau distribué

Architecture de Knot

• Knot est le composant central de Tangled, un serveur léger qui permet aux utilisateurs d’héberger eux-mêmes des dépôts Git
  • Il prend en charge les configurations single-tenant comme multitenant
  • Il peut être auto-hébergé sur de petits équipements comme un Raspberry Pi
• Tangled propose par défaut un service Knot managé gratuit
• Grâce à cette architecture, les serveurs personnels des utilisateurs et les serveurs communautaires peuvent se relier naturellement pour former un réseau Git distribué

App View et réseau unifié

• L’App View proposée sur tangled.sh sert à afficher les dépôts de tout le réseau dans une vue unifiée
• Les utilisateurs peuvent facilement cloner et contribuer à des dépôts, même lorsqu’ils sont hébergés sur d’autres Knot
• Cette conception conserve le workflow habituel de Git tout en supprimant les barrières propres aux environnements distribués

Principes de développement

• L’équipe Tangled a défini les trois principes suivants pour guider le développement
  • 1. Propriété des données — chaque utilisateur possède directement le code et les métadonnées qu’il crée
  • 2. Faible barrière à l’entrée — une structure et une interface simples pour permettre à chacun de participer facilement
  • 3. Cohérence de l’expérience utilisateur — garantir un niveau d’UX comparable à celui des services centralisés malgré l’architecture distribuée
• Ces principes se reflètent dans les choix techniques de Tangled ainsi que dans l’ensemble de la conception UI/UX

Accès et communauté

• Au départ, l’accès était sur invitation uniquement (invite-only), et les développeurs pouvaient participer via le canal IRC #tangled (libera.chat)
• L’accès est désormais ouvert avec connexion publique, et tout le monde peut utiliser le service sur tangled.sh/login
• Tangled en est encore à ses débuts, mais le projet continue de grandir en validant ses fonctionnalités par un usage interne (dogfooding)

Conclusion

• Tangled cherche à étendre la collaboration Git vers une expérience connectée, proche d’un réseau social
• Il attire l’attention comme un nouvel écosystème de plateforme Git distribuée combinant autonomie, accessibilité et culture de développement conviviale

[lamanus]

Comme il n’y avait pas de conteneur officiel, la configuration initiale était un peu fastidieuse.

[GN⁺]

Commentaires sur Hacker News

• En tant que cofondateur de Tangled, nous avons récemment remplacé la bibliothèque OAuth, ce qui a causé un problème empêchant les nouveaux utilisateurs d’être ajoutés au knot et au spindle par défaut (notre serveur d’hébergement git interne et notre runner CI) ; un correctif vient d’être appliqué, donc après déconnexion puis reconnexion, la création de dépôts devrait de nouveau fonctionner normalement. Je peux répondre aux questions à tout moment.
  • Ma première question est de savoir s’il est possible de changer de handle ou de supprimer son compte sur le PDS de tngl.sh. La seconde concerne les ressources nécessaires pour créer et exploiter un AppView : par exemple, si l’on construit un AppView basé sur un PDS qui met en ligne un dossier de site web statique et le sert tel quel, comme avec Cloudflare Pages, est-ce que l’opérateur de l’AppView doit assumer seul les coûts d’un trafic important ? J’aimerais comprendre comment se répartit la charge opérationnelle dans une architecture de ce type.
  • Tangled a utilisé l’expression « social-enabled », ce qui semble lié au protocole AT. Je me demande si vous prévoyez d’ajouter davantage de fonctionnalités sociales à l’avenir, ou si cela signifie simplement la prise en charge du protocole AT.
• Je trouve ce projet vraiment formidable. J’aime l’idée de déconstruire la structure monopolistique des services de forge logicielle existants. Si ce domaine m’intéresse autant, c’est parce que j’ai l’impression que les code forges essaient de résoudre trop de problèmes à la fois et en deviennent inefficaces. La plupart regroupent en un seul endroit les dépôts git, un visualiseur web, des outils de collaboration, des pipelines CI/CD, la gestion de tâches, etc. Mais je ne pense pas que tout cela doive nécessairement être lié. Par exemple, si l’accès direct au dépôt git n’est pas nécessaire, on peut proposer un visualiseur web entièrement statique comme https://pgit.pico.sh, ou bien avoir séparément un serveur de collaboration qui permet de partager, relire et gérer des patchs localement (https://pr.pico.sh). Héberger simplement un dépôt git bare sur un VPS suffit largement, et c’est très facile à faire. Git est déjà un système distribué ; le fait qu’il se recentralise à cause d’autres services annexes me semble être un anti-pattern.
  • On entend souvent dire que « Git est déjà distribué », mais en réalité la notion de distribution reste ambiguë. Git lui-même n’est pas tant centré sur la distribution que sur un protocole maître-esclave classique (HTTP, etc.), ce qui tend à recréer malgré tout de la centralisation.
  • Quand les services se multiplient, une question de confiance se pose. Vaut-il mieux auditer un seul service qui couvre 80 % des besoins, ou vérifier séparément dix services différents ? Il faut aussi tenir compte des économies d’échelle de l’infrastructure et des avantages obtenus en intégrant plusieurs fonctions. C’est aussi pour cela que beaucoup préfèrent encore les monolithes : cela met en lumière les arbitrages autour de l’expérience développeur.
  • Configurer un dépôt git distant sur un VPS est vraiment simple : il suffit d’un accès ssh et cela fonctionne. Au fond, le véritable enjeu me semble être le lock-in (dépendance à un service). Pourquoi GitHub et d’autres se concentrent-ils davantage sur le lock-in que sur le service lui-même ? Derrière cela, il y a le financement et le modèle économique. Le cycle centralisation → lock-in → revenus réapparaît sans cesse dans de nombreux services. Si un service n’a pas de structure permettant de générer des revenus par lui-même, ce phénomène semble difficile à éviter.
  • Techniquement, séparer les fonctions n’est pas impossible, mais il y a aussi des questions d’économie (chaque fonction ne génère pas assez de revenus pour être maintenue indépendamment) et d’usage (les gens veulent le confort du « batteries included »). Il en va de même dans l’open source : beaucoup de projets ignorent la question économique, mais finissent souvent par disparaître lorsque leur unique mainteneur s’arrête. Même les projets open source les plus réussis reposent en général sur du sponsoring d’entreprise ou sur le soutien d’ingénieurs.
  • Il n’est pas nécessaire de tout séparer, mais c’est vrai que l’intégration est bien plus pratique.
• J’ai appris récemment, à JJ Con, la prise en charge de Jujutsu. On peut en lire davantage ici : https://blog.tangled.org/stacking
  • Ce service prend réellement en charge les stacked PR, ce que GitHub n’a pas réussi à faire depuis des décennies. En revanche, si l’on devait l’utiliser en interne de façon privée, il n’est pas très clair comment configurer une instance Tangled pour qu’elle ne soit pas connectée au réseau externe, et c’est dommage.
• Je pense qu’on ne peut plus faire confiance à GitHub. Migrer au moins la stack OSS vers le protocole AT ou vers un autre réseau ouvert me semble être une bonne manière de se protéger des risques liés aux grandes entreprises, à la censure, etc. Je suis heureux de voir ce type d’initiative.
  • Mais la plupart des gens ne veulent pas gérer leur propre serveur. Seules de grandes organisations OSS pourront probablement l’assumer. Et en dehors de l’e-mail, il serait difficile de proposer ne serait-ce que des PR.
• Je fais partie des 100 premiers inscrits sur Tangled. J’ai été impressionné par la feuille de route pour la revue de PR en stacked patches et par la rapidité des améliorations fonctionnelles, et j’ai aussi ressenti une énergie positive dans la communauté. J’attends avec beaucoup d’intérêt l’évolution du projet. S’il continue à avancer ainsi, je pense qu’il pourra offrir une expérience bien meilleure, un contrôle plus fondamental et une durabilité à long terme.
• Je m’intéresse beaucoup à des modes de collaboration git plus distribués. Quel est selon vous le principal obstacle à leur adoption ? L’exploitation des serveurs, la gestion des clés privées, ou au final surtout les effets de réseau ? J’aimerais connaître votre avis.
  • La plus grande barrière, ce sont le spam, les contenus illégaux et les problèmes de modération en général. Comme un PDS peut être associé à n’importe quel domaine et qu’un seul PDS peut accueillir un nombre illimité d’utilisateurs, cela conduit souvent à des situations où la confiance s’effondre. Que faire si des gens remplissent des dépôts git avec des ebooks ou des séries TV piratés ? Ou si un projet subit une attaque de spam pour des raisons politiques ? L’intérêt du concept d’AppView, c’est qu’une équipe de modération centrale, comme chez BlueSky, peut appliquer une politique cohérente. Chacun peut publier ce qu’il veut, mais côté frontend, on peut quand même faire une curation sélective. Cela dit, les décisions de modération centralisées restent toujours controversées. C’est aussi pourquoi je n’ai pas envie d’assumer complètement la charge et la responsabilité d’un réseau totalement distribué. L’ouverture du protocole AT est un avantage par rapport à un service comme Twitter, mais elle nécessite en contrepartie une structure où l’administration quotidienne et l’attribution des droits restent concentrées. Personnellement, je me demande aujourd’hui s’il y aurait des volontaires pour opérer des seed nodes radicle « permissifs » (autorisant les uploads git anonymes).
  • GitHub est gratuit, et la décentralisation a un coût.
  • Je suis très satisfait que Tangled permette d’utiliser git de manière indépendante sans devoir exploiter soi-même un serveur. Son plus gros défaut est d’être encore trop nouveau. Il n’a pas encore de notoriété grand public, et beaucoup de gens ne savent pas ce que Bsky et les PDS apportent. J’aimerais voir davantage de fonctionnalités et de clients alternatifs. Malgré cela, je pense que les premiers utilisateurs bénéficient déjà d’une très bonne expérience, et j’attends le jour où davantage de développeurs la découvriront.
• J’étais content de voir la prise en charge des pipelines CI, mais je suis un peu déçu que cela ressemble à GitHub Actions. Je ne pense pas qu’il soit nécessaire de décrire une simple exécution séquentielle en YAML ; un script bash suffit. Le YAML de pipeline n’a vraiment du sens que lorsqu’il exprime des dépendances (un DAG), pas simplement le flux d’un programme. Buildkite est bien meilleur sur ce point.
• Demain arriveront sans doute une plateforme no-code pour entreprises nommée « Spaghetti », ainsi qu’un important service de coffre-fort pour la conservation des données baptisé « Lock-in ».
• Dans mon entreprise, nous sommes contraints d’utiliser une org publique GitHub. Serait-il possible de faire la revue de code (CR) dans Tangled puis de synchroniser ensuite avec GitHub, tout en conservant l’expérience de revue avec l’outil jj ?
  • Il est possible de faire du mirroring, et aussi de créer un pipeline spindle qui pousse vers GitHub au moment du merge. Documentation de référence : https://tangled.org/@tangled.org/core/blob/master/docs/spindle/pipeline.md
• Je me demande s’il est possible d’adopter Tangled pour un usage enterprise/privé. Le flux de revue en stacked diffs semble très bien correspondre au travail en entreprise.
  • C’est envisageable. Une version de Tangled totalement air-gapped et séparée d’AT est en discussion. C’est un chantier assez important, donc difficile à lancer immédiatement.
  • À l’heure actuelle, il n’existe pas encore clairement de solution enterprise dédiée. La discussion sur le sujet est visible ici : https://tangled.org/@tangled.org/core/issues/60