I’m considering setting up my own single-user (or possibly family and friends) instance of a lightweight AP server such as GotoSocial or Mitra (other recommendations welcome).
However, I’d like to be able to switch server software in the future if I find something I like better.
I’ve read (in the GtS docs) that this can cause major federation problems.
I wonder if it would be possible to switch if my server is hosted on a subdomain (social.example.com, etc), even if the handles use the root domain (@me@example.com). Or would it still be problematic?
What exactly is the cause of the problem (different signing keys?) and is it something I could work around (eg manually copying the keys from one DB to the other)?
I don’t know if it’s an issue with those two specific servers, but in general, the problem is that many server implementations force a URI path structure. So, the actor URI https://social.example.com/users/me on one server might need to be https://social.example.com/actors/me or https://social.example.com/me or https://social.example.com/88A706C8145F4341917FE8A93AF380B8 (as examples) on another server.
Thanks for the reply @stevebate. Hmm, yes, I can see that would be a problem – but if the server was not on the same (sub)domain as the acct URI / webfinger endpoint, would that still be an issue?
I guess if servers actually store the resolved actor URI instead of resolving the acct URI via webfinger each time, it would be a problem. I wonder if setting up a 301 redirect would be enough to solve it.
Another thought: I wonder if sending a Move activity would work in this case (to update the saved actor URIs) even though the new and old acct URIs are the same?
Uh-oh, you just surfaced a corner-case that had NEVER OCCURED TO ME before. Hmmm. The way this FEP is written, it would technically work to “move in place” but it would be quite hard to guarantee/assure that followers on other servers would handle the circular announcement activity the way you want them to-- depending on how they structure their own records internally, this might make for all kinds of corner cases or failures. Probably safer not to create weird (potentially invisible or difficult to diagnose, much less realize you need to patch) behavioral bugs for other instances, even if this is a clever idea that should work on the happy path?
Indeed, I also assumed it would be a fragile edge case – though the FEP does indeed seem to suggest that it should work in theory.
It would be quite interesting to test a few different platforms and see how they handle it…
As @stevebate pointed out, if you change the software, your new account will likely have a different ActivityPub ID, in that case you will lose your old identity.
You may encounter additional issues, but they will be implementation specific (inefficiencies and bugs of all kinds). Likely there will be authentication failures caused by changed signing keys, but eventually other servers should update their caches.
Thanks all for the replies. It sounds like this is indeed a bad idea. It’s a shame though, as particularly for small or single-user instances, being able to change server software seems like a really desirable feature.
I wonder what changes would be necessary (perhaps at a spec level) to make this possible?
I guess if nomadic ID gets widely implemented that will make it possible?
Some implementations use same URI templates, so switching should be possible without losing identity. For example Mastodon, Pleroma and Mitra use {instance}/users/{username} template for actor IDs (bad practice by the way, it prevents people from changing usernames).
I think seamless switching can be achieved without nomadic IDs, but experience with nomadic identity would push developers into adopting software architectures that enable portability.
Would redirects not be good enough? Or at least should they not be enough? I feel like it should be, even if they aren’t currently.
Or maybe instead of doing redirects, you preserve all the old paths but the JSON you return is updated. That unfortunately means that you might GET an actor with one URL but the ID you get back is another URL (because the actor ID has changed).
In general, I think this is quite a big problem honestly. I don’t think it’s realistic to expect any ActivityPub site to stick to the same implementation forever. ActivityPub implementations come and go, or just evolve over time. Restricting anything to be completely static and unchanging is cumbersome and just a plain bad way to model reality. Nothing is ever static like that forever.
Yes, I think redirects can be used to solve this particular problem. A redirect from one ID to another ID is enough to prove that two objects are clones if their IDs belong to the same server (have the same origin).
However, redirects are not enough when objects are located on different servers, hence the search for a generic solution (i.e. nomadic identity).
I 100% agree – and in fact, the fact that there is a barrier to switching in future is honestly the only reason I am not running my own server yet.
Is there a reason why in the case of changing usernames the server wouldn’t simply send a Move to the new actor ID? (And presumably also maintain a redirect from the old URLs to the new ones.)
Yea this seems infeasible the longer I think about it and even if you do have redirects, other implementations may not behave well when an ID changes. But I don’t see a way to fix it since ActivityPub using URLs as IDs is just such a fundamental part of the protocol.
The more I think about URLs as IDs, the more I think it was just a super bad idea. I just don’t see a way to migrate from one implementation to another if IDs are like that. I’m starting to wonder why ActivityPub didn’t just use a /.well-known/... path so that all implementations use the same paths for Activities, which should make it simple to change implementations.
Is there a way around this problem without having literally thousands upon thousands of redirects (and even that might not work)?
The general idea is that you can have the canonical ID be made up of two parts:
A pointer to some service (the exact service is variable)
A relative reference to be appended to the target of the redirect from part 1.
Ideally the ActivityPub server needs to be aware of, and assign IDs against, the canonical part. This identity providing authority component should be longer-lived than the ActivityPub server itself and can be reused independently of the AP server.
But that’s the whole problem. There’s so much freedom in defining the identifier that changing from one implementation to another will almost by definition have different identifiers that will not be compatible.
Also I don’t see how this fixes anything unless both the implementation that you’re moving from and the one you’re moving to supports this FEP (which sounds unlikely).
But the implementation I am moving from and to still need to support this no?
I am the admin of Feddit.dk, a Lemmy instance. Let’s hypothetically say that I and all the users of Feddit.dk decide that we like Mastodon more than Lemmy, so we want to switch to Mastodon. This seems completely impossible at the moment and I don’t see a way that Lemmy or Mastodon could support this in the future, seeing as their current IDs are already the way that they are. But it feels like a long-term social protocol such as ActivityPub ought to support an easy way to change the underlying implementation.
There’s also the problem of implementation willingness. Why would the Lemmy or Mastodon developers support a feature for migrating from their platform to another platform? It doesn’t help anyone actually using the platform.
This seems like a major use case gap in ActivityPub and I don’t see a way to fix it backwards-compatibly. To me, it seems that Feddit.dk is stuck with Lemmy forever whether I like it or not.
Developers can start offering portable accounts and motivate users to migrate. This process will take many years, but it is something that can be done. Portability is a feature that is desired by many, especially power users and those with large followings, so either it will be implemented, or ActivityPub will be abandoned in favor of ATProto or Nostr because these protocols already have it.
As long as they support HTTP redirects and the abstract concept of a storage service or personal data repository, then it should be fine. Note that we are not there yet. But we could be there in a few years, probably.
It’s not really a problem in ActivityPub, it’s a problem with web architecture in general. You need a layer of indirection to solve it. If you want to stick to web architecture, then that’d be either with PURLs or with DID parameters service + relativeRef through an HTTP redirect or gateway. To remote implementations, it would look just like any other HTTPS URI. That’s probably the most “backwards compatible” way to do it – make the actor into a DID and have it be served by an HTTP server capable of redirecting according to the appropriate query parameters mapping to DID parameters. There is also the more breaking change, which is to migrate to a scheme other than https: and force everyone else to come along for the ride.
I’m not sure what you’re proposing here - migrate where? This topic is about changing the underlying server implementation on the same domain. There is no migration from one domain to another. This has nothing to do with nomadic identities or portable objects - actually all the objects should stay in the same domain, just the underlying implementation should change. Again, I see no migration path for already-established IDs.
Ideally, I should just be able to shut down my current implementation, migrate the database over to the new implementation (and that part will probably not be trivial but let’s say it can be done) and then start the new implementation and other instances will be none the wiser and will just have noticed a little bit of downtime from my domain, but nothing else.
But this doesn’t help already-set IDs right? Like my user on Feddit.dk has the ID https://feddit.dk/u/SorteKanin. I don’t see a way to change that, ever. The whole point of an ID is after all that it identifies someone and that it doesn’t change.
I don’t think so. If ActivityPub didn’t use implementation-defined URLs as IDs, then it would be much easier to switch implementation.
For example, imagine that all activities, actors and objects and such all get a UUID as their ID instead (or maybe a UUID + a domain, either way). To fetch an actor/object/activity you simply fetch https://domain.example/.well-known/ap/{uuid}. Then I can easily switch implementations because all implementations would use this ID scheme because it is set by the protocol, not by the implementation. I wouldn’t need to use any redirects because the URLs for all implementations would be the same.
But again, this isn’t baked into the standard so the implementation I am moving from and to doesn’t support this. Are there any implementations that do it this way?
