We need external people who follow @me@myserver.example.com seamlessly still follow at the new server, which has a different code an URL structure. Will it "just work"?
ActivityPub doesnt have the concept of a "username" in the sense that you are thinking. An activitypub "preferredUsername" field is just a preferred display name for that actor. Instead they have actor ids - which are just URIs.
Behind the scenes, mastodon (and similar) simply treat @me@myserver.example.com as a webfinger ref. They do a lookup via webfinger which returns the actor id, and then they connect to that URI to return the respective object(s).
Of course, because your mastodon instance is also likely hosting your actor AND its respective collections AND its activities, then ALL the URIs are ALSO tied to their domain. In order to "migrate" they (probably - im not 100% sure) send updates for your actor object (and your other activity types) to your outbox and distribute to your followers, who will then update their own references to your actor, its aliases (such as the webfinger ref), and other associated collections and activities.
Its 100% possible to have a webfinger alias on your own domain and use separate hosts for your actor, specific collections, and each individual activity, should you wish. Mastodon can reach other activitypub actors and activities configured in this way, but it cant provide a similar service for its own users, due to its current implementation (it expects to be the originator of activities for its associated actors).
What does not migrate currently is your old posts. If you control the target server, you do get a dump of your old posts and you can import them with some effort, but it's not automated. E.g. in my case, if you go to [1] you can see my old posts and a notice from mastodon.social that I have moved. The 40 followers remaining on that account are the few followers who either have not moved or have manually followed on my new account but not bothered to unfollow on my old.
Moving the posts have a few issues. One concern the Mastodon devs have that I don't agree with is that it might make it easier to "fake" your history. But you can trivially do that if you set up your instance anyway, and the exported posts are signed so they could check the signature on import, for what little benefit that'd give. The other is that anyone who have linked to the old posts would link to the old site. Fixing that (e.g. with redirects) would potentially require a mapping. It's doable, but would require a new mechanism (e.g. an activity posted from the new server telling the old server of the new URLs after import - the mechanism for the old server to know the new server is where you're moving is already in place).
If you are going to migrate software on the same server you'd likely be in a better place if you just generate static pages from the Mastodon export for the actual posts after doing the follower migration.
If you're outright replacing the Mastodon server you might get away with just importing the followers as well, as long as the software you're interacting with is well behaved and do webfinger lookups. You can improve on that by ensuring the inbox url stays the same, worst case with a redirect.
Mastodon can move accounts only, and requires different domains. Mastodon's import/export can help with content assuming you're moving to another Mastodon instance, but won't do anything to update the URIs of content objects in other instances databases. Webfinger redirects can be used to move accounts across domains too.
However as far as I can tell there's no way to move arbitrary Activity Pub objects across domains.
There's nothing stopping it on the same domain either, as long as there's no conflicting URLs. It'll be harder to do "online", and may result in a bunch of redirect rules, and it definitely ought to be easier, but nothing prevents you from doing it.
But there's little reason to do that, because what users interact with your account by is the webfinger address, which can point to whichever hostnames you like. So you can migrate to a server on a different hostname, and then redirect the webfinger from your main domain name to the new host name, no problem at all.
> Mastodon can move accounts only, and requires different domains.
Using the built in move functionality, you'd run into that if you insist on never having the servers referenced by different hostnames. But if you're keeping it on the same domain that you control, you can "just" migrate the data. It could absolutely be made more convenient, sure.
> However as far as I can tell there's no way to move arbitrary Activity Pub objects across domains.
Define "move" here. You can't cause other instances to update their references, so if you can you'd want to leave redirects in place. You can however just move the objects over. It'd be nice if you could announce an update for the links as well, but since you can't avoid "external" links from places that don't federate at all, this will never be perfect.
That said, the Note activities are signed, so can be served up from another domain and can still be verified as long as the old pub-key can be obtained from the original URL or is cached by a trusted third party. But this is not a problem for the hypothetical scenario I replied to, as whether you keep it on the same hostname as you clarified you meant, or put it on another hostname as I suggested, nothing prevents you from maintaining the old posts as static content on the original hostname, so you don't need to move those objects. You can at least conceptually include them in your outbox so they're visible as part of the timeline (though I suspect that would either require a change to Mastodon if you insist on running Mastodon, or including them as "boosts"/ "Announce" activities instead of posts if you change the hostname)
Mastodon - partly due to the fact that it predates federating through ActivityPub - doesn't have the concept of URL as a unique identifier for an object (in the ActivityPub sense), but uses numeric ids, or uuids in some places.
If you really want "a structure", I wonder why nobody is implementing ActivityPub services[1] using the simplest and dumb way of mapping objects in storage using their ids.
Ie: an actor has the ID https://example.com/user1, therefore it's inbox/outbox should be https://example.com/user1/inbox|outbox. Then, an activity created by that user can be found at https://example.com/user1/outbox/{unique-activity-id}. If the activity is a Create (the only ones with a side effect of creating an object), then this object can have the id https://example.com/user1/outbox/{unique-activity-id}/object, samd.
[1] My own fediverse software does this for multiple types of storage: filesystem hierarchy, k/v store, database tables, but I haven't seen anything else similar.
> https://example.com/user1/outbox/{unique-activity-id}
This isn't actually the simplest way, and is what makes it hard to move between software. Mastodon might use /userid/outbox/activityid, GoToSocial might use /users/<id>/posts/<id>, and so on.
The "simplest" way to do this is to treat the URLs as the ids themselves, which is what the Activity Pub spec defines. This should be the most interoperable.
Now if you're saying the ActivityPub spec is tragically underdeveloped, sometimes on purpose it seems, and doesn't define actually useful stuff but leaves it "to the particularities of implementations" then I fully agree with you
As for Activity Pub lacking clarity, I do completely agree, it's going to be years before we have a good understanding of what the spec actually necessitates in production implementations.