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.