Weg von fedify – was ich erst nach dem Abschied an fedify zu schätzen lernte

(Dies ist ein Beitrag aus meinem eigenen Blog. Den Text habe ich mit Unterstützung meines AI-Assistenten Shiro geschrieben; wenn es Fehlinterpretationen gibt, freue ich mich über Hinweise.)

Dies ist ein Erfahrungsbericht darüber, wie der kleine Fediverse-Server sukhi-fedi – ein SNS-Netzwerk, in dem Server wie bei Mastodon miteinander verbunden sind – fedify (eine als Bun Worker laufende Bibliothek) entfernt hat, das bisher den Zusammenbau von JSON-LD (das Erstellen von Nachrichten in einem Format, das Server untereinander verstehen) und HTTP-Signaturen (das Signaturverfahren zur Prüfung, ob eine Nachricht echt ist) übernommen hatte, und stattdessen alles direkt in Elixir implementiert hat. Es ist keine Schimpftirade; zur Hälfte geht es um „die guten Seiten von fedify, die ich erst nach dem Weggehen erkannt habe“.

• Die Framework-Funktionen von fedify (createFederation, Inbox Listener, Dispatcher usw. – höher angesiedelte Werkzeuge, die die Föderationsfunktionen insgesamt automatisch übernehmen) habe ich von Anfang an nicht genutzt, sondern nur die Bauteile auf der untersten Ebene ausgeliehen:

  • vocab-Klassen
  • toJsonLd/fromJsonLd (Konverter, die Nachrichtenformate ineinander umwandeln)
  • signRequest/verifyRequest, die beide Signaturverfahren kennen: draft-cavage und RFC 9421
  • LD-Signaturen, document loader
  • Ein- und Ausgabe von Schlüsseln/JWK (ein Standardformat für öffentliche Schlüssel)

• Für den Abschied gab es drei Gründe:

  1. In dem Moment, in dem ich mich gegen das Framework entschied, musste ich all die Dinge, die fedify sonst kostenlos mitgebracht hätte (Accept-Antworten auf Follow, Idempotenz – ein Mechanismus, damit dasselbe Ergebnis nur einmal wirksam wird, auch wenn dieselbe Anfrage mehrfach eintrifft –, authorized fetch, instance actor), ohnehin schon selbst behandeln. Übrig blieben nur die Grundbausteine, daher war der Umfang der Migration klar begrenzt
  2. Ziel war ein kleiner Server mit 512–768 MB Arbeitsspeicher. In Belastungstests lief Elixir mit 130 MB stabil bis zum Ende durch, während nur der Bun Worker schon bei 120 MB mit OOM (Absturz wegen Speichermangels) scheiterte. Der einzige Teil des Systems, der in einer anderen Sprache lief, war der schwerste und zugleich schwächste
  3. Die Grenze zwischen Sprachen und Prozessen erzeugte selbst Probleme. Rohdaten für die Signaturprüfung unverändert zu bewahren, durch Tunnel veränderte Adressen wiederherzustellen, in der DB liegende Schlüssel als JWK zu verpacken und in einen anderen Prozess zu verschieben – das war nicht fedifys Schuld, aber es wurde immer mehr Klempnerarbeit

• Die Ersetzung war mit 12 Dateien und rund 2.100 Zeilen erledigt. Die Struktur der Message Queue blieb unverändert; der neue Teil wurde derselben Gruppe hinzugefügt, und die Umschaltung bestand schlicht darin, „den Bun-Container anzuhalten“

• Das Sicherheitsnetz lieferte ausgerechnet fedify selbst. Ed25519-Signaturen und die URDNA2015-Normalisierung (Regeln, die ein Dokument immer in dieselbe Reihenfolge bringen) liefern bei gleicher Eingabe immer dasselbe Ergebnis. So konnte ich mit dem echten fedify-Code vorab „Referenzdaten“ erzeugen und prüfen, dass das nach Elixir übertragene Ergebnis bis auf das letzte Zeichen identisch ist

• Der Bun Worker wurde in den Ruhestand geschickt, aber nicht gelöscht. Er bleibt auch jetzt in der Entwicklungsumgebung erhalten, wo er Referenzdaten erzeugt

• Das fedify-Team baut DrFed (https://drfed.org/), ein Debugging-Tool für ActivityPub. Geplant sind Diagnosefunktionen, die zeigen, auf welcher Stufe der Föderation (DNS/TLS/HTTP/Signatur/JSON-LD) etwas bricht, sowie ein Debugger, mit dem man die beiden Signaturverfahren Schritt für Schritt nachvollziehen kann (unterstützt von NLnet NGI0, AGPL-3.0 Open Source, derzeit in Entwicklung)

• Unterm Strich heißt das auch: Wenn man in TypeScript/JavaScript ein ganzes Framework verwenden möchte, ist fedify weiterhin die beste Wahl. Ghosts ActivityPub-Funktion, hackers.pub und Hollo laufen alle darauf