FEP-7952: Roadmap For Actor and Object Portability

Warning

このFEPはまだ翻訳されていません。

ここから翻訳に協力することができます。

Summary

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.

Migration from a live (cooperating) server

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.

Migration from a backup/export produced by a dead (or non-cooperating) server

Current Approaches

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:

  1. Identity hosting (hosting of the Actor profile object, which serves as the source of truth for all others in the list)
  2. Authentication and authorship/provenance of objects
  3. Key management (used for HTTP Signatures for Server to Server request authentication)
  4. ActivityPub Object and Collection storage (typically in a database)
  5. Message Transfer Services (hosting of inboxes and outboxes, delivering of outgoing objects, notifications, etc)
  6. Instance-based content moderation
  7. Community discovery (via the instance's Local feed)
  8. Front-end clients, i.e. “website” and/or mobile app (most current implementations bundle the backend system with a made-for-purpose front end that runs off the same server)

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.

Roadmap For Portability

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.

1. Unbundle the services and concerns of a typical instance

  1. Sign everything: Recognize client-side cryptographic signatures as proof of authorship, in addition to the current practice of relying solely on the instance URL:
  2. add verification key(s) to the Actor object via FEP-521a
  3. Sign individual activities using the same key(s), as specified in FEP-8b32: Object Integrity Proofs
  4. B.Y.O. Actor ID: Using Object Integrity proofs enables Identity Hosting to be separated from the other instance concerns. Actor profiles can now be hosted separately from the instance, which in turn enables service providers to offer their users a “BYO (Bring Your Own) domain name” feature.
  5. Separate Inbox/Outbox: (Optional) The previous steps enable message transfer and Inbox/Outbox hosting to be outsourced to separate service providers (the Actor profile links to these in the usual manner).
  6. Separate Object and Collection hosting: (Optional) Similarly, AP Objects and Collections can now be stored on domains separate from the Actor's domain (since authorship and controller-ship can be proven cryptographically, in a domain-independent way). This enables the user to migrate storage service providers without having to change their Actor ID.

2. Implement Portable (migration-stable) Object IDs

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:

  • FEP-ef61: Portable Objects, which introduces a new ap:// URI scheme.
  • Actor-Relative URLs (regular https URLs that are redirected to their current location), specified in FEP-e3e9: Actor-Relative URLs
  • Various content-based identifier schemes (such as IPFS CIDs, Named Information Hashes, etc.)

As 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:

  • Object and Collection hosting can now be extracted to general-purpose storage providers that are on different domains than the Actor profiles
  • Actors can migrate between different storage providers without changing the Actor id and url.
  • Moderation actions gain additional features for fine-grained handling of services distinct from individual objects:
  • Individual Actor IDs can be blocked/moderated, as is currently possible
  • Actor profile providers (in the example above, https://alice-personal-site.example or https://example.com/users/alice) can now also be blocked/moderated or accrue reputational weighting
  • Object-hosting or inbox providers (in the example below, https://storage-provider.example) might also be worth tracking separately for some moderation or spam-/sybil-protection use-cases.

3. Create account export/import features that assume Actor-Relative URLs and segmented services

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.

4. Enable verifiable Actor URL migration

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.

End Result: Stable, migration-aware distributed data

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.

例

Example 1: Standalone ActivityPub Actor Profile

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:

  • The Actor profile's URL is hosted on https://alice-personal-site.example/actor, but the Inbox and Outbox services are hosted separately, at https://service-provider.example/users/alice/inbox
  • The assertionMethod section, as defined in FEP-521a.
  • The 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.