Skip to content

Note

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

FEP-2677: アプリケーションアクターの識別方法

概要

Fediverseアプリケーションにおいて、Application型の特別なアクターを使用するパターンは一般的である。例えば、Mastodonの場合はhttps://mastodon.example/actor、Pleromaの場合はhttps://pleroma.example/internal/fetchといったURLでアクセス可能なアクターがこれに該当する。この種のアプリケーションアクターは認証不要のリクエストで取得可能であるため、公開鍵を取得するための手段として利用できる。

本FEPの目的は、アプリケーションアクターを明確に識別するメカニズムを提供することで、以下のような追加的な用途に活用できるようにすることである:

  • アプリケーション間通信を可能にするため、あるアプリケーションアクターが別のアプリケーションアクターの受信トレイへアクティビティを送信する仕組み
  • 関連情報を添付可能なオブジェクトとして機能させること。具体的には、実装済みFEPの一覧などをアプリケーションアクターに関連付けることが可能となる

要件

アプリケーションアクターの定義

まず「アプリケーションアクター」の概念を明確に定義する。以下の2つの要件を満たすものとする:

  1. [ActivityPub]仕様におけるApplicationActorであること
  2. 認証なしで取得可能であること。具体的には、署名なしのHTTPリクエストによって取得できる状態にあること

既に述べたように、現在多くのFediverseアプリケーションではこの種のアプリケーションアクターが公開鍵を取得するために使用されている。具体的な実装例についてはこちらを参照されたい。

nodeinfoによるアプリケーションアクターの識別

[NodeInfo]仕様、特に[FEP-f1d5]において、よく知られたパス/.well-known/nodeinfoが定義されており、この場所にはJRD形式[RFC 7033]に準拠したドキュメントが提供されるとされている。

本FEPの要件として、/.well-known/nodeinfoに以下の追加リンクを含めることが求められる: 関係タイプhttps://www.w3.org/ns/activitystreams#Applicationを持ち、前述のセクションで説明したアプリケーションアクターを参照するものであること。

なお、[NodeInfo]仕様で規定されている全ての関連付けを実装しなくても、本FEPの目的は達成可能であることに留意されたい。

具体例

ドメインnode.exampleを持つサーバーを例に挙げる。つまり、https://node.example/.well-known/nodeinfoへのリクエストは以下のJSON形式の応答を返す:

 {
    "links": [
        {
            "rel": "http://nodeinfo.diaspora.software/ns/schema/2.0",
            "href": "https://node.example/nodeinfo/2.0"
        },
        {
            "rel": "https://www.w3.org/ns/activitystreams#Application",
            "href": "https://node.example/actor"
        }
    ]
 }

次に、acceptヘッダーにapplication/activity+jsonを指定してhttps://node.example/actorへリクエストを送信した場合、以下のようなJSON応答が得られる可能性がある:

{
    "@context": [
        "https://www.w3.org/ns/activitystreams",
        "https://w3id.org/security/v1",
    ],
    "id": "https://node.example/actor",
    "type": "Application",
    "inbox": "https://node.example/actor/inbox",
    "outbox": "https://node.example/actor/outbox",
    "publicKey": {
        "id": "https://node.example/actor#main-key",
        "owner": "https://node.example/actor",
        "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n....\n-----END PUBLIC KEY-----\n"
    }
}

議論

本FEPのアプローチは最小限の変更で済むように設計されている。代替案としては以下が考えられる:

  1. アプリケーションアクター用の固定パスを定義する
  2. アプリケーション情報用に別個の固定パスを設ける代わりに、アプリケーションアクターに直接関連付ける方法を採用する

どちらの選択肢も、新たなパスを導入する必要があるため、全ての実装において同様の方法で対応することが求められる。本提案では既存のパスを再利用することで、各実装者がアプリケーションアクターを配置する場所を自由に選択できるようにしている。


第二の論点として、なぜApplication型に限定し、Service型を採用しなかったかについて説明する。まず第一に、現在のほとんどの実装と整合性が取れるためである。第二に、Mastodonではボットアカウント用にService型を使用している。このため、この用途から区別し始めることは妥当な判断と言える。この区別を以下のように表現できる:

  • Application型アクターは、アプリケーション内で発生したイベント(署名付きリクエストなど)によってトリガーされ、対応する公開鍵を取得する役割を担う
  • Service型アクターは、受信トレイに届いたアクティビティや外部イベント(タイマー起動時など)によってトリガーされる。つまり、Service型アクターはユーザー操作によって制御されるタイプのアクターと類似している

これらはあくまで「Application」または「Service」を使用すべきタイミングに関する厳密なルールではない。より複雑なFediverse実装が構築されていくにつれて、この区別も崩れていく可能性がある。しかし、現時点ではアクターを分類する際の一定の指針として機能することを期待している。

現在実装されているアプリケーションアクター一覧

ソフトウェア アプリケーションアクターURI
Bovine https://bovine.example/activitypub/bovine
Firefish https://firefish.example/actor
Lemmy https://lemmy.example/
Mastodon https://mastodon.example/actor
Mitra http://mitra.example/actor
Pleroma https://pleroma.example/internal/fetch
Mbin https://mbin.example/i/actor
WordPress https://wordpress.example/wp-json/activitypub/1.0/application
Mobilizon https://mobilizon.example/relay
Gancio https://gancio.example/federation/u/<instance_name>
Friendica https://friendica.example/
PeerTube https://peertube.example/accounts/peertube
Pixelfed https://pixelfed.example/i/actor

注記:さらに追加すべきリンクがあれば自由に記載されたい。

実装状況

ソフトウェア 実装日 リリース日
WordPress 2023年12月21日 -
Mobilizon 2023年12月14日 -
Gancio 2023年12月22日 -

参考文献

著作権

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

法律で許容される範囲内において、本Fediverse機能拡張提案の著者らは、当該作品に関する全ての著作権および関連する権利を放棄している。