Bluesky: support account migration

[snarfed]

Specifically, let people migrate an existing Bluesky account into BF to become a bridged account, or an existing bridged Bluesky account out of BF to become a normal Bluesky account that they can log into and use.

Big project! AP corollary is #330. Background:

• https://atproto.com/guides/overview#account-portability
• https://docs.bsky.app/blog/self-host-federation#account-migration

[tesaguri]

Is the plan to allow using an atproto data repository as a bridged account and a "normal" account at the same time, or is it going to be mutually-exclusive, that is, you won't be able to manually write your own atproto records into the data repository while it's used as a bridged account?

[snarfed]

There isn't a plan for this yet, it's honestly pretty unlikely, but if it does happen, it'd be the latter. I definitely don't plan to support bridged accounts that can also be used "manually" like normal accounts.

[snarfed]

Now that goat can migrate Bluesky accounts, this might already be possible. I'd love to hear how it goes if anyone wants to try!

Sadly the "easy" way requires logging into the source PDS, which Bridgy Fed doesn't support, but the "manual" way doesn't: https://whtwnd.com/bnewbold.net/3l5ii332pf32u#:~:text=Manual%20Account%20Migration

[rossabaker]

I haven't tried it, but I'm studying the fire escapes. The part of the manual process that looks most troublesome to me is:

Retrieve the token ($PLCTOKEN) from email, then request a signed version of the PLC params:

# old PDS
goat account plc sign --token $PLCTOKEN  ./plc_unsigned.json > plc_signed.json

I don't think BF has our email? Would this step need to be exposed as a command to the bot, both to avoid the login and to get the token delivered?

[Tamschi]

[…] Would this step need to be exposed as a command to the bot, both to avoid the login and to get the token delivered?

Yes, I think that's the case. I'm not sure this is feasible to do via DM, since most software doesn't let you attach arbitrary files there.
Maybe if fetching the "recommended" DID parameters from the new PDS doesn't require authentication, then Bridgy fed could get that file directly.

Alternatively, I think Bridgy Fed could expose a recovery key to the user for them to sign the PLC operation offline.
I'm really not sure how to look for instructions on that, though, and how it integrates in this process here.

[snarfed]

Yes! Thanks, you're both right.

For now, if anyone wants to do all of the manual migration steps up to the PLC DID doc update, I'll happily do that update manually. After that, if there's enough demand for this, I can implement the methods that goat needs to do it automatically.

[Tamschi]

cc @alien-sunset I'm not sure if you're subscribed here, but would that work for you?
This way you could take control of the current bridge account on another PDS and post to it directly when botsin.space shuts down.

[alien-sunset]

Thanks, but I’ve already set up a new account and coded the bot to post directly to Bsky (which took way too long, I am NOT a good coder 😅)

[Daft-Freak]

IDK if I'm missing something, but the manual method seems to also require logging into the source PDS pretty much immediately.

[snarfed]

@Daft-Freak try logging into the destination PDS instead?

The bsky.social PDS doesn't yet support migrating accounts into it, and I haven't set up a separate PDS myself to test, but it's possible that it could work!

[Daft-Freak]

Yeah, it definitely needs a token from the source PDS, generating one from an account on the dest results in: error: failed to create account: XRPC ERROR 401: AuthenticationRequired: Missing auth to create account with did: [...]

(I'm not in any rush to actually do this, mostly just curious about the possibility)

[snarfed]

@Daft-Freak just to confirm, this is on a self-hosted PDS, not the main bsky.social one, right?

bsky.social doesn't allow inbound migration right now, but supposedly self-hosted PDSes should...

[Daft-Freak]

Yep, self-hosted PDS.

[snarfed]

Interesting! cc @bnewbold, I doubt that's expected. Is there maybe a setting you need to enable on the PDS to allow creating new accounts as deactivated?

Assuming this error is on the goat account create command, I don't think there's anything I can do about this on Bridgy Fed's side, that command is going to your PDS. It needs to allow creating new accounts.

Maybe paste in all of the commands you ran, including eg goat account login and goat account service-auth, without passwords and tokens, and we can look?

[bnewbold]

The "smooth" account migration path is described here, basically documenting what goat does internally:

bluesky-social/atproto#3176

It requires a number of endpoints implemented on the "old" PDS:

• com.atproto.server.getServiceAuth: used in first steps so that client (eg, goat) can "prove" to new PDS that it is the account in question. if the old PDS doesn't implement or is offline, the client needs control of the identity (DID document) and could generate such a proof locally (using the atproto signing key in the current DID document).
• com.atproto.server.checkAccountStatus: probably not really required on the old PDS, but is mentioned in migration guide
• com.atproto.sync.getRepo: for CAR export
• com.atproto.sync.listBlobs: enumerates all the blobs; client will pull from this list, then download each with getBlob
• com.atproto.identity.requestPlcOperationSignature: for DID PLC, this is a request to generate a signed PLC op (using old PDS rotation key), for the case where client doesn't have control of the identity (DID document). sometimes this requires a secret token, eg delivered via account email.
• com.atproto.server.deactivateAccount: as a final step on old PDS

All of these are authenticated methods, so also require login and session endpoints.

I think bridgy pseudo-PDS does not support a bunch of these, and maybe doesn't make sense to? Eg, password login/auth.

Some of the full-offline mechanisms (like self-signing a "service auth token") are important for the unavailable-old-PDS flow, but are not yet implemented in goat. This is a good reminder to get around to implementing those and documenting that migration process.

[bnewbold]

I created an issue to track the later functionality in goat here: bluesky-social/indigo#864