FEP-7628: Move actor

[helge]

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.

[trwnh]

@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.

[silverpill]

@trwnh

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)

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.

@trwnh

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).

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?

@trwnh

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.

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.

[silverpill]

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

[underlap]

Another way to move actors between servers would be to make the primary actor independent of any server and then associate a server with the actor. Moving would be implemented by changing the server associated with the primary actor.

The association could be analogous to how email addresses can be associated with email providers: by using a MX record etc. in the DNS for the domain name of the email address.

The primary actor’s domain name would have a SRV record defined in the DNS. The SRV record would point at the server currently associated with the primary actor. To move the actor to another server, the SRV record would be updated. To make this secure, the server would need to be configured with the primary actor analogously to the way an email provider is configured with an email address.

To illustrate the idea more concretely, I defined the following SRV record for the hostname toot.underlap.org:

Type: SRV
Service: _activitypub
Protocol: TCP
Points to: fosstodon.org
Priority: 10
Weighting: 0
Port: 80
TTL: 1 hour

(The service name _activitypub is non-standard and would need to be registered with IANA to avoid collisions.)

An advantage of this approach is that it builds on existing DNS concepts and tooling and should be relatively straightforward to implement (e.g. compared to Nomadic identity).

[silverpill]

@underlap

To move the actor to another server, the SRV record would be updated.

How actor’s followers should be notified about the move? Do they need to query DNS records on a regular interval?

Once a follower is notified, what should it do? Does re-follow mechanism described in FEP-7628 make sense for this kind of migration?

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.

[underlap]

I don’t think the actor’s followers need to be notified because they know the actor by the domain name and this will be dereferenced as necessary.

However, the actor’s followers collection needs to be moved between servers, so updating the SRV record isn’t the whole story.

The option of notifying the actor’s followers and then they, or their server, dereferencing the actor’s domain name and refollowing the actor at its new server seems overly complicated. I don’t know ActivityPub well enough to know whether that would really be necessary.

Edit: In the scenario where the actor’s server is permanently down or the actor is suddenly banned, the actor won’t have an opportunity to either notify their followers of the move or even copy the collection of followers to the new server. But the followers could detect that the move has happened by noticing that the SRV record has been updated, at which point they could (attempt to) unfollow at the old server and re-follow at the new server. Thus, eventually, the actor’s followers collection could be, at least partially, reconstituted (partially, if not all the followers’ servers implemented this feature).

[silverpill]

Maybe I’m missing something, but I see only two possibilities:

• User-controlled domain name is a part of actor ID and this ID doesn’t change during migration (other endpoints like inbox URL also remain unchanged). But in this case you need to update the A record.
• User-controlled domain name is not part of actor ID, but used to link two actors together. This means you need to migrate from old actor ID to new actor ID, possibly by sending Move activity (FEP-7628 is an attempt to describe this process).

[underlap]

It was the first of those possibilities that I was suggesting: the user-controlled domain name is a part of the actor ID and this ID doesn’t change during migration.

During migration, the SRV record of the user-controlled domain name would be updated, to refer to the domain name of the server now hosting the actor. (The actor ID’s domain name would not need an A record as there is no IP address directly associated with the actor ID.)

However, I’m not sure that the inbox URL would necessarily be unchanged. The inbox URL could include the domain name of the server currently hosting the actor. (In fact, if the inbox URL included the user-controlled domain name, that would require the user to host a server too.)

[silverpill]

According to ActivityPub specification, actor IDs must be publicly dereferencable URIs:

Publicly dereferencable URIs, such as HTTPS URIs, with their authority belonging to that of their originating server. (Publicly facing content SHOULD use HTTPS URIs).

@underlap

The actor ID’s domain name would not need an A record as there is no IP address directly associated with the actor ID.

Then your actor ID is not an HTTPS URI? Do you imagine some other kind of URI?

[silverpill]

@underlap

(There could be some wiggle room in the spec as the term “originating server” isn’t particularly well defined, but I think exploiting that would be much too risky.)

