Account Migration (Move)

[tamaina]

Summary

アカウントの引っ越し機能（Mastodon 3に搭載されたのと同じ、ActivityPub標準）

ユーザーが設定画面で引っ越し先アカウント（事前に作成しておき、引っ越し元のアカウントを専用のフォームに入力しておく）を指定して引っ越し操作を指示すると、プログラムは

• 引っ越し元アカウントのフォロワーが引っ越し先アカウントをフォローするようにする
  • ActivityPubではMove Activityをフォロワーへ送信し受信したサーバーは同様の対応をする
  • ブロックやミュート、リストも追従
  • 「通知のみでフォローなどを自動で移行しない」のを選択することもできるように？
• 引っ越し元アカウントが操作できないようにする（データの出力等はできる）
• 引っ越しから30日以上は引っ越しできないようにする

Related to #4706

MastodonではMoveを送らずmovedToの設定だけをする?redirectも行えるが、実装する？

RD

Recieve movedTo/Move Activity

• [ ] Add movedToUri to DB user entity
• [ ] Pack and display movedTo
• [ ] Deny users to follow users with movedToUri/movedTo
• [ ] Store movedTo by Account Update activity or Move activity
• [ ] Re-follow the new account, add mute/block relationships with that, and modify user lists to add that when receiving account Move activity
• [ ] Account Aliases = alsoKnownAs uri collection

Set movedTo, Start Migrating

• [ ] Implement the endpoint and ui to start migrating
  • Check alsoKnownAs (Continue only if requested account is included in alsoKnownAs of the account to which to move)
• [ ] Send Account Move activity
• [ ] Lock down api call to prevent new postings, etc but to allow exporting lists, etc
• [ ] Stop accepting followings
• [ ] Prohibit migration for a certain period of time (30 days)

[tamaina]

Mastodonが実装している以上、とりあえずMoveアクティビティの受信とその処理にだけでも対応しておいた方が良い気がする

[tamaina]

mstdn.jpの閉鎖が発表されました。

めいめいはあんまり乗り気じゃないけど（実装難しいし）、ユーザーの利便性を考えると付けた方がいいのかなと思います。

引っ越し元アカウントのフォロワーが引っ越し先アカウントをフォローするようにする

フォロワーには引っ越し通知を送るだけで、通知から任意にフォローしてもらうとかでもいいかもしれない。

[4ioskd]

Implement moving account https://git.pleroma.social/pleroma/pleroma/-/merge_requests/3524

Recently in Pleroma git repo, this pull request is developed in progress. 最近プレロマのgitリポジトリで、このプルリクが現在進行形で開発されてます。

[tamaina]

ブロックとミュートも追従するようにするとよさそう（Mastodonはもうなっている？）

[4ioskd]

In mastodon,You can export a csv file of block,mute,domain blocks and bookmarks list. マストドンではブロック、ミュート、ドメインブロック、ブックマークのリストをcsvファイルでエキスポートできます。

[mei23]

マストドンではブロック、ミュート、ドメインブロック、ブックマークのリストをcsvファイルでエキスポートできます。

ちゃうちゃう、ブロミューフォローじゃなくて 被ブロミューフォローの方だわ

[4ioskd]

At any time you want, you can go to Settings > Export and download a CSV file for your current followed accounts, your currently created lists, your currently blocked accounts, your currently muted accounts, and your currently blocked domains. https://docs.joinmastodon.org/user/moving/

なるほど。。

[tamaina]

pinした

[syuilo]

priorityどのくらいかしら

[tamaina]

highかlowで言ったらhighだと個人的には思っている
（ただし、私がいきなり連合周りに手を突っ込むより、他の人が作業したほうが効率的だと思う）

[mei23]

• moveToを取得しておく => 雑魚い
  • API/UIにまで反映させる => ちょっとめんどい
• Move Activityに対して引越し先を検証する => 罠はあるけどやれば出来る
  • Move Activityで何かをする => 何をするのか (Follow/Mute/Block/List追従？ユーザーに選ばせる？通知のみ？) みたいなのを決めるコミュニケーションがめんどい

って感じなのだわ

[tamaina]

データベース変更まで実装していただければAPI/UIは私かしゅいろでやる

何をするのか (Follow/Mute/Block/List追従？ユーザーに選ばせる？通知のみ？) みたいなのを決める

各ユーザーの設定で、Moveを受け取った時の動作としてFollow/Mute/Block/List追従 or 通知のみを選ばせておくのがいいのではないかと（Move発出側で決めるわけではないでしょ…？）

[mei23]

AP周りの罠はこのあたり

• 引越し元と引越し先をそれぞれ取得してINSERTする実装にすると、元と先 双方が新規だった場合にループするので避けること。
• 引っ越し先がループさせられるのを防ぐこと。
• 引っ越し元と先を検証するときは最新のデータを使用すること。

[robflop]

