Inform followers that your account has moved

[garbados]

Migration tooling should proactively inform a user's followers that the migration has occurred.

Here are some feature suggestions that meet this requirement:

• After indicating that your account has moved, the instance from which you are migrating should send a notification to all your followers that you have moved which includes a link to the new profile, where a follower can opt to re-follow the user at their new instance. This serves as a deprecation notice for the old account.
• For a time (ex: six months), every time a migrated user toots from their new account, the old account boosts it with a header including a button to follow the user at their new location. This serves as an ongoing deprecation notice for the old account.

Here are some backend suggestions to make it work:

• API endpoint to broadcast notifications to all your followers.
• Backend hook to create and delete rules indicating that an account should automatically boost posts from another account. (In this case, specifically for the old account to boost the new account)
• New UI component for the "header message" which accompanies these automated boosts and includes a follow button.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[RobertRence]

Is it possible this could be exploited with circular references between accounts to create a DDOS across a set of federations?

As a potential solution, you might want to make it so it only allows a single boost. Alternately, or only boost toots that aren't already boosted.

[nightpool]

duplicate of #177, i think?

[jfmcbrayer]

I think it's a narrower, more incremental approach to #177. Just like delete-and-redraft is a narrower, more incremental approach to editing. It's also more concrete.

[paralithode]

This seems like a great solution to the issue, one I recently encountered myself. I moved instances & have been experimentally boosting a post explaining that I've moved, or a post from my new account, every few days. I consistently garner a few refollows at my new account every time I do this, so evidently it's very easy to miss someone having moved in the current system.

[trwnh]

re: #177, yeah, this has been discussed there, but it's also more of an improvement to the already-existing "account moved" setting and not at all to do with migrating your account -- it's about moving to a new account.

Is it possible this could be exploited with circular references

no, because the "account moved" setting checks for circular references and disables several account functions while the redirection is enabled. you can't follow a moved account, and you can't point the redirection toward an account that has moved iirc

[oct2pus]

i'm hesitant on the idea of 'old account boosts all new toots and provides a new link to the new account'. It could get very annoying quickly if you toot a lot and it doesn't check if you already follow the new account.

There are plenty of reasons to continue following old accounts, i usually still follow old migrated accounts because sometimes an instance goes down and I still want to stay in contact with the poster while its down (because people usually just treat it as an alt), they decide to re-purpose the account at a later date for whatever reason or they just move back to their old account for one reason or another.

But, if it was to be implemented, 6 months produces zero urgency to move and follow the new account, a week would be much better.

[trwnh]

it doesn't check if you already follow the new account

i assume this would be on the user to unfollow the old account? idk, i think this is mostly an artefact of creating a new account rather than migrating it -- so mirroring doesn't really work as expected. kind of a flawed analogy that can't really be fixed with the current paradigm.

6 months produces zero urgency to move and follow the new account, a week would be much better

any timeframe is going to have the same issues -- is it enough time? it gets confusing quickly, because of that uncertainty about what "moving" actually means. right now, it's not actually moving, it's just a (temporary) redirection.

[oct2pus]

i assume this would be on the user to unfollow the old account? idk, i think this is mostly an artefact of creating a new account rather than migrating it -- so mirroring doesn't really work as expected. kind of a flawed analogy that can't really be fixed with the current paradigm.

I listed multiple reasons why I believe some people would prefer to continue following the old account besides pure laziness.

any timeframe is going to have the same issues -- is it enough time? it gets confusing quickly, because of that uncertainty about what "moving" actually means. right now, it's not actually moving, it's just a (temporary) redirection.

I don't understand how your comment relates to my comment. I think if Mastodon is to implement boosting new account tweets (which i was against without certain considerations re: my first point), I think 6 months produces zero urgency to follow the new account. 1 Week is a better timeframe because it encourages the user to swap over, versus 'do nothing about it'.

---

The context of this issue asks Mastodon (and I assume particularly Gargron) to expand upon the previously established method; I honestly prefer the redirect method; still, the addition of a ping would help quite a lot! Because this can create a push notification, and personally my notification timeline tends only have bursts of notification compared to my home timeline which has a constant stream of messages, requiring me to catch the user saying their moving, or for the user to constantly repeat themselves over and over.

[oct2pus]

Also, assuming an account got hacked, couldn't it redirect to another account that could consistent post spam/offensive messages, wouldn't this require an additional layer of admin intervention

1. if the spam account got banned and the redirect account did not, the spammer can simply change the redirect.

2. If the original account got banned, it still requires a different set of admins to find the spam account.

3. If the spammers instance is unwilling to ban the user, or if their self-hosting, it will require the original set of admins to also block the instance.

