FEP-e3e9: アクター相対URLスキーム

概要

「コンピュータサイエンスにおけるあらゆる問題は、インダイレクトネスの階層を一段階追加することで解決できる」（ソフトウェア工学の基本定理）

-- バトラー・ランプソンに帰せられる（出典：Wikipedia）

本FEPでは、ActivityPubオブジェクトおよびコレクションに対するIDスキームを提案する。この方式は以下の特性を有する：

IDはドメイン移行後も安定している。すなわち、オブジェクトの管理者がホストプロバイダーを変更しても、オブジェクトIDを変更する必要がない。
IDは通常のHTTP(S) URL形式で、クライアントが「302」リダイレクトを許可している場合、HTTP GETリクエストによって解決可能である。

提案するメカニズムでは、既存のアクタープロフィールURLにクエリパラメータを追加することでオブジェクトを識別する。ActivityPubクライアントがこれらのオブジェクトを取得しようとする際には、通常どおりこのURLに対してHTTP GETリクエストを送信し、必要な認証機構を適用した後、応答に含まれるHTTP 302ステータスコードによるリダイレクトに従い、現在のオブジェクト保存場所を取得する。

アクター相対URLの具体例：

https://alice-personal-site.example/actor?service=storage&relativeRef=/AP/objects/567

この形式のオブジェクトIDに遭遇したActivityPubクライアントは、他のオブジェクトIDと同様にHTTP GETリクエストを送信する：

GET /actor?service=storage&relativeRef=/AP/objects/567 HTTP/1.1
Host: alice-personal-site.example

サーバーは現在の保存場所を示す302リダイレクト応答を返す（これはすべてのHTTPクライアントが自動的に処理可能である）。例えば：

HTTP/1.1 302 Found
Location: https://storage-provider.example/users/1234/AP/objects/567

このリダイレクト機構は既存のすべてのHTTPクライアントでデフォルト有効化されており（詳細は[https://developer.mozilla.org/en-US/docs/Web/API/Request/redirect]を参照）、ActivityPubクライアントコードに追加の改修を必要としない。

オブジェクトおよびコレクション用アクター相対URL

クライアント側で必要な主な変更点は、著者/管理者認証処理手順である（アクター相対URLでオブジェクトを取得する場合、HTTPリダイレクトの追従機能が有効になっていること以外に変更は不要）。

サーバー側（特にアクタープロフィールをホストするサーバー）では、以下の2つの変更が必要となる：

（データモデル変更）アクタープロフィールに「service」セクションを追加すること。これは著者/管理者認証に必須である。
（プロトコル変更）「service」と「relativeRef」クエリパラメータを含むアクタープロフィール要求時に、HTTP 302リダイレクト応答を返す機能を有効にすること。

さらに推奨事項として： FEP-8b32: オブジェクト完全性証明の実装を推奨する。これにより、アクタープロフィールホストがダウンしている場合やその他の理由で利用できない状況においても、著者/管理者認証が容易になる。

オブジェクトの著者/管理者検証手順

以下に示す例示的なアクタープロフィールを想定：

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://www.w3.org/ns/did/v1"
  ],
  "service": [{
     "id": "https://alice-personal-site.example/actor#storage",
     "serviceEndpoint": "https://storage-provider.example"
  }],
  // ... その他のプロフィールプロパティ
}

クライアントは以下の手順でオブジェクトを検証する：

アクタープロフィールを取得する：GET https://alice-personal-site.example/actor
応答内容を確認する：

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://www.w3.org/ns/did/v1"
  ],
  "id": "https://alice-personal-site.example/actor",
  "type": "Person",
  "service": [{
    "id": "https://alice-personal-site.example/actor#storage",
    "serviceEndpoint": "https://storage-provider.example"
  }],
  "assertionMethod": { /* ... */ },
  // ... その他のプロフィールプロパティ
}

オブジェクトを作成する例：

POSTリクエスト：POST /AP/objects/ Host: old-storage-provider.example

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "これはメモです",
  "attributedTo": "https://alice-personal-site.example/actor",
  "id": "https://alice-personal-site.example/actor?service=storage&relativeRef=/AP/objects/567"
}

応答：HTTP 201 Created Location: https://old-storage-provider.example/AP/objects/567

注意：この作成されたオブジェクトは、以下の2つの異なるURLで取得可能である： 1. 直接URL（現在の保存場所）：https://old-storage-provider.example/AP/objects/567 2. 間接アクター相対URL：https://alice-personal-site.example/actor?service=storage&relativeRef=/AP/objects/567

異なるストレージプロバイダーへ移行する場合、新しいプロバイダーがhttps://brand-new-storage.exampleにあると仮定する。アリスは以下の手順を実行する。

まず、アクタープロフィールのサービスエンドポイントを更新し、新規プロバイダーを指すようにする：

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://www.w3.org/ns/did/v1"
  ],
  "id": "https://alice-personal-site.example/actor",
  "type": "Person",
  "service": [{
    "id": "https://alice-personal-site.example/actor#storage",
    "serviceEndpoint": "https://brand-new-storage.example"
  }],
  "assertionMethod": { /* ... */ },
  // ... その他のプロフィールプロパティ
}

移行時に変更が必要なアクタープロフィールの唯一の項目は「serviceEndpoint」である。

次に、オブジェクトを新規プロバイダーに移行する（本例では個別に転送するが、将来のFEPではストレージ内の全オブジェクトを一括転送するためのAPI仕様が策定される予定である）。

POSTリクエスト：POST /AP/objects/ Host: brand-new-storage.example

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Note",
  "content": "これはメモです",
  "attributedTo": "https://alice-personal-site.example/actor",
  "id": "https://alice-personal-site.example/actor?service=storage&relativeRef=/AP/objects/567"
}

応答：HTTP 201 Created Location: https://brand-new-storage.example/AP/objects/567

注意：新規プロバイダーに保存されるオブジェクトは、旧プロバイダーのものと同じバイト単位で同一であり、その間接IDやコンテンツは変更されない。

このサービスプロバイダー移行期間中、外部から見たオブジェクトの間接IDは他のすべてのActivityPub機構（受信箱配信、いいね・再投稿など）において 変化しない 点に注意されたい。

参考文献

FEP-8b32: オブジェクト完全性証明
Christine Lemmer Webber, Jessica Tallon, [ActivityPub][AP], 2018年
S. Bradner, 「RFCで要件レベルを示すためのキーワード」, 1997年

著作権

CC0 1.0 Universal（CC0 1.0）パブリックドメイン献呈

法律で許容される範囲において、本Fediverse Enhancement Proposalの著者らは、当該作品に関するすべての著作権および関連する権利を放棄している。