Ce qui est difficile, c'est surtout de savoir ce qu'on veut dire par "fédération de forge", car j'ai le sentiment que personne ne définit vraiment les choses et personne ne pose les questions difficiles, et tout le monde rajoute son petit truc. Et c'est pour ça que ça n'avance pas.
La raison d'avoir uniquement les étoiles, c'est parce que c'est le truc ou tu as le moins de latitude et de choix. Le décompte ne change rien de substantiel, n'a aucun impact si il est faux et n'est qu'un nombre attaché à un dépôt.
Par contre, si on commence à parler de choses plus complexes comme les bugs/issues/PR, ça devient d'un coup plus compliqué.
Par exemple, il y a des gens qui voudraient que la fédération de forge soit totalement décentralisé (comme un salon matrix), d'autres qui voudraient simplement avoir un login fédéré (comme une liste de discussion, ou une communauté lemmy).
Suivant ce que tu vises, faut se demander ou se passe la collaboration (eg, qui a la version de référence de la discussion), la forge upstream, ou la forge locale ?
Dans la vision 2 (login fédéré), la réponse est "la forge upstream".
Il se passe quoi quand il y a des conflits d'humain, qui décide de fermer la discussion ? Comment tu fait pour bosser si le projet est sur la forge A, tu es sur B, et quelqu'un de C vient, avec C bloqué par la forge B (la tienne) mais pas la forge A ? (tout rapport avec du dramastodon passé n'est pas fortuit).
Si la forge centrale est en panne, il se passe quoi ? Qui décide du numéro de ticket quand on en ouvre un ? Est ce que les tickets sont par dépôt, comme maintenant, ou attaché par magie au code (et donc synchro comme le code, avec merge conflict, etc)
Et vu que ActivityPub, c'est simplement de la publication de messages (il n'y a pas automatiquement de réconciliation comme avec le protocole Matrix), il se passe quoi quand des bouts sont perdus ?
Et si la réponse est "on s'en fout, on synchronise via F3", alors pourquoi se faire chier à faire un vocabulaire vu que la synchro va éventuellement arriver.
Maintenant, si on parle de la vision décentralisé comme Matrix, pourquoi ne pas avoir gardé le protocole de Matrix comme au début du projet Forgeflux.
Pourquoi faire un protocole d'export quand ce qu'il faut, c'est un système d'operational transform (comme Google Wave et par la suite etherpad, google docs, etc)
Donc si la vision est "comme Lemmy" et de tout centraliser sur un serveur d'origine, pourquoi se faire chier avec ActivityPub quand on peut:
- mettre un cron sur git clone (gitea le fait déjà, je fait des copies de mes applis en local depuis gitlab/github/framagit, ou l'inverse, je pousse via cron)
- déléguer l'authentification pour écrire des issues via openid ou n'importe quoi d'autre
Car fondamentalement, on pourrait juste avoir nos emails/mxid/id xmpp/id mastodon comme identifiants, et mettre une forme de login par dessus. Pas besoin de faire tout un vocabulaire ActivityPub pour ça, faut juste changer le format des logins et des urls.
Et si c'est la vision "comme Matrix", pourquoi avoir pris ActivityPub et pas Matrix ?
Comme visiblement, c'est AP qui a été pris, donc j'en conclus que des gens ne veulent pas centraliser comme je l'indique (sinon, ça serait plus simple), ni faire comme Matrix (sinon, tu mets juste une passerelle git vers matrix).
Par exemple, si je reviens sur le format de stockage F3, c'est utile, mais ça n'est pas spécialement une question de fédération en soi, c'est juste se donner les moyens techniques de claquer la porte pour divers raisons (pratique quand on ne sait pas gérer sa frustration et qu'on a l'habitude de le faire, par exemple). Bien sur, ç'est à la fédération ce que le Brexit est à la gouvernance fédéré de l'Europe, donc je peux voir le rapport.
On a pas besoin d'un format d'export pour la fédération (le SMTP n'utilise pas ça, par exemple) et c'est pour moi un indicateur qu'il y a une vision autre que la simple fédération si on rajoute autre chose de périphérique.
Autre exemple, un des cas d'usage qui avait été discuté à l'époque, c'était d'utiliser la fédération pour éviter les soucis de blocage de l'OFAC vis à vis des fournisseurs US (les nationaux iraniens n'avaient pas le droit d'utiliser Github, ou certains citoyens russes).
Mais du coup, en tant qu'objectif, comment ça se positionne vis à vis de demandes futures et probables de ne pas interagir avec tel ou tel personne pour divers raisons ? Car si tu permets de bloquer un spammeur, tu peux aussi bloquer l'Iran (voir même, c'est plus facile de bloquer l'Iran que les spammeurs).
Et puis dans tout ça, quid de la modération ?
Il y a déjà une tonne de spam sur les forges publiques, en quoi proposer un moyen de contourner l'éventuelle vérification au login va aider à ce niveau ? Surtout que Codeberg a bien montrer que niveau modération, il y a encore des trous et c'était pas la priorité (vu qu'il y a fallu avoir un souci pour avoir une réunion sur "comment limiter les APIs").
Bref la fédération, je vais faire comme l’apôtre Thomas, je vais y croire quand je vais la voir.
[^] # Re: Besoin d'interopérabilité
Posté par Misc (site web personnel) . En réponse au journal Forge publique et privée : centralisation ou décentralisation ?. Évalué à 10.
Ce qui est difficile, c'est surtout de savoir ce qu'on veut dire par "fédération de forge", car j'ai le sentiment que personne ne définit vraiment les choses et personne ne pose les questions difficiles, et tout le monde rajoute son petit truc. Et c'est pour ça que ça n'avance pas.
La raison d'avoir uniquement les étoiles, c'est parce que c'est le truc ou tu as le moins de latitude et de choix. Le décompte ne change rien de substantiel, n'a aucun impact si il est faux et n'est qu'un nombre attaché à un dépôt.
Par contre, si on commence à parler de choses plus complexes comme les bugs/issues/PR, ça devient d'un coup plus compliqué.
Par exemple, il y a des gens qui voudraient que la fédération de forge soit totalement décentralisé (comme un salon matrix), d'autres qui voudraient simplement avoir un login fédéré (comme une liste de discussion, ou une communauté lemmy).
Suivant ce que tu vises, faut se demander ou se passe la collaboration (eg, qui a la version de référence de la discussion), la forge upstream, ou la forge locale ?
Dans la vision 2 (login fédéré), la réponse est "la forge upstream".
Il se passe quoi quand il y a des conflits d'humain, qui décide de fermer la discussion ? Comment tu fait pour bosser si le projet est sur la forge A, tu es sur B, et quelqu'un de C vient, avec C bloqué par la forge B (la tienne) mais pas la forge A ? (tout rapport avec du dramastodon passé n'est pas fortuit).
Si la forge centrale est en panne, il se passe quoi ? Qui décide du numéro de ticket quand on en ouvre un ? Est ce que les tickets sont par dépôt, comme maintenant, ou attaché par magie au code (et donc synchro comme le code, avec merge conflict, etc)
Et vu que ActivityPub, c'est simplement de la publication de messages (il n'y a pas automatiquement de réconciliation comme avec le protocole Matrix), il se passe quoi quand des bouts sont perdus ?
Et si la réponse est "on s'en fout, on synchronise via F3", alors pourquoi se faire chier à faire un vocabulaire vu que la synchro va éventuellement arriver.
Maintenant, si on parle de la vision décentralisé comme Matrix, pourquoi ne pas avoir gardé le protocole de Matrix comme au début du projet Forgeflux.
Pourquoi faire un protocole d'export quand ce qu'il faut, c'est un système d'operational transform (comme Google Wave et par la suite etherpad, google docs, etc)
Donc si la vision est "comme Lemmy" et de tout centraliser sur un serveur d'origine, pourquoi se faire chier avec ActivityPub quand on peut:
- mettre un cron sur git clone (gitea le fait déjà, je fait des copies de mes applis en local depuis gitlab/github/framagit, ou l'inverse, je pousse via cron)
- déléguer l'authentification pour écrire des issues via openid ou n'importe quoi d'autre
Car fondamentalement, on pourrait juste avoir nos emails/mxid/id xmpp/id mastodon comme identifiants, et mettre une forme de login par dessus. Pas besoin de faire tout un vocabulaire ActivityPub pour ça, faut juste changer le format des logins et des urls.
Et si c'est la vision "comme Matrix", pourquoi avoir pris ActivityPub et pas Matrix ?
Comme visiblement, c'est AP qui a été pris, donc j'en conclus que des gens ne veulent pas centraliser comme je l'indique (sinon, ça serait plus simple), ni faire comme Matrix (sinon, tu mets juste une passerelle git vers matrix).
Par exemple, si je reviens sur le format de stockage F3, c'est utile, mais ça n'est pas spécialement une question de fédération en soi, c'est juste se donner les moyens techniques de claquer la porte pour divers raisons (pratique quand on ne sait pas gérer sa frustration et qu'on a l'habitude de le faire, par exemple). Bien sur, ç'est à la fédération ce que le Brexit est à la gouvernance fédéré de l'Europe, donc je peux voir le rapport.
On a pas besoin d'un format d'export pour la fédération (le SMTP n'utilise pas ça, par exemple) et c'est pour moi un indicateur qu'il y a une vision autre que la simple fédération si on rajoute autre chose de périphérique.
Autre exemple, un des cas d'usage qui avait été discuté à l'époque, c'était d'utiliser la fédération pour éviter les soucis de blocage de l'OFAC vis à vis des fournisseurs US (les nationaux iraniens n'avaient pas le droit d'utiliser Github, ou certains citoyens russes).
Mais du coup, en tant qu'objectif, comment ça se positionne vis à vis de demandes futures et probables de ne pas interagir avec tel ou tel personne pour divers raisons ? Car si tu permets de bloquer un spammeur, tu peux aussi bloquer l'Iran (voir même, c'est plus facile de bloquer l'Iran que les spammeurs).
Et puis dans tout ça, quid de la modération ?
Il y a déjà une tonne de spam sur les forges publiques, en quoi proposer un moyen de contourner l'éventuelle vérification au login va aider à ce niveau ? Surtout que Codeberg a bien montrer que niveau modération, il y a encore des trous et c'était pas la priorité (vu qu'il y a fallu avoir un souci pour avoir une réunion sur "comment limiter les APIs").
Bref la fédération, je vais faire comme l’apôtre Thomas, je vais y croire quand je vais la voir.