Note
このドキュメントは2026-02-27 03:08にPLaMo Translation Modelを使用して自動翻訳されました。
FEP-0499: マルチボックスエンドポイントによる複数受信箱への配信機能の実装
概要
本FEPでは、サーバー全体で利用可能なエンドポイントを導入し、活動(アクティビティ)を複数の受信箱に一括して配信する機能を提供します。現在sharedInboxでもこの機能は利用可能ですが、送信先アドレスの属性に基づいて適切な配信方法を決定するためには、リモートサーバー側でその仕組みを理解する必要があります。しかし、プライベートユーザーやコレクション内の特定メンバーへの配信方法について、リモートサーバーが必ずしも適切に処理できるとは限りません。このマルチボックスエンドポイントを導入することで、受信側サーバーからこの判断要件を撤廃し、代わりに送信側が明示的に配信対象とする受信箱を指定する責任を担うようになります。
背景と必要性
(本セクションは規範性を持たない解説です)
sharedInboxは、パブリックな活動を複数の宛先に配信する際のネットワークトラフィックを削減できる機能を提供しますが、コレクション内のメンバーやbto/bccを使用したプライベートオーディエンスへの配信には対応していません。アドレス指定がコレクションに対して行われている場合、そのアクティビティをリモート側のsharedInboxエンドポイントに送信すると、受信サーバーは当該コレクションの内容(少なくともそのローカル部分)を把握している必要があります。フォロワーリストを含むコレクションを対象にsharedInboxエンドポイントを使用する一般的なケースでは、リモートサーバーはまずこのコレクションIDが特定の「フォロワー」コレクションであることを認識し、さらにどのローカルユーザーがその活動の発信者をフォローしているかを推測しなければなりません。この方法には問題が生じる可能性があり、特にフォロワー情報に不整合が生じた場合には重大な結果を招く恐れがあります。
共有されたフォロワー状態への依存を解消し、パブリック以外のアクティビティ配信を可能にするため、本FEPでは新たなエンドポイントを提案します。この新しいエンドポイントでは、リモートサーバー側に特別な知識がなくても複数の受信箱への配信が可能になります。これにより、任意のコレクションに対するアドレス指定や、bto/bcc機能をより効率的に活用できるようになります。
関連技術
(本セクションは規範性を持たない解説です)
元のマルチボックス提案では以下の利点が挙げられています:
共有Inboxは、送信先人数Rに応じて発生するネットワークトラフィックを、単一のHTTPリクエストに削減する機能を提供します。これは送信者と受信者双方にとって望ましい特性であり、HTTPラウンドトリップ回数を削減できます。しかし、ActivityPub仕様書に記載されたShared Inboxの設計では、明示的な配信宛先を指定しないため、スパム行為者がシステムを簡単に悪用できる可能性があります。本提案では、この問題を回避しつつ、Shared Inboxが持つ利点を維持するための代替ソリューションとして「MultiBox」を提案します。これは、送信者がShared Inboxを濫用してサーバーに「スパム」を送ることを防ぐ仕組みです。
Shared Inboxと同様に、MultiBoxも複数のActor向けの単一HTTPエンドポイントで構成されます。ただし、Shared Inboxとは異なり、MultiBoxリクエストでは各宛先がInboxごとに明示的にリストされ、対応するActorとそのInboxに関する情報が必要となります。この情報はHTTPヘッダー「Audience」を使用して送信され、各Inboxはカンマ区切り値形式で指定されます。
これはShared Inboxに比べて2つの利点があります。単独で使用すれば、前述のメッセージ受信者を列挙する必要がない脆弱性を解消できます。さらに、オブジェクト権限ベースのインボックス提案(4.5項)と本提案を組み合わせることで、特定のInboxが定める基準に従って受信メッセージを適切にフィルタリングできる機能が得られるほか、各Inboxの発信元情報も把握可能になります。
送信側にとって、MultiBoxリクエストを送信するための追加的な計算リソース要件は最小限ですが、これによりシステムを悪用しようとする大量メッセージ送信者にとってはコストが高くなるという効果があります。
本提案に関する未解決の課題として、HTTPヘッダー「Audience」に受信者リストを格納する場合、何らかの制約が生じる可能性があります。HTTPヘッダーサイズはプロトコルレベルで明確に制限されているわけではありませんが、実装によっては異なる上限値が設定されています(例えばNginxウェブサーバーでは4KB、Apacheでは8KB)。
これによりメッセージごとの宛先数に制限が生じますが、この制約が実際に問題となることは稀でしょう。本提案に代わる解決策として、「Audience」フィールドと~Activityを含む新しいMultiBoxオブジェクトを導入する方法が考えられます。
提案内容
(本セクションは規範性を持たない解説です)
本FEPでは、HTTPヘッダーではなくPOSTリクエストの本文部分に受信箱情報を格納する「代替アプローチ」を採用しています。デフォルトではヘッダーサイズが最大4KBに制限される可能性がある一方、POSTリクエストボディの制限値は通常はるかに高く、Nginxではデフォルトで1MBまで許容されます。これは4,000文字と100万文字という大きな違いに相当します。
仕様
サーバーは、同一ドメイン内の複数受信箱への活動配信を効率的に行うためのmultiboxエンドポイントを任意で実装できます。
サーバーは以下の場合に、個別に配信されるはずだったすべての宛先が共通して持つmultiboxエンドポイントを特定し、以下の形式のアクティビティをその共有multiboxエンドポイントに一括送信することで、配信リクエスト数を削減できます:
typeは必ずAddである必要があります。objectには実際に配信する活動データを含める必要があります。targetには、すべての宛先となる受信箱を指定しなければなりません。
このようなアクティビティを受信したサーバーは、objectに含まれる活動データをtargetで指定されたすべてのローカル受信箱に追加する必要がありますが、実装固有のルール(例えばスパムフィルタリングなど)に基づいて特定の受信箱への配信を適宜フィルタリングすることも可能です。
使用例
(本セクションは規範性を持たない解説です)
マルチボックスエンドポイントの発見方法:
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/fep/0499"
],
"id": "https://remote.example/actors/af4c8205cd81",
"type": "Person",
"name": "Alice P. Hacker",
"inbox": "https://remote.example/inboxes/fbb433c8e6c4",
"endpoints": {
"multibox": "https://remote.example/multibox"
}
}
コンテキスト宣言を省略した場合の例:
{
"@context": "https://www.w3.org/ns/activitystreams",
"id": "https://remote.example/actors/af4c8205cd81",
"type": "Person",
"name": "Alice P. Hacker",
"inbox": "https://remote.example/inboxes/fbb433c8e6c4",
"endpoints": {
"https://w3id.org/fep/0499/multibox": {"id": "https://remote.example/multibox"}
}
}
マルチボックスエンドポイントへの配信例:
POST /multibox HTTP/1.1
Host: remote.example
Content-Type: application/ld+json; profile="https://www.w3.org/ns/activitystreams"
{
"@context": "https://www.w3.org/ns/activitystreams",
"type": "Add",
"object": "https://example.com/some-activity",
"target": [
"https://remote.example/inboxes/fbb433c8e6c4",
"https://remote.example/inboxes/d21f509146e5",
"https://remote.example/inboxes/68a7453f79e4",
"https://remote.example/inboxes/655216a0be07",
"https://remote.example/inboxes/84907eff485d",
]
}