AP: add account migration (Move) support

@manton

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

Came here to +1 this though.

➕1️⃣

@tantek

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

@t

[tantek] added "Add details of my experience migrating from xoxo.zone/@t

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.

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

@qazmlp

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.

@qazmlp

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

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?

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.

dms.migrate_to: call check_can_migrate_out first

dms: add protocol-specific migrate-to commands for AP, ATProto

test_dms: use lower level mocks for tests for migrate-to ActivityPub …

add integration tests for migrating out to ATProto and ActivityPub

migration: move activitypub.NeedsAlias, move MAIN_PDS_DOMAINS from dm…

web UI: add account migration to settings

migration: move activitypub.NeedsAlias, move MAIN_PDS_DOMAINS from dm…

web UI: add account migration to settings

migration: move activitypub.NeedsAlias, move MAIN_PDS_DOMAINS from dm…

web UI: add account migration to settings

web UI: misc UI tweaks for migrate out

launch migrating out!

Done! https://blog.anew.social/migrations-update-launch/

Navigation Menu

Repository navigation

AP: add account migration (Move) support #330

20 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

AP: add account migration (Move) support #330

Description

Activity

StarrWulfe commented on Jan 9, 2023

snarfed commented on Apr 23, 2023

snarfed commented on Feb 23, 2024

lstaples3 commented on Feb 24, 2024

snarfed commented on Jun 18, 2024

snarfed commented on Jun 18, 2024

qazmlp commented on Jun 18, 2024

snarfed commented on Jun 18, 2024

qazmlp commented on Jun 18, 2024

20 remaining items

snarfed commented on Jun 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions