I just realized that the default specifications for ActivityPub/ActivityStreams do not have a way to perform an update on an object's ID.

[evan@cosocial.ca]

@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.

https://swicg.github.io/activitypub-data-portability/lola

[mariusor@metalhead.club]

@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]

@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.

[julian@community.nodebb.org]

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.

[thisismissem@hachyderm.io]

@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 Move is used for migrating actors from one ID to another: FEP-7628. It can be used for migrating objects too, but I don't think it's practical.

FEP-ef61 solves the problem by making identifiers portable.

[julian@community.nodebb.org]

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?

[adiz@mtl.jinxian.casa]

@julian It dies. @silverpill @mariusor @evan

[mariusor@metalhead.club]

@adiz @julian I think the general behaviour is that your user-agent (client or browser) tries to find an application that can understand that protocol and delegate to the user if nothing is found.

@silverpill

[silverpill@mitra.social]

@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/object

which works like a regular HTTPS URL, but ef61-aware implementations treat it as equivalent to ap://did:example:abcd/object

@mariusor

[julian@community.nodebb.org]

silverpill@mitra.social ah that’s pretty clever!