Account Migration

[bumblefudge]

I think realistically we might be looking at a whole cluster of interlocking FEPs, and if they’re each breaking off a thin layer of the problem, they might be composable enough to work across very different instances. Most of these won’t be finalizable until they’ve been prototyped and those prototypes composed/tested against each other. Which is to say, not an unmanageable project, but a pretty hard coordination challenge without someone serious project management hours getting burnt. Entirely doable, though, and perhaps even in a short span of time if we can all find the bandwidth/budget to move quickly and trust each other and the plan we come up with together.

@mk3

Here’s how I see something like this working:

1. User on instance A exports all of their data (profile, subscriptions, follows, imports, etc) from account 1
2. User registers account 2 on instance B
3. User attempts to import their data to account 2
4. Before accepting the import, instance B verifies that the user actually owned account 1 on Instance A
5. After successful verification, instance B lets instance A know the account has been created and import is complete
6. instance A deprecates account 1 and makes any aliases to redirect all traffic to account 2

The only thing I’m seeing ActivityPub could build a standard for is step 4, which is already covered in fep/fep-c390.md at main - fep - Codeberg.org .

I think Step 4 is far from the only FEP worth writing here, but the cross-dependencies get complicated real quick. I have been thinking that a number of different topics coexist under the vague heading of “migration” and here is my list, slicing things as thinly as possible into the maximum number of things I can imagine being a FEP (perhaps many are not worth FEPing or worth combining, but thinnest atomic unit is a classic Project Manager exercise):

• Data model for how Server A exports profiles, subscriptions, follows, etc
• Parsing rules for ^ making explicit what Instance B does with that data model, including entries and objects it does not support
  • e.g., does it store in a persisted export file to merged into future export file if they later want to move to Server C, which does support them? how does that export file get linked to or concatenated to the future export file? etc.
• Protocol/interface for Instance B checking Instance A for valid account
  • Note: if this protocol could take a dependency on per-account key material, such as on FEP-521a, this gets a lot easier. Could just be a wellknown/did-web pattern, Instance A could sign import request, etc etc.
• Protocol/interface for Instance B telling Instance A import was succesful and can tombstone
  • note that there should be a FEP-521a section, since key material must also be tombstoned/redirected…
• Server A behavior and data model for “tombstoned” accounts, including redirects
• Location-indepedent Content-storage (e.g. “just put all uploads on IPFS” or equivalent self-certifying URI scheme) and protocol for layering “upload export/import” to the above (i.e. instance B can fetch and pin all CIDs it finds in export file if Instance A includes them in export)
• As this comment points out, there is a crucial moderation layer in export/import-- most instances wouldn’t want to import data unless they had a way to re-moderate that content or search through records of prior moderation against a known schema (assuming they even have resources to do so, or a way to bill the importer for that resource spend…)
  • excellent prior art here

</ takes project manager hat off and collapses into an exhausted puddle>