FEP-c180: ActivityPubにおける問題詳細仕様

概要

ActivityPubはRESTful APIおよびHTTPベースのプロトコルであり、標準化されたソーシャルネットワーキングを実現しますが、エラー形式については規定していません。本文書では、ActivityPubで使用するためにProblem Details for HTTP APIs仕様（RFC 9457）のプロファイルを提供します。

はじめに

ActivityPubはW3Cが定めるフェデレーション型ソーシャルネットワークの標準規格です。テキスト、画像、音声、動画などのソーシャルコンテンツを作成・共有するための標準的なRESTful APIを定義しており、さらにソーシャルコンテンツのサーバー間連携プロトコルも規定しています。これにより、異なるソーシャルプラットフォーム間でユーザーが相互にやり取りすることが可能になります。

クライアントAPIとサーバー間通信プロトコルはいずれもHTTPベースであり、リクエストの成功/失敗を示すためにHTTPステータスコードを使用しています。ただし、HTTPステータスコードだけではエラーの性質を完全に説明できない場合や、クライアントがエラーから回復するための十分な情報を提供できない場合があります。

Problem Details for HTTP APIs仕様（RFC 9457）では、HTTPレスポンスにおいてより詳細なエラー情報を提供する方式を規定しています。このフォーマットには、機械可読なエラー記述に加え、人間が読みやすい説明文、エラーに関する追加データ、および詳細情報へのリンクが含まれます。

本文書ではActivityPubに関連する具体的なエラータイプを複数定義し、Problem Details for HTTP APIs形式をActivityPubでどのように活用すべきかについての指針を示します。

適用事例

ActivityPub APIクライアント開発者として、サーバーから機械可読なエラー記述を取得したい。これにより、ユーザーに具体的かつ適切なエラーメッセージを提供できる。
ActivityPub APIクライアント開発者として、誤ったリクエストに対して回復可能かどうかを把握したい。より堅牢なユーザー体験を提供するためである。
サーバー開発者として、誤ったリクエストに対して回復可能かどうかを判断したい。これにより信頼性の高い通信サービスを提供できるためである。
サーバー開発者として、送信するアクティビティが遠隔のサーバーで受理されるかどうかを事前に知りたい。これにより、拒否されることが確実なアクティビティを送信せずにリソースを節約できる。

仕様

ActivityPubサーバーは、HTTPリクエストに対する応答においてProblem Details for HTTP APIs形式を使用してエラーを記述することが推奨されます。このフォーマットについてはRFC 9457に詳細が記載されています。

以下の種類のHTTPリクエストについては、Problem Details形式によるエラー処理を使用することが望ましいとされます（本文書で使用する略語は括弧内に示します）：

オブジェクト（アクティビティ、アクター、コレクションなど）に対するGETリクエスト ("get")
アクターの送信待ちキューに対する新規アクティビティ作成用POSTリクエスト ("outbox")
メディアアップロード用のPOSTリクエスト ("media upload")
プロキシURL用のPOSTリクエスト ("proxy")
アクターの受信トレイに対する遠隔アクティビティ配信用POSTリクエスト ("inbox")
複数アクターで共有される受信トレイ用のPOSTリクエスト ("shared inbox")

その他のActivityPubリクエストについては、Problem Details形式を使用することが可能です。

RFC 9457で定義されているabout:blankタイプは、特定のエラータイプが存在しない場合に使用できます。また、IANA問題タイプレジストリに登録されている他のタイプも、特定の問題に対して使用可能です。

ActivityPub向けエラータイプ

本語彙で使用するエラータイプには、https://w3id.org/fep/c180というプレフィックスを使用します。

以下に各エラータイプについて、その適用範囲、タイプURI、エラータイトル、使用するHTTPステータスコード、およびレスポンスに含まれる可能性のある追加フィールドを示します：

非対応型

適用範囲: inbox, outbox, sharedInbox, media upload
タイプ: https://w3id.org/fep/c180#unsupported-type
タイトル: 非対応型
ステータス: 400 Bad Request
追加フィールド:
id: 非対応型のオブジェクトID
type: サポートされていない型

これは、アクティビティの種類、またはアクティビティが参照するオブジェクトのいずれかが、APIサーバーまたは受信側フェデレーションプロトコルサーバーによってサポートされていないことを示します。

対象オブジェクト未存在

適用範囲: inbox, outbox, sharedInbox, media upload
タイプ: https://w3id.org/fep/c180#object-does-not-exist
タイトル: 対象オブジェクトが存在しない
ステータス: 400 Bad Request
追加フィールド:
id: 存在しないオブジェクトのID

アクティビティが「object」「target」プロパティやアドレス指定用プロパティなどで参照するオブジェクトが存在しません。

別のケースとして、対象となるアクターがコレクションであり、当該コレクション内のどのアクターもサーバー上に受信トレイを持っていない場合が考えられます。例えば、あるアクティビティがそのアクターのフォロワーコレクション宛てであっても、そのフォロワーの中にサーバー上の受信トレイを持つ者が存在しない場合などです。

レート制限超過

適用範囲: outbox, media upload, get, proxy, inbox, sharedInbox
タイプ: https://w3id.org/fep/c180#rate-limit-exceeded
タイトル: レート制限超過
ステータス: 429 Too Many Requests

クライアントまたはセキュリティプリンシパルが、指定されたアクティビティに対して設定されたレート制限を超えています。サーバーはレスポンスにRetry-Afterヘッダーを含めることで、レート制限がリセットされるタイミングを示すことができます。

このエラータイプは主にActivityPub APIにおけるクライアントとサーバー間の通信に適用されます。フェデレーションプロトコルにおいて、受信側サーバーが送信元プラットフォームに直接的にレート制限を適用することは一般的ではありません。

プライバシーに関する考慮事項

本文書で定義されている一部のエラータイプは、オブジェクトの存在状況、オブジェクトとアクターの関係、あるいは複数アクター間の関係性など、サーバーの内部状態に関する情報を露呈する可能性があります。サーバーはエラーメッセージにおいて機密情報が漏洩しないよう注意を払う必要があります。

参考文献

Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018
Christine Lemmer Webber, Amy Guy, 他, メディアアップロード, 2018
M. Nottingham, E. Wilde, S. Dalal, RFC 9457: Problem Details for HTTP APIs, 2023

著作権

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

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