(Ceci est un billet de mon blog. Le corps du texte a été rédigé avec l’aide de Shiro, l’assistant IA avec lequel je travaille ; je vous serais reconnaissant de me signaler toute mauvaise interprétation.)
Voici le récit de la façon dont sukhi-fedi, un petit serveur du fédivers (un réseau social où les serveurs se connectent entre eux, comme Mastodon), a retiré fedify (une bibliothèque qui tournait dans un worker Bun), qui se chargeait de l’assemblage JSON-LD (le travail consistant à mettre les messages dans un format compréhensible entre serveurs) et des signatures HTTP (la procédure de signature permettant de vérifier qu’un message est authentique), pour tout réimplémenter directement en Elixir. Ce n’est pas un règlement de comptes : la moitié de l’article porte sur les « qualités de fedify que j’ai découvertes après l’avoir quitté ».
-
Dès le départ, je n’utilisais pas les fonctions de framework de fedify (createFederation, inbox listener, dispatcher, etc. — les outils de haut niveau qui prennent en charge toute la fédération) ; je n’empruntais que les briques de plus bas niveau :
- les classes de vocabulaire
- toJsonLd/fromJsonLd (des convertisseurs qui transforment les formats de message dans un sens ou dans l’autre)
- signRequest/verifyRequest, qui connaissent les deux méthodes de signature draft-cavage et RFC 9421
- les signatures LD, le document loader
- les entrées/sorties de clés/JWK (un format standard qui contient les clés publiques)
-
Il y avait trois raisons au départ :
- À partir du moment où j’avais décidé de ne pas utiliser le framework, tout ce que fedify gérait gratuitement (la réponse Accept à un Follow, l’idempotence — un mécanisme qui fait qu’une même requête reçue plusieurs fois ne produit son effet qu’une seule fois —, authorized fetch, l’instance actor) devait déjà être pris en charge par moi-même. Il ne restait que les briques de base, donc le volume à porter était borné
- Je vise un petit serveur doté de 512 à 768 Mo de mémoire ; lors d’un test d’endurance, Elixir a terminé de façon stable à 130 Mo, tandis que le worker Bun est parti en OOM à 120 Mo (mort par manque de mémoire). La seule partie du système qui tournait dans un autre langage était aussi la plus lourde et la plus fragile
- La frontière entre langage et processus créait elle-même des problèmes. Préserver les données brutes nécessaires à la vérification des signatures, restaurer les adresses modifiées par le tunnel, emballer les clés présentes en base de données en JWK pour les transférer vers un autre processus, etc. : ce n’était pas la faute de fedify, mais cela faisait une tuyauterie qui ne cessait de s’étendre
-
Le remplacement s’est achevé en 12 fichiers, pour environ 2 100 lignes. La structure de la file de messages est restée inchangée ; il a suffi de le faire rejoindre le même groupe, puis la bascule s’est résumée à « arrêter le conteneur Bun »
-
Le filet de sécurité, c’est fedify lui-même qui l’a fourni. Les signatures Ed25519 et la normalisation URDNA2015 (une règle qui remet toujours un document dans le même ordre) donnent toujours le même résultat pour une même entrée ; il a donc été possible de générer à l’avance les « données de référence » avec le vrai code de fedify, puis de vérifier que le résultat porté en Elixir correspondait au caractère près
-
Le worker Bun a pris sa retraite, mais il n’a pas été supprimé. Il reste aujourd’hui dans l’environnement de développement pour générer les données de référence
-
L’équipe fedify développe DrFed (https://drfed.org/), un outil de débogage ActivityPub. Il devrait inclure des fonctions de diagnostic indiquant à quelle étape la fédération casse (DNS/TLS/HTTP/signature/JSON-LD), ainsi qu’un débogueur permettant de suivre pas à pas les deux méthodes de signature (soutenu par NLnet NGI0, open source sous AGPL-3.0, actuellement en développement)
-
En conclusion : cela signifie aussi que, si vous utilisez le framework complet en TypeScript/JavaScript, fedify reste probablement le meilleur choix. La fonctionnalité ActivityPub de Ghost, hackers.pub et Hollo tournent tous dessus
Aucun commentaire pour le moment.