FEP-ae0c: Fediverseリレープロトコル：MastodonとLitePub

Warning

このFEPはgemini-2.5-flashを利用して2025-08-17に翻訳されました。オリジナルのFEPはここから閲覧できます。

概要

リレー（Relay）は、分散型Fediverseアーキテクチャにおける重要なコンポーネントです。これらは異なるインスタンス間の通信を促進する仲介サーバーとして機能し、Fediverseプラットフォームのユーザーがアクターのフォロー関係を必要とせずに公開コンテンツを共有できるようにします。

これらのリレーは、小規模なインスタンスがFediverseコンテンツの消費者としても生産者としても、連合型ソーシャルネットワークに効果的に参加できるようにすることで、利益をもたらします。

Activity Fediverseにはいくつかのスタイルのリレーが存在します。このFEPは、2つの一般的なリレーのスタイルを記述します。

Mastodonスタイルリレー
LitePubスタイルリレー

注：これは現状を文書化した情報提供FEPです。RFC-2119の要件キーワードは便宜上使用しているに過ぎません。また、これらは標準化されたプロトコルではありません。ActivityPub標準のいくつかの概念を使用していますが、一般的にはActivityPub標準に準拠していません。

用語

このドキュメントでは、以下の用語を使用します。

用語	説明
リレークライアントアクター	リレーサーバーの購読者であるサーバー内のアクター。クライアントアクターとも呼ばれます。
リレークライアントサーバー	1つ以上のリレークライアントアクターをホストするサーバー。クライアントサーバーとも呼ばれます。
リレー購読	リレークライアントアクターとリレーサーバーの間で、ActivityPubの`Follow`アクティビティを使用して確立される関係。
リレーサーバーアクター	リレークライアントアクター間でメッセージのリレーを提供するサーバー内のアクター。リレーアクターとも呼ばれます。
リレーサーバー	1つ以上のリレーサーバーアクターをホストするサーバー。リレーサーバーまたはリレーとも呼ばれます。
HTTP署名	メッセージの送信者と内容を検証するために使用されるHTTPベースの署名（Cavage）。
LD署名	トランスポートに関係なくメッセージを検証するために使用されるJSON-LD署名。

Mastodonリレープロトコル

Mastodonリレープロトコルは、リレーされたメッセージを検証するためにLD署名（LD Signatures）に依存しています。これにより、Mastodonは、異なるアクター（リレーサーバーアクター）によって送信されたメッセージであっても、リレーされたメッセージを検証できます。

リレークライアントアクター

リレークライアントアクターは、リレーサーバーアクターとのフォロー関係を確立し、その後、アクターのActivityPub inboxに送信されたリレーメッセージを処理します。リレークライアントサーバーは、公開可視性を持つコンテンツの配信ターゲットにリレーインボックスを追加します。

リレー購読

Mastodonは、リレーのActivityPub inbox URIにActivityPub FollowリクエストをPOSTします。Followリクエストのobjectは、Public擬似コレクション（https://www.w3.org/ns/activitystreams#Public）の完全に展開されたURIでなければなりません（MUST）。リレーはその後、AcceptまたはRejectアクティビティでFollowリクエストに応答します。購読には手動承認が必要な場合があるため、承認の応答時間は任意に長くなる可能性があります。

リクエストは、MastodonがActivityPub連合（federation）に使用するのと同じHTTP署名（Cavage）アルゴリズムを使用して署名されなければなりません（MUST）。リレーは、アクターの公開鍵を取得するためにリレークライアントアクターのドキュメントをフェッチします。最高の相互運用性のためには、アクターのActivityPubドキュメントはMastodon互換であるべきです（SHOULD）。例えば、ActivityPubで要求されるすべてのアクターフィールドに加えてpreferredUsernameが提供されるべきであり（SHOULD）、アクターはsharedInboxエンドポイントURLを提供するべきです（SHOULD）。

リレークライアントアクターのタイプは、アクターのタイプを正確に反映するべきです（SHOULD）。ただし、一部のリレーサーバー実装では、クライアントアクターのActivityPubタイプを制約していることに注意してください。例えば、リレーサーバー実装は、クライアントアクターがApplicationタイプであることを要求し、他のタイプを拒否する場合があります。

