Implementation portability (switching implementation on the same domain)

[SorteKanin]

Hi, I hope this is the right place to discuss this.

There's recently been a discussion on socialhub.activitypub.rocks about switching from one ActivityPub implementation to another on the same domain. This has led to a lot of concerns being raised that basically makes it sound like this is impossible. This makes me quite worried about the future of the current ActivityPub servers, as they are likely bound to a single implementation forever. This seems bad, see also my comment here.

The current draft has a Domain Portability section which suggests that a simple backup/import flow of switching implementations should be possible. I like the vision of such a simple process but it is clearly not possible today. The final point of the section lists the problem:

Different implementations may use different URI patterns for activities or content.

This is the crux of the issue. How is it ever going to be feasible for an ActivityPub instance to change its underlying implementation without breaking IDs of all of its activities, actors and objects? ActivityPub implementations aren't just allowed to use different URI patterns, they are downright almost guaranteed to do so. If IDs change, other ActivityPub implementations will probably be (justifiably) confused.

This is quite a big problem I think honestly. It’s not realistic to expect any ActivityPub site to stick to the same implementation forever. ActivityPub implementations come and go, or just evolve over time or get forked or whatnot. 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, not even actor/activity/object IDs.

But how can this be solved? URLs as IDs is a very ingrained property of the ActivityPub protocol. Changing how it works seems infeasible. Is changing underlying implementations of ActivityPub servers just not possible then? Was using URLs as IDs a bad idea?

[bumblefudge]

Was using URLs as IDs a bad idea?

Maybe? I think the JSON-LD style of URI design kind of assumes everyone has complete control of both new and old domain apexes and will design in 300 and 301 redirects and all that... and I think there was a deliberate decision in 2018 to leave API design and paths out of scope and leave all flexibility to implementers (partly to avoid potentially infinite bikeshedding and to have something to ship before the clock ran down!).

I think this is an important question even though it's not quite in current scope of the data- and account-portability we signed up to work on here. That said, I'm inclined to keep the issue open as a reminder to come back to it when we have v1s of our current-scope work items, as the implementation of what we're working on will make thinking about "upgrade paths" (to support new features we're designing) and migrations easier and more topical.

I would also note that some of the contributors here in this task force have proposed a "long-lived" URL scheme for content that hangs on a separation of concerns between an actor object (easy/cheap to self-host) and swappable implementations (favored by C2S designs and closer to email's IMAP/POP3 swappability).

[lisad]

I believe that LOLA can and should be used for a certain kind of solution to this. From the outside, it's impossible to tell if a new domain or a new path is a new server or not, so LOLA can equally be used to signal a change in URL even if the data "moving" is actually only changing URLs and/or using a implementation-specific tool to import bulk content.

I can update LOLA to make this a LOT more clear and to highlight which things would need to be done and which wouldn't in order to successfully appear like this from the outside.

[bumblefudge]

^ Add an appendix: "Using LOLA to re-path or re-organize object IDs" 😎

[SorteKanin]

I believe that LOLA can and should be used for a certain kind of solution to this.

I'm not familiar with LOLA but from what I understand, you're saying that an idea might be to send some kind of move signal out to other servers letting them know that the user that previously had the ID https://my.domain/users/123 now has the ID https://my.domain/u/321? And you'd do the same with every single other object on the server? Or am I misunderstanding what you meant?

Just to be clear, I'm not talking about moving instances between domains, I'm talking about a single domain changing its underlying implementation (as an example, say a Lemmy instance changed to become a Mastodon instance using the same domain).