Flexible URI structure in AP Server Implementations

Isn’t this basically the same as what was discussed here? I personally don’t think FEP-ef61 is a solution and the idea of just redirecting to all the old content using the old URIs is not really feasible - even if you do that, you could still run into a situation where your old implementation and your new implementation have overlapping URIs and then you’re out of luck.

What I’ve basically concluded from this is that the freedom to choose any URI an implementation wants as IDs for objects was a mistake. It would’ve been much better if all implementations were required to use a .well-known path. Then all paths across all implementations would be the same. So if I have a user on domain.example then its ID could (for example) be https://domain.example/.well-known/ap/users/58b5cbaf-069b-4ee8-bdb2-3c0d381ac8ce or something like that - and if I changed my implementation, it would be the exact same path after the change.

This design choice of ActivityPub can’t really be changed in any backwards-compatible manner, so unfortunately I don’t see any realistic path forward where this will ever be feasible. I gave up on my own ActivityPub implementation effort once I realized this as I see it as too much of a dealbreaker.

Hopefully some AP 2.0 or spiritual successor will one day fix this, but that seems very, very far away indeed.

1 Like