Saying that you are Moveing your own account to another one is kind of weird, but in the absence of anything else it makes some kind of sense. I’ve just realised that ideally we’ll want to “migrate” some objects that are “owned” by the original user (in Bookwyrm’s case, users are expecting/requesting to be able to move a List, and maybe a Review). The URL will change so I guess that’s a Move and not an Update.
this is something that’s not currently handled or supported. Move in mastodon is handled only for accounts, nothing else. also, objects generally stay on the original server and original account, as there’s no clean way to migrate them over.
i suppose you could extend the idea of Move to apply to any object, but that would imply one Move activity per object. if you have 1000 or 100,000 objects… you can see how that gets to be a lot, very quickly. and there’s no good way to conceptually signal that an “account” Move came with the data or not. there’s no concept of an “account” or “data” in activitypub, there’s just objects.
the closest analogy would be buying a new domain name and moving there – if your old domain’s web server goes down, none of the old domain’s links will resolve. if it stays up, you need an HTTP redirect (301 for permanent, 302/307 for temporary) in order to signal that the content now lives elsewhere. but good luck fixing every single link across the entire web. best you can usually hope for is that the new domain’s web server will respond to all the old paths… if the URI structure changes, then that’s another wrench in the works.
conceptually, the solution to all this is to have persistent identifiers that can be resolved to the current location, then use those for “permalinks” instead of the pretty URL which is simply a redirect to the permalink. but creating and resolving those persistent identifiers is an entire area of research in its own. link rot is a part of any web, especially if there are multiple authorities. all the workable solutions i’ve seen have been to basically centralize on a single name server or data store.
Move is defined in AS2-Vocab but it has no side-effects in ActivityPub. The side-effects (“account migration”) are defined by Mastodon.
If you think it’s worth extending Mastodon’s semantics of Move to cover lists in Bookwyrm, I think you can go for it. It might be something that only Bookwyrm recognizes, though. Somewhat relatedly, you’ll probably have to figure out how or if an actor should move from Bookwyrm to non-Bookwyrm.
For this migration to work, both accounts must be linked to an external identity. Anyone who receives Move activity should verify that origin and target actors have “identity proofs” signed by the same private key. That key is controlled by the user, not the server, so migration can work even if user’s old server is not online.
The mechanism of identity proofs is described in FEP-c390. However, FEP-c390 is still work in progress, and there might be breaking changes in the future (because it depends on other unfinished FEPs and W3C specs).
This was the original purpose of FEP-c390. Cryptographic proof is needed to make independent verification possible. Alice may publish her public key elsewhere (e.g. on a personal website) and Bob can verify that identity proof attached to actor X is signed by that key, meaning that Alice actually uses actor X (otherwise she wouldn’t sign that identity proof). Of course, the proof can be signed with server-owned key too (one that Alice doesn’t control), but Bob can ask Alice to sign arbitrary message to prove that she owns the key.
The purpose of FEP-521a, on the other hand, is to represent server-owned keys. In that case server is the authority, and cryptographic proof is not needed.