Mastodon: Suggest following new account whenever a followed account moves

[ThibG]

Since 2.1.0, Mastodon displays and federates information about migrated accounts.
However, end-user followers of a migrated account are not notified of such changes.

Followers should be notified in some way, suggesting them to follow the new account and unfollowing the old one. But I currently have no idea how that should be presented to the user.

---

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.
• [ ] This bug happens on a tagged release and not on master (If you're a user, don't worry about this).

[Gargron]

The idea is to make the unfollowing & re-following automatic. The challenge is that the process needs to be authorized by both old and new account and followers need to be able to verify this. So like having two signatures or something like that...

[Gargron]

Something like: old account generates Move activity and sends it to new account. New account sends back Accept->Move (signed). Old account adds own signature to that, and sends it to followers..? Or would it have to become Announce->Accept->Move? It's getting a bit weird. Paging @cwebber

[ThibG]

While a completely automatic process is a worthwhile goal, it's going to be a massive pain to get right, specify and implement properly.

On the other hand, if we can figure out the correct interface for it, the suggestion approach can be deployed right now, take care of accounts that have already been migrated, require no further specification, and have the advantage of letting the user know what's going on and give them a chance to check that the account migration isn't fishy.

[Sylvhem]

I don't know if it's technically possible, but one way to do that would be to have people receiving a notification when an account they are following have migrated. It would look something like "[email protected] has migrated to [email protected]. Do you want to follow this new account? [Button to follow]". It'll require to create a new type of notification though.

[ThibG]

That would be possible and that seems reasonable. However:

• That's a new notification type, which may cause issues with clients
• That would require a rake task or something to issue notifications for previously-migrated accounts

[Sylvhem]

Is the last point really mandatory? If it's too much of a burden to implement, I don't know if it's really worth it.

[ThibG]

Nah, it would just be better to not miss out on the old migrations. And I don't think that point would be very difficult to write.

I may try to work on this if @Gargron doesn't oppose to the idea.

[ThibG]

@Gargron I still think we need something that doesn't require additional protocols, even if it's not entirely automatic as a result. Indeed, what about accounts that already moved on? Accounts moving from an unmaintained server that won't support the new protocol? There are many cases where the ideal fully-automatic idea isn't applicable.

I think we need to implement either a new type of notifications (but that may break existing clients depending on how they handle notifications) or a new API endpoint entirely (but I'm not sure how to display the information then…)

[trwnh]

If this gets implemented as such, I'm in favor of a new notification, and explicitly against forcing any un/follow behavior. Forcing unfollows can make previously-visible followers-only toots hidden. Making account redirects automatic is more in the domain of #177 anyway.

[ThibG]

Good point about automatically unfollowing. As for for automatic follows, I'm pretty much in favor of them but it does require some more work (both in spec and implementation), and requires the cooperation of both the person is moving from and the one they are moving to.

[skylerbunny]

If I understand how a 'redirect' works, can't this be handled on the server side without user intervention at all? In other words:

1. User sets up a redirect from [email protected] to [email protected]. They have moved.
2. An instance like mstdn.jp, checking for new toots from [email protected], the followers of [email protected], or...(whatever) runs into the redirect set up in (1).
3. If the reason [email protected] appeared in a query is because it was saved somewhere in mstdn.jp's database (which is why the query in (2) happened), overwrite it with [email protected], and make the query to the new server.

Why think about it this way? Well, sooner or later, somebody "Important" is going to appear on a Mastodon instance, who has 1M followers, and will move to a new instance. It would probably be extremely valuable if instances of [email protected] can be seamlessly changed to [email protected] without any user interaction at all. The real question is, assuming a 1M follower moved, what would the impact be in today's federation? What's ideal?

I'd guess that minimizing the number of redirects that any one server has to handle minute to minute is a good thing to do. So a server encountering a redirect should (IMO) point to the new location, and KEEP that new location, so it doesn't have to keep encountering the redirect - if it doesn't already happen that way.

[skylerbunny]

(Apologies if the above is either out of scope for this question or was answered long ago. I had a hard time finding documentation of how an account redirect is actually handled in the 'documentation' repository by name, and in the code here, so I really didn't know where to look.)

[ThibG]

The redirect is just an attribute of the Actor, that is, instances with multiple followers will only receive the message once.

Mastodon doesn't currently do anything with it other than disable new follows on the old account and put a banner showing the new one.

If it were to automatically follow the new account, though, the new instance would receive 1M new follows in a very short timeframe.

[skylerbunny]

_If it were to automatically follow the new account, though, the new instance would receive 1M new follows in a very short timeframe._

Yeah. If it didn't automatically follow accounts from a redirect, then there would probably be a curve of manual refollows that goes like 300K (first hour), 100K (second hour), 50K (next four hours) and taper off. It wouldn't actually prevent that load from happening; it would just change the nature of it.

If it WAS done automatically, just thinking out loud, it would seem like a way to do this might be to capture a UNIX timestamp at the moment a user sets up a redirect, and then batch 'follow here instead' automated notifications to accounts both on and off that instance in groups of say, 10,000 at a time, saving accounts/instances that don't respond to retry them later. When that notification is received, it changes the follow from the old to the new account, and uses the UNIX timestamp payload from earlier to determine toots that should be pulled from the new account's timeline, so the following user doesn't miss anything.

I'm not sure the best way to go, though I suspect that the only reason this hasn't become a 'fix it fix it right now' crisis is that no one migrating user has yet been large enough to cause one or more instances to grind to a halt because of the load it causes (whether it's a 'manual' or 'automatic' fix of a redirect) . That time will probably come though, as Mastodon grows.

[stevenroose]

I think we need to implement either a new type of notifications (but that may break existing clients depending on how they handle notifications) or a new API endpoint entirely (but I'm not sure how to display the information then…)

Wait, what??? Clients break when a new type of notification is introduced??

If this gets implemented as such, I'm in favor of a new notification, and explicitly against forcing any un/follow behavior. Forcing unfollows can make previously-visible followers-only toots hidden. Making account redirects automatic is more in the domain of #177 anyway.

I'm in favor of two config variables: (1) automatically follow new account when an account you follow moves (default: true) and (2) automatically unfollow the old account (default: false).

Another thing to keep into account here is what if an account gets hacked and the hacker migrates. I think having a 7-day delay on a migration wouldn't be overkill. Or at least an option to delay migration of your account (of course with a 7-day delay to turn it off). While someone (1) migrates or (2) turns off the delay, Mastodon should display a permanent warning in the interface.