FEP-73cd: ユーザーアカウント移行に関するユースケース

概要

ユーザーアカウントの移行、複数アカウント管理、およびコンテンツ/アクティビティ履歴のエクスポート/インポート/移行といった問題領域を明確にし、関係者間で認識を統一するため、以下に提示するユーザーストーリーは議論の整理と解決策の共有を目的としています。

貢献方法

これらのユーザーストーリーのいずれかについて、SWAT演習の精神に基づき、さらに詳細な仕様を追加することが可能です。必要に応じて、別のFEP（機能拡張提案）またはSocialHubスレッドで個別に議論を進めてください。

ユーザーアカウント移行に関するユースケース

PR歓迎！追加・更新をお願いします！

1, 2, 3はフォロワー関係とプロフィール情報の移行について、4, 5, 6, 7は投稿済みアクティビティの移行について説明しています。

1. アリスは、どちらもオンライン状態で相互にフェデレーションされているAlphaからGammaへ、両方向のフォロー関係を維持したままアカウントを移動したいと考えています。この場合、以下の4つの可能なバリエーションが考えられます（互いに排他的ではありません）：
   • A. Alpha上のアリスのアカウントを完全に終了させ、人間が読める形式のリダイレクトを設定すること。具体的には、古いAlice@Alphaコンテンツへのリンクに「Aliceはもうここにはいません」という警告を表示するようにします。
   • B. Alphaが、Alice@Alphaや彼女が同アカウントで投稿・生成した特定コンテンツへのすべてのリンクを、Gammaにおける合理的なデフォルト「ホームページ」に動的にリダイレクトすること。
   • C. Alphaが、Alice@Alphaコンテンツへのすべてのリンクを、移行先であるGamma上の該当コンテンツ（301 HTTPステータスコードとnginxスタイルのURL書き換え）に動的にリダイレクトすること。
   • D. AliceはAlphaアカウントをそのままアクティブな状態に保ちつつ、個人用アカウントとして新規投稿を受け付けたいと考えています。同時に、フォロワーには新しいプロフェッショナル向けアカウントについても知らせたいとしています。このため、Alice@Alphaから厳選されたプロ向けコンテンツが移行され、彼女の新アカウントでは少しの過去履歴を引き継ぐことができます（ただし元はAlphaにアップロードされたものである旨の免責事項を付記します）。
   • E. アリスは、フォロワーとフォロー中ユーザーに加え、Alpha上で手動でブロックまたはミュートした「非フォロー」状態の特定アカウントもGammaに移行したいと考えています。
   • F. フォロワー、フォロー中ユーザー、および「非フォロー」リストに加えて、AliceはAlphaの慎重に管理された「フェデレーション除外リスト」（サーバーレベルで設定されたブロックリスト）をGammaにも移行したいと考えています。これはGammaがAlphaよりも新しく、かつ管理体制が整っていないコミュニティであるためです。
2. Bobは、モデレーションチームからAlphaアカウントの利用停止を求められました。同チームはそのアカウントでの新規投稿を無効化していますが、礼儀としてBobには任意の新しいサーバーへの一方通行かつ恒久的な移行を認めています。BobはAlphaにログインし、Alphaとフェデレーション関係にある新たなサーバーへ永久的にデータを移行します。これにより、サーバー間接続が可能になります。しかし実際には、互換性のないモデレーションポリシーを理由にAlphaから意図的に非フェデレーション化されたBetaサーバーを新たなホームとして選択しました。Bobは、AlphaやBetaが相互通信することなく（なぜならAlphaはそもそもBetaとの連携を完全に拒否しているため）、フォロワーに対して新しいアカウントの存在を告知したいと考えています。
3. Charlieは、政府の介入により突然オフラインになったDeltaから、プロフィール情報、フォロー関係、および長年にわたって蓄積したオリジナルコンテンツ全体をGammaに移行したいと考えています。移行前にGammaはCharlie向けにカスタムクライアントを承認しており、彼はこのクライアントを使って各投稿に自己管理型の秘密鍵で署名していました。また、フォロワー/フォロー中リストもバックアップを取っていました。Deltaではこれらすべての内容を読み込み認証することで、新しいアカウント上で表示することが可能です。
4. Bobは、AlphaからBetaへ、非フェデレーション状態にある過去のコンテンツも移行したいと考えています。サービス利用が部分的に制限された後、彼はAlpha上のアーカイブデータ（メディアアップロードを含むが、モデレーション記録は含まない - なぜならAlpha自体にはそのような記録を生成する機能がないため）をエクスポートし、Betaにインポートして再公開を検討できるようにしたいと考えています。
5. Charlieは、Charlie向けカスタムクライアントによる認証を経て、Gammaコンテンツのアーカイブも取得することに成功しました（これにはメディアアップロードとモデレーション記録が含まれます）。このクライアントを使用して、このコンテンツをDeltaに対して認証することができ、デルタはGammaがオフライン状態であってもこれを再公開対象として検討可能です。
6. Deltaを一定期間使用した後、CharlieはさらにEpsilonサーバーへの移行を検討しています。Danielがこの移行を担当しており、Epsilonには唯一のユーザーであるDaniel自身が完全な管理者権限を持っています。Epsilonは最近のバックアップデータを読み込みますが、デルタからエクスポートされたモデレーションポリシー情報はスキップします。
7. インポート時点で、DeltaはGammaがエクスポート時にサポートしていたすべての機能やアクティビティタイプを完全にはサポートしていません。以下の2つのバリエーションが考えられます（互いに排他的ではありません）：
   • A. Deltaのインポートウィザードは、Charlieに対してバックアップを保持するよう警告し、後日再試行することを推奨します。数年後に彼がこれを実行すると、デルタがより広範なGammaアクティビティタイプをサポートできるようになったため、重複することなく追加コンテンツがインポートされます。
   • B. Deltaは未インポート状態のすべてのGammaアクティビティを別アーカイブとして保存しています。数年後、Charlieがこの歴史的データをデルタデータと共にEpsilonへエクスポートする際、未インポートのGammaコンテンツ、既にインポートされたGammaコンテンツ、および最新のDeltaコンテンツがすべて新しいバックアップに含まれ、これらの全てがEpsilonに一括インポートされます。

ユースケースとFEP対応表

注：本セクションは主観的な内容が多く、意思決定を支援するための参考資料として提供されています。他のFEPの有用性や必要性について確定的な見解を示すものではありません。 各ユーザーストーリーの具体的な実装方法を説明するブログ記事やその他のチュートリアルへのリンクを、「プロフィール」欄の形式 [1](<リンク>), [2](<リンク>)... でPRにて追加してください。

• キー：
• [R] 必須
• [H] 有用
• [U] 不明
• [1/2/3] オプション設定

未解決事項

• FEP-fb2aで提案されている任意のActorメタデータk/vペアは、上記の一部に対してレガシー対応やフォールバック手段として有用かもしれません？
• 同様に、FEP-612dが提案するドメインとActorをマッピングするためのカスタムTXTレコードは、「死滅したサーバーからの移行」ケースにおいて有用な手段となる可能性があります？
• [ABC] Alyssa P. Hacker, 一例としての提案書, 2020

著作権

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

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