La fédération des forges est nécessaire
(blog.tangled.org)- La collaboration open source repose sur l’idée qu’une combinaison de protocoles décentralisés, répartissant le transport du code et la communication, est préférable à une structure dépendant fortement d’un fournisseur unique
- La collaboration sur le code s’est d’abord faite avec la combinaison git et e-mail, puis s’est déplacée vers git et le site web GitHub ; ForgeFed prolonge cette évolution avec la combinaison git et ActivityPub, et Tangled avec la combinaison git et le protocole AT
- Tangled fédère les événements entre serveurs git ; chaque serveur est appelé un knot, et même si les serveurs diffèrent, il prend en charge la collaboration sur les dépôts, les forks inter-serveurs et les pull requests vers des dépôts situés sur d’autres serveurs
- Pour l’Authenticated Transfer autour du code, Tangled utilise AT et gère ensemble les issues, les pull requests, les timelines d’événements, les follows, les stars, ainsi que les invitations de collaborateurs et le partage de clés publiques SSH
- Tout en rappelant le flux consistant à héberger soi-même une instance cgit et à envoyer des patchs par e-mail, l’approche montre une volonté de sortir de la monoculture GitHub tout en préservant la dimension sociale et le plaisir de la collaboration
Pourquoi une fédération des forges est nécessaire
- Une structure où une grande partie de la collaboration open source dépend d’un fournisseur unique n’est pas souhaitable, et l’idée de fond est que les protocoles décentralisés résistent mieux dans la durée que les systèmes centralisés
- La collaboration sur le code a toujours reposé sur deux protocoles utilisés ensemble : l’un pour le transport du code, l’autre pour la communication
- Au départ, le flux reposait sur la combinaison de git et de l’e-mail
- Ensuite, il a évolué vers la combinaison de git et du site web GitHub
- ForgeFed explore la possibilité d’une combinaison de git et d’ActivityPub
- Tangled est en cours de construction autour de la combinaison de git et du protocole AT
- Tangled fédère les événements entre serveurs git, et appelle chaque serveur un knot
- La collaboration sur les dépôts est possible quel que soit le serveur
- Les forks entre serveurs sont pris en charge
- Après avoir effectué un push vers un dépôt sur son propre serveur, il est possible d’ouvrir une pull request vers un dépôt hébergé sur un serveur complètement différent
- Cette approche rappelle à bien des égards le flux consistant à exploiter directement une instance cgit tout en envoyant des patchs par e-mail
Le rôle assuré par Tangled
- Tangled utilise AT pour l’Authenticated Transfer des événements autour du code
- Il sert à transmettre des événements comme les issues et les pull requests
- Il gère aussi des fonctions sociales comme la timeline d’événements, les follows et les stars
- Les vouches devraient également être ajoutés prochainement
- AT est aussi utilisé pour inviter des collaborateurs et partager des clés publiques SSH ; pour le reste, git existant est utilisé tel quel
- L’open source doit sortir d’une monoculture comme GitHub, tout en conservant la dimension sociale et le plaisir de la collaboration sur le code
- tangled alpha
- docs
- source
- discord
- bluesky
- twitter (x)
- feed
1 commentaires
Commentaires Hacker News
Je ne sais pas trop à quel point ce sera vraiment meilleur que Mastodon
Il existe une couche d’hébergement indépendante des applis, chacun peut héberger ses propres données, et les applis affichent ensuite les données agrégées depuis tous les hôtes
Du coup, la notion même de defederation à la manière de Mastodon n’existe pas
Pour aller plus loin, voir https://overreacted.io/open-social/ et https://overreacted.io/a-social-filesystem/
Les comptes sont hébergés sur des PDS et l’historique y est stocké, mais ce qui apparaît dans l’appli est fourni par un AppView qui agrège les données de plusieurs PDS
Donc, quel que soit le PDS utilisé, l’expérience dans l’appli ressemble à celle d’un service centralisé ; on peut aussi avoir plusieurs AppView et les héberger soi-même
Le coût d’une découvrabilité de fait quasi globale, comme aujourd’hui, mérite réflexion, mais il est difficile de réduire ça à un simple autre Mastodon
On peut aussi simplement ne pas se positionner, ou aller vers ce qu’on estime juste soi-même
Je suis peut-être biaisé parce que j’utilise déjà beaucoup l’écosystème atprotocol, mais j’utilise vraiment Tangled avec satisfaction
C’est ce qui se rapproche le plus du remplaçant de GitHub que j’attendais ; les fonctionnalités sont plus simples, mais depuis un an c’est mon principal service social/git pour mes projets open source personnels
Mon compte est ici : https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
J’aime le fait que le graphe social que je connaissais sur Bluesky se prolonge ici, ce qui permet de relier intuitivement les commits, PR et issues aux personnes derrière ; et la connexion est pratique car identique à celle des autres services atproto
Il y a aussi eu récemment la prise en charge intégrée des sites statiques, très pratique pour héberger directement depuis un repo un site web côté client ou un simple index.html
Spindles joue le rôle de système de build / actions, et même sans être fan de Nix, ça convenait très bien à mes besoins
L’open API est aussi très bonne, ce qui m’a permis de créer facilement des rendus d’informations en exploitant des standards basés sur atproto, de faire des bots et d’ajouter quelques fonctions à npmx.dev
On peut exploiter soi-même knot (serveur git) et le runner (Spindles), ou utiliser la version hébergée, mais l’essentiel est que la couche sociale est découplée : même si le serveur git est séparé, les discussions d’issues et de PR continuent sur une couche sociale commune
Ce n’est pas parfait, et le badge alpha dans la barre de navigation n’est pas là pour rien, mais pour le travail open source il y a de fortes chances que je continue à l’utiliser
Je ne sais pas encore si cette inquiétude est vraiment fondée
L’ambiance des commentaires est assez négative, mais même si moi aussi je me méfie du financement VC, je pense qu’il faut encourager la concurrence dans ce domaine
À ce stade, lancer ce genre de chose en bootstrap paraît extrêmement difficile, voire pratiquement impossible ; oui, le timing colle bien avec les critiques de GitHub qui étaient hier en haut de HN, mais malgré tout j’ai envie de soutenir ce type d’initiative
J’aimerais que ça atteigne une taille significative
En voyant seulement le titre, j’étais enthousiaste, mais dès que j’ai su qu’il y avait du financement VC, c’est immédiatement sorti de ma liste
Si je dois mettre mon projet passion qui ne rapporte rien sur une plateforme, je préfère choisir un endroit où le risque de rug pull dans 5 ans est faible
Un projet financé par des VC devra bien finir par rendre l’argent, donc je pense qu’un rug pull arrivera d’une manière ou d’une autre
Du coup, je préfère aujourd’hui soit l’utiliser comme client payant, soit passer par un service où l’on paie une cotisation de type coopératif avec un droit de vote dans les décisions
Donc, du point de vue des utilisateurs, il faut connaître ce risque à l’avance
J’aime peu les services qui affichent un idéalisme excessif alors que cette réalité approche à grands pas
Je préférerais qu’ils facturent le service, ou, s’ils visent réellement un idéal, qu’ils démarrent en non-profit, ou au minimum qu’ils exposent clairement leur plan de monétisation
Que ce soit difficile, évidemment, mais surtout si l’objectif est la fédération, on devrait pouvoir construire ça avec une infrastructure moins coûteuse, pas au même coût ni plus cher
Si le modèle de données atproto vous intéresse, j’ai écrit un article d’introduction ici : https://overreacted.io/a-social-filesystem/
C’est un peu long, mais ça donne une vision d’ensemble très claire
C’était le meilleur article d’introduction à ATProto que j’aie vu jusqu’ici
Je me demande s’il existe un tag ou une liste qui regroupe ces articles au même endroit
À mon avis, ce dont on a besoin, ce n’est pas d’une forge federation, mais d’un git repo plus riche en lui-même
Fossil est déjà à presque 90 % de cet objectif : tickets, forum et wiki sont intégrés au dépôt comme partie de celui-ci, et quand on clone, on récupère aussi tout cela pour pouvoir le consulter hors ligne
On peut même rédiger des réponses dans l’avion, puis les synchroniser tout de suite ou plus tard quand la connexion revient, si les permissions le permettent
Cela dit, plutôt que de coder en dur certains types d’artefacts dans le VCS, il me semblerait préférable de mettre une appli dans le repo et de laisser cette appli décider quels artefacts sont autorisés, quelles règles s’appliquent et qui peut téléverser/télécharger quoi et quand
La forge n’aurait alors qu’à appliquer cette politique et à la rendre aux utilisateurs web de la manière voulue
Dans ce modèle, changer de forge reviendrait au fond à simplement push le repo ailleurs
En ce moment, je construisais justement des choses comme un système de tickets ou des agents sous forme de flat files dans un git repo, et maintenant je me dis qu’il faut étendre cette logique jusqu’à la gestion du repo elle-même
Ça a l’air excellent
Le problème central d’une federated solution, selon moi, c’est le cold start
Si on rejoint un gros serveur existant, on retombe dans le problème de centralisation qu’on voulait fuir, mais on obtient au moins un grand réseau dès le départ
À l’inverse, si on ouvre son propre serveur, on part avec un réseau nul, une découvrabilité nulle, un fil vide, et il faut convaincre les autres sites de se fédérer avec soi ou de ne pas vous bloquer au motif qu’il s’agit d’un serveur d’une seule personne
Je ne sais pas si je suis le seul à le ressentir ainsi ou si je comprends mal la fédération
Peut-être que c’est simplement un problème propre à Mastodon
Le système est conçu pour que des AppView centraux agrègent les serveurs individuels et offrent une vue unique cohérente, à la manière d’un réseau centralisé
N’importe qui peut héberger un AppView
atproto ne fonctionne pas comme un ensemble de zones à moitié isolées où chaque serveur vit dans son coin
Pour une explication du point de vue des systèmes distribués, https://atproto.com/articles/atproto-for-distsys-engineers l’explique bien
Si un gros serveur devient douteux à cause de sa modération, de sa politique, de son contenu ou de problèmes techniques, il est relativement simple d’en partir pour faire grandir ou rejoindre un autre serveur déjà assez important
Autrement dit, on peut avoir dès le départ un refuge doté d’un minimum de réputation et de taille
Il existe déjà des forges alternatives comme GitLab, Codeberg, freedesktop, Fedora ou Debian ; si la visibilité et la découvrabilité des projets sont préservées, cela peut suffire comme refuge sûr
Mais en voyant ce projet il y a quelques jours, je me suis dit que celui-ci pourrait vraiment marcher
Parce que ses utilisateurs cibles recoupent fortement les personnes habituées au self-hosting
Je n’ai pas besoin que tout mon réseau y vienne ; il suffit que ce sous-groupe, qui a réellement des chances de l’utiliser, soit présent pour que ce soit déjà très utile
Le coût d’un serveur frontend sera très faible, donc cela semble exploitable presque indéfiniment, tandis que les données réelles sont fournies par d’autres hôtes
Le fait que Tangled soit soutenu par du VC me donne moins un sentiment de stabilité qu’une impression de pression à croître à tout prix
Je vois mal l’attrait
Même si c’est fédéré, si le développement s’arrête, qui corrigera les bugs et assurera la maintenance ?
L’idée est que tout soit entièrement reproductible et auto-hébergeable à coût minimal
Le financement VC n’est pas une fin, mais un moyen ; pour deux fondateurs indiens installés en Europe, les subventions étaient en pratique presque irréalistes, car il fallait attendre 4 à 12 mois ou plus avant de les toucher
Le VC était le moyen le plus rapide de constituer une équipe, mettre l’infrastructure en place et accélérer le développement, et ils ont passé plus de 6 mois à chercher un partenaire dont les objectifs étaient fortement alignés avec les leurs
Tangled fait des choix structurels intéressants, mais le code lui-même est relativement simple, et d’après ce que j’en ai vu, il ne paraît pas difficile à maintenir
L’essentiel consiste en des Go modules faiblement couplés, avec par-dessus du HTML+CSS statique, un peu de TypeScript et du Nix pour l’orchestration
Si je me souviens bien, les besoins matériels sont aussi très faibles, au point qu’à cette échelle une seule personne pourrait l’héberger elle-même
En pratique, une grande partie de la charge d’infrastructure repose sur les knots, spindles, PDS des utilisateurs et sur l’ensemble de l’écosystème atproto
Pourquoi faut-il absolument du VC, et pourquoi ne pas faire comme Ladybird avec du mécénat d’entreprise ?
Et puisque les investisseurs attendent un retour x10, pourquoi consacrer du temps à un outil pour développeurs qui finira par être enshittifié ?
Ça me rappelle la blague selon laquelle, quand il existe déjà 4 standards et qu’on veut en créer un nouveau pour unifier le tout, on se retrouve simplement avec 5 standards
Blague à part, il me faudrait des arguments plus solides pour comprendre pourquoi ActivityPub ne suffirait pas
Avant de tenter de résoudre à nouveau le problème de la communication décentralisée avec une autre approche
Les opposer revient un peu à demander pourquoi on a besoin du web alors que l’email existe déjà
ActivityPub fonctionne comme l’email : les serveurs jouent le rôle de boîtes de réception et s’échangent des messages
atproto, au contraire, fonctionne comme le web : les dépôts utilisateur hébergent les données et les applis les agrègent pour les afficher
Cette différence de topologie produit aussi des propriétés différentes : avec atproto, on peut changer d’hébergement utilisateur sans casser l’expérience applicative, et n’importe qui peut créer une nouvelle appli à partir des données existantes
ActivityPub ne permet pas cela ; on se rapproche plutôt de petits services centralisés couplés à leur hébergement et à leur appli, qui s’échangent des messages entre eux
Il existe aussi une alternative à GitHub relativement mature fonctionnant sur Nostr : https://gitworkshop.dev/
L’idée centrale est que les dépôts peuvent être envoyés sur plusieurs relais nostr compatibles GRASP, et si un serveur tombe, la synchronisation continue de manière transparente via les autres
En choisissant des serveurs de confiance, on s’approche donc en pratique d’une disponibilité quasi à 100 %, et les dépôts, activités, issues, etc. sont aussi signés cryptographiquement
Rien que le nom semble violer la politique de marque de git
https://git-scm.com/about/trademark
Pour certains, le navigateur indiquait qu’il ne prenait pas en charge les URL ssh ou https ; pour d’autres, je n’obtenais qu’un
Failed to load file treeavec chargement infiniDu coup, l’étiquette fairly mature me paraît difficile à accepter
Je suis très favorable à la fédération, mais je n’ai jamais bien compris l’intérêt d’une federation of forges
Quelles données les forges doivent-elles exactement échanger entre elles ?
Pourquoi une forge pour Blender devrait-elle être connectée à une forge pour Ubuntu ?
La plus grande valeur que je retire de GitHub, c’est le single sign-on qui me permet de naviguer entre les projets ; à mon avis, même des forges indépendantes pourraient déjà offrir une grande partie de cette valeur avec du social login, sans toute la complexité d’une fédération de forges
Si on héberge sa propre forge, à moins d’être déjà un nom aussi connu que Blender, personne ne trouvera le logiciel
Donc pour éviter que le code ne disparaisse dans le vide, le mirroring GitHub est presque obligatoire
Si l’on veut éviter cela et permettre à de plus petites forges d’être compétitives comme un ensemble, il faut un réseau unique qui rende les logiciels trouvables quel que soit l’hôte, et c’est précisément ce que vise ForgeFed
Cela réduit aussi la friction pour les nouveaux contributeurs, à qui l’on n’a plus besoin de faire créer un compte spécifique à chaque forge ; c’est secondaire, mais lié
GitHub s’est centralisé parce qu’il a bien résolu l’UI, les issues et les PR, permettant aux débutants de tout faire depuis l’interface
La fédération est plus fidèle à la philosophie de Git, sans pour autant devoir aller jusqu’à une décentralisation extrême où si un nœud tombe, l’upstream disparaît ou devient introuvable
Git ne résout pas le problème de disponibilité, et la fédération peut le compenser tout en conservant cette philosophie décentralisée
Il faut un moyen simple de trouver des projets open source répartis sur des serveurs dispersés
La recherche de projets GitHub ne fonctionne qu’à l’intérieur de GitHub
Et au-delà de ça, ce serait aussi plus resilient quand un hébergeur de projet disparaît, change sa politique ou se retrouve bloqué par un gouvernement
Ensuite, les AppView agrègent les données de plusieurs PDS dans une même interface
Donc même si tangled.org finit par enshittifier le service, on pourrait continuer exactement de la même façon depuis n’importe quel autre AppView, sans que tangled.org ait une position privilégiée
Le social login entre forges indépendantes aide, certes, mais personnellement je préfère n’avoir qu’un seul compte à gérer, et grâce à l’AT protocol, même si une forge individuelle disparaît, les données restent accessibles via d’autres AppView