Skip to content

Note

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

FEP-e965: マイグレーションおよび墓標イベントにおけるアクティビティの移動と告知

概要

本FEPでは、FEP-73cd: ユーザー移行シナリオで定義されているほぼすべてのマイグレーション関連ユースケースにおいて、厳密に1つの具体的な手順を規定しています：

  • マイグレーションまたは非活性化イベント後にActorオブジェクトに対して行われる更新
  • ソースサーバーがフォロワーに対し当該Actorオブジェクトの更新情報を伝えるために発行する「移動」アクティビティ

本提案は、厳格に依存関係にある先行FEPFEP-7628の意味論と動作を明確に定義するものです。 さらに、Activity Streams語彙で既にサポートされているtype配列に「墓標」メンバーを追加することで、Actorオブジェクトを「墓標化」（削除状態を示す）することで「非活性化済み」のActorを表現する簡潔かつ追加的な手法を提案します。 また、FEP-ef61: ポータブルオブジェクトおよびFEP-7952: 独立ホスト型Actorオブジェクトで記述されているような新しい形式のActorオブジェクトへのマイグレーションにも対応しており、準拠・非準拠双方の消費者向けに適用可能です。 このため、本提案のすべてのオプション機能を完全に実装するには、FEP-521a: Actorの公開鍵表現を実装する必要があります。これは、ドメインに依存せずにActorに関する主張を検証するための検証方法をActorオブジェクトに追加するものです。

現行アプローチ

現在のマイグレーションサポートは、統一された期待仕様が存在しないため、かなり場当たり的かつ部分的な対応となっています。マイグレーション後や非活性化後にActorオブジェクトをどのように更新・告知・解釈すべきかについて、明確なガイドラインがありません。 非活性化は「墓標」イベントと呼ばれることがあり、これは分散システムにおける一般的な用法としても、Activity Streams語彙のTombstoneオブジェクトタイプとしても用いられています。 Actorオブジェクトのtype配列に「墓標」メンバーを追加することは、そのActorが非活性化状態にあることを示すもので、既に可能ではあるものの、コンテンツやアクティビティの削除時に比べてActorに対してより一般的に実装されている方法です。 既存コードベースのレビューは実施しておらず、現時点で把握している唯一の先行事例は、FEP-7628: Actor移動における現行プラクティスの後付け仕様定義のみです。

将来的なクエリに対する「墓標」ヒントを受動的に残すこと以外に、特定のActorがその制御者によって『［当該Actor］が忘れ去られる意図』を持つことを示すための明示的な手法は存在しません。

未知のActor URIへの対応方法

movedToまたはcopiedToプロパティに従来とは異なるURL（前述のFEPで拡張された実装によって生成されたものなど）が含まれている場合、これらの値を解釈する際には以下の注意点があります：

  • movedToまたはcopiedTo値がap://プレフィックスで始まる有効なURLであり、かつ@context値が関連する拡張プロパティを含んでいる場合、マイグレーション先サーバーはFEP-ef61を実装している可能性が高く、この場合はカスタム解決ロジックを用いてActorオブジェクトを取得する必要があります。
  • 同様に、movedToまたはcopiedTo値にFEP-7952で定義された種類のActor相対URLが含まれている場合、そのサーバーが稼働中であれば、クエリを実行する実装がHTTPリダイレクトを許容しており、かつ異なるドメインにおけるid値とは異なるinbox値に関するポリシーやハードコードされた前提条件がない場合、通常通り解決されるべきです。
  • 返されたActorオブジェクトに非空のmovedToまたは非空のcopiedTo値が記載されている場合、これもさらに参照する必要があります（ただしドメインベースのポリシーで禁止されている場合は除きます）。
  • クエリを実行する実装がこれらのタイプの値やさらなる間接参照を解決できない場合、それらは404を返すURLと同等とみなすべきです。適切な場合には、エラーログまたは警告メッセージをユーザーもしくはシステムログに記録することが推奨されます。
  • 解決不能なmovedTo値については、エンドユーザーに『破損した』あるいは『不完全な移動』と表示することが、非活性化アカウントとして表示するよりも適切です。

墓標状態のActorに対する「移動」アクティビティまたは告知アクティビティの解釈

MoveまたはAnnounceアクティビティを受信したサーバーは、対象がActorである場合、sharesコレクションをインクリメントしてはなりません。 マイグレーション中やマルチホームユーザーをより円滑に追跡するため、あるいはその他の理由でリダイレクトやエイリアスを保持している受信サーバーは、新しいActorオブジェクトを解決し、前述のチェックを実施した上で当該Actor更新を記録することができます。

未解決事項

  1. 古いActorの［何らかの方法でインポートされた］Followers以外にも、Actor更新を伴うMoveまたはAnnounceを送信すべき対象は存在するか？サーバーインスタンスレベルのActorについても明示的に言及する価値はあるでしょうか？（モデレーション目的などで知る必要がある場合があるため）
  2. 告知アクティビティの具体例
  3. Actor等価性証明オブジェクトについて明確に規定すべきか、それとも実装者の裁量に委ねるべきか？

参考文献

著作権

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

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