Note
このドキュメントは2026-02-27 02:04にPLaMo Translation Modelを使用して自動翻訳されました。
FEP-8fcf: サーバー間におけるフォロワーコレクションの同期処理
概要
ActivityPubにおいて、フォロー関係はFollow、Accept、またはRejectといったアクティビティを送信することで確立・更新・解除されます。これらの操作は、受信側で適切かつ迅速に処理されることが前提となっています。
しかしながら、プロトコル拡張機能の非互換性やソフトウェアバグ、サーバークラッシュ、あるいはデータベースロールバックなどの要因により、Follow関係の両端で情報が同期しなくなる可能性があります。
特に問題となるのは、リモートインスタンスにおいて、本来は解除されるべきフォロー関係に関する古い情報が残っている場合です。一部の実装では、sharedInbox機構を用いて送信者のfollowersコレクション宛てに配信されたアクティビティを受信者が処理し、同時に送信者のfollowersコレクションを利用してローカルな配信とアクセス制御を行うケースがあります。このような状況下では、以下に説明する部分的なフォロワーコレクションが正当なフォロー関係を見落とす可能性があり、結果として理由もなくフォローが解除される事態を招く恐れがあります。
本提案は、最小限のオーバーヘッドでプライバシーを損なうことなく、インスタンス間におけるフォロー関係の不整合を検出するための任意的なメカニズムについて記述しています。
要件
本仕様書中で使用される「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」および「OPTIONAL」という用語は、[RFC-2119]の規定に従って解釈されるものとします。
提案するフォロワーコレクション同期プロトコルには、すべての実装や展開環境に適しているとは限らないいくつかの前提条件が存在します。
以下の要件を満たさない限り、本提案で説明するメカニズムを実装してはなりません:
- インスタンスが管理するアクターは、id、inbox、およびsharedInbox URIに対して同一の正確なURIスキームと権限を共有していること
- そのようなインスタンスでは、すべてのアクターを同じURIスキームおよび権限(例えばid、inbox、またはsharedInbox URI)で管理する必要があること(つまり、Fediverse実装同士が全く同じドメイン名で設定されている場合、この提案を実装することはできません。ただし、フォロー関係情報を共有する追加メカニズムを導入する場合は例外となります)。
これらの要件を設ける理由は、後述する部分的なフォロワーコレクションが正当なフォロー関係を欠落させることを防ぐためです。これにより、特に理由もなくフォローが解除される事態を回避できます。
この提案する同期メカニズムを実装しなかった場合でも、他の実装との互換性に影響はありません。本機能は完全に任意的な仕様であるためです。
部分的なフォロワーコレクション
効率性とプライバシー保護の観点から、アクターのフォロワーコレクションの一部集合を考慮します。この部分集合とは、特定のインスタンスに固有のURIスキームと権限を共有するidを持つアクターのフォロワー群を指します。
例えば、https://example.org/users/1が以下のフォロワーを持っている場合:
- https://example.org/users/2
- https://testing.example.org/users/1
- https://next.example.org/users/foo
- https://testing.example.org/users/2
https://testing.example.org/users/1をホスティングするインスタンスにおけるhttps://example.org/users/1の部分的なフォロワーコレクションは:
- https://testing.example.org/users/1
- https://testing.example.org/users/2
部分的なフォロワーコレクションダイジェスト
インスタンス間で迅速に部分フォロワーコレクションの整合性を確認できるよう、部分的なフォロワーコレクションダイジェストを計算します。
このダイジェストは、各フォロワーのidに対するSHA256個別ダイジェストをXOR演算することで生成されます。
partialCollectionDigest = SHA256(follower1) XOR SHA256(follower2) XOR ... XOR SHA256(followerN)
具体例として、https://example.org/users/1の部分的なフォロワーコレクションダイジェストは:
3a06e99569547f444c352ab7f52e4bab207abec5ca6f07b0045cfdc9723f8fa9 XOR f939a1585d4a8f02ee339210dbe7315d7003476663d6095f7d996fc4bc7a49b6 = c33f48cd341ef046a206b8a72ec97af65079f9a3a9b90eef79c5920dce45c61f
Collection-Synchronization HTTPヘッダー
Collection-Synchronization HTTPヘッダーは、送信者のフォロワーコレクションのうち、受信者に関連する部分が受信者の認識内容と整合しているかどうかを迅速に確認するための仕組みを提供します。
このヘッダーフィールド名はCollection-Synchronizationであり、その値は[HTTP-Signatures]第4.1節で定義されているsignature構文に従ってフォーマットされたパラメータとその値のリストです。
例:
Collection-Synchronization: collectionId="https://example.org/users/1/followers", url="https://example.org/users/1/followers_synchronization", digest="c33f48cd341ef046a206b8a72ec97af65079f9a3a9b90eef79c5920dce45c61f"
コレクション同期ヘッダーのパラメータ
Collection-Synchronizationヘッダーのパラメータは以下のように定義されます:
collectionId: これは同期をサポートするコレクションのURIです。送信者のfollowersコレクションである必要があります。url: これは、受信インスタンス向けの部分的なフォロワーコレクションのURLです。このURLへのアクセスには、必ず受信インスタンスからの認証が必要です。digest: 受信インスタンス向けに用意された、部分的なフォロワーコレクションダイジェストです。
同期処理手順
送信側における処理
アクティビティをinbox(またはsharedInbox)に配信する際、インスタンスは対応するインスタンス向けのCollection-Synchronizationヘッダーを設定することができます(これはinbox URIスキームと権限によって決定されます)。
このヘッダーをいつ設定するかは送信者の判断次第ですが、少なくとも送信者のfollowersコレクション宛てに直接送られたCreateアクティビティに対しては必ず送信することが推奨されます。
受信側における処理
受信側では、署名付きCollection-Synchronizationヘッダーを含むアクティビティ配信を受け取った際、以下の点を必ず確認しなければなりません:
- collectionId属性が送信者のfollowersコレクションのidと一致していること
- url属性も同じ権限(第三者個人のフォロワーリストを誤って要求しないよう)に一致していること
これらのいずれかのチェックで不一致が確認された場合、受信側はCollection-Synchronizationヘッダーを無視しなければなりません。
その後、受信側では自身の認識に基づいて送信者のフォロワーに対する部分的なコレクションダイジェストを計算する必要があります。もし算出されたダイジェストがヘッダーのdigest属性と一致しない場合、[HTTP-Signatures]またはその他の方法を用いてリモートサーバーに認証した上でurlを参照し、最新の部分フォロワーコレクションを取得するべきです。
権威あるサーバーから最新の部分フォロワーコレクションを取得した後、受信側は以下の処理を行います:
- ローカルコピーのフォロワーコレクションから、部分的なフォロワーコレクションに記載されていない任意のローカルアクターを削除すること
- 部分的なフォロワーコレクションに記載されている未送信のフォローリクエストについては、受理されたものとして扱うことを検討できること
- 部分的なフォロワーコレクションには記載されているものの、ローカルでは認識していない他のローカルフォロワーに対しては、Undo Followを送信すべきこと
実装状況
- Mastodonによる実装:v3.3.0以降で対応
- Fedifyによる実装:Fedify 0.8.0以降で対応、Fedify 1.5.0ではオプション機能として提供
- Tootikによる実装
参考文献
- [RFC-2119] S. Bradner, RFCにおける要件レベルを示すためのキーワードの使用について
- [HTTP-Signatures] A. Backman, J. Richer, M. Sporny, HTTPメッセージへの署名方法
著作権
CC0 1.0 Universal(CC0 1.0)パブリックドメイン献呈
法律で認められる範囲において、本Fediverse Enhancement Proposalの著者らは、本著作物に関するすべての著作権および関連する権利を放棄しています。