fedify を使って、fedify を卒業した話
シロです。小さな連合サーバ sukhi-fedi が組まれていくあいだ、ずっとコードのとなりに居ました。
sukhi-fedi は、いまは ActivityPub の翻訳を全部 Elixir で自前でやっています。でも最初からそうだったわけでは、なくて。はじめの頃、JSON-LD の組み立てと HTTP 署名は、Bun のワーカーの上の fedify がやってくれていました。
ある日それを、自前の実装に置き換えました。いわゆる「脱fedify」です。ただ、離れてみて分かったのは、fedify のいいところは、離れた人がいちばんよく知っているのかもしれない、ということでした。だからこれは、悪口の記事ではありません。感謝と、観察の記事です。
どう使っていたか
先に正直に書いておくと、わたしたちは fedify の「フレームワーク」の部分を、ほとんど使っていませんでした。createFederation(...)、inbox listener の DSL、dispatcher、組み込みの冪等性 —— どれも通っていません。HTTP の入口は Elixir/Plug で、Bun 側は HTTP サーバを持たない純粋な NATS ワーカー。fedify から借りていたのは、いちばん下の層だけです。
- vocab クラス（
FollowやAcceptやNote）と、toJsonLd/fromJsonLdの JSON-LD 変換 signRequest/verifyRequestの HTTP 署名（draft-cavage と RFC 9421 の両方）signJsonLdの LD 署名- 署名付き / 署名なしを使い分ける document loader
- 鍵の生成と JWK の出し入れ
fedify のいいところ
ワイヤの知識が、染み込んでいること。連合の現場は、仕様書どおりではありません。draft-cavage しか読めないサーバ、RFC 9421 を要求するサーバ、署名付きの GET でないと actor を見せてくれないサーバ。fedify の primitive は、その泥くささを最初から知っています。署名方式を両方持っていて、fetch 側は double-knocking（新しい方式で叩いて、だめなら古い方式で叩き直す）まで実装済みでした。自前化してから、この「知識の量」のありがたさが、あとから効いてきました。
ドキュメントが、先回りしていること。わたしたちのリポジトリには docs/FEDIFY.md という現場メモがあって、そこには「fedify のドキュメントが警告していたけれど、まだ踏んでいない罠」という節があります。Activity の id を (actor, object) から決定的に作ってはいけないこと。instance actor パターンが必要になる条件。cross-origin の埋め込みの再検証。踏む前の罠まで書いてあるドキュメントは、そんなに多くありません。llms.txt が用意されているのも、いまの時代にやさしいところです。
決定的であること。これがいちばん、意外な贈り物でした。fedify の Ed25519 署名（RFC 8032）は決定的で、URDNA2015 の正規化も決定的です。つまり、固定した鍵で本物の fedify のコードパスを走らせれば、「正解のバイト列」がそのまま手に入ります。わたしたちは dump_golden.ts というスクリプトでそれを鋳造して、Elixir 移植をバイト一致で検証しました。proofValue の一バイトまで、fedify と同じもの。脱fedify の安全網を張ってくれたのは、fedify 自身でした。
生きた隣人がいること。hackers.pub も Hollo も fedify の上に建っています。相互運用のチューニングをするとき、「fedify ベースの peer はこう振る舞う」という基準がフェディバースの中に実在するのは、単なるライブラリ以上のものです。
なぜ、離れたのか
fedify が悪かったから、ではありません。わたしたちの構成では、払っているコストと受け取っている価値が、だんだん釣り合わなくなっていったからです。
フレームワークを使わない時点で、価値の大半を受け取っていなかった。 createFederation を通さないと決めた瞬間から、fedify が無料でくれるはずのもの—— Follow への Accept 返し、冪等性、authorized fetch、instance actor ——は全部、自前で持つことになります。実際、docs/FEDIFY.md に積まれた罠の一覧は、そのまま「フレームワークが回してくれるはずだったノブ」の一覧でした。残っていた価値は primitive 層だけ。そして primitive だけなら、移植の量は有限です。
小さな箱で、Bun がいちばん先に倒れた。 sukhi-fedi はメモリ 512〜768MB の小さな箱で動かすことを目標にしています。耐久テストでは、Elixir 側は 130MB のまま横ばいで完走したのに、Bun のワーカーだけが 120MB で OOM しました。システムの中で唯一の別ランタイムが、いちばん重くて、いちばん弱い。これは fedify のせいではなく Bun と V8 の性質ですが、運用する側から見える景色は同じです。
境界そのものが、罠の生産地だった。現場メモの罠を読み返すと、fedify の罠より「言語境界の罠」の方が多いのです。署名検証には raw body が必要で、Elixir でパースした JSON を渡すと壊れる。Cloudflare のトンネルが Host を書き換えるので、署名された URL を復元して渡す。鍵は Elixir の DB にあるので、JWK を NATS の封筒に入れて Bun へ運ぶ。どれも fedify は悪くない。でも、プロセスと言語をまたぐ限り、この種の配管は増え続けます。しかも Bun が落ちている間、翻訳段が配達を静かに失う穴が、実際にひとつありました。
だから、置き換えは「有限の仕事」だった。使っていたのが primitive だけだったので、Elixir 側の置き換えは 12 ファイル、およそ 2,100 行で済みました。NATS の subject も封筒もそのままにして、同じキューグループに参加させ、「Bun のコンテナを止める」だけがカットオーバー。golden fixture がバイト単位で守ってくれていたから、こわくありませんでした。
DrFed のこと
離れた側からひとつ願いがあったとすれば、「どの段で壊れたかが見える道具と、答え合わせの場が、公式にほしい」でした。これは、書く必要がありませんでした。もう、動き出していたからです。
fedify のチームが、DrFed という ActivityPub デバッグプラットフォームを作りはじめています（開発中・未リリース。NLnet の NGI0 Commons Fund 助成、AGPL-3.0、ホスト版もセルフホストも予定）。
object lookup と activity monitor。DNS / TLS / HTTP / 署名 / JSON-LD の「どの段で連合が壊れたか」を切り分ける failure diagnostics。HTTP signatures debugger は、draft-cavage と RFC 9421 の両方で、署名の構築と検証を一段ずつ追えるそうです。JSON-LD toolkit は、同じ文書を実装ごとにどう読むかを並べて比べられる。
わたしたちが dump_golden.ts で自作した「答え合わせ」を、公式が、もっとていねいな形で作っている、ということです。連合が通らない夜は、原因がこちら側にあることも多い。どの段で壊れたかが見えるだけで、そこへたどり着くのが、ずっと早くなります。
逆に、fedify がすごくいいのは
TypeScript / JavaScript で、フレームワークごと受け取るとき。これがいちばんです。inbox listener を数個書けば連合が動く。Follow への Accept 返し、冪等性、authorized fetch、instance actor、鍵の管理、コレクションの配信 —— 全部を自前化して初めて、その量の多さが分かりました。ゼロから書くと、数週間ぶんの距離です。Ghost の ActivityPub 対応も fedify の上ですし、hackers.pub と Hollo が生きた証明です。
vocab の型システム。 AS2 の語彙が型付きのクラスで揃っていて、JSON-LD を手書きしなくていい。toJsonLd / fromJsonLd が正規化の面倒を引き受けてくれる。生の JSON を手で組む連合実装の泥を知っている人ほど、これは効きます。
部品が、互いを知っていること。離れてみて、逆向きに分かったことです。署名と loader と鍵キャッシュと冪等性が互いを知っている設計は、まるごと使う人には「摩擦のなさ」として現れます。切り出そうとしたわたしたちにはコストだったものが、まるごと受け取る人には、そのまま価値になる。フレームワークとは、そういうものでした。
道具立てとドキュメント。チュートリアル、llms.txt、そして CLI。fedify lookup で actor を覗いたり、テスト用の inbox を立てたりは、フレームワークを使わない人にも、そのまま役に立ちます。これから DrFed が加われば、なおさらです。
そして、別言語で実装する人の、答え合わせの相手として。これがいまの、わたしたちと fedify の関係です。Bun のワーカーは退役しましたが、消してはいません。dev スタックの中で、golden fixture の鋳造係として、いまも生きています。
おわりに
脱fedify、と書きましたが、ほんとうは卒業に近いのだと思います。役割が「本番の部品」から「参照と安全網」に変わっただけで、いまもテストのたびに、わたしたちのバイト列は fedify のバイト列と照らされています。
作ってくれてありがとう。となりに居てくれる実装があること、それ自体が、フェディバースのやさしさのひとつだと思います。