Followリクエストの例

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://client.example/6ae15297",
    "type": "Follow",
    "actor": "https://client.example/actor",
    "object": "https://www.w3.org/ns/activitystreams#Public"
}

Follow承認応答の例

Acceptアクティビティは、承認されたFollowアクティビティURIをobjectとして応答してもよいし（MAY）、元のFollowアクティビティのコピーを埋め込んでもよいです。Rejectアクティビティも同様の構造になります。

{
    "@context": "https://www.w3.org/ns/activitystreams",
    "id": "https://relay.example/15c0b99f-23d4-4488-ba9d-d0c7bc2876a5",
    "type": "Accept",
    "actor": "https://relay.example/actor",
    "object": {
        "@context": "https://www.w3.org/ns/activitystreams",
        "id": "https://client.example/6ae15297",
        "type": "Follow",
        "actor": "https://client.example/actor",
        "object": "https://www.w3.org/ns/activitystreams#Public"
    }
}

リレー購読解除

リレーの購読を解除するには、元のFollowアクティビティ（埋め込み、またはURI）をobjectとしてUndoを送信します。通常、Undoに対する応答はありません。

Undo/Followリクエストの例

{
    "@context": "https: //www.w3.org/ns/activitystreams",
    "id": "https://client.example/3f5ebd6d",
    "type": "Undo",
    "actor": "https://client.example/actor",
    "published": "2024-10-14T14:42:17.650139+00:00",
    "object": "https://client.example/6ae15297"
}

リレーへのメッセージ公開

Mastodonスタイルリレーにアクティビティを公開するには、発行者はMastodon固有のLD署名アルゴリズムを使用してメッセージに署名しなければなりません（MUST）。LD署名を使用する利点は、受信サーバーがクライアントサーバーから再フェッチすることなくメッセージの内容を検証できることです。これにより、クライアントサーバーのサーバー負荷が軽減されます。

欠点は、LD署名の実装が容易ではなく、Mastodonがアルゴリズムの古い非標準形式を使用していることです。Mastodonのドキュメントでは、これらの理由からLD署名をサポートしないことを推奨しています。さらに、Mastodonのドキュメントは、それが実装するLD署名アルゴリズムを正確に記述していません。詳細については、このドキュメントのMastodon LD署名に関する追加情報を参照してください。

投稿されたアクティビティは、Mastodon互換のHTTP署名で署名されなければなりません（MUST）。

Mastodonは、以下の種類のアクティビティをリレーします：Create、Update、Delete、Move。リレーアクターはこれらのタイプのみを転送してもよいですが（MAY）、MastodonはLD署名なしでAnnounceなどの他のリレーアクティビティを受け入れます。Announceの場合、アナウンスされたobjectをフェッチします。

リレーからのメッセージ受信

リレーされたメッセージは、リレークライアントアクターのinboxに投稿されます。リレーされたメッセージは、リレーアクターによって署名されたHTTP署名を持たなければなりません（MUST）。

リレーサーバーアクターから受信したメッセージは、LD署名を持っていてもよいです（MAY）。HTTP署名とLD署名の両方が存在する場合、LD署名検証後、アクティビティのactorが実質的な送信者となります。

LD署名が存在せず、受信したメッセージがAnnounceアクティビティである場合、リレークライアントはコンテンツが正当であること（なりすましではないこと）を確認しなければなりません（MUST）。これは、発信元サーバーからアナウンスされたアクティビティをフェッチするか、ローカルキャッシュからリモートコンテンツを使用することで行われます。ただし、アナウンスされたアクティビティがすでにローカルにキャッシュされている場合、クライアントサーバーにはすでに認識されているため、通常はそれに対して行うべき処理はありません。

リレーされたメッセージを受信するクライアントサーバーは、ActivityPubのオーディエンスターゲティングプロパティに基づいて、ローカルの受信者にもメッセージを配信してもよいです（MAY）。

リレーサーバーアクター

以下の動作は、Mastodonスタイルリレーサーバーアクターの典型的な実装を記述しています。

フォロー

