6 ms·

Ok, since everyone's here, I'll ask: what is the credible exit from Bluesky - as in, not ATProto as a whole, but specifically the Bluesky PDS/AppView/etc - righ

Ok, since everyone's here, I'll ask: what is the credible exit from Bluesky - as in, not ATProto as a whole, but specifically the Bluesky PDS/AppView/etc - right now, in 2026? I have a Bluesky identity that I registered primarily to follow someone that I happened to meet in person while stumping for the Rio Grande Plan[0]. I only have like five posts on it, but I would like to migrate that over to the same domain I already self-host Mastodon on. Bluesky has an option to have your handle on a custom domain, but that involves publishing a DNS record containing a did:plc whose keys are custodially owned by Bluesky. This is not so much an exit as it is an overcomplicated verification scheme. My assumption is that if Bluesky wanted a better credible exit than ActivityPub, then we would need some way to rotate keys so that I could have my own PDS publish new posts on my existing identity and have other AppViews recognize that as the same kmeisthax that was previously using Bluesky as a PDS. The Mastodon exit is woefully inadequate, but at least if the admin cooperates, you can redirect your account and export your data. Everyone else on any other ActivityPub instance will see the same thing. As it currently stands, ATProto has a great way to migrate between AppViews[1], but no way to migrate off an uncompliant PDS. [0] The Rio Grande Plan is a citizen-led movement calling for burying the heavy rail corridor going through Salt Lake City. [1] ActivityPub is actually really lousy at cross-app interaction. If you're on a Mastodon instance, there is no way to participate in a Lemmy forum. Mastodon does not understand how to send the correct ActivityPub messages that Lemmy expects; and there's no protocol for Lemmy to tell Mastodon to publish certain ActivityPub messages on its behalf.

jimmydoe 3mo ago
Google did:web
- kmeisthax 3mo ago
  There is no mechanism to migrate a did:plc identity to a did:web one (or vice versa). The DID string is morally an SQL primary key.
jsmith45 3mo ago
The PLC keys are normally intended to be held by your current PDS. Not a hard protocol requirement, but without it, certain things like migrating to a custom domain handle cannot be done cleanly though the app, and would need to be done manually. It might be a requirement of the bluesky hosted PDSes though, as those have some extra requirements beyond the reference self-hosted PDS. The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere. If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process. See https://atproto.com/guides/account-migration https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.
- kmeisthax 3mo ago
  This more or less answered my question in exactly the way I was dreading. The option to register and manage PLC rotation keys should be built into the Bluesky Appview itself, sitting right next to the existing option to verify a domain with your did:plc string. Having the option only exist as a command line tool means most people aren't going to use it and third-party PDS hosts are going to be a pain in the ass to use for people with data already on Bluesky's PDS. I'm also not happy about the existence of the PLC directory at all, mostly because it's not really explained all that well in the Bluesky interface. I assumed PDSes were just identified by their domain name (like a Mastodon instance is) - and while that is an option with did:web, it's not the default option, and you cannot migrate an identity between PLC and DNS governance. Hopefully that will change.
kyle-rb 3mo ago
If you don't like BlueSky managing your keys, the alternative to did:plc is did:web. Unfortunately, afaiu, it's not possible to migrate[0]. If this is something you really care about, and you trust yourself to manage your own private keys, you should probably bite the bullet and do it now. Make a pinned post on the old account to point to the new one. That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc. Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free. Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back. [0] https://github.com/bluesky-social/atproto/discussions/2705 https://github.com/bluesky-social/atproto/discussions/2705 [1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did` [2] https://atproto.com/specs/account#pds-account-migration https://atproto.com/specs/account#pds-account-migration [3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...

jimmydoe 3mo ago

Google did:web

kmeisthax 3mo ago
There is no mechanism to migrate a did:plc identity to a did:web one (or vice versa). The DID string is morally an SQL primary key.

jsmith45 3mo ago

The PLC keys are normally intended to be held by your current PDS. Not a hard protocol requirement, but without it, certain things like migrating to a custom domain handle cannot be done cleanly though the app, and would need to be done manually. It might be a requirement of the bluesky hosted PDSes though, as those have some extra requirements beyond the reference self-hosted PDS. The fact that BlueSky runs the PLC central server is supposed to be fixed by them creating a swiss association to run and control it instead, but while they announced this, it is unclear if it went anywhere. If you migrate to a self hosted PDS using the all-in-one migration `goat account migrate` command, it will temporarily change your handle to a subdomain of your new PDS, and leave the new PDS managing the PLC. You can instead perform each step manually via goat or raw API calls, either of which would let you transition to direct PLC key management, and/or a new domain based handle as a single atomic plc update, as part of the overall migration process. See https://atproto.com/guides/account-migration https://atproto.com/guides/account-migration for a discussion of the process at the protocol level. See https://whtwnd.com/bnewbold.net/3l5ii332pf32u https://whtwnd.com/bnewbold.net/3l5ii332pf32u for a breakdown of both the automated, and step by step process via `goat`. It does not go into the details of switching to self managed, but it basically requires crafting your new PLC document, sending that one to the old PDS to sign, and then submitting the result. There are manual PLC signing, and submission commands available as `goat plc` subcommands, for use once you have manual control.

kmeisthax 3mo ago
This more or less answered my question in exactly the way I was dreading. The option to register and manage PLC rotation keys should be built into the Bluesky Appview itself, sitting right next to the existing option to verify a domain with your did:plc string. Having the option only exist as a command line tool means most people aren't going to use it and third-party PDS hosts are going to be a pain in the ass to use for people with data already on Bluesky's PDS. I'm also not happy about the existence of the PLC directory at all, mostly because it's not really explained all that well in the Bluesky interface. I assumed PDSes were just identified by their domain name (like a Mastodon instance is) - and while that is an option with did:web, it's not the default option, and you cannot migrate an identity between PLC and DNS governance. Hopefully that will change.

kyle-rb 3mo ago

If you don't like BlueSky managing your keys, the alternative to did:plc is did:web. Unfortunately, afaiu, it's not possible to migrate[0]. If this is something you really care about, and you trust yourself to manage your own private keys, you should probably bite the bullet and do it now. Make a pinned post on the old account to point to the new one. That's the one part you can't migrate; everything else you can change while retaining your followers, posts, etc. Setting your handle to a domain name via DNS[1] is intended to be easy for non-technical users (especially with registrars adding one-click forms for doing so) and also decoupled from actual PDS hosting. Many users just want their handle to reflect their identity on the web, and are ok trusting BlueSky to host their PDS for free. Migrating to a new PDS is possible in both the cooperative case[2] or in the adversarial case[3]. The gist is that A: you should take regular backups by exporting your account data, and B: if you're using did:plc instead of did:web, you should register a backup key that has a higher priority than the key held by your PDS, so a malicious PDS can't simply migrate you back. [0] https://github.com/bluesky-social/atproto/discussions/2705 https://github.com/bluesky-social/atproto/discussions/2705 [1] Alternatively there's an option for HTTP handle resolution instead via `/.well-known/atproto-did` [2] https://atproto.com/specs/account#pds-account-migration https://atproto.com/specs/account#pds-account-migration [3] https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migration.html https://www.da.vidbuchanan.co.uk/blog/adversarial-pds-migrat...