Portability: A set of design choices, data models, and protocols, that enable an end-user to automatically migrate from one service provider to another with the least amount of data loss and service disruption, including loss of or disruption to the user’s social graph (Followers and Following collections, etc).
We focus on automated migration because the option of fully manual migration always exists, such as re-typing all of one’s messages and content, manually re-adding everyone to one’s following collection, manually contacting everyone on one’s former followers list and asking them to re-follow, and so on. However, that’s an extreme failure state in usability terms; we want to avoid that.
This FEP targets two main categories of migration, covering user stories 1A-1F and 2 + 3 in FEP-73cd: User Migration Stories, respectively. It also draws inspiration from an earlier information document, FEP-cd47: Federation-friendly Addressing and Deduplication Use-Cases.
Note that the data handling and formatting recommendations made here will be strictly complementary to the in-progress LOLA proposal, which target the same user stories.
Most current Fediverse implementations tend to follow a pattern of comprehensive service providers (or instances) that bundle the following concerns into a single service running on a web domain:
This tight coupling of concerns constrains the possibilities for migrating from a live server, and the daunting task of automating migrations to other, less-bundled architectures has yet to be attempted. Its strict reliance on interactive HTTP signatures in concern #2 also excludes migration from a dead server altogether, severely degrading user experience when servers go offline.
For example, a typical current Move Actor implementation (such as the one
implemented by Mastodon,
or specified in FEP-7628)
only assists the user with automatically migrating their Followers list (by
setting up a bi-directional alsoKnownAs links and sending the Move activity
to all of their followers). In addition, some implementations allow the manual
export and re-import of the Following lists, mutes, blocks and bookmarks.
However, important content like posts, media attachments, reactions, reposts and
so on, does not get automatically transferred.
This FEP proposes a roadmap (a set of steps, design concepts, and recommendations) that enables more complete live migrations, as well as enabling migrations from dead server backups.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in RFC-2119.
Separating the object storage provider from the Actor profile hosting provider enables the implementation of Object IDs that can remain unchanged through migrations and export/import cycles. Specifically, we’re looking for Object IDs that remain unchanged even after migrating the objects to be hosted at a different storage provider.
There are several methods of achieving these types of portable IDs, including:
ap:// URI scheme.https URLs that are redirected to their current
location), specified in FEP-e3e9: Actor-Relative URLsAs long as a user’s identity provider’s web domain remains constant, they can migrate to different inbox/outbox and storage providers, without breaking portable links. That is, users will be able to switch hosting and service providers to different domains, without breaking signatures, replies and threading, likes, following and followers, or anything else.
This means that:
https://alice-personal-site.example or https://example.com/users/alice)
can now also be blocked/moderated or accrue reputational weightinghttps://storage-provider.example) might also be worth tracking separately
for some moderation or spam-/sybil-protection use-cases.Exporting an account based on this model segments neatly and brings with it verifiability, if each object was separately signed by a key published in the still-live Actor object. Importing from such a file is trivial to implement compared to today’s account migrations that need to be aware of the data structures and addressing schemes of the previous server.
If the user wants to move their Actor to a different domain, or switch identity hosting services, a future FEP could define this in a simple, Verifiable Credential-style data model containing attestations and proofs that the new actor is equivalent to the old, controlled by the same subject, etc. This would generalize and standardize one currently thorny requirement of interoperable migration, that of authenticating migration requests.
Note: one possible extension of this authentication artefact would be to incorporate “pre-rotation” style commitments of the sort used in distributed key management.
Taken together, these items allow for painless automated migration between service providers, without broken links or effort duplication, and enables restoration from backup and thus migration from dead servers.
Hosted at https://alice-personal-site.example/actor
{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://www.w3.org/ns/did/v1",
"https://w3id.org/security/multikey/v1"
],
"id": "https://alice-personal-site.example/actor",
"type": "Person",
"name": "Alice",
"preferredUsername": "alice",
"inbox": "https://service-provider.example/users/alice/inbox",
"outbox": "https://service-provider.example/users/alice/outbox",
"assertionMethod": [
{
"id": "https://alice-personal-site.example/actor#ed25519-key",
"type": "Multikey",
"controller": "https://alice-personal-site.example/actor",
"publicKeyMultibase": "z6MkrJVnaZkeFzdQyMZu1cgjg7k1pZZ6pvBQ7XJPt4swbTQ2"
}
],
"service": [{
"id": "https://alice-personal-site.example/actor#storage",
"serviceEndpoint": "https://storage-provider.example/users/1234"
}]
}
Things to note:
https://alice-personal-site.example/actor,
but the Inbox and Outbox services are hosted separately, at
https://service-provider.example/users/alice/inboxassertionMethod section, as defined in FEP-521a.service section, which sets up the ability to use Actor-Relative URLs
for mapping (and thus routing) all requests to their current locations at
service providers (see FEP-e939).CC0 1.0 Universal (CC0 1.0) Public Domain Dedication
To the extent possible under law, the authors of this Fediverse Enhancement Proposal have waived all copyright and related or neighboring rights to this work.