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