À part bloquer les comptes plus rapidement (ce qui a apparemment suffisamment aidé) et prendre position publiquement, je ne sais pas trop ce qu'ils peuvent faire d'autre. Des poursuites en justice pour du spam?
Je suis d'accord, et fondamentalement, je pense qu'en effet, il faut revoir le logiciel de fond en comble. Pas dans le sens ou tout est à jeter, loin de la, très loin de la, mais dans le sens ou la sécurité doit être intégré dans le design depuis le début.
Car au final, le choix de prendre un logiciel destiné à une forge personnelle/privé pour un service ouvert au public est le péché originel.
Je vais donner 2 exemples sur d'autres logiciels et choix pour illustrer.
Le premier, c'est le fait d'utiliser Slack pour une communauté ouverte au public. En dehors de la question du proprio, c'est un mauvais choix parce que Slack ne permet pas d'ignorer quelqu'un/quelque chose, car on part du principe que dans une entreprise (l'audience visée par Slack), ça se règle via les RH. C'est un design qui a du sens dans son contexte et qui permet d'éviter de surcharger les menus, mais qui pose souci dans un autre (à savoir une commu ouverte à tout le monde avec des gens relous ou qui parlent trop).
Second exemple, les tickets de CoC de Fedora. Fedora utilise sa forge (avant Pagure, maintenant Forgejo) pour ça, et il y a eu plusieurs fois des leaks d'infos à cause de la fonction de notification inline. En l'occurrence, si tu colles un log avec @toto, toto est mis en copie et reçoit un mail, c'est facheux quand tu colles un log irc pour te plaindre de ce que toto a dit si ton log est "@toto> casse toi de la, pov' con". Il y a 5 ans, j'ai découvert le bug en tombant dedans, j'ai corrigé. C'était le 2nd correctif, cf le message de pingou. Il y a 2 semaines, le souci est revenu sur la nouvelle forge. Le fait que ça revienne me fait dire que le souci est dans le design, car on utilise un système de ticket qui n'est pas pensé pour ça à la base.
Soit on veux faciliter la collaboration donc il ne faut pas mettre de friction sur les notifications (le cas actuelle des forges de Fedora), soit on veux avoir plus de controle sur l'information, et ça implique de la friction sur le partage (par exemple, chaque notification demande une confirmation explicite).
Comme pour Slack, tu ne peux pas optimiser un design dans 2 directions.
Et donc pour moi, l'usage d'un logiciel de forge privé/perso afin d’héberger un service pour le grand public, c'est pareil.
L'attaque de spam de 2025, c'était fondamentalement un manquement dans le design initial qui n'a rien prévu pour éviter ça, car l'idée (je suppose) est qu'un probléme de ce genre peut se régler hors du logiciel quand on est dans le cadre d'une forge fermé. Si sur ma forge, je n'ouvre un compte que pour quelqu'un que je connais et ce quelqu'un insulte quelqu'un d'autre, je peut intervenir en dehors, je connais les gens. Si c'est des inconnus qui s'ouvrent eux même leur compte, je peux pas faire grand chose, et peut être qu'il faut permettre de mieux filtrer et traiter la forge comme un réseau social avec tout ce que ça implique, que ça soit en terme de quantité d'interactions, d'affordances à proposer (blocage, reporting, mais aussi rate limitation, quotas, etc). La question du nombre de comptes se pose aussi. Une forge pour un petit/moyen groupe n'est pas une forge pour 1 million de personnes.
Un autre exemple de l'inadéquation d'une forge privée pour un service publique, c'est la gestion des nouveaux comptes. Pour une forge privée, pas de souci, tu crées les comptes, tu ne va pas avoir une tonne de gens à filtre/modérerr. Pas pour une forge publique, et de ce que j'ai compris, c'est chiant à faire (en tout cas, c'était chiant par le passé). Un logiciel pensé pour être un service publique aurait sans doute un module de gestion du spam (ce qui implique un choix autre que go pour la modularité, par exemple), etc, etc.
Ensuite, je pointe ça, mais je comprends bien que c'est un tradeoff. On ne vit pas dans un monde idéal ou refaire de 0 une forge était une option viable, et je pense que le choix de partir sur Gitea à la création de Codeberg était un choix pragmatique, j'aurais sans doute fait pareil.
Disons que pour un projet commencé en 2020 via le projet fedeproxy, on peut dire que c'est un peu lent (et on va pas remonter plus loin, parce que le premier commit sur forgefed, c'était en 2017.
Mais je continue aussi de penser que la fédération est un rêve imprécis (pour avoir été dans les premiers meetings autour de fedeproxy à Paris), et j'ai le sentiment que tout le monde n'est pas d'accord sur ce que ça couvre.
Car tu peux vouloir une forge "distribué" sans SPOF (par exemple, Forgeflux, un design basé sur Matrix qui avait été discuté par le passé) et dire que c'est fédéré. Tu peux avoir un projet sur une forge centrale avec des interactions par des comptes distants, avec donc une authentification fédérée, et dire que c'est fédéré (mais quid du spam, vu que ça a tué openid). Tu peux avoir la possibilité d'avoir des forks distants avec des discussions distantes sur chaque serveur donc des PR/bugs en fédération, et donc un fil de discussion sur 2 serveurs, (quid de la numérotation, etc), etc. C'est des designs différents, mais qu'on peut tous qualifier de fédéré.
Il y a vaguement ce coté égalitaire dans l'idée de la fédération, mais c'est très mal défini, et c'est une des 2 choses qui rend le progrès difficile selon moi. L'autre, c'est que le design initial de la forge n'a pas été prévu pour ça donc c'est dur de changer ça sans casser des choses existantes. Tangled est une forge faite de 0 qui intègre dans la conception la décentralisation](https://docs.tangled.org/). Radicle utilise du p2p pour ça, et intègre ça dans le conception. Les 2 sont des créations récentes (Tangled 2025, Radicle 2023), soit bien après les premières discussions formel de fédération. Les 2 sont fonctionnels et intègre la fédération plus vite car il n'y a pas d'existant à garder.
https://gitea-open-letter.coding.social/ ne mentionne pas la fédération. De mon point de vue, le fork est principalement pour des raisons politiques (gouvernance du projet) et pas pour des raisons techniques.
Oui, alors ça, c'est la raison publique.
En pratique, le fork a démarré comme un "soft fork" pour ajouter la fédération, puis Loic s'est disputé avec les gens de Gitea début 2022 (parmi tant d'autres, il y a aussi eu une dispute avec l'April qui a coïncidé avec la dissolution de la FSF France en 2022, officiellement pour manque d'activité), cf ce que j'ai expliqué par le passé. Les disputes, c'était sur des questions business (à savoir le fait de vouloir financer le travail sur la fédération via un service appelé hostea, mais gitea a fondé sa propre boite en même temps sans l'impliquer en 2022, il a vraiment pas aimé qu'on lui dise "non" puis de faire pareil), mais aussi des questions de caractère (fight avec le designer sans raison autre que mauvaise gestion de ses émotions de ce que je vois).
Et je sais pas si les gens de Gitea ont capté que Loïc avait 2/3 comptes pour voter, mais je pense que je doit pas être le seul qui a constaté que silentcodeg sur github était un faux nez de Loic (qui avait donc 2 votes au TC).
Et c'est un pattern qui se répète vu que earl-warren est Loïc D, cf le leak du whois par Gandi qui était mal anonymisé et qui montre qui a enregistré le domaine en 2022.
[^] # Re: Quitte ou double ?
Posté par Misc (site web personnel) . En réponse au journal Blog de Codeberg sur la protection des communs contre les LLMs. Évalué à 9 (+6/-0).
Je suis d'accord, et fondamentalement, je pense qu'en effet, il faut revoir le logiciel de fond en comble. Pas dans le sens ou tout est à jeter, loin de la, très loin de la, mais dans le sens ou la sécurité doit être intégré dans le design depuis le début.
Car au final, le choix de prendre un logiciel destiné à une forge personnelle/privé pour un service ouvert au public est le péché originel.
Je vais donner 2 exemples sur d'autres logiciels et choix pour illustrer.
Le premier, c'est le fait d'utiliser Slack pour une communauté ouverte au public. En dehors de la question du proprio, c'est un mauvais choix parce que Slack ne permet pas d'ignorer quelqu'un/quelque chose, car on part du principe que dans une entreprise (l'audience visée par Slack), ça se règle via les RH. C'est un design qui a du sens dans son contexte et qui permet d'éviter de surcharger les menus, mais qui pose souci dans un autre (à savoir une commu ouverte à tout le monde avec des gens relous ou qui parlent trop).
Second exemple, les tickets de CoC de Fedora. Fedora utilise sa forge (avant Pagure, maintenant Forgejo) pour ça, et il y a eu plusieurs fois des leaks d'infos à cause de la fonction de notification inline. En l'occurrence, si tu colles un log avec @toto, toto est mis en copie et reçoit un mail, c'est facheux quand tu colles un log irc pour te plaindre de ce que toto a dit si ton log est "@toto> casse toi de la, pov' con". Il y a 5 ans, j'ai découvert le bug en tombant dedans, j'ai corrigé. C'était le 2nd correctif, cf le message de pingou. Il y a 2 semaines, le souci est revenu sur la nouvelle forge. Le fait que ça revienne me fait dire que le souci est dans le design, car on utilise un système de ticket qui n'est pas pensé pour ça à la base.
Soit on veux faciliter la collaboration donc il ne faut pas mettre de friction sur les notifications (le cas actuelle des forges de Fedora), soit on veux avoir plus de controle sur l'information, et ça implique de la friction sur le partage (par exemple, chaque notification demande une confirmation explicite).
Comme pour Slack, tu ne peux pas optimiser un design dans 2 directions.
Et donc pour moi, l'usage d'un logiciel de forge privé/perso afin d’héberger un service pour le grand public, c'est pareil.
L'attaque de spam de 2025, c'était fondamentalement un manquement dans le design initial qui n'a rien prévu pour éviter ça, car l'idée (je suppose) est qu'un probléme de ce genre peut se régler hors du logiciel quand on est dans le cadre d'une forge fermé. Si sur ma forge, je n'ouvre un compte que pour quelqu'un que je connais et ce quelqu'un insulte quelqu'un d'autre, je peut intervenir en dehors, je connais les gens. Si c'est des inconnus qui s'ouvrent eux même leur compte, je peux pas faire grand chose, et peut être qu'il faut permettre de mieux filtrer et traiter la forge comme un réseau social avec tout ce que ça implique, que ça soit en terme de quantité d'interactions, d'affordances à proposer (blocage, reporting, mais aussi rate limitation, quotas, etc). La question du nombre de comptes se pose aussi. Une forge pour un petit/moyen groupe n'est pas une forge pour 1 million de personnes.
Un autre exemple de l'inadéquation d'une forge privée pour un service publique, c'est la gestion des nouveaux comptes. Pour une forge privée, pas de souci, tu crées les comptes, tu ne va pas avoir une tonne de gens à filtre/modérerr. Pas pour une forge publique, et de ce que j'ai compris, c'est chiant à faire (en tout cas, c'était chiant par le passé). Un logiciel pensé pour être un service publique aurait sans doute un module de gestion du spam (ce qui implique un choix autre que go pour la modularité, par exemple), etc, etc.
Ensuite, je pointe ça, mais je comprends bien que c'est un tradeoff. On ne vit pas dans un monde idéal ou refaire de 0 une forge était une option viable, et je pense que le choix de partir sur Gitea à la création de Codeberg était un choix pragmatique, j'aurais sans doute fait pareil.
Disons que pour un projet commencé en 2020 via le projet fedeproxy, on peut dire que c'est un peu lent (et on va pas remonter plus loin, parce que le premier commit sur forgefed, c'était en 2017.
Mais je continue aussi de penser que la fédération est un rêve imprécis (pour avoir été dans les premiers meetings autour de fedeproxy à Paris), et j'ai le sentiment que tout le monde n'est pas d'accord sur ce que ça couvre.
Car tu peux vouloir une forge "distribué" sans SPOF (par exemple, Forgeflux, un design basé sur Matrix qui avait été discuté par le passé) et dire que c'est fédéré. Tu peux avoir un projet sur une forge centrale avec des interactions par des comptes distants, avec donc une authentification fédérée, et dire que c'est fédéré (mais quid du spam, vu que ça a tué openid). Tu peux avoir la possibilité d'avoir des forks distants avec des discussions distantes sur chaque serveur donc des PR/bugs en fédération, et donc un fil de discussion sur 2 serveurs, (quid de la numérotation, etc), etc. C'est des designs différents, mais qu'on peut tous qualifier de fédéré.
Il y a vaguement ce coté égalitaire dans l'idée de la fédération, mais c'est très mal défini, et c'est une des 2 choses qui rend le progrès difficile selon moi. L'autre, c'est que le design initial de la forge n'a pas été prévu pour ça donc c'est dur de changer ça sans casser des choses existantes. Tangled est une forge faite de 0 qui intègre dans la conception la décentralisation](https://docs.tangled.org/). Radicle utilise du p2p pour ça, et intègre ça dans le conception. Les 2 sont des créations récentes (Tangled 2025, Radicle 2023), soit bien après les premières discussions formel de fédération. Les 2 sont fonctionnels et intègre la fédération plus vite car il n'y a pas d'existant à garder.
Oui, alors ça, c'est la raison publique.
En pratique, le fork a démarré comme un "soft fork" pour ajouter la fédération, puis Loic s'est disputé avec les gens de Gitea début 2022 (parmi tant d'autres, il y a aussi eu une dispute avec l'April qui a coïncidé avec la dissolution de la FSF France en 2022, officiellement pour manque d'activité), cf ce que j'ai expliqué par le passé. Les disputes, c'était sur des questions business (à savoir le fait de vouloir financer le travail sur la fédération via un service appelé hostea, mais gitea a fondé sa propre boite en même temps sans l'impliquer en 2022, il a vraiment pas aimé qu'on lui dise "non" puis de faire pareil), mais aussi des questions de caractère (fight avec le designer sans raison autre que mauvaise gestion de ses émotions de ce que je vois).
Et je sais pas si les gens de Gitea ont capté que Loïc avait 2/3 comptes pour voter, mais je pense que je doit pas être le seul qui a constaté que silentcodeg sur github était un faux nez de Loic (qui avait donc 2 votes au TC).
Et c'est un pattern qui se répète vu que earl-warren est Loïc D, cf le leak du whois par Gandi qui était mal anonymisé et qui montre qui a enregistré le domaine en 2022.