🚧 Page en cours de construction
Compte rendu d'une expérimentation de fédération de Forges avec le projet « Graft » lors de la Troisième Journée Forgeons ! Voir aussi ForgeX.
La question de la fédération de Forges est un problème qui reste à ce jour ouvert, en attente de solutions effectives pour résoudre la question de la collaboration inter-Forges. Il s'agit d'une problématique qui touche à l'écosystème des Forges open-source telles que Forgejo et Gitlab. On pourrait d'ailleurs retenir l'année 2018, et l'acquisition de GitHub par Microsoft, comme point d'origine dans l'émergence de cette problématique. Date anniversaire de la création du projet Codeberg, il s'agit également d'une date fondatrice dans l'émergence d'un écosystème décentralisé de Forges, et la fin, non pas du monopole de la plateforme GitHub, mais à tout le moins, d'une unique centralité dans l'espace de la fabrication de l'Ouvert et du Libre.
La question centrale de cette problématique peut se résumer ainsi : comment un/une développeur.euse ayant un compte ouvrant des droits d'écriture sur une Forge X peut il/elle contribuer sur un projet hébergé sur Forge Y sans pour autant être membre de cette Forge tierce ? Car, s'il s'agissait simplement de devenir membre de cette nouvelle Forge, en multipliant la problématique sur autant de Forges que ne compte l'écosystème des Forges libres, il apparaîtrait évident que la situation nécessiterait alors de revenir à la situation d'une Forge Unique, ce qui n'est pas souhaitable.
Dans le contexte des services publics numériques, cette problématique se pose à la fois en termes de gestion des accès entre institutions, mais également en termes de découvrabilité des contenus car il s’agit de gérer une décentralisation numérique opérant à l’échelle de l’État dans son ensemble. Dans ce cas d’usage très particulier, la gestion des droits d’accès doit pouvoir être réalisée grâce à ProConnect, ce qui ne relève donc pas de la fédération à proprement parler, mais d’un cas d’usage à part. En revanche, la question de l’indexation des dépôts publics, pour en faciliter notamment l’exploration et le référencement, relève bien d’une problématique plus générale.
Cette problématique de l'interconnexion des Forges concerne aujourd'hui autant la fabrique de l'open-source, que la science ouverte, ou la question des Forges citoyennes (social coding). Et c'est donc sous l'intitulé de « fédération de Forges » qu'elle se pose aujourd'hui. Si le terme de fédération apparaît clairement dans le sens d'une multitude et de son union ou association, à travers la constitution d'une entité fédératrice, ou à tout le moins d'un support fédérateur, le terme renvoie avant tout au principe de « Fediverse ».
Le Fediverse, à l'image de l'Internet — et de sa culture de la mutltitude — repose sur l'idée d'un maillage (mesh) d'entités interconnectées dont la nature rhizomique aurait pour effet la dissolution de l'idée de centralité. Techniquement parlant, cette décentralisation est aujourd'hui associée au protocole ActivityPub sur lequel repose la principale initiative de fédération de Forges du côté de Forgejo.
La présentation du projet Graft (greffe) à permis de réaliser un premier tour d'horizon des protocoles associés à la décentralisation des Forges. En premier lieu, actant de la nature décentralisée de Git, la question fut d'abord posée en termes d'« orchestration » entre les « instances git ».
Ensuite, il fut noté que les éléments qui sont venus se « greffer » autour de Git quand fut « inventée » la première Forge basée sur Git — c'est-à -dire GitHub — gestion des tickets et demandes d'ajouts par exemple, ces éléments « périphériques » se situent « hors » de la sphère du projet Git à proprement parler. Ces éléments sont donc stockés dans une base de données séparée et non dans le répertoire Git. Les projets de fédération basés sur ActivityPub ont pour mission de faire circuler ces éléments annexes.
À date de la Troisième Journée, les fonctionnalités déjà implantées dans Forgejo concernent la création de favoris (stars), le suivi de comptes distants et de leurs activités, sur la base d'un socle technique couvrant les notions d'acteur, de découvrabilité et de requêtes signées. L'implantation de « favoris » a permis de tester le fonctionnement de la fédération sur un premier cas d'usage limité à la seule réception d'un message signé, sans besoin de modération, suivant le principe des boîtes de réception du protocole ActivityPub.
(…)