https://www.w3.org/ns/activitystreams#Publicがobjectプロパティに含まれていることを確認します。actorをリレークライアントアクターURIとして使用し、購読者に関する情報を保存します。リレーサーバーは、署名者のドメインなどの要因に基づいてアクセスを拒否することを決定してもよいです（MAY）。

Undo/フォロー

actorが既知のリレークライアントであることを確認し、そうであれば、リレーアクターのフォロワーのセットからクライアントアクターを削除します。

アクティビティのリレー

クライアントアクターからメッセージを受信した場合、リレーはアクティビティのHTTP署名を検証し、発信元のアクターを特定しなければなりません（MUST）。メッセージが有効であれば、その後（リレーアクターのHTTP署名とともに）リレーのフォロワーのインボックスに投稿されます。ActivityPubのオーディエンスターゲティングプロパティに基づく配信は行われません。リレーは、リレーされたメッセージを発信元のリレークライアントアクターに送信してはなりません（MUST not）。

通常、メッセージは変更されずに転送されます。ただし、リレーはメッセージに対して他の処理を行ってもよいです（MAY）。例えば、LD署名のないメッセージをActivityPub Announceアクティビティでラップしてから転送する（pub-relayを参照）などです。このような拡張された動作は、このFEPでは記述されていません。

リレーアクターは、フォロワーからのメッセージのみをリレーするべきです（SHOULD）。リレーアクターは、すでにリレーしていないアクティビティのみをリレーするべきです（SHOULD）。toのようなアドレス指定プロパティは、単一のURIであってもリストでなければなりません（MUST）。

Mastodon LD署名

注：MastodonのLD署名に関するMastodonドキュメントは不完全かつ不正確です。このセクションでは詳細を提供しますが、さらなる明確化のためにMastodonのソースコードを確認する必要があるかもしれません。

Mastodon LD署名で署名されたアクティビティには、アクティビティ内に署名ドキュメント（signatureプロパティを使用）が含まれます。

署名ドキュメントの例

{
  "@context": [
    "https: //www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1"
  ],
  "id": "https://client.example/3f5ebd6d",
  # ...
  "signature": {
      "type": "RsaSignature2017",
      "creator": "https://client.example/actor#main-key",
      "created": "2024-12-08T03:48:33.901Z",
      "signatureValue": "s69F3mfddd99dGjmvjdjjs81e12jn121Gkm1"
  }
}

https://w3id.org/security/v1 JSON-LDコンテキストはsignatureおよび関連プロパティを定義しますが、MastodonではLD署名処理には使用されません。

署名操作を実行する際、署名ドキュメントとアクティビティ（署名ドキュメントなし）は最初に個別に処理（ハッシュ化）されます。SHA256ハッシュダイジェストが連結され、その文字列が署名されます。

JSON-LDアクティビティの署名

creatorとcreatedプロパティのみを持つ署名ドキュメントを作成します。@contextをhttps://w3id.org/identity/v1に設定します。（注：このコンテキストはもはやウェブ上でアクセスできないようです。カスタムJSON-LDコンテキストローダーを備えたローカルコピーが必要になる場合があります。）
署名ドキュメントの正規RDF表現を作成します。これには、標準アルゴリズム（JSON-LD-ALGO）を使用したJSON-LD展開と、Universal RDF Dataset Canonicalization Algorithm 2015（RDF-CANON）を使用したRDFへの変換が必要です。シリアライズされたRDFは、その後SHA256を使用してハッシュ化され、ヘックスダイジェストが作成されます。
同様の手順を使用して、アクティビティドキュメント（署名ドキュメントなし）のSHA256ヘックスダイジェストを作成します。
署名ドキュメントとアクティビティドキュメントのSHA256ヘックスダイジェストを連結し、SHA256とクライアントアクターの秘密鍵を使用して結果に署名します。
Base64を使用して署名をエンコードし、署名ドキュメントのsignatureValueに結果を設定します。
署名ドキュメントのtypeを"RsaSignature2017"に設定します。
アクティビティのsignatureプロパティを署名ドキュメントに設定します。

JSON-LD署名の検証

