Skip to content

Note

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

FEP-a974: すべてのアクター種別はフォロー可能であるべき

概要

相互運用性と適切な意味論を促進するため、ブロックされていない有効なアクターは、あらゆるプラットフォームにおいて検索時に表示可能かつフォロー可能な状態である必要があります。初期段階でのフォローにおいてはアクターのtypeは考慮する必要はありませんが、必要に応じて後から活用することが可能です。

背景

フェデレーションを実現するために、ActivityPubサービスは一連のアクターを公開します。これらのアクターは以下の2つの条件を満たすActivityPubオブジェクトです：(a) アクティビティを実行可能であること、および (b) 他のユーザーからフォロー可能であること（ActivityPub仕様書参照）。

各アクターにはtypeが割り当てられています。Activity語彙では、以下の5つの「基本」タイプが定義されています：Person、Group、Service、Organization、および Application。これらの5種類は多くのアプリケーションで適切に機能しますが、すべてのケースに適しているわけではなく、ActivityPubではアクターがどのようなtypeを持っていても構わないと明確に規定されています。

多くのサービスでは、アクターに対して基本タイプ以外のオブジェクト型を使用することが望まれる場合があります。これには定義済みのオブジェクト型だけでなく、カスタムタイプも含まれます。具体例としては以下のようなケースが考えられます：

  • 読書特化型プラットフォームにおいて、ユーザーは特定の書籍シリーズをフォローし、新規アイテムの追加を追跡したいと考えるでしょう。この場合、書籍シリーズはGroupではなく意味的に適切なOrderedCollectionとして表現されるべきです。
  • 音楽プラットフォームでは、ユーザーがプレイリストをフォローしたいと望む場合があります。これもOrderedCollectionとして表現可能ですし、プラットフォームが特別な意味論を表現したい場合にはカスタムPlaylistタイプを使用することも可能です。

しかしながら、一部のActivityPubプラットフォームでは検索時に基本5種類のアクター型のみを表示する選択をする可能性があります。もしサービスがより意味的に適切なタイプをアクターに使用したい場合、そのようなサイトではそのアクターが表示されず、結果として非基本タイプを使用するサービスからバグ報告が寄せられる事態が生じかねません。

アクティビティ/オブジェクトタイプに基づくフィルタリングは、いかなるActivityPubプラットフォームにおいても合理的かつ不可避な処理です。しかし、アクタータイプレベルでのフィルタリングは、新規サービスが適切に意味論的な型を使用することを制限し、時間の経過とともにその型を効果的に使用できなくする可能性があります。新しいサービスでも、適切な型ではなく基本5種類のいずれかを選択せざるを得ない状況に陥るでしょう。

この問題はコミュニティ内で既に議論されています（Mastodon Issue #22322参照）。このFEPでは、そうした議論を単一の簡潔な互換性声明として整理することを目的としています。

決定事項

準拠すべきActivityPubサービスは、検索時およびアクターレベルのアクティビティ（フォロー、承認、取消、ブロックなど）においてアクターtypeによるフィルタリングを行ってはなりません。すべての非ブロック状態のアクターは、どのサービスにおいてもフォロー可能な状態でなければなりません。

影響範囲

もちろん、サービス側で後から配信されるアクティビティをフィルタリングすることは自由です。このFEPではそのような制限は一切設けていません。例えば、Documentオブジェクトタイプのアクティビティのみを投稿するアクターの場合、マイクロブログプラットフォームのユーザーにはそのフィードが完全に空に見える可能性があります。どのようなActivityPubサービスにおいても、自身が処理したいと考えるアクティビティのみを扱う権利と権限を保持しています。

ただし、すべてのアクター型をフォロー可能にすることで、新規サービスは適切な場所にどの種類のアクティビティを送信すべきかを自由に選択できるようになります。その際、自身のアクターが少なくとも表示され、かつアクティビティが正しく受信されるという確信を持って行動できます。

具体的な実用例として：Manyfoldでは、Fediverseユーザーが個別の3Dモデル（Documentまたは3DModelアクタータイプを持つ可能性がある）をフォローでき、それらが変更された際にはそのモデルをobjectとしてUpdateアクティビティを投稿します。しかしManyfoldは、マイクロブログアプリケーションがこれらのアクティビティを理解しないこと（そして理解する必要もないこと）を認識しています。そこで互換性確保のため、同じ情報を含む人間が読み取り可能なCreate Noteアクティビティである「互換性ノート」を送信することで、マイクロブログユーザーがモデルをフォローし、都合の良い場所で更新を確認できるようにしています。この種のコンテンツをどこにどのように送信するかについては、将来的にFEP-9fdeで提案されている互換性検出メカニズムを活用することが考えられます。

潜在的な負の影響として、サービスが基本タイプの使用に基づいてアクターに対して追加的な前提条件を設定する場合に生じる可能性があります（例えばMastodon Issue #22322で議論されているGroupアクターの異なる意味論的解釈など）。このような影響についてはさらなる検討が必要です。

参考文献

著作権

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

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