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)

#ActivityPub #fedidev #ActivityPubDev

Is anyone aware of a FEP for that?

#ActivityPub #ActivityPubDev #FEP

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

LOLA Portability for ActivityPub (0.2)

(swicg.github.io)

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

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)

#ActivityPub #fedidev #ActivityPubDev

Is anyone aware of a FEP for that?

#ActivityPub #ActivityPubDev #FEP

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

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

@mariusor