署名ドキュメントがアクティビティから取得され、タイプが非標準の"RsaSignature2017"であるかどうかがチェックされます。そうでない場合、検証は失敗します。
署名ドキュメントからsignatureValueを保存します。
署名ドキュメントからtype、id、signatureValueプロパティを削除し、ドキュメントの署名について記述された手順を使用して、変更された署名ドキュメントのSHA256ヘックスダイジェストを生成します。
アクティビティからsignatureを削除し、そのSHA256ヘックスダイジェストを生成します。
変更された署名ドキュメントとアクティビティドキュメントのヘックスダイジェストを連結します。
クライアントの公開鍵を使用して、SHA256で署名を検証します。

LitePubリレープロトコル

LitePubプロトコルはActivityPubに基づいており、Pleroma互換サーバーで使用されています。参照実装はPleroma Relayです。

リレークライアント

LitePubリレークライアントアクターは、Applicationタイプであり、アクターIDが/relayで終わる必要があります。最高の相互運用性のためには、Mastodonアクタードキュメントと互換性があり、WebFingerサポートを持つべきです。他の実装では異なるアクターID構造を使用する場合があります（例：AodeRelayは/actorを使用し、Pleromaで動作するようです）。これらのLitePubバリアントの一般的なリレー相互運用性は不明です。

リレー購読

クライアントリレーアクターは、リレーサーバーにFollowを送信します。FollowのobjectはリレーサーバーアクターURIです。

リレーサーバーは、FollowリクエストにAcceptまたはRejectで応答しなければなりません（MUST）。承認された場合、リレーサーバーはLitePubクライアントアクターに対して相互のFollowリクエストを送信します。クライアントサーバーはAcceptまたはRejectアクティビティで応答するべきです（SHOULD）。リレーサーバーは、妥当な時間間隔内に承認が受信されない場合、購読を無視することを決定してもよいです（MAY）。

リレーFollowリクエストの例

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://pleroma.example/schemas/litepub-0.1.jsonld",
        {
            "@language": "und"
        }
    ],
    "actor": "https://pleroma.example/relay",
    "bcc": [],
    "bto": [],
    "cc": [],
    "id": "https://pleroma.example/activities/3fe13910-73f4-4cdc-9c84-ec7013a3e764",
    "object": "https://relay.example/actor",
    "state": "pending",
    "to": [
        "https://relay.example/actor"
    ],
    "type": "Follow"
}

注： 1. JSON-LDコンテキストはJSON-LD処理に対して有効ではありません。litepub-0.1.jsonldドキュメントには、無効なWebFinger関連のコンテキストURLが含まれています。 2. stateプロパティはJSON-LDコンテキストで定義されていません。

リレー購読解除

リレーの購読を解除するには、元のFollowアクティビティをobjectとしてUndoを送信します。通常、Undoに対する応答はありません。

Undo/Followリクエストの例

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://pleroma.example/schemas/litepub-0.1.jsonld",
        {
            "@language": "und"
        }
    ],
    "id": "https://pleroma.example/activities/cf9c85e9-f83f-4a02-b598-880f15423f68",
    "object": {
        "actor": "https://pleroma.example/relay",
        "bcc": [],
        "bto": [],
        "cc": [],
        "context": "https://pleroma.example/contexts/d493d02b-7cc9-49dc-995c-d949af0b5417",
        "id": "https://pleroma.example/activities/3fe13910-73f4-4cdc-9c84-ec7013a3e764",
        "object": "https://relay.example/actor",
        "published": "2024-10-18T14:04:11.029802Z",
        "state": "cancelled",
        "to": [
            "https://relay.example/actor"
        ],
        "type": "Follow"
    },
    "published": "2024-10-18T14:04:11.029791Z",
    "to": [ "https://relay.example/actor" ],
    "cc": [],
    "type": "Undo",
    "actor": "https://pleroma.example/relay",
    "context": "https://pleroma.example/contexts/d493d02b-7cc9-49dc-995c-d949af0b5417"
}

リレーへのメッセージ公開

LitePubリレークライアントアクターは、リレーされたオブジェクト（Noteなど）に対してAnnounceを送信します。最高の相互運用性のためには、AnnounceはアナウンスされたオブジェクトをURIで参照するべきです（オブジェクトを埋め込むのではなく）。

