Add handler for Move activity

[Gargron]

See: #177, #6955, #8003

Traffic

My guesses about the traffic patterns of this feature:

Given N as the number of followers on the original account, and M (M <= N) as the number of separate servers those followers are on.

1. The Move activity is distributed to M inboxes
2. M servers access the new account via account resolution
3. N accounts send unfollow activity to the old server
4. N accounts send follow activity to the new server
5. N accept-follow activities are distributed from the new server to the new followers

Categorizing the workload by servers goes as such:

• The old server has to make inbox deliveries M times and process N incoming activities (Simplified: 2N)
• The new server has to answer M queries and process N incoming activities, then send out N activities more (Simplified: 3N)
• Each server that has any followers of the old account must process 1 incoming activity and send out 2 * (x / N) activities. In some cases this includes the old and new servers, so this could add on top of their workloads as well.

Let's imagine a large account decides to move - me. At the time of writing, that's roughly N=200,000. That means the old server has to process 400,000 Sidekiq jobs, the new server has to process 600,000 Sidekiq jobs.

That is to say, that's a lot of Sidekiq jobs, and a lot of traffic. For this reason I believe that the UX around the account migration feature should be incredibly strict, to prevent multiple uses by the same person (across servers, too) as much as possible.

Risks

It allows potentially amassing a large following for a brand new account from multiple smaller parts. Kind of like that large Mastodon power ranger mech assembling from the smaller ones, or that game where you are a bubble that eats other bubbles to grow larger. Amass a number of followers, then sell your account to someone who is willing to pay for them. (Consider that I primarily view this risk not from the perspective of high follower counts being desireable, but from the perspective of being able to put a message on many people's home feeds).

Risk mitigation

On the old server side, it is easy to add a cooldown (perhaps permanent!) on sending out Move activities. On the new server side, it is required to add the old account's URI to an "also known as" attribute, otherwise the Move activities won't validate anywhere (i.e. both old and new accounts have to point at each other). So it is possible to put a cooldown on updating that attribute, as well.

However, those precautions can be patched out by a malicious admin (or non-Mastodon software), i.e. the risk of massive follower accumulation from different sources remains.

End notes

Just as a disclaimer since it may not be obvious, this PR, in any case, does not include any UIs for performing Move activities in any capacity. For this feature to be effective, the UIs cannot be released until most of the Mastodon servers in the wild have upgraded to a release that includes this Move handler.

[chartier]

Thank you so much for spending more time on this. I feel like it’s the last major roadblock for getting more friends on here.

Just this morning I had yet another friend really interested in trying Masto and hopefully moving to it. But he’s unfamiliar with the mechanics of instances and spooked out at the prospect of losing followers if he has to move. “I’ll wait until they fix that then.”

If you could use help beta testing, I recently switched instances. I was on .cloud with ~ 850 followers, am now on toot.cafe with ~ 360. I’d love to bring the rest of those over.

[Gargron]

If you could use help beta testing

Unfortunately, you won't be able to test this until all the servers where you have followers will have this patch, by which point testing it will be useless.

[trwnh]

3. N accounts send unfollow activity to the old server

I'm concerned this means that old followers-only content will become inaccessible. Unless content is also moved over, or if the privacy code checks for relations with the alsoKnownAs/movedTo, maybe?

[Gargron]

Unfollowing the old account is a crucial safety mechanism. Otherwise there's gonna be a business of selling followers, not just once to one person, but to as many people as are willing to pay.

[ClearlyClaire]

I understand your concerns, but I'm really uneasy with the unfollow part… especially with the code attempting to unfollow, then attempting to follow, possibly failing in the process.

I wonder if we really need fully-automated migration? What about some kind of notification giving user the choice to follow the new account and (separately) unfollow the old one?

[nightpool]

Yeah, after looking closely at this, a fully-automated unfollowing that removes access to previously accessible follower-only content is going to be really surprising for most people. Let's fix this in a follow-up before release—probably by making it it partially automated, like @ThibG suggests

[tribela]

I think that unfollowing part should changed.

1. Not every server is Mastodon.
   If follower is on non-mastodon server(or older version of Mastodon), unfollowing is never happened.
2. If original account concerns about privacy, Use Block-Unblock(or something) to force remove followers. And it should be checkboxed option for migrator.