I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID.
-
@mariusor it's not easy; the ID is really where the thing is, as well as what it's named.
We have some work going on it; try LOLA.
-
@evan I understand that, but at the same time, HTTP contains all we need to make sure these changes get tracked.
1. Move activity is disseminated, so downstream instances are aware of the new ID.
2. Instances/clients/user-agents making use of the old ID get redirected through HTTP to the new ID, and they get the new resource with only one extra request if that.Sounds simple to me, but maybe I'm overlooking something.
-
@evan from what I can see the document you proposed handles the difficult cases where the move is done across servers.
I'm thinking of something simpler, same instance move.
-
mariusor@metalhead.club yeah that's basically it, but as far as I know no servers support it.
Mastodon, for example, will support an update that changes a user's preferred username, but on the backend a new user is created. Not quite ideal but they're hamstrung on some db decisions they made early on tying preferred username to the URL.
-
@mariusor yeah, there's an issue on w3c/activitypub about this, it's been there for few years I think? This is a problem with JSON-LD in general too
-
-
silverpill@mitra.social mariusor@metalhead.club here's a dumb question... What happens when my software with no idea of the concept of nomadic identity, encounters an object with an
ap://protocol? -
@julian It dies. @silverpill @mariusor @evan
-
-
@julian Hopefully nothing, the object is ignored. It may also crash :)
We use a different kind of identifier to keep portable objects compatible with ef61-unaware implementations:
https://social.example/.well-known/apgateway/did:example:abcd/objectwhich works like a regular HTTPS URL, but ef61-aware implementations treat it as equivalent to
ap://did:example:abcd/object -
silverpill@mitra.social ah that's pretty clever!
