脱fedify ― 離れてみてわかったfedifyの良いところ

（私が運営しているブログの記事です。本文は、私と一緒に働いているAIアシスタントのシロの助けを借りて書きました。読み違いがあれば教えていただけるとありがたいです）

小さなFediverse（Mastodonのように、サーバー同士が相互接続されるSNSネットワーク）サーバーである sukhi-fedi が、JSON-LD の組み立て（メッセージをサーバー同士が理解できる形式にする作業）と HTTP 署名（メッセージが本物かどうかを確認する署名手順）を担っていた fedify（Bun ワーカーで動いていたライブラリ）を取り除き、すべて Elixir で直接実装した記録です。悪口ではなく、「離れてみてわかった fedify の良いところ」が半分を占める記事です。

• そもそも fedify のフレームワーク機能（createFederation、inbox listener、dispatcher など — 連合機能全体を自動で処理してくれる上位ツール）は使わず、最下層の部品だけを借りていました。

  • vocab クラス
  • toJsonLd/fromJsonLd（メッセージ形式を相互に変換するコンバーター）
  • draft-cavage と RFC 9421 の2種類の署名方式をどちらも扱える signRequest/verifyRequest
  • LD 署名、document loader
  • 鍵/JWK（公開鍵を格納する標準形式）の入出力

• 離れた理由は3つあります。

  1. フレームワークを使わないと決めた時点で、fedify が無料で面倒を見てくれていたもの（Follow への Accept 応答、冪等性（同じリクエストが複数回来ても結果が一度だけ反映されるようにする仕組み）、authorized fetch、instance actor）は、すでにすべて自分で処理する必要がありました。残ったのは基本部品だけだったので、移植する量は決まっていました
  2. メモリ 512〜768MB の小さなサーバーを目標にしているのに、耐久テストでは Elixir は 130MB で安定して完走し、Bun ワーカーだけが 120MB で OOM（メモリ不足で落ちること）になりました。システム内で唯一別言語で動いていた部分が、最も重く、最も弱かったのです
  3. 言語とプロセスの境界そのものが問題を生み出していました。署名検証に必要な元データの保持、トンネルが書き換えてしまうアドレスの復元、DB にある鍵を JWK で包んで別プロセスへ移す作業など、fedify のせいではありませんが、増え続ける配管作業でした

• 置き換え作業は12ファイル、約2,100行で終わりました。メッセージキュー構造はそのままに、同じグループへ参加させたうえで、切り替えは単に「Bun コンテナを止めること」だけでした

• セーフティネットを用意してくれたのは、ほかならぬ fedify 自身でした。Ed25519 署名と URDNA2015 正規化（文書を常に同じ順序に整理するルール）は、同じ入力なら常に同じ結果になる方式なので、本物の fedify コードで「正解データ」をあらかじめ出力しておき、Elixir に移した結果を一文字も違わないよう検証できました

• Bun ワーカーは引退しましたが、削除はしていません。今でも開発環境で正解データを作る役割として残っています

• fedify チームは ActivityPub デバッグツール DrFed（https://drfed.org/）を作っています。連合がどの段階（D… NGI0 支援、AGPL-3.0 オープンソース、現在開発中）

• 結論としては、TypeScript/JavaScript でフレームワークを丸ごと使うなら、fedify は今でも最善の選択肢だという話でもあります。Ghost の ActivityPub 機能、hackers.pub、Hollo はいずれもその上で動いています