Ok that makes sense I think.
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 isn’t a special Mastodon thing, it’s defined in the w3c Activity Vocabulary standard:
Indicates that the
actorhas movedobjectfromorigintotarget. If theoriginortargetare not specified, either can be determined by context.
So what I’m suggesting seems to be the exact use case Move exists for? The typical Bookwyrm user would have, at most, dozens of Lists, not thousands.
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).
Cool, that makes sense, thanks @silverpill
This is important. Question: Do we have a preferred method to acknowledge user control of a key?
Using something like keyoxide would tie use to using pgp, which might not be an user friendly choice…
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.
This is a great discussion! Do we even need to think about Migrating accounts though.
What about just letting users export their data and import into another instance and just recommending a standardized import/export format for that?
It would avoid issues like having failed migrations, undoing, etc.
Due to user identifiers, i.e. user@instance_domain and https://instance_domain/actors/user, are provide by the instances and every server needs to be informed about this change, a simple import / export is not enough.
Can all that not be addressed at the instance level when user attempts to import?
Then you are back to doing something not straightforward, with a lot of issues regarding if other instances can trust the message, definitely not something I would describe as “a simple import”.
Given all the other issues with imports like “how do we ensure it satisfies the importing instance’s rules?”, you should arrive at the conclusion that the current process is simpler.
If you don’t own your historical data, and don’t own your identifier, which is exactly the case right now, fediverse becomes just a standard for smaller walled gardens to talk to each other to expand their content base. I think this migration problem can be solved by identify proof (fep-c390) and object integrity proof fep-8b32? After that it’s just exporting and importing to a new server/service and let your followers know that you moved.
Yes, FEP-c390 is one way to “own your identifier”. These two posts explain how identity can be managed in the future:
Another way to own your identity is hosting your own instance.
I’m sure I sound foolish, and apologies if it doesn’t make sense at all, but I have a thought last night that’s from a completely different perspective –
We need to prove that account A on server/service X is the same person from account B on server/service Y. DID is a solution that allows you to own and bring your identify around, but I’ve seen arguments about downsides like having a long unreadable ID being user unfriendly and difficulties in ID recovery etc.
What if we just let user identify and confirm their own identity across the servers? Let the accounts do a handshake similar to “follow each other” across servers. As an example, I use account A on server X to identify account B on server Y as myself, and then log into account B on server Y to confirm. Once this handshake is complete, my profile on both servers and accounts will show as:
My user name: chnynf (can be duplicates)
My accounts: chnynf@vivaldi.com; cheny@vivaldi.com; chnynf@mastodon.social (will be unique)
In this case, we avoided creating another ID for all existing users, and users can still benefit from features like password recovery from the services they use. Technically they’re still separate accounts, and we’re simply introducing a feature to allow users say “these accounts are all me” with verification. A person’s identify is tied to oneself in person, rather than the account IDs.
This sounds similar to “Account aliases” feature in Mastodon. It is used for migrations, but maybe one can also build an account recovery mechanism with it.
I feel it would be nice if it can be done outside Mastodon cross-service as well.
I used the word “simple” because other than user verification, it doesn’t seem like there’s much the ActivityPub can provide here. Actual importing/exporting seems like something that should be left up to platforms. Lemmy is already talking about migrating to other Lemmy accounts and how to import/export their data into other Lemmy instances using something like OPML.
Here’s how I see something like this working:
The only thing I’m seeing ActivityPub could build a standard for is step 4, which is already covered in fep/fep-c390.md at main - fep - Codeberg.org. Everything else seems like it should be left up to the platforms using the AP features already available, because only they know how their data is structured.
Interesting. I think a standard export/import format (cross-platform) would be one area where an FEP could be useful, even without a standard account migration process. A JSON-LD graph dump using standard ActivityPub/AS2 representations (possibly with extensions) would be a candidate format. It should be relatively easy to import since an AP instance must be able to process the AP/AS2 JSON-LD/JSON data already.
Different topic, but for item 6, do you mean redirecting just for actor/account requests or also for all the objects attributed to the actor on server A? Are you thinking of something like a 308 Permanent Redirect that would tell remote instances to modify their local URI for the retrieved object?
During data migration the server can simply read activities from old actor outbox and then rewrite IDs. Easier for users too.