feat: account migration

[nmkj-io]

What

Moveアクティビティによるアカウントの引っ越し（フォロワー引き継ぎ）に対応する。一度引っ越したアカウントでは二度と引っ越しできなくなるが、フォローや投稿は引き続き可能。引っ越したアカウント（PersonオブジェクトにmovedToが設定されている）に対しては引っ越し先を表示する。

Calckey の実装に基づいています。

#5475 を一部解決。

This PR implements the account migration functionality using Move activity. The old account won't be migrated again, but still functional. If the account has movedTo value, its new account is indicated in its old profile page.

Some codes were adopted from Calckey.

Partially resolves #5475

Why

アカウントの引っ越しに対応するため。例えば Mastodon → Mastodon のフォロワー引き継ぎにも対応する。

This also enables Misskey to follow account migrations between Mastodon servers.

Additional info (optional)

Migration

• Misskey → Misskey
• Misskey → Mastodon
• Mastodon → Misskey
• Mastodon → Mastodon

Follower Relationships

• Remote follow from Mastodon
• Remote follow from Misskey
• Local follow from Misskey

以上の組み合わせでフォロワーが引き継がれることを確認した。

I confirmed followers are transferred with the above combinations.

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[codecov]

Codecov Report

Merging #10507 (6908376) into develop (eb30976) will decrease coverage by 0.10%.
The diff coverage is 56.02%.

@@             Coverage Diff             @@
##           develop   #10507      +/-   ##
===========================================
- Coverage    75.26%   75.17%   -0.10%     
===========================================
  Files          881      885       +4     
  Lines        86409    86982     +573     
  Branches      5883     5911      +28     
===========================================
+ Hits         65039    65390     +351     
- Misses       21370    21592     +222     

Impacted Files	Coverage Δ
...ges/backend/src/core/activitypub/ApInboxService.ts	17.47% <5.76%> (-1.00%)	⬇️
.../backend/src/core/activitypub/ApRendererService.ts	75.95% <32.00%> (-1.59%)	⬇️
packages/backend/src/core/AccountMoveService.ts	43.85% <43.85%> (ø)
...end/src/core/activitypub/models/ApPersonService.ts	63.11% <50.00%> (-0.09%)	⬇️
...ges/backend/src/server/api/endpoints/i/known-as.ts	66.30% <66.30%> (ø)
...ackages/backend/src/server/api/endpoints/i/move.ts	70.58% <70.58%> (ø)
packages/backend/src/core/AccountUpdateService.ts	100.00% <100.00%> (ø)
packages/backend/src/core/CoreModule.ts	100.00% <100.00%> (ø)
packages/backend/src/core/activitypub/type.ts	94.13% <100.00%> (+0.14%)	⬆️
...ges/backend/src/core/entities/UserEntityService.ts	92.91% <100.00%> (+0.07%)	⬆️
... and 7 more

... and 3 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[tamaina]

A→B/B→A/A→C

A→B/B→Aってできるの（というかやっていいの）？

followとunfollowでawaitをする必要は無い

同時多発的にfollow, unfollowを走らせるのは負荷的にまずい気がする

[nmkj-io]

A→B/B→Aってできるの（というかやっていいの）？

この実装ではそのような使い方はできない（古いアカウントは二度と元通りに使えない）と引越し実行時に警告が出るようになってます。

同時多発的にfollow, unfollowを走らせるのは負荷的にまずい気がする

follow、unfollowは引っ越し先がリモートの場合はキューに入ります。引っ越し先がローカルの場合はキューに入りません。

負荷が有るとしたら follow, unfollow 関数のなかで findOneByOrFail している（クエリする）部分だと思います。

misskey/packages/backend/src/core/UserFollowingService.ts

Line 84 in 789689e

this.usersRepository.findOneByOrFail({ id: _follower.id }),

[tamaina]

負荷が有るとしたら follow, unfollow 関数のなかで findOneByOrFail している（クエリする）部分

checkBlockedもデータベースに問い合わせる可能性がある

1000人や1万人単位で移動があると大変なことになりそう

[nmkj-io]

1000人や1万人単位で移動があると大変なことになりそう

最悪ケースはリモートユーザーのフォロワー1万人が全員同じMisskeyサーバーに属していた場合です。（かなり特殊事例だとは思います）
この場合そのリモートユーザーがフォロワー1万人と同じMisskeyサーバーに引っ越してきた場合は1万回followとunfollow処理がローカルで走ることになります。これはMastodonも同様だと思います。

https://github.com/mastodon/mastodon/blob/99e3e152cd2180cfa9a5bcafae208d44f31078f8/app/workers/move_worker.rb#L10

フォロー処理を全てキューイングする場合はそもそもfollowの実装を書き直す必要があると思います。

[tamaina]

最悪ケースはリモートユーザーのフォロワー1万人が全員同じMisskeyサーバーに属していた場合です。（かなり特殊事例だとは思います）

misskey.ioの状況を見ると(ioからフォロワー1万あるというのは)割とあり得る

[tamaina]

