Skip to content

Note

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

FEP-2277: ActivityPubの基本オブジェクトタイプ

概要

ActivityPubにおける各オブジェクトをその構造に基づいて分類した体系。

根拠

ActivityPubアプリケーションでは、アクター、アクティビティ、コレクションなどの異なる種類のオブジェクトに対してそれぞれ異なる処理規則が適用されることが一般的です。多くの場合、オブジェクトのクラスはその文脈から推測可能です。例えば、受信トレイに配信されるオブジェクトは通常アクティビティであり、そのactorプロパティ値はアクターであるべきです。

しかしながら、文脈だけでは必ずしもオブジェクトのクラスを特定できるとは限りません。ユーザーが直接提供する場合など、オブジェクトIDのみが既知のケースも存在します。また、埋め込みデータに関しても曖昧さが生じる可能性があります：

  • Updateタイプのアクティビティにおけるobjectは、オブジェクトまたはアクターのいずれかとなり得ます。
  • Announceタイプのアクティビティにおけるobjectも、オブジェクトまたはアクティビティのいずれかを指定可能です。

アプリケーションはtypeプロパティを用いてオブジェクトのクラスを判定することも可能ですが、この方法では未知の型を持つオブジェクトを処理できないため、相互運用性が阻害されます。したがって、より適切なアプローチを採用することが望ましいと言えます。

基本オブジェクトタイプ

Activity Streams 2.0標準では、以下の8つの基本オブジェクトタイプが定義されています：

  • Object
  • Link
  • Activity
  • IntransitiveActivity
  • Collection
  • OrderedCollection
  • CollectionPage
  • OrderedCollectionPage

残念ながら、仕様書に記載されている定義は必ずしも明確ではありません。明確に区別されているのはObjectとLinkのみでありdisjoint types、つまりオブジェクトが同時にActivityかつCollectionであることはありません。「アクター」はObjectの特殊化として記述されていますが、対応するActor型が定義されていない点も問題です。

これらの不明確な定義とActorタイプの除外により、標準分類は実用的な用途には適していません。そのため、アプリケーションでは別の分類体系を採用する必要が生じる場合があります。

オブジェクトを明確に区分されたクラスに分類する一つの方法として、そのプロパティと他のオブジェクトとの関係性（プロパティによって示される）に着目する方法があります。このアプローチを用いることで、以下の7つの基本型を定義できます：

  • Actor: アクティビティの発信および受信を行うエンティティ
  • Activity: アクターが実行するアクション
  • Collection: 他のオブジェクトを保持するコンテナ（コレクションまたはページ形式のコレクション）
  • VerificationMethod: 検証方法
  • PublicKey: 公開鍵（検証方法のレガシーな表現形態）
  • Link: リンク情報
  • Object: 上記いずれにも該当しないその他のオブジェクト

次節では、オブジェクトの構造を分析することで、任意のActivityPubオブジェクトをこれらの基本タイプのいずれかに分類するアルゴリズムについて詳述します。この手法はダックタイピングとしても知られています。

ダックタイピング

以下のアルゴリズムを用いて、オブジェクトのコアタイプを判定できます：

  1. オブジェクトがinboxおよびoutboxプロパティを持つ場合、「Actor」型と判定する。
  2. オブジェクトにpublicKeyMultibaseプロパティが存在する場合、「VerificationMethod」型と判定する。
  3. オブジェクトにpublicKeyPemプロパティがある場合、「PublicKey」型と判定する。
  4. オブジェクトにhrefプロパティが存在する場合、「Link」型と判定する。
  5. オブジェクトにactorプロパティがある場合、「Activity」型と判定する。
  6. オブジェクトがitems、orderedItems、totalItems、partOf、first、last、next、prev、またはcurrentプロパティを持つ場合、「Collection」型と判定する。
  7. 上記のいずれにも該当しない場合、「Object」型と判定する。

このアルゴリズムを適用した場合、各オブジェクトは互いに排他的な基本タイプに分類されます。例えば、itemsプロパティを持つアクターであっても、依然として「Actor」であり「Collection」ではありません。

なお、typeプロパティの値は考慮対象に含まれません。

[!WARNING] ActivityPub標準ではアクターがinboxとoutboxの両方のプロパティを持つことを必須要件としていますが、実際にはoutboxプロパティが常に存在するとは限りません。非準拠実装との互換性を重視する場合、ステップ#1は「オブジェクトにinboxプロパティが存在する場合、『Actor』型と判定する」と変更することが可能です。

[!WARNING] Pleromaではアクティビティでないオブジェクトにもactorプロパティを追加しています。この例外に対応するため、アルゴリズムのステップ#5は「オブジェクトにactorプロパティが存在し、かつattributedToプロパティを持たない場合、『Activity』型と判定する」と変更することができます。

JSON-LD形式について

このアルゴリズムの出力結果は、@contextにおける用語の再マッピング可能性により、LD対応アプリケーションと非対応アプリケーションで異なる場合があります。これはセキュリティ上のリスクとなり得ます。

具体例：

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "foo": "as:inbox",
      "bar": "as:outbox"
    }
  ],
  "type": "Note",
  "id": "https://social.example/note",
  "foo": "https://social.example/inbox",
  "bar": "https://social.example/outbox"
}

検討された代替案

多重型付け

ダックタイピングに代わる手法として、複数のタイプを併用する方法があります。例えば、以下のオブジェクトは明らかに「Activity」型として識別可能です：

{
  "type": ["Bite", "Activity"]
}

しかしながら、既存の実装では第二のタイプを追加しておらず、仮に全ての実装を変更することができたとしても、移行期間中は依然としてダックタイピングをフォールバック手段として採用する必要があります。

型階層構造

オブジェクトの基本タイプは、その語彙におけるtype定義によって決定することも可能ですが、この場合すべてのActivityPubアプリケーションがJSON-LDをサポートする必要が生じます。

参考文献

  • Christine Lemmer-Webber, Jessica Tallon, Erin Shepherd, Amy Guy, Evan Prodromou, ActivityPub, 2018年
  • James M Snell, Evan Prodromou, Activity Streams 2.0, 2017年

著作権について

本Fediverse Enhancement Proposalの著者らは、法律で認められる範囲内において、本作品に関するすべての著作権および関連する権利を放棄し、パブリックドメインに提供しています。