Changing the underlying server implementation of an ActivityPub server on the same domain raises significant questions, particularly around data migration and maintaining established identities. This isn’t about domain migration or nomadic identities, but rather a fundamental shift in the server infrastructure while keeping everything else consistent for users and the wider network. The core challenge lies in ensuring a smooth transition without disrupting existing user IDs and connections.
Ideally, the process should be as straightforward as shutting down the current server, migrating the database to the new implementation – acknowledging this data migration step might be complex – and then launching the new server. The goal is for other instances in the Fediverse to perceive only a brief downtime, with no other disruptions.
However, the current system of implementation-defined URLs as IDs presents a major obstacle. Consider a user on a platform like Feddit.dk with an ID like https://feddit.dk/u/SorteKanin. Changing the server implementation could potentially alter how these IDs are managed internally, leading to inconsistencies. The very nature of an ID is to be permanent and unchanging, so how can we reconcile server changes with this principle?
Perhaps the issue stems from ActivityPub’s reliance on implementation-specific URLs for identification. What if the protocol adopted a more abstract approach? Imagine if all activities, actors, and objects were assigned a UUID (Universally Unique Identifier), possibly combined with the domain. To retrieve an actor or object, a standardized URL structure like https://domain.example/.well-known/ap/{uuid} could be used.
This approach would drastically simplify server implementation changes. All implementations, regardless of their internal workings, would adhere to this protocol-defined ID scheme. Switching servers would become more seamless, eliminating the need for complex redirects because the URLs would remain consistent across implementations.
However, this UUID-based ID system isn’t currently part of the ActivityPub standard. Neither existing nor new server implementations inherently support it. Are there any ActivityPub server implementations that are pioneering such an approach, utilizing UUIDs or similar abstract identifiers to facilitate easier server migration and decoupling from implementation-specific URLs? Exploring such solutions could be crucial for the future evolution and flexibility of the ActivityPub ecosystem.
