FEP-7628: Move actor

Standards Fediverse Enhancement Proposals
,
1

Hello!

This is a discussion thread for the proposed FEP-7628: Move actor.
Please use this thread to discuss the proposed FEP and any potential problems
or improvements that can be addressed.

Summary

Migration of social graph from one ActivityPub server to another.

2 Likes
2

@silverpill Example (activity subtype 2) is addressed a bit weirdly – if it is sent to the server2 followers, then someone following the server1 profile will never see it unless they are also following the server2 profile (in which case the migration is unnecessary)

also, the movedTo and copiedTo are not properly defined with an IRI prefix. for example, mastodon defines movedTo within the as: namespace (unauthoritatively, like a handful of other extension properties).

also, the description of copiedTo is incorrect. it does not indicate a migrated account; it indicates a replicated account (per Zot/Nomad). it doesn’t make sense to do the unfollow-and-refollow flow with a Move when the actor is replicated.

1 Like
3

Targeting old collection is also kind of weird because the old server may not exist anymore.
Account owner is supposed to import the follower list somehow (maybe from a CSV file) before sending the Move activity, so the followers collection on server2 is not empty, it is just not “synced” with other servers.

I’d like to define them in FEP namespace (FEP-888d):

{
  "@context": {
    "copiedTo": {
      "@id": "https://w3id.org/fep/7628/copiedTo",
      "@type": "@id"
    },
    "movedTo": {
      "@id": "https://w3id.org/fep/7628/movedTo",
      "@type": "@id"
    }
  }
}

Is it correct context document?

Un-following is not required (all actors following object MAY un-follow it), but I think (re)following makes sense during replication too.

I can clarify that in “movedTo and copiedTo properties” section.

4

I think the primary audience of Move activity can be set to https://www.w3.org/ns/activitystreams#Public.