I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID.
Uncategorized
13
Beiträge
6
Kommentatoren
0
Aufrufe
-
I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID. (ie, moving it from example.com/1 -> example.com/2)
An Update activity does not allow ID updates because it would lose the reference to the original one. (It can be massaged by using an Origin property, but I don't like that).
Another option would be to use a Move activity (which is defined as moving objects between collections), where the Origin property is the object itself instead of a collection. (I like this behaviour better, as it requires less divergence from the spec)
Is anyone aware of a FEP for that?
-
Is anyone aware of a FEP for that?
@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.
-
@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 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.
-
@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.
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.
-
I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID. (ie, moving it from example.com/1 -> example.com/2)
An Update activity does not allow ID updates because it would lose the reference to the original one. (It can be massaged by using an Origin property, but I don't like that).
Another option would be to use a Move activity (which is defined as moving objects between collections), where the Origin property is the object itself instead of a collection. (I like this behaviour better, as it requires less divergence from the spec)
@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
-
Is anyone aware of a FEP for that?
-
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 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 -
@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/objectsilverpill@mitra.social ah that's pretty clever!
