Track migrations of bridged (ActivityPub) accounts

[Tamschi]

I thought about this again, and it occurred to me that it would be nice if Bridgy Fed supported a third Move situation in addition to the on- and off-ramp for bridging where:

• Neither the object nor target Actors is a bridge account.
• object is bridged to one or more other networks.

Here's a sketch on how that could work:

1. Fetch target with low allowed staleness (a minute?) and verify its alsoKnownAs.
   Stop here if that property doesn't contain object.

For each remote networks which object is bridged to.

2. For remote networks that don't support follower-transfers (Bluesky), ensure target is not currently¹ bridged there.
   Otherwise, stop here for that remote network and alert both object and target of this via DM.

3. Attempt to Follow target with the instance actor representing the remote network.
   Only proceed once Accepted. (Maybe by using the Follow's ID to distinguish it from ones for other tasks.)

4. Associate the bridge account on the other network with target internally.
   At this point, target should be considered bridged while object is now unbridged.

5. Update the remote network:

   1. If target wasn't bridged to the remote network prior to 4. and the remote network supports handle changes, change the handle of the bridge account from object's to `target''s.
   2. Otherwise, if the remote network supports transferring followers and target is bridged to there, transfer followers from object's bridge account to target's there.

6. Undo-Follow object with the instance actor representing the remote network.
   Don't check if that works, just consider object not bridged (moved) at this point.

7. If followers were transferred in 5.ii., mark object's bridge account as moved to target's if the remote network supports it.

Originally posted by @qazmlp in #330 (comment)

Footnotes

1. Using the normal Move flow on ActivityPub, where the user imports all follows before Moveing the followers in order to check out the new instance, it's likely that both are bridged here already.

   The DM should instruct the user to, in order to successfully transfer the identity on e.g. Bluesky, unbridge target immediately, then reissue the Move once the Move-cooldown on object has expired. Since that tends to be long (30 days on Mastodon), also consider slowly (daily or with backoff?) looping a failing 2. for a few days while (the refreshed) object.movedTo still points to target. ↩

[Tamschi]

In addition to what's laid out in the original comment, Bridgy Fed would also need to follow/unfollow on the remote network to synchronise the follow set with that of target. There should probably be instructions that suggest importing follows before moving the account, to avoid visible noise in that regard.

The profile would also have to be updated.

Not sure what to do about existing content. Maybe the best solution would be to let it linger and provide DM commands to delete specific posts and/or date ranges (the latter with confirmation)?

I'm labelling this as compat since AP Moves and AT handle changes are currently used for the same purpose, i.e. to change an AP handle you currently have to Move the account's followers. Similarly, the only way to "keep" followers on AT is to change the handle while preserving the did:.

[snarfed]

Interesting! This would be a very comprehensive approach to supporting AP Moves, but it definitely makes sense.

It seems like this and #330 would both try to preserve object's bridged accounts and re-associate them with target. Is the main difference that you expected #330 wouldn't also try to migrate bridged followers? Or something else?

[Tamschi]

They are disjoint. Quoting you from #330 (comment):

Also, to clarify, this issue only covers migrating an existing fediverse account to/from a Bridgy Fed bridged fediverse account, eg a web site or (eventually) Bluesky account bridged into the fediverse.

Meanwhile, this issue here is only about migrations that happen entirely outside Bridgy Fed, without involving a bridge account on the ActivityPub side.

[Tamschi]

This also needs to bypass the spam filter rules for the target account.