migrating between PDSes (time limit)

[monicaellerose]

Not sure exactly how to phrase this or if this is the right discussion channel for this topic - but ill do my best

One thing I've noticed is limited discussion on being able to deactivate accounts.

When migration becomes a feature (aware it doesn't exist yet), will migration have a time limit set, or can a user export their account for a period of time weeks, or months, and then migrate it (re import it)?

For safety and security reasons (and international reasons), if that hasn't been considered, I hope it can be.

[bnewbold]

Good question!

The short answer to your question is that there will be no time limit on migrating accounts. This is baked-in to how the protocol works. If you do a repository export, you will be able to re-import that at any time as long as you still have control over the account identity.

A couple more specifics:

• there will probably be a "smooth account migration" workflow where both servers cooperate and transfer content directly, with no need to download and re-upload the repository. that process might have a timeout if something goes wrong. but it will also be possible to do the manual transfer, if you have (or can find) an export of the account, even if your old service does not cooperate or doesn't exist (eg, shut down or got corrupted)
• handles (domain names) can change over time, but the identity of an account is rooted in the DID identifier (which is not shown often but looks like did:plc:yk4dd2qkboz2yv6tpubpc6co). With did:plc (the default for Bluesky), it is possible to permanently delete the DID, and after a recovery time window (a few days), it becomes impossible to recover the identity. if somebody went through with a full hard account delete, including the identity (DID), then it would not be possible to migrate or recover the original account. the export could be used to set up a new account, but all the old follower relationships, likes, replies, etc would be lost

Being able to deactivate an account, without actually shutting it down or deleting the content, is something we are thinking about adding. the core feature would be the ability to toggle whether the account is active or not, and have that propagate through the network/ecosystem, without destructively deleting data. This should be easier and less scary than doing a manual export / delete / re-import.

[monicaellerose]

incredible answer!! thank you for taking the time to reply, I appreciate it. I am super happy to know it isnt being overlooked, and potentially with multiple methods is excellent!!

[aendra-rininsland]

Thank you for putting thought into this, I really think it's important for users to be able to temporarily deactivate during e.g. harassment campaigns.

Follow-up question, given the above, would you consider putting some sort of authentication on the com.atproto.sync.getRepo method? It seems otherwise someone could call that using any of the multitude of repo-related tools that exist (one of which is mine) in order to obviate the "deactivating" functionality (to be honest, I was really surprised when I learned how that works, and I think most people I've mentioned it to were as well).

[bnewbold]

I would imagine that when we implement account deactivation, com.atproto.sync.getRepo would be a 403 (or similar status code) for anybody trying to export that repository. With the possible exception of the account itself, but we might implement a separate endpoint for the "backup/migrate my own content while account is deactivated" use case.

Authenticating that endpoint in general would touch on the ability to do permissionless antagonistic interoperability between service providers, which we think is a pretty important part of the atproto social contract.