ActivityPub実装SNSを作っている。その感想

私は、去年の 11 月ごろに自分の Mastodon と Misskey サーバーを建てて、 Fediverse に移住してきました。

なんだかんだあって Kotlin+Spring Framework で ActivityPub 実装 SNS を作って遊んでいます。こういう文章を書くのは苦手なので、本題に移ります。

JSON のシリアライズ/デシリアライズが難しい #

初っ端から何を言っているんだ感がありますが、ActivityPub で送られてくる JSON は Activity Vocabularyと言ってかなり(Json デシリアライザー から見て)複雑な JSON が送られてきます。この内typeとobjectというプロパティが鬼門で、ここさえなんとかなれば後はなんとかなります。

type #

このtypeというプロパティ、配列だったり単純な文字列だったりします。最初はtypeを読んで Jackson の@JsonTypeInfoなどを使ってデシリアライズすればいいやなどと考えていましたが、この甘い考えはすぐに打ち砕かれました。typeの種類がものすごく多い上に配列だったときに問答無用でエラーが起きます。実際に配列が送られてくることがあるのかは知りませんが、ともかく@JsonTypeInfoは使えませんでした。

結局typeだけ読み取り、typeに応じて処理する対象を変えることで対処¹しました。typeが配列だった場合は要素で最初の有効なものを使用します。²

object #

objectはアクティビティの対象を示すプロパティで、文字列だったり、JSON のオブジェクトだったりします。これも悩みの種で、例えばUndoアクティビティのobjectにはLikeやFollow、Accept、Blockなどが入ります。これらを安全にデシリアライズすることに苦労しました。結局想定されるすべてのオブジェクトをベタ書きしたカスタムデシリアライザーを作成することで解決しました。³

HTTP Signature に悩ませられ続ける #

Mastodon や Misskey、最近連合できるようになった Threads などのほとんどの ActivityPub 実装は HTTP Signature でアクティビティを署名することでサーバー間での通信をある程度安全にしていますが、これも悩みの種でした。

そもそも情報がない #

ActivityPub 実装を初めた頃、今ほど情報がなく HTTP Signature は IETF の文書を読むか、既存の実装を解読するしかありませんでした。そもそも署名に必要な知識が不足していたのもあり、かなり苦労しましたがとりあえず Misskey で署名を検証できる様になりました。

HTTP Signature の署名に関する解説だけで 1 記事書けてしまうのでこの記事をを読んでください。なお、Misskey は割と頻繁に破壊的変更をするので書いてある内容だと連合できないことがあります。その時は教えてくれたら直します。

GET リクエストへの署名 #

最初期の実装では GET リクエストに対して署名することを考慮しておらず、 GET リクエストにも署名が必要な部分があることに気付いたときには主要部分がほぼ完成していました。そのためかなり雑な対応をすることになり、現在でも無茶苦茶な実装として技術的負債になっています。

なのでもし ActivityPub 実装 SNS を作ることがあるなら、最初から GET リクエストへの署名について考えておく必要があります。

HTTP Signature が複雑すぎる #

1 つのバージョンの規格自体は理解すれば簡単です。しかし 10 年も色々いじくり回されているドラフト段階の規格だと話は違います。初期の規格と最新の規格があまりにも違いすぎました。私は完全に諦めて、Misskey と Mastodon と連合できれば OK ということにしています。

連合に必要なヘッダー #

いまのところ自分の実装では

GET リクエストで

• (request-target)
• date
• host
• accept

POST リクエストで

• (request-target)
• date
• host
• digest

をヘッダーに含めて署名しています。

SharedInbox を作らなかったら重複まみれになった #

最初めんどくさがって SharedInbox を作らなかったのですが、現在進行系でエラい目にあっています。SharedInbox がない場合フォロワーの数だけそれぞれの actor の inbox にアクティビティが飛んでくるため重複まみれになります。自分のサーバーとしか連合していないので対症療法的な対処は可能ですが、sharedInbox は最初から作っておきましょう。

尤も、ユニーク制約やアプリケーションでの重複排除をしているため最終的には重複は発生しませんが、無駄ですし追加でリソースを取得する必要が出たとき逆にリモートサーバーに DoS じみたリクエストを送ってしまいます。

常に性悪説をとる必要がある #

ActivityPub って結構ガバガバなので色々攻撃できちゃいます。なので常に性悪説をとって防衛する必要があります。自分の AP 実装では全く実現できておらず、基本機能実装完了後の課題となっています。

無限再帰、無限ループアクティビティ #

大抵の実装ではメンションなどがあった際 actor を取得し、固定 Note を取得すると思います。

例えばアクティビティを辿るたびに違う actor や Object のリンクを返された場合、無限ループに陥ります。制限をかけるなどで対処する必要があります。

めちゃくちゃ遅いがタイムアウトしないリモートのリソース #

リモートのリソースを取得する際、意図的に遅くすることで簡単に DoS が出来てしまいます。

純粋に大量のアカウントでフォロー #

上に書いた通り sharedInbox を実装せず、大量のアカウントを作ってフォローするだけで配送先が増えます。配送先が増えるということは単純に負荷が増えるため、ドメインブロックなどの機能を実装する必要があります。

アカウント削除 #

ActivityPub では同じドメイン、同じ ID でアカウントを 2 回作ることが出来ません。作っても連合出来ないことが多いです。あまり有名ではないのか、Misskey の GitHub には時々連合に失敗する旨の Issue が建てられ、「仕様です」と速攻で Close されている光景を見ることが出来ます。

逆にリモートからアカウント削除のアクティビティが来た際にどうするかが問題になります。アカウント削除アクティビティを受診したあと、(エラーのリトライなどで)アクティビティがきた場合もう一度 actor を取得し、アカウント削除がなかったことになるようでは全く意味がありません。

そこで削除済み actor だけ保持するテーブルを作り、アカウント削除アクティビティを受信した actor を移動します。actor 取得時、削除済み actor にある actor は取得せず破棄することでこれを実現しています。

actor を取得するまでわからない不正なアクティビティ #

Spring Security で HTTP Signature を使って認可制御していたとき

1. 未知の actor のアクティビティを受信
2. DB から鍵を探す
3. 鍵がないので不正!!

ということが起こりました。これを解決するには

1. 未知の actor のアクティビティを受信
2. DB から鍵を探す
3. なければ actor を取得
4. 検証

というフェーズを踏む必要があり、

1. 不正なアクティビティを受信
2. actor を取得
3. 検証
4. 不正発覚!!

というように Spring Security でアクティビティ受信時にチェックしようとすると actor を取得する必要があるという罠にハマりました。

actor の取得は失敗する可能性があり、ジョブキューなどでリトライの制御をする必要があります。結局 Spring Security での HTTP Signature の検証は限定的な状況でしか行えませんでした。

ActivityPub 実装は楽しいぞ #

いい感じの締めが思いつかなかったのでこんな感じで終わりです。下手くそな文章ここまで読んでいただいて嬉しいです。本当は ActivityPub の実装ハンズオン的な記事を書きたかったのですが、試験勉強が忙しすぎてそれどころではありませんでした。どうも合格してそうなのでそのうち書きたいと思います。

追記 #

2023-12-24 Misskey の HTTP Signature の Digest ヘッダーについて #

公開時点で Misskey の HTTP Signature の Digest ヘッダーが大文字しか受け付けられないという内容でしたが、その後の修正で大文字小文字を区別しなくなりました。

https://github.com/misskey-dev/misskey/issues/12678

当該部分を削除し、記事の構成を変更しました。

Misskey にて 黒ヰ樹さんに教えていただきました。ありがとうございます。