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.
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”.
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.
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 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.
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.
I don’t want to comment on the current situation , but one should be able to. Let’s put it on the list of requirements for the person who writes an account migration FEP
: 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.
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.
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).
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.
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 …
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”.
It should be reasonably simple for the user moving;
It should not trigger a crippling surge in network activity or processing for any server involved;
Ideally it’s reversible, at least within a reasonable time period;
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
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?
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)