From non-portable accounts to portable accounts.
This is literally what “portable” means: your data is not tied to a specific software. FEP-ef61 solves that, and many other problems, including migration from one domain to another.
But again, in order to do this, both the implementation I am moving from and the one I am moving to will need to support that FEP. And my existing user with an already-established ID have no way of ever moving over as the id does not fit. It feels like this would’ve had to be part of ActivityPub from the start to be realistically usable. Also I don’t necessarily want this decentralised ID - I just want to be able to switch the underlying implementation. I don’t mind being “bound” to a domain.
FEP-ef61 portable IDs can be centralized too. When authority is did:key, the server can store the secret key; when authority is did:web, your ID will be tied to a single domain, which can be the same domain as your server’s domain.
Other solutions would require a similar amount of effort from implementers, so why not choose a more powerful one? I don’t see any reason to limit ourservles to 20th century tech stack.
1 Like
At minimum and at present, this means you will have to write an ETL program to migrate from one software’s database format to another software’s database format, then you will have to maintain a redirect mapping at the HTTP server level that keeps track of every single old ID and maps it to the new ID. Depending on the softwares chosen, this could be either “hard” or “extremely hard”.
Something like Mastodon to Pleroma might be possible if you patched Pleroma to support snowflake IDs and not just flake IDs or UUIDs. Your HTTP server would then be able to maintain a wildcard mapping from something like /users/{username}/statuses/{statusid} to something like /objects/{statusid} and/or /notice/{statusid}. Something like Lemmy to Mastodon would probably be a lot harder.
Another option you have is to write your ETL program so that it generates static files that can be served as-is on the same domain. This mostly amounts to a “render once” strategy and then cache forever. This would at least keep old objects from 404ing.
Sure, but that’s not what we ended up with. Also such a URI schema would have to be chosen very carefully because if you’re not careful you could be forcing everyone into a paradigm that doesn’t fit their application. However it is possible to migrate over time to something similar to this (but not exactly like this – .well-known would have several issues that make it a bad idea). In this thread there have been two different proposals cited, one using an ap:// scheme serviced by an HTTPS gateway, and one using DID parameters mapped to an HTTPS gateway.
2 Likes
That’s fair - my main problem is that this (or any other solution) is not part of the specification from the start, so basically a breaking change of the protocol would have to be released for it to actually work like this. It seems like there is no migration path so eventually something will have to break - I do not look forward to that day. It makes me worried as I don’t see the fediverse succeeding if users will need to migrate their accounts from essentially one protocol to another (whether that is AP 2.0 or another successor).
I’m not too worried about such an ETL program. I actually don’t think it would be that hard, depending on the two implementations (I agree Lemmy<->Mastodon sounds hard). I mean the ActivityPub representations of the objects are kinda made to be used as the intermediate format. You store all the AP representations from the old app and load them in to your new implementation. You already have code to handle producing and ingesting the AP representations after all. Certainly there’s stuff beyond the AP representations that you’d need to move over but that would seem to handle the bulk of it.
About redirects: Would redirects even work? I mean if another instance fetches an old migrated ID on my instance and automatically follows the redirect, then from their perspective they would’ve tried fetching, for example, https://domain.example/old/id/path/123 but the object they received has the ID https://domain.example/new/path/to/id/123. An implementation might reasonably include a sanity check to check that the ID of the object received matches the URL followed and if so they would get a mismatch and might just error out. That sounds like it could majorly break federation.
I feel like the only way to do it is to literally keep all the pre-existing IDs and store them as legacy IDs and then new objects can have new IDs. And you’d have to move them with you again if you ever decide to change implementation again. And god help you if you ever get to an implementation that has an overlapping ID path with an old implementation.
That’s a shame, I feel. I think using pre-defined paths would’ve been a lot easier than the “follow your nose” strategy we have now. What exactly is so bad about .well-known paths? The page you linked just calls it an anti-pattern without really saying why (aside from “because it breaks the portability of content across directories and systems” but I don’t really agree with that, since in this situation it actually helps portability or “implementation migration” if you ask me).
How could a pre-defined URI fit badly for an application? Could you give an example? I can see that it forces the use of a specific path but I don’t exactly see how that could be problematic. In the worst case, you would just have to maintain an internal mapping from the pre-defined path to whatever additional information you need to fit your application. That doesn’t seem that bad to me.
1 Like
If an implementation doesn’t support redirects, then they’re failing to support a cornerstone of web architecture. As you point out, it breaks federation to include such a check.
It entirely breaks subdirectories. .well-known needs to be placed at the root of the domain and is therefore unworkable in any multi-tenant domain. You need to “know” ahead-of-time that the “well-known” route exists.
You mean like a scenario where multiple AP servers live in the same domain? How would that even work? Has that ever happened or does it exist currently? It seems like a very fringe case (is it even possible according to the spec?). Are there any implementations out there that support something like that?
Wouldn’t a subdomain be the saner option if you have a multi-tenant domain? Then you can still use .well-known paths for each subdomain.
2 Likes
@trwnh interestingly I learned a while back that apparently friendica (iirc) does support subdirectory installations, where /.well-known ends up being /foo/.well-known which… I don’t know, kinda feels like it breaks the whole notion of .well-known
Honestly the fact that this is impossible is really demotivating me from building an ActivityPub implementation. I could build an implementation but nobody (not even myself) could migrate to it and only new instances/domains would be able to use it. And those new instances running my implementation would be similarly stuck using my implementation, so if I ever decided to not maintain it any more, they’d be lost (or would have to take it up themselves).
3 Likes
I’ll admit I haven’t read the comments in this thread yet, but I thought it might be relevant to point out that Takahē supports multiple domain names on one Takahē server. Is it possible that examining how Andrew did this might provide some clues on how to migrate a set of accounts from one software to another on the same (sub)domain? Also, there’s @macgirvin’s FEPs implementing Zot features like NomadicIdentity, which are all about abstracting accounts away from a hard dependence on domain names. Could that provide some clues relevant to this challenge?
Not that I can see. This is about moving an account to a different server implementation using the same domain that the account owner controls. I recommend reading the thread. It’s been a while since I’ve studied the Takahē source code, but IIRC it has the same issues we’ve discussed previously (e.g., hard-coded URI structure).
Just to clarify, it’s not just about moving users (actors) but also all other AP objects referenced by IDs. E.g. posts and all other activities.
Currently moving from one implementation to another while preserving data is basically impossible.
How is this different from …
Except that I specified accounts, plural.
Uh-huh. What about …
?
Right, I wasn’t clear. By account, I meant all data (including posts and other objects) associated with an account.
1 Like
Can you link this? I can’t find it.
You left out the Takahē context of that phrase. AFAIK, the techniques used in Takahē will not help with the issues being discussed here. The problem isn’t multidomain support (which is a nice feature, for different reasons).
I’m not an expert on Zot but I’ve done some light reading about it. Does Nomadic identity allow you to move a specific actor URI likehttps://mydomain.example/community/me (and all related data) from one server implementation to another (for example, Mastodon to Akkoma)? If not, that answers your “?”.
Please read the thread. Thanks.
I guess @strypey is talking about FEP-ef61. It is not written by @macgirvin, but he endorsed it and implemented it in Streams.
My Mistake. @deadsuperhero reported otherwise;
Mike is already doing the work of figuring out how to retrofit these concepts onto ActivityPub. It’s likely that we’ll see additional Fediverse Enhancement Proposals to accommodate certain needs. For implementers, there are a few existing FEPs in the
DRAFTstage that come recommended:
No, no I didn’t @stevebate. It’s quoted right there, under;
… and above…
Between those two phrases, you will see your words about Takahē;
Physician heal thyself.
Right - I personally don’t think FEP-ef61 is a solution for this problem, especially since it still uses certain paths for the identifiers as far as I understand.
The way to solve this problem in my mind would be to ensure that identifiers carry no information. Identifiers should be just that - an identifier. Nothing more, nothing less. An identifier that carries information (like a domain or a path or whatever) inevitably gets bound to that information. An identifier without information is more free to change any information associated with the object identified by the identifier.
The text you quoted didn’t include Takahē in my browser’s interface (double-checked). But, in any case, you seemed to have not understood what was being discussed. I have tried to get this back on topic, but …
Or don’t read it. It’s up to you. It was a serious suggestion. It will be sad if this ends up being yet another hijacked thread… (muted).
1 Like