FEP-4f05: ソフト削除機能

概要

ActivityPub規格で規定されている標準的なCRUD（作成・読み取り・更新・削除）操作では、すべてのケースにおいて単一のDeleteアクティビティを使用することが定められています。しかし、この仕様では二段階削除方式――一般に「ソフト削除」と「ハード削除」と呼ばれる手法――を適切に記述するには不十分です。

すべてのソフトウェアがこの二段階削除を実装しているわけではないため、本FEPでは以下の方針を採用します：サポート対象システムに対しては機能を段階的に拡張しつつ、それ以外の場合には後方互換性を維持するものとします。

前提条件

kaniini氏によるブログ記事では、リモートサーバー上のデータコピーを「キャッシュされた表現」として扱うことが提唱されています。これに基づき、以下の前提条件を導き出します：

• リモートサーバー上に保存されているデータは正規版と見なされる
• 受信したDeleteアクティビティは、ローカルにキャッシュされたコピーを更新するか、もしくはその削除を依頼する要求として処理されるべきである

フォーラムおよびスレッド型ディスカッションタスクフォース（ForumWG）では、スレッド型ディスカッションモデルにおける組織化されたオブジェクトの呼称について以下の共通認識が確立されています：

• 本FEPで扱う対象は原則として「オブジェクト」ですが、ここで説明する概念は一般的なコンテキストにも適用可能です

発行者側の対応

ソフト削除処理

オブジェクトをソフト削除した場合、そのActivityPub表現は必ずTombstone状態に更新されなければなりません。サーバーは、当該オブジェクトに対するリクエストに対して200番台のレスポンスコードを返すことが推奨されます。ただし、オブジェクト自体は元の場所にそのまま保持されます。

他のサーバーへソフト削除を通知するため、必ずDeleteアクティビティを発行する必要があります。

ハード削除処理

オブジェクトをハード削除した場合、そのObjectPub表現は完全に消失しなければなりません。サーバーは当該オブジェクトに対するリクエストに対して400番台のレスポンスコードを返すことが必須です。404 Not Foundステータスコードも許容されますが、410 Goneを使用することで、オブジェクトが明示的に削除されたことをより明確に示すことができます。セキュリティやプライバシーの観点から、404以上のレスポンスを返す必要がある場合もあります。

他のサーバーへハード削除を通知するため、必ずDeleteアクティビティを発行する必要があります。

受信者側の対応

Deleteアクティビティを受信した場合、参照先のobjectは完全なオブジェクトそのものか、あるいはその参照のいずれかである可能性があります。

埋め込まれたオブジェクトの真正性検証については本FEPの対象外です。いかなる受信Deleteアクティビティの真正性も確認するには、オリジンベースセキュリティモデルに従ってください。

もしobjectが参照形式の場合、サーバーはそのidを用いて直接オリジンサーバーから当該オブジェクトを取得しなければなりません。

受信したレスポンスコードまたはオブジェクトのtypeに基づき、以下の手順で処理を実施してください：

[!NOTE] actorと対象オブジェクトのattributedTo属性が一致しない場合があります。これはモデレーターや特権ユーザーが削除操作を行う場合に許容される仕様です。

Tombstone状態の場合

ローカル実装者の標準動作に従い、当該オブジェクトをソフト削除する必要があります。

Tombstone状態でない場合

該当する場合は、オブジェクトのローカル表現を更新してください。

HTTP 404または410ステータスコードの場合

ローカル実装者の標準動作に従い、当該オブジェクトをハード削除する必要があります。

予期しないレスポンスへの対応

前述の「受信者側」セクションでは、受信したDeleteアクティビティの処理方法を詳述しています。バックリファレンスチェックの際にオブジェクトタイプやレスポンスコードが想定と異なる場合、取得された状態がアクティビティ内容に優先します。

具体例： - Deleteアクティビティを受信したが、バックリファレンスチェックで200ステータスとともにNote型オブジェクトが返された場合、これは「Tombstone状態ではない」ものとして扱われます（たとえ受け取ったアクティビティがそう示していたとしても）

逆のケースも同様です： - Undo(Delete)アクティビティを受信したが、バックリファレンスチェックでTombstone状態が確認された場合、それでもなお「Tombstone状態」として処理されます

追加考慮事項

更新アクティビティについて

以前の二段階オブジェクト削除実装ではUpdate(Tombstone)アクティビティを使用していましたが、これはDeleteと同様の効果――キャッシュ無効化と内容更新――を示すため、冗長であると判断されました。

広範なサポート状況（あるいはその欠如）

ActivityPub対応ソフトウェアの大多数が二段階オブジェクト削除をサポートしていないものと推測されます。Deleteアクティビティを発行することで、ソフト削除の意図――すなわち対象オブジェクトのコンテンツが表示されなくなるという効果――が他のサーバーにも確実に伝達されるようになります。

実装者向けUX設計

各実装者は、好みに応じてソフト削除を実装することができます（例：NodeBBでは、投稿（オブジェクト）を元のアクターに関連付けたまま保持し、特権ユーザー以外にはコンテンツを非表示にする方式を採用しています）。本FEPでは、個々の実装者がリモートデータのローカル表現をどのように扱うべきかについては特に規定していません。

通知対象について

発行されたDeleteアクティビティの受信者リストについては、本文書の対象外とします。

実装推奨システム

• NodeBB
• Discourse

参考文献

• Christine Lemmer Webber, Jessica Tallon, ActivityPub, 2018年
• kaniini氏, The Delete Activity And It's Misconceptions, 2019年（アーカイブ版）
• Julian Lam, ForumWG Nomenclature, 2024年
• silverpill, FEP-fe34: Origin-based security model, 2024年

著作権情報

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

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