Requiring two or more instance admins to interact introduces a meaningful latency and in the third case, also increase the burden of moderation on instance admins.

[trwnh]

I don't understand how your comment relates to my comment. [...] I think 6 months produces zero urgency to follow the new account. 1 Week is a better timeframe because it encourages the user to swap over, versus 'do nothing about it'.

My meaning was that "urgency" can't really be defined within a specific time frame. Say you want a specific follower of yours to follow you at your new account. Now, say they don't log in for 2 weeks because they're taking a vacation. They won't see your boosts.

There's a fundamental disconnect between "I want my followers to know I've moved" and "I'm going to do that by boosting things from a new account" because they're technically still two different accounts, and not treated the same in any meaningful way -- no deduplication, no content moving, etc. You can't force any actions between the two because that would require consent of each follower. Maybe you can ping them, and that's probably the stronger half of this feature request -- it should be easy to generate notifications that an account has moved (and allow filtering for such notifications, so that they don't get lost among all the faves/boosts/mentions).

assuming an account got hacked, couldn't it

If an account got hacked, then the issue is with the hack and not strictly with what happens afterward; the hacker could post directly to the account without any redirection at all. In that case, having an auto-boost option would probably make the problem worse, but I'm not sure it makes a meaningful difference besides offering more vectors and perhaps reducing API calls on the server. Prevention and mitigation are more important.

[oct2pus]

Re: Urgency, fair enough. I agree with your opinion.

---

the autoboost option; in my mind, would be a vector for mass boosting from multiple accounts all at once, say someone wants to do a delay attack and then fill user feeds with exceedingly large amounts of gore, they could 'delay' swapping/hijacking the account until their time to strike (or in the case of longer durations like 6 months, could just start setting the redirect early compared to the attack). I think an auto-boost option could substantially worsen the effects of such a breach.

Granted, we both agree account security is more important, and frankly, the scenerio I created was a stretch. I just don't think the autoboosting option is a good idea in general IMO.

[schiessle]

In general I like your ideas but I wonder why the user should manually decide to follow you on your new instance? If you send already the automated notification that you moved from instance X to instance Y, why not automatically unfollow the old account and follow the new one?

[trwnh]

@schiessle Because the notification may have been sent in error, because the old account has followers-only posts on it that you would lose access to, etc etc. In general, any breaking change should ask users for consent in order to avoid potentially irreversible consequences. This is doubly important because the follow button is disabled on accounts marked as "moved", and because a user may move back at some point.

[schiessle]

Because the notification may have been sent in error, because the old account has followers-only posts on it that you would lose access to, etc etc.

Not sure if I understand this point correctly. But I don't think this is an issue, I don't see how post type affect the move of an account to a different server.

This is doubly important because the follow button is disabled on accounts marked as "moved", and because a user may move back at some point.

If moving would be automated you could as easily move back to the old instance the same way you moved to the new one.

I can only speak for myself. I'm at the moment at mastodon.social and I'm completely happy there. If I could move to another instance and take all followers with me I would probably try out to run my own instance, just for me. But as I don't know if I really want to do this for ever. You know, personal preferences can shift, you might have less time, energy, money,... at some point to run your instance. For this reasons I don't feel comfortable trying it out. It was also one of the main reasons why I have chosen mastodon.social, because it is probably the last instance which will shut down. 😉 I don't want to rebuild my community at the new instance and maybe in a few years have to rebuild it again. But also for people who don't consider running their own instance, all public instances out there can disappear at any time.

I'm strongly believe, that for the long-term success of the federated web we need to have some "fault tolerance" for such situations. This can be either complete nomadic identities like for example Hubzilla provides (but what is probably hard to implement on ActivityPub) or an easy way to move, like:

1. Create a new account
2. Link both accounts
3. Tell the system that I moved from A to B
4. The system makes sure that all followers and people I follow are moved (as a minimum). You could think about extending it to moving settings, maybe the last 100 posts to have a smooth transition with the latest content and discussions, etc.... point is to make the move as smooth, complete and automated as possible.

Most people do social networks for the social contacts and for their personal/professional network. Keeping your community and contacts is a important part of the whole "social"-thingy and still one of the main challenges for the fediverse.

[trwnh]

@schiessle Setting the "account moved" flag doesn't move any of your content right now, so the privacy of old posts definitely matters. "If moving would be automated" falls under #177 instead of this issue.

either complete nomadic identities like for example Hubzilla provides (but what is probably hard to implement on ActivityPub)

It's not that it's hard to implement with ActivityPub, it's that this problem falls entirely outside of ActivityPub spec -- authorization and authentication are simply not part of the spec at all. The Actors being passed around are owned by that server, vouched for by that server, and exist solely within that server's domain namespace. See #177 (comment) for more details.