Skip to content

FEP-7628: Move actor

by silverpill silverpill@firemail.cc submited on 2023-09-20

Summary

Migration of social graph from one ActivityPub server to another.

History

Move activity is defined in Activity Vocabulary.

Mastodon started using Move activity for migrating accounts in 2019. The activity is sent by the old server to actor’s followers and actors who receive this activity un-follow the old account and follow the new account.

Streams implements Nomadic Identity mechanism, that makes identity independent from a server. Nomadic accounts are currently not supported by ActivityPub but are available via the Nomad protocol.

Requirements

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC-2119.

Linked actors

One persona can be represented by one or more actors. Different actors are considered associated with one persona if they are linked. Possible ways to link actors:

  • alsoKnownAs property of an actor object. This method is used by Mastodon.
  • FEP-c390 identity proofs. Actors are linked if they have identity proofs with the same subject property.
  • rel-me links. Actors are linked if their profile metadata contains verified rel-me links pointing to the same website.

Migration

Among actors associated with a persona, there MUST be one primary actor. Migration of an account means the change of a primary actor.

Move activity

Move activity is used to notify other actors about the migration. It MUST have the following properties:

  • type: the type of activity must be Move.
  • actor: the actor performing the migration.
  • object: the old primary actor ID.
  • target: the new primary actor ID.

The activity is considered valid if object and target actors are linked.

Upon receiving valid Move activity, all actors following object MAY un-follow it by sending Undo(Follow) activity and MUST either send Follow activity to the target or otherwise notify the user that their contact has moved.

This activity comes in two sub-types:

  1. Move sent by the old actor. In this case, the old server needs to be online.
  2. Move sent by the new actor. In this case, the old server doesn’t need to be online, but the person using the actor SHOULD have a reserve copy of the follower list.

Example (activity subtype 1):

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://server1.example/activities/9b496346-fa69-40ac-bc4e-7ac06192abe1",
  "type": "Move",
  "actor": "https://server1.example/users/alice",
  "object": "https://server1.example/users/alice",
  "target": "https://server2.example/users/alice",
  "to": "https://server1.example/users/alice/followers"
}

Example (activity subtype 2):

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://server2.example/activities/9b496346-fa69-40ac-bc4e-7ac06192abe1",
  "type": "Move",
  "actor": "https://server2.example/users/alice",
  "object": "https://server1.example/users/alice",
  "target": "https://server2.example/users/alice",
  "to": "https://server2.example/users/alice/followers"
}

movedTo and copiedTo properties

If previous primary actor is deactivated after migration, it MUST have movedTo property containing the ID of the new primary actor. Publishers SHOULD NOT deliver activities to actor’s inbox if movedTo property is present.

If it is not deactivated, copiedTo property MUST be used.

References

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.