Clinton Bowen has submitted a protocol proposal for PDS to PDS Migration @torrho.blacksky.team
Announce thread:
PR into proposals directory:
0014: PDS-to-PDS Repository Migration
Adds proposal 0014: a destination-initiated, encrypted account transfer protocol for AT Protocol that replaces the current client-orchestrated migration model.
User navigates to the destination PDS’s migration UI, authorizes via OAuth, and the destination PDS pulls all account data directly from the source
PDS
Account data (repo CAR, blobs, preferences, private state) is delivered in a single streaming HTTP response encrypted with HPKE (RFC 9180)
Three new XRPC endpoints: exportAccount, completeTransfer, getTransferStatus
A /.well-known/atproto-transferdiscovery document for source PDS capability advertisement
Nice! This sounds similar to how migration and mirroring works in Peergos. My advice from experience there is you want to be able to do it incrementally / resumable, because large account migrations will get interrupted by a network error or something.
I’ll put my longer feedback on the meat of the proposal here:
Big picture: yes! I think PDS migration should be a feature of the “destination” PDS, should use OAuth back to the “source” PDS, and data should flow PDS-to-PDS, for both public (repo, blobs) and non-public content.
Adding account migration UI flows to the PDS reference implementation has been on the Bluesky protocol team roadmap for a while, but we have been prioritizing other work (like permissioned data), and we don’t have a timeline. This is pretty high-stakes (bugs would be very bad) and in the guts of the PDS, so an external PR might be difficult to get reviewed. But it would be great to see other PDS implementations experiment with this.
To echo comments @retr0.id made on the github PR, i’m not sure whether the additional mechanisms of HPKE or a new stream endpoint are needed. I think certainly as a first step all of this could be implemented with the getBlobs and getRepo public endpoints, and those would resolve the more acute issues with blob and CAR file limits on the receiving PDS, transfer would probably be much faster, and the receiving PDS can persist state and resume transfer progress as needed.
This should all work with the various types of “permissioned data”: to me that is a pretty hard requirement for any of the permissioned data proposals (if they store data in the user’s PDS). There are likely to end up being additional auth permissions and sync mechanisms involved. Access ACLs should also transfer.
Whether to transfer app passwords, API tokens (future feature?), or OAuth sessions is something i’d need to think about more. My previous thinking was to not attempt those.
Right now at @roomy.space we’re running the reference PDS and are considering making our own and migrating to it, so if we do that I’d totally want to experiment with that flow.