Account Migration

ActivityPub
1

I’ve been idly looking for documentation on account migration. Does somebody have a reference with details for Mastodon

I can imagine how it is done, I’m wondering if there exists a reference.

2 Likes
3

Mastodon and Mitra use the same Move activity. In Mastodon this activity is distributed by user’s old server, whereas in Mitra it is distributed by user’s new home, so migration can work even if old server is not available.

1 Like
4

this is something i need to correct. there is a PR on the mastodon/documentation repo which does this – the correct language should be “Requires alsoKnownAs to be set on the new account pointing to the old account.” even though theoretically it should be both in order to have a guaranteed link you can trust… mastodon doesn’t check the old account’s aliases. i think it just checks the target account’s aliases include the origin actor of the Move (the old account which initiates the Move, before the server goes down), and also that actor matches the object and origin. so semantically it’s like saying “trwnh moved trwnh from trwnh to 2rwnh”. it sounds like mitra is instead saying “2rwnh moved trwnh from trwnh to 2rwnh”.

2 Likes
5

I have a new fantastic business idea: Sell followers!! It works like this:

  • Start an account with content attracting followers, e.g. post cat pictures
  • Once you reach sufficiently many followers, say 1000, you offer to sell half of them
  • If I get a buyer Bob, I set him as my alsoKnownAs
  • I send some randomly chosen 500 people the Move Activity that I’m now Bob.
  • I continue posting cat pictures to attract followers

My understanding from the explanation so far is that there is nothing to stop this abuse pattern. Nor am I sure how easy it will be to detect, depending on how Bob proceeds to communicate to his new followers.

2 Likes
6

the “selling followers” concern is real, but there’s not much you can realistically do to prevent it in cases where there is collaboration. you can only really prevent unauthorized migration of followers. or of course you can simply not do automatic migration of followers :slight_smile: you might do a notification of the move, or refuse to handle it at all, or publish it as a post. the side effects aren’t really defined in any such way because Move is altogether unspecified for S2S activitypub. as2 vocab describes it as an actor Moving object from origin to target.

here is the PR for mastodon that added the Move handler: https://github.com/mastodon/mastodon/pull/9629

3 Likes
7

Just following up on myself. If you look at the following comment, this type of server slowdown is probably fixable with a better account migration strategy:

I don’t have the requests being made, but my gut tells me: Somebody making the flow charts should be able to drastically able to reduce the number of requests requiring processing.

8

There’s a sequence diagram created by @boyter of the current process:

sequenceDiagram
    actor User
    User->>Instance Old: Move
    Instance Old--)Instance Old: Fetch Followers
    loop Every Follower
      Instance Old--)Remote Instance: Move
      Remote Instance--)Instance Old: Unfollow
      Remote Instance--)Instance New: Follow
    end

Sequence diagram of Account Migration
Sequence diagram of Account Migration903×729 30.5 KB

See: https://github.com/boyter/activitypub/blob/8aa3a5418901af9f27878cb00744f4a511c359d6/move-post.md

PS. Also refer to Ideating organization structure for the Grassroots Fediverse (wiki) where the proposal is to unify several documentation efforts.

PPS: Should “Account Migration” become a FEP?

3 Likes
9

I think that would be VERY helpful.

2 Likes
10

First: If we take the FEP name with proposal literally, no.

Second: I’m confident this is not good behavior, as it creates Mastodon typical load bottle necks of all instances doing the same. Trying to figure out how to do it properly, seems pointless without a Mastodon commitment to implement a better solution.

3 Likes
11

Yes. Well, the FEP should be the ultimate best-practice based on input from implementers.

Btw, something else… I bumped into this cry of frustration from a failed migration and wondered: Can one change their mind and migrate back to original account, i.e. ‘undo their migration’?

12

I don’t want to comment on the current situation [1], but one should be able to. Let’s put it on the list of requirements for the person who writes an account migration FEP :sweat_smile:

[1]: There are probably issues related to data models and requirements regarding the usage of accounts, i.e. acct:user@domain, and unique key constraints. Also you don’t want to be that guy. So some level of not reassigning accounts might be wise. All these things boil down to best practices someone should write down.

1 Like
13

Its a concern that this moving workflow could pose significant challenges. While it may initially seem like a beneficial feature, there’s potential for user dissatisfaction. The proper implementation of the FEP by all followers is not certain, and even with correct implementation, there could still be issues. This could lead to an influx of support tickets, placing undue strain on admins. Moreover, any shortcomings could negatively impact the reputation of the entire fediverse.

