I ran into this while working on the ActivityPub plugin for WordPress, and I could not find a FEP that covers it.
Our actor ids used to be built from the permalink, so https://example.com/@handle. The id contains the handle, which means changing the handle changes the id. We are moving to an id that does not contain the handle. The origin stays the same, the WebFinger address stays the same, only the id changes.
FEP-7628 gives me the right signal for this, the Move activity. But the receiving behaviour it describes does not fit. It says a follower should Undo the follow of the old actor and Follow the new one. In my case both ids are the same actor, on the same origin, with the same inbox and the same followers collection. Unfollowing and following again is noise at best, and for an actor that approves followers manually the new follow arrives as a request, so people can quietly lose their followers.
The other migration FEPs do not cover it either, as far as I can see:
FEP-e965 describes the actor object after a migration between personas.
FEP-1580 does allow the target instance to be the same as the source, but only for migrating objects after an actor move, and it requires FEP-8b32 proofs. Here the origin never changes, so the authority over both ids never changes, and there is nothing to prove.
FEP-a427 is a domain move, and its mapping rules (replace the origin, replace a path prefix) cannot express a change from /@handle to ?author=5.
So I would like to write a small FEP that relies on FEP-7628 and describes only this one case. Roughly:
the old id has to stay dereferenceable and carries movedTo
the new actor lists the old id in alsoKnownAs, so the Move can be verified
WebFinger for the unchanged address returns the new id
a receiver updates the id it has stored and keeps the follow, instead of undoing and following again
no object integrity proof is needed, because the origin did not change
What I am not sure about is whether this should be its own FEP or a section in FEP-e965. There are a few migration FEPs already and I do not want to add one just to add one. But the receiver behaviour here contradicts FEP-7628 rather than clarifying it, and that felt wrong to put inside somebody else’s document. Happy to be told otherwise.
It also does not solve the object side. Object ids change on the same origin too, for example when the permalink structure changes, and I have no answer for that yet.
This is indeed a limitation of the “unfollow and refollow” behavior, but that behavior is only necessary because changing the id fundamentally changes the identity. That’s what idis.
I think I’d suggest that “unfollow and refollow” could possibly be handled differently, such as with a rewrite of any URIs, but that would be conceptually different than a Move activity, and also practically different from how actor migrations have ended up in the fediverse.
WebFinger subject staying the same is a red herring; it should not have any bearing on the situation unless the identifier was based on WebFinger.
FEP-7628 gives me the right signal for this, the Move activity. But the receiving behaviour it describes does not fit. It says a follower should Undo the follow of the old actor and Follow the new one.
It's MAY, not SHOULD:
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.
It seems to me that your use case fits FEP-7628.
I was going to finalize this FEP, but can postpone that if you'd like to add something to it
The biggest concerns I have with extending FEP-7628 are:
The title does not accurately reflect the use case. This is not primarily about “Moving Actors”; it is more about changing IDs. Even if these are technically the same operation, developers may not find the FEP based on its current title.
The visibility: Modifying an existing FEP may not provide sufficient visibility. Developers who have already implemented the FEP may not revisit it to check whether there have been changes. As a result, important updates could easily go unnoticed.
@trwnh I generally like the idea of the rewrite, but I think it could break for sites that use the ID both as the ID and the URL and can’t forward all traffic to the new ID. That’s why I like the general idea of a Move!
I definitely get the use case here! Especially for projects that started out with usernames in AP ids, and then later realized that they should use other ids instead so that users can change their usernames.
Having said that, I’m with @trwnh and @silverpill here: id really does define identity in AP, full stop. If we try to design a way to let the same actor (or object) have multiple ids, even as part of a transition, we’re going to have a bad time.
Also, one minor nit:
You probably still do need/want object integrity proofs, at least if you were providing them before. Server-custodial keys are common in AP, but not required. There are AP implementations where the server isn’t quite as trusted, and users retain their private keys and sign their own activities/objects.