Skip to content

Note

このドキュメントは2026-02-27 02:08にPLaMo Translation Modelを使用して自動翻訳されました。

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

概要

本Fediverse拡張提案では、ActivityPubプロトコルに基づく分散型ソーシャルネットワークにおけるコンテンツ配信の効率化を目的として、リレーサーバー機能を提案します。これにより、ユーザーは自身のフィードに他のアカウントやトピックからのコンテンツを容易に統合できるようになります。

基本概念

  • リレーサーバー: ActivityPub準拠のノードで、他のノードから受信したコンテンツを集約・配布する役割を担います。
  • コンテンツ配信プロトコル: リレーサーバー間でコンテンツを転送するための標準化された方法を提供します。

技術的仕様

1. リレーサーバー機能

リレーサーバーは以下の主要な機能を実装します：

  1. コンテンツ収集
  2. 登録済みのノードから定期的にコンテンツを取得します。

  3. 取得したコンテンツは適切なフォーマットに変換されます（例：埋め込みオブジェクトをURI参照に置き換える）。

  4. コンテンツ配信

  5. 集約したコンテンツを、自身に接続されたすべてのクライアントノードに配布します。

  6. ActivityPub仕様に従い、各コンテンツには正しいtype属性を付与します（例：Announce, Noteなど）。

  7. アドレス指定方式

  8. toフィールドには、リレーサーバーが接続されているフォロワーコレクションを指定します。
  9. 必須ではありませんが、管理者向けの特別なアドレスもサポートすることが推奨されます。

2. メッセージ送受信プロトコル

リレーサーバー間およびクライアントノードとの通信には以下のプロトコルを使用します：

  1. Announceプロトコル
  2. リレーされたオブジェクト（例：Note）に対してAnnounceアクティビティを送信します。
  3. objectフィールドには、URIを使用してアナウンス対象のコンテンツを指定します（埋め込みではなく）。
  4. 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"
}

3. リレーサーバーの追加機能

リレーサーバーは基本的なコンテンツ配信機能に加え、以下のオプション機能を実装できます：

  1. WebFingerサポート

  2. Mastodonなどのノードがリレーサーバー上のアカウント情報を取得できるよう、WebFingerプロトコルをサポートします。LitePub専用のリレーサーバーでは必須ではない場合があります。

  3. NodeInfo実装

  4. サーバーの活動状況やメタデータを公開するため、NodeInfoを実装することが推奨されます。

  5. その他の機能

  6. 複数のリレープロトコルをサポートすることができますが、その能力を標準化された方法で広告する方法は現在確立されていません。
  7. 単一のノードで運用される場合が多いですが、特定のトピックやハッシュタグ、モデレーションカテゴリごとに専用のリレーノードを作成することも可能です。クライアントは複数のリレーノードに同時に登録できます。
  8. 動的なリレーノード作成機能を実装するサーバーもあります。この場合、ハッシュタグやトピック名に基づいて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（パブリックドメイン）による提供

本Fediverse拡張提案の著者は、法律で認められる範囲内において、この文書に対するすべての著作権および関連する権利を放棄しています。