14

no. an “account migration” as done by mastodon is basically just telling your followers that you have started using another account. anything your followers do in response to that notice, that would be irreversible. unfollowing someone means you have to send a new follow.

it’s frankly the worst of all worlds, as far as handling such a situation goes. i’d much rather see redirects via inbox forwarding, or a form of identity not bound to both current domain (and also username, in many cases).

2 Likes
15

In my implementation user can freely migrate back and forth between the servers. The Move activity basically marks the new account as primary account, it doesn’t delete or lock the old account. Also, Move can be sent multiple times to pick up followers who failed to re-follow because they were offline or for some other reason.
Maybe I’m missing something, but I don’t understand why for Mastodon account migration is such a big deal.

1 Like
16

mastodon doesn’t use key-based ids.

2 Likes
17

I know, what I don’t understand is why the process is irreversible. User should be able to send Move activity from the new server and migrate followers back to the old server.

18

they can, but it is a very expensive process with a 7-30 day cooldown and each time you do it, all follow relationships have to be re-accepted.

3 Likes
19

I’ll assume for a second that this is a new FEP being submitted. Here’s what I would write:

This sequence diagram is flawed and confusing. It should be Following not Followers. Followers can update themself on the next message send from the new account (they got a profile update). The Accept / Follow stuff is also unnecessary then, as the Move Activity acknowledges that I still want to follow that person.

Fortunately, this discussion is not a discussion on a new FEP …

2 Likes
20

Thanks all for this discussion.

I’m about to start work on account migration for Bookwyrm and trying to work out the best way to handle this.

Seems there are a few things to consider, and they may be in potential conflict with each other. I’d prefer to set it up in a way that is compatible with other ActivityPub software but I’m not interested in doing anything in a particular way simply because “that’s how Mastodon does it”.

  1. It should be reasonably simple for the user moving;
  2. It should not trigger a crippling surge in network activity or processing for any server involved;
  3. Ideally it’s reversible, at least within a reasonable time period;
  4. It should clean up after itself eventually.

Looking at that the diagram that was shared, seems to me one could skip a lot of work by simply making a user Move activity trigger a notification alerting a follower of the original account that it has been moved to the new account, and asking whether they want to follow the new one and unfollow the old one. This would have two advantages:

  • followers are notified that the migration has occured (rather than just seeing a random new follow request, or not even that)
  • server load for follow/unfollow activity is spread out over time because it relies on all followers to manually take action

However, I may be missing something?

I’m also wondering about @trwnh’s comment:

i’d much rather see redirects via inbox forwarding

In my experience, the most frequent reason for account migration is that the account holder has a reasonable belief that the original server is unreliable, at risk of going offline permanently, or actually scheduled to go offline (all are good reasons to reduce the amount of work required by the original account’s server, per item 2 above). Perhaps I’m misunderstanding what is meant by 'inbox forwarding" but if it means continuing to send to the original account and relying on that inbox to be available to forward it on, that seems like a pretty risky strategy. @trwnh have I misunderstood what you mean by this?

And lastly, I’m not familiar with Mitra but if the migration can be triggered from the destination account, how does that work? @helge ? I can definitely see the advantage (see previous comment about why people migrate), but it also seems rather open to misuse. If I load a bunch of Alice’s followers into Bob’s account and then send a Move activity from Bob’s server asserting that Alice has moved to Bob, why would any Inbox accept the message as legitimate? Are you exporting Alice’s private key as well so the Activity object can be authenticated, or pre-creating signatures at export, or using some other technique?

Thanks in advance!

21

think of how you can set up an auto-forwarder in email. it isn’t expected to be your address forever, but people eventually figure out that you’ve moved to a new address when you reply to them from that address.

so the “soft” version of a migration is to show a banner that you’re currently at a new account, but anyone replying or mentioning that old account will not be seen at the new account unless you actively go and check your old notifs or threads. (an auto-forwarder would help fix this.)

the next level after that is to notify your contacts (followers, etc, anyone you want really) with a migration notice, currently done via a special Move activity defined by Mastodon (which is kind of weird semantically, and it can be inconsistent between softwares as mentioned above, so it would possibly need some standardization).

upon receipt of whatever activity, your software has a choice to either generate a notification (as in pleroma), or perhaps auto-follow the new account (as in mastodon, which also force-unfollows the old account so you lose access to old followers-only statuses, which is actually pretty bad when you think about it, but no one really thought about it since 2018)

2 Likes