I think it's important to keep what @Gargron said in issue #8690 in mind when implementing this.

[tamaina]

引越し元のアカウントをフォロー解除するという仕様は、ノートがホームから消えたりフォロワー限定投稿が見られなくなったりするので良くなさそう

https://misskey.m544.net/notes/7180d338bda8be52d24e905f

[mei23]

さらすなって

考え方は多様だから最終的にオプションにするしかない感だわ

[robflop]

UXのことよりGargronさんが話してたフォロワーを売るの可能性の問題を防ぐのはもっと大事だと思う

元アカウントのフォロワー限定のノートとかがまた見たい場合で元垢を自分で再フォローのはどうだろう？

[tamaina]

説明をするようなことではないけれど、何でもかんでもオプションにするのは、実装やテストが面倒になるし、ユーザーに混乱をもたらす

UXのことよりGargronさんが話してたフォロワーを売る可能性の問題を防ぐのはもっと大事だと思う

その意見は理解しますが、引用リノート(ブースト)機能に代表されるように、MisskeyはUXを重視してきました。

[tamaina]

あ、でもユーザー各位でフォローを外すかどうかのオプションはあっても良さそう
（ここのオプション1こが2こに増えるのはあんまり変わらなさそう）

[robflop]

Misskeyにある特徴機能（例えば引用リノート）はすごく好きけど悪用の可能性がある場合は少しUXについて妥協するのが出来たらいいと思う

[tamaina]

日本語の話: 引越しって言うとノートやドライブの内容まで移行するものと誤解されがちなので、アカウント移行と表現したほうがいいかしら？

[robflop]

確かに

[ThatOneCalculator]

日本語の話: 引越しって言うとノートやドライブの内容まで移行するものと誤解されがちなので、アカウント移行と表現したほうがいいかしら？

Agreed. When a user goes into settings to perform account migration, it should probably come with a big warning, explanation, and confirmation too and really emphasize that it's a full migration.

[robflop]

Agreed. When a user goes into settings to perform account migration, it should probably come with a big warning, explanation, and confirmation too and really emphasize that it's a full migration.

I think you misunderstood - it's the opposite. tamaina was saying it should be renamed to not give the wrong impression that it moves everything, including drive content etc (which 引っ越す implies - it's the verb you'd use when you express that you are moving houses in english). It'll only move followers to my understanding (which 移行 is clearer about).

I agree with there being a warning that explicitly states the full consequences of the move though.

[ThatOneCalculator]

Ah. DeepL has failed me again :pensive:

[Johann150]

日本語の話: 引越しって言うとノートやドライブの内容まで移行するものと誤解されがちなので、アカウント移行と表現したほうがいいかしら？

I think in English it would be the other way around: "Migrating" an account would mean to me that all the contents are migrated too, like in a database migration sense? But when I read "move" in a Fediverse context it almost always means the user is using a different account now.

[Johann150]

I think a new user.movedTo column or similar will be necessary. It can contain a user id (foreign key) and be nullable. Necessary both to track whether a user has already moved and for displaying the moved to account in the UI.

There are some more edge cases to be considered with this, in regard to the foreign key constraint on movedTo. What should happen if the move target account gets deleted? (ON DELETE)

1. Both NO ACTION and RESTRICT can not be the right choice, because it would disallow user deletion. (might be an issue with GDPR) And there is no sensible default so SET DEFAULT is also not an option.
2. Delete the previous accounts as well? (CASCADE) Could be resource intensive, and because there are other things connected to user deletion, would need to track user deletion jobs for those accounts as well.
3. Delete the movedTo information? (SET NULL) Would be the same as "undoing" a move and allow the user to send another Move activity.

What should happen if the move target has a movedTo value already? Not accepting moves into accounts that already moved disallows "circular moves", like Move(A -> B) + Move(B -> A).

---

I think automatic follower migration could be regulated by a field user_profile.autoAcceptMove similar to the existing user_profile.autoAcceptFollowed. Pleroma has a similar setting called "Allow auto-follow when following account moves".

The move notification should probably include a follow button. Or a "migrate" button to handle other features of missey as well (Lists, Groups, Blocks, ...)? And who should receive the notification? If only followers receive the notification, Blocks etc. may not be handled correctly because there can not be a following between them.

My personal opinion is that Mastodon and Gargron are trying to solve a social issue with technology. So I'm not sure if it is a good idea to automatically unfollow. I think Pleroma and maybe also Mastodon take into account followings in the past to compute visibility which Misskey does not, so our problems are a bit different in those regards.

[tamaina]

Requirements defined in more detail https://github.com/misskey-dev/misskey/issues/5475#issue-501300427

[ThatOneCalculator]

Account migration (to and from) has been implemented in Calckey if as per the spec in https://github.com/misskey-dev/misskey/issues/5475#issue-501300427 you'd like to take a look at our implementation :)

[tamaina]

いる？（面倒くさくなってきた）