AP: add account migration (Move) support

[snarfed]

This is largely outside the AP/AS2 specs. Mastodon docs, AS2 Move activity spec, @manton's great blog post.

[StarrWulfe]

Came here to +1 this though.

➕1️⃣

[snarfed]

Interesting, @tantek reports that migrating from Mastodon to Bridgy Fed already works! https://tantek.com/2023/112/t2/account-migration-post-blog-archive-format

[snarfed]

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.

[lstaples3]

I would like to +1 on this feature as well. I’m more interested in migrating from Bluesky to fediverse.

[snarfed]

From @qazmlp in #1046 (comment) :

It's just my two cents, but it would definitely be nice for Bridgy Fed to support migration (of followers at least, though converted data exports would be "nice to have" where that's feasible, maybe better as a largely separate service).

Off-migration would give some assurance for people that they wouldn't lose their connections if something goes wrong with the bridge (short of a sudden long outage, at least) and symmetric1 migration between networks would enable much greater mobility of experience, so to speak.

I'm not sure fully symmetric migration is actually possible, though, due to potential protocol differences… On Bluesky, is it possible to "merge" multiple accounts into one through migration? On ActivityPub, that is the only supported migration option.

[snarfed]

@qazmlp True! Migration is a great feature request. Big project though!

By symmetric migration, I assume you mean migrating a user-controlled AP account to a user-controlled Bluesky account, or vice versa? Agreed, that's even more difficult, and largely outside Bridgy Fed's scope.

I don't think you'll be able to merge Bluesky accounts like AP does, since repos being structured as Merkle search trees, they expect them to be immutable, and hashes from those trees used externally in other repos and bits of the network architecture. I guess you could merge two existing accounts into a new account, but that's getting pretty hypothetical.

[qazmlp]

@qazmlp True! Migration is a great feature request. Big project though!

Yes, definitely. (And sorry, hadn't seen this issue.)

By symmetric migration, I assume you mean migrating a user-controlled AP account to a user-controlled Bluesky account, or vice versa? Agreed, that's even more difficult, and largely outside Bridgy Fed's scope.

Not necessarily as one-step process, but let's say it's possible to migrate off the bridge on either network but onto the bridge only on Bluesky. In such a case, that would create an imbalance where users could effectively move their social graph from ATProto to AP but not back (if they convert their data export offline and import their follows on the AP-side, since restoring outbound relationships that way is a common feature there).

In practice, on-migration is much easier to implement than off-migration in AP, though, of course, since the "old" account there handles authentication and must send out the Move to all followers.

I don't think you'll be able to merge Bluesky accounts like AP does, since repos being structured as Merkle search trees, they expect them to be immutable, and hashes from those trees used externally in other repos and bits of the network architecture. I guess you could merge two existing accounts into a new account, but that's getting pretty hypothetical.

I should have been more clear: I'm strictly talking about signalling a change to followers, to move them to an already-existing account without removing the existing followers there. Since it's seemingly possible to change between did:plc and did:web without losing all followers, merging may be possible on Bluesky too.

I have no idea how handle changes work on Bluesky, though, or which direction is more difficult to implement there.

[snarfed]

Ok!

I'm strictly talking about signalling a change to followers, to move them to an already-existing account without removing the existing followers there.

Yeah, this doesn't exist at all in Bluesky right now. The goal with the protocol is that you can change PDSes, handles, etc without needing to do this.

It's theoretically possible, I guess, with new PDS operations that you'd need to get everyone to implement, but I wouldn't hold my breath.

Since it's seemingly possible to change between did:plc and did:web without losing all followers, merging may be possible too.

Really? That's not possible that I know of. Where did you hear that, out of curiosity?

[qazmlp]

Really? That's not possible that I know of. Where did you hear that, out if curiosity?

Several people I follow switched from @*.bsky.social to their website as handle, but I suppose that's not actually a did:web.

Edit: Found the documentation, yeah I misunderstood this.

[elfprince13]

There's a subtle variation on this, which is "migrate Mastodon/Fediverse followers to Bridgy without apparent change in handle" (for users who control the instance they are migrating off of).

I think this basically requires (a) setting the custom handle (b) telling Bridgy about the existing followers so that it knows who to push posts to (c) NOT telling existing followers to unfollow/refollow (d) taking old instance offline.

[snarfed]

@elfprince13 it's possible to preserve handle, but with the fediverse ecosystem right now, it's not usually possible to preserve actor id, ie identity. Mastodon and some other AP implementations currently require that actor and object ids are on the same host that serves them. (AP doesn't require this; it's an unfortunate design choice those projects have made.)

In other words, you can happily redirect mumak.app's Webfinger to fed.brid.gy, and that may let you keep your @elfprince13@mumak.app handle, but under the covers, your actor id will need to change from https://mumak.app/users/elfprince13 to https://web.brid.gy/ap/mumak.app, which will be a new identity, without any of your existing posts, followers, or other content. So we'd still need the usual Move migration.

[qazmlp]

GoToSocial documentation (for good measure): Actor Migration / Aliasing

---

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.

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. ↩