> When migrating between systems, this difference presents a problem.
How does it break anything? ActivityPub ids can be any URI. You dont need to migrate your original rest-style links to anything - just publish those as the ids...
And if you are going in the other direction (and why would you), then I cant think of a single app router that ENFORCES you to use rest-style routes. It may be encouraged with many, but its certainly not enforced.
> Can the framework function in most of the ways we’d expect from a modern web framework, but with every URI being a UUID?
URIs should already be unique. You can use those...
> These requirements suggest that the framework would likely be content based, rather than route based
ActivityPub objects contain the type, so thats ALWAYS going to be the case to reliably use 3rd-party ActivityPub objects. As for locally-sourced objects, you can still use your rest-style URIs and use those URIs as the ActivityPub ids!
I think that's the conclusion that TFA reaches also. However the premise it was started from is how Mastodon and Mastodon-likes do not do that.
> so thats ALWAYS going to be the case to reliably use 3rd-party ActivityPub objects.
From Mastodon's point of view there hardly are any '3-rd party' objects. Mastodon wants to store the whole world locally (which is one of the pain points that its admins find out sooner or later) instead of using the web as it was intended and saving shallow copies of remote objects that get refreshed when users want to access them. :(
Say I migrate my ActivityPub server from ProductX to ProductY, but I want to keep all the usernames and external follow relationships intact.
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"?
> I want to keep all the usernames and external follow relationships intact
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).
That will just work for any new software which follows the move mechanism built into Mastodon. Not all do still, but it's fairly new. When I moved from mastodon.social to my own instance, about ~80%-90% of my followers automatically migrated. Most of the ones left were on older version of Mastodon, and some non-Mastodon servers like Misskey.
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).
Yes, you can. You will need to have both running at the same time if you want to use the built in migration mechanism in Mastodon (assuming the new software supports it), and so will need to ensure the URL space does not collide, e.g. by giving one of them a different hostname and adding an alias to the webfinger response.
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.
Sorry, by "same server" what I actually meant was the same domain. As far as I can tell there's no support for migrating Activity Pub content between software on the same domain.
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.
> Sorry, by "same server" what I actually meant was the same domain.
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)
Why does the new server need to have a new url structure? Why do the URLs need a "structure" anyway? That's what TFA and OP are actually saying.
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.
[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.
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.
But it doesn't matter what each software does because the necessary endpoints are defined in your actor object linked from your webfinger entry. That's the only endpoints the user agent is supposed to see and use.
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
Maybe true with endpoints in the actor object, but clients should be able to refresh any object from its URI at any time, I believe this is a spec requirement rather than just advised, although I could be wrong.
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.
This would be "interoperable" in that it's easy to go from one framework/software to the other, but it's still not transparent. The current way of doing things is to use the url of the object in the search bar, and thus use the search bar as the "new" url bar. In practice it is more interoperable because all softwares then behave the same.
You're right, you can, and it works. E.g. my Mastodon id is @vidar@galaxybound.com, but my Mastodon server is hosted on m.galaxybound.com. The webfinger on galaxybound.com is just a redirect. In addition to redirecting the webfinger query, the webfinger results themselves can point to an inbox etc. elsewhere.
How does it break anything? ActivityPub ids can be any URI. You dont need to migrate your original rest-style links to anything - just publish those as the ids...
And if you are going in the other direction (and why would you), then I cant think of a single app router that ENFORCES you to use rest-style routes. It may be encouraged with many, but its certainly not enforced.
> Can the framework function in most of the ways we’d expect from a modern web framework, but with every URI being a UUID?
URIs should already be unique. You can use those...
> These requirements suggest that the framework would likely be content based, rather than route based
ActivityPub objects contain the type, so thats ALWAYS going to be the case to reliably use 3rd-party ActivityPub objects. As for locally-sourced objects, you can still use your rest-style URIs and use those URIs as the ActivityPub ids!