I’m exploiting that in FEP-ef61, where DID URLs are used instead of HTTPS URLs. Perhaps something similar could be done with dns: URIs. ActivityPub specification is not strictly followed in Fediverse, and in my opinion minor deviations are acceptable.

@underlap

But it doesn’t seem to rule out other ways for actors to be associated with personas. Would it be helpful to tighten up the definition of association so that it requires linking?

I’m not sure. How would you do that?

@underlap

With that in mind, I’m wondering if linking is transitive. For example, if actor ID K is alsoKnownAs L and L is alsoKnownAs M, are K and M linked? K and M would seem to be associated with the same persona.

Linking via identity proofs and rel-me links is transitive. alsoKnownAs case is more complicated, because often this link goes only in one direction (K → L but not L → K), and Move activity confirms that this link is valid.

[underlap]

@silverpill Based on the ActivityPub spec, I suspect most implementations assume the originating server’s authority is present in object IDs. So extending this is likely to have a broad impact. Wouldn’t that need to be done by revving the ActivityPub spec?

You could tighten up the definition of association by saying “Different actors are considered associated with one persona if and only if they are linked.” However, the asymmetry in alsoKnownAs makes that tricky because the notion of actors being associated with the same persona is clearly symmetric.

[silverpill]

@underlap

Based on the ActivityPub spec, I suspect most implementations assume the originating server’s authority is present in object IDs. So extending this is likely to have a broad impact. Wouldn’t that need to be done by revving the ActivityPub spec?

DID URLs are not supported by any existing ActivityPub implementation, but I think it shouldn’t be very difficult for a server to use two dialects of ActivityPub at the same time.

@underlap

You could tighten up the definition of association by saying “Different actors are considered associated with one persona if and only if they are linked.”

This sounds better. I’ll update the proposal.

[devnull]

Hi all, apologies if this is incorrect, but briefly perusing the FEP draft it looks to be limited to migration of followers only?

It would be ideal if this allowed for migration of content as well, and I think that is a common ask from what I have heard.

[silverpill]

You’re right, this proposal is about migrating followers. The mechanism for content migration was proposed in FEP-ef61

[devnull]

Thank you My apologies.

[silverpill]

Update: #236 - FEP-7628: Update proposal - fediverse/fep - Codeberg.org

I changed the text according to your suggestion @underlap

Also changed the summary and added context.jsonld file for FEP-888d

[silverpill]

#267 - FEP-7628: Push and pull modes - fediverse/fep - Codeberg.org - subtypes of Move activity are now called “push” and “pull” modes.

[bumblefudge]

@underlap

Another way to move actors between servers would be to make the primary actor independent of any server and then associate a server with the actor. Moving would be implemented by changing the server associated with the primary actor.

Hey there @underlap –

It isn’t quite the same as what you’re proposing with DNS records, but our team has been experimenting with a similar model for making the actor “independent” of underlying service providers that manage distinct aspects of the actor’s… entire online existence, like their AP inbox/follower-management, persistence/storage or backup services, bridging to other federations or namespaces, etc. Instead of making the servers of followers check DNS records or otherwise change their behavior and assumptions, we just break out the actor to a different (longer-lived, service-independent) domain controlled by the user, and leave individual properties of the Actor on the domains of the service provider du jour. We think this could work well to detach publication from interaction, i.e. an actor could be hosted on wordpress or sutty or flipboard or any other CMS, with the “comments section” and inbox outsourced to a headless service like GoToSocial, Fedify, etc etc. This separation of concerns debatably just makes explicit an assumption baked into the original JSON-LD actor object syntax, which is basically just a bag of HTTPS URIs, which the original specification never said needed to be on the same domain in the first place!

[bumblefudge]

We also wrote up a FEP that basically “wraps” 7628 (i.e. restates it and is hopefully 100% backwards compatible with it) explicitly stating how Move actor would work with DID-based and/or [domain] “independent” Actors, and also formalizing the as:Tombstone convention for deactivating accounts:

fep/fep/e965/fep-e965.md at main