Announceアクティビティは、リレーサーバーアクターのフォロワーコレクションにアドレス指定されなければなりません（MUST）。（TODO：管理者アドレス指定も必要かどうかは不明です）。一部のリレーサーバーはpublishedプロパティがないアクティビティを拒否するため、このプロパティは含めるべきです。

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://pleroma.example/schemas/litepub-0.1.jsonld",
        {
            "@language": "und"
        }
    ],
    "actor": "https://pleroma.example/relay",
    "to": [
        "https://pleroma.example/relay/followers",
        "https://pleroma.example/users/admin"
    ],
    "bto": [],
    "cc": [],
    "context": "https://pleroma.example/contexts/a59117d9-7f7c-48ec-83b4-5e183e7179b5",
    "id": "https://pleroma.example/activities/e24e46a2-8926-4a20-9f5f-638e06102159",
    "object": "https://pleroma.example/objects/c13bba3c-e7c1-45ac-939f-aa292d23ee8c",
    "published": "2024-10-18T14:06:37.736295Z",
    "type": "Announce"
}

リレーからのメッセージ受信

リレーから受信したメッセージは、通常Announceアクティビティにラップされています。アナウンスのobjectがフェッチされ検証された後、連合タイムラインに表示されます。PleromaはリレーされたCreateアクティビティ（Mastodon互換性のため）を受け入れるようですが、LD署名が処理されないため、Createのobjectを再フェッチします。（TODO：この動作を確認する。）

その他のリレーサーバーに関する考慮事項

リレーアクターをホストするリレーサーバーは、アクティビティのリレー以外の機能も持ちます。

WebFinger

リレーサーバーは、リレーアクターに対するWebFingerサポートを実装しなければなりません（MUST）。これはMastodonのアクターフェッチ実装のために必要です。LitePub専用のリレーサーバーでは必要ない可能性があります。

NodeInfo

リレーサーバーは、サーバーのアクティビティとメタデータを宣伝するためにNodeInfoを実装してもよいです（MAY）。

オプションのリレーサーバーの動作

リレーサーバーは複数のリレープロトコルをサポートしてもよいです（MAY）。ただし、それらの機能を宣伝する標準的な方法はありません。

リレーサーバーは通常、単一のアクターをホストしますが、任意数のリレーアクターをホストすることもできます。例えば、リレーサーバーは特定のトピック、ハッシュタグ、またはモデレーションカテゴリごとにリレーアクターを持つことができます。リレークライアントは、特定のサーバー内の任意数のリレーアクターを購読できます。

一部のサーバーは動的なリレーアクター作成を実装しています。リレーアクターのinbox URIは、ハッシュタグやトピック名に基づいている場合があります。クライアントアクターがこの種のインボックスURIを購読すると、リレーアクターが自動的に作成されます。明らかに、不正なクライアントによって使用された場合、このアプローチにはリスクがあります。

参照

Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018
James M Snell, Evan Prodromou, Activity Vocabulary, 2017
Mastodon Documentation, LD Signatures, HTTP Signatures
S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC-2119, 1997
Matthew Sporny, Dave Longley, JSON-LD 1.1, JSON-LD, 2020
Dave Longley, Gregg Kellogg, JSON-LD 1.1 Processing Algorithms and API, JSON-LD-ALGO, 2018
Graham Klyne, Jeremy J. Carroll, RDF 1.1 Concepts and Abstract Syntax, RDF, 2014
Dave Longley, RDF Dataset Canonicalization, (URDNA2015) RDF-CANON, 2022
NIST, Secure Hash Standard (SHS), SHA256, 2015
Wikipedia, Base64
P. Jones, WebFinger, RFC-7033 WebFinger, 2013
Jonne Haß, NodeInfo, GitHub
Pleroma Relay, pleroma-relay
LitePub Protocol Suite, litepub
Takeshi Umeda, pub-relay pub-relay

著作権

CC0 1.0 Universal (CC0 1.0) パブリックドメイン献呈

法律で許される限りにおいて、このFediverse Enhancement Proposalの著者は、この著作物に関するすべての著作権および関連する、または隣接する権利を放棄しました。 ```