フォロー処理を全てキューイングする場合はそもそもfollowの実装を書き直す必要がある

(これが嫌なのでアカウント移行に手をつけてなかったというのはある)

[nmkj-io]

followに限ればフォローのインポートが参考になるのでそれを使う手はあります。

[tamaina]

フォローのインポートが参考になる

フォローインポートも1回のジョブで全部インポートしようとするのでならない

（そして案の定、ユーザーが数千件のフォローインポートを誰かが行うと阿鼻叫喚になる）

[tamaina]

(つまり: フォローのジョブキュー化はどっちみちやらなくてはならない

[nmkj-io]

フォローインポートも1回のジョブで全部インポートしようとするのでならない

ではフォローのインポートも含めて根本的に直す必要がありますね……。ただ中規模以下のサーバーでは無視できる話だと思うので、コントロールパネルから（もしくはロールで）引っ越しを無効にできるようにすれば妥協策になります。

[tamaina]

（引越の有効無効をロールで簡単に制限できるのはなんかちょっと違う気がしている）

[nmkj-io]

（引越の有効無効をロールで簡単に制限できるのはなんかちょっと違う気がしている）

ちなみにロールにすると「misskey.ioに居るがフォロワーはそんなに多くないので引っ越したい」という要求に対応できるようになります。（引っ越しを承認制にする）

[nmkj-io]

あるいは、一定数以上のフォロワーが居る場合は引っ越しを許可しないという処理もできます。

[tamaina]

一定数以上のフォロワーが居る場合は

コンディショナルロールで設定できるのでロールで実装するということになりそう

[tamaina]

全く別の問題: 移行先のアカウントでフォローされまくることになるので、通知破壊される

[nmkj-io]

全く別の問題: 移行先のアカウントでフォローされまくることになるので、通知破壊される

これは仕方ないですね……。（Mastodonでも起こる）

[nmkj-io]

一定数以上のフォロワーが居る場合は

コンディショナルロールで設定できるのでロールで実装するということになりそう

フォロー処理がジョブキューになるまで一旦これでやってみます。

[tamaina]

あとフォローだけじゃなくてユーザーリストやブロック・ミュート関係も移行する必要がある

[nmkj-io]

あとフォローだけじゃなくてユーザーリストやブロック・ミュート関係も移行する必要がある

これは引っ越し機能ではなくインポート・エクスポートしてもらう形になります。

（引っ越しはあくまでフォロワーに着いてきてもらうための機能）

[tamaina]

（引っ越しはあくまでフォロワーに着いてきてもらうための機能）

それが嫌という意見は多くある
フォロワーがついてくるならブロック・ミュートも追従するべき

[nmkj-io]

（引っ越しはあくまでフォロワーに着いてきてもらうための機能）

それが嫌という意見は多くある フォロワーがついてくるならブロック・ミュートも追従するべき

Misskey同士なら可能かもしれません。MastodonやAkkomaとは現状その互換性が無いですが、やめる理由にはならないと思います。

処理を分けることはできます。

[tamaina]

引っ越しする人から他の人に対してのブロックミュートリストはエクスポート/インポートでいい

私が言いたいのは他の人から引っ越しする人に対してのブロックミュートについてで、これは互換性は関係ないはず
(moveアクティビティを受け取ったらフォローと同様にブロックやミュートをコピーしたい

[nmkj-io]

他の人から引っ越しする人に対してのブロックミュートについてで、これは互換性は関係ないはず (moveアクティビティを受け取ったらフォローと同様にブロックやミュートをコピーしたい

Moveアクティビティはフォロー関係がひとつでもあるサーバーにしか飛ばないので、飛んでくることを期待して楽観的な処理にすることはできます。

Moveを受信したときにローカルユーザーのブロック・ミュート関係をチェックする。

[tamaina]

楽観的な処理で良さそう

[tamaina]

（新規に発見 or 何らかの拍子にアップデートされたユーザーでも引っ越し関係はデータとしてあるのだからブロック・ミュート処理を行うのは可能ではありそう）

[tamaina]

優先順位（個人的な勝手な意見）

• フォローのジョブキュー化ができるまではアカウント移行機能は復活させたくない
• 通知破壊はmutingNotificationTypesにfollowを自動で追加するみたいな処理を入れると良さそう
• ブロック・ミュート関係はoptinal (機能をブロックするまでの問題ではない)

[nmkj-io]

フォローのジョブキュー化ができるまではアカウント移行機能は復活させたくない

大量のローカルユーザーが一つのリモートユーザーをフォローしていて、そのリモートユーザーが引っ越した場合は人数制限で解決しないので、引っ越し機能はジョブキュー化が完了するまで保留にした方が良いでしょう。

（ジョブキュー化すればそもそも人数制限などの回りくどいものが必要ないと仮定した話ではあります。）

中規模以下のサーバーと大規模サーバーで引っ越し対応に齟齬を許すならセキュリティオプションにするという手もありますが、どのみちジョブキュー化で両方解決するならそれに越したことはないと思いますので。