Stop putting `actor` on non-Activity objects #770

New issue

Open

opened 2024-05-04 13:47:37 +00:00 by a · 3 comments

a commented

2024-05-04 13:47:37 +00:00

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-actor

The actor property's domain is Activity, so it is only valid on activities. It should be removed from the Object representation of posts.

I haven't verified whether activities produced by Akkoma use both actor and attributedTo in the same way that objects do, but if so, then they should remove attributedTo as well.

Upstream issue: https://git.pleroma.social/pleroma/pleroma/-/issues/3269

https://www.w3.org/TR/activitystreams-vocabulary/#dfn-actor The `actor` property's domain is Activity, so it is only valid on activities. It should be removed from the Object representation of posts. I haven't verified whether activities produced by Akkoma use both `actor` and `attributedTo` in the same way that objects do, but if so, then they should remove `attributedTo` as well. Upstream issue: https://git.pleroma.social/pleroma/pleroma/-/issues/3269

Oneric commented

2024-05-05 02:49:31 +00:00

Member

funny thing, there’s a ~4 year old todo for that # TODO: Remove actor field for Objects

Internally *oma always uses actor and normalises incoming data to create this field from attributedTo and sync both values for objects. (i’m guessing that’s a relic from pre-ActivityPub days when AS was used as a purely internal format)
Incoming Activities which don’t already contain an attributedTo field shouldn’t be affected by this afaik

Intuitively i’d expect other implementations to just ignore the extra actor field. Does this cause issues with JSON-LD normalisation or other kinds of issues?

[activities] should remove attributedTo as well.

Activities are also objects, shouldn’t this technically be valid?

funny thing, there’s a ~4 year old todo for that [`# TODO: Remove actor field for Objects`](https://akkoma.dev/AkkomaGang/akkoma/src/commit/21a81e111165bd29ef953d5e51c682f3dd94dfb4/lib/pleroma/web/activity_pub/transmogrifier.ex#L148) Internally \*oma always uses `actor` and normalises incoming data to create this field from `attributedTo` and sync both values for objects. *(i’m guessing that’s a relic from pre-ActivityPub days when AS was used as a purely internal format)* Incoming Activities which don’t already contain an `attributedTo` field shouldn’t be affected by this afaik Intuitively i’d expect other implementations to just ignore the extra `actor` field. Does this cause issues with JSON-LD normalisation or other kinds of issues? > [activities] should remove `attributedTo` as well. Activities are also objects, shouldn’t this technically be valid?

a commented

2024-05-05 02:58:05 +00:00

Author

Intuitively i’d expect other implementations to just ignore the extra actor field. Does this cause issues with JSON-LD normalisation or other kinds of issues?

It causes problems for inferencing. Because actor's domain is Activity, anything with an actor will be seen as an Activity. So plain Note objects for example will be erroneously detected as Activity.

Incoming Activities which don’t already contain an attributedTo field shouldn’t be affected by this afaik [...] Activities are also objects, shouldn’t this technically be valid?

OK, that's good, but if the sync works in the other direction, then there might be issues with FEP-0391 which uses attributedTo on the activity to point to the activity that caused it. In that case, Akkoma will receive an activity that has both actor and attributedTo, but they will not be the same.

> Intuitively i’d expect other implementations to just ignore the extra actor field. Does this cause issues with JSON-LD normalisation or other kinds of issues? It causes problems for inferencing. Because `actor`'s domain is Activity, anything with an `actor` will be seen as an Activity. So plain Note objects for example will be erroneously detected as Activity. > Incoming Activities which don’t already contain an attributedTo field shouldn’t be affected by this afaik [...] Activities are also objects, shouldn’t this technically be valid? OK, that's good, but if the sync works in the other direction, then there might be issues with FEP-0391 which uses `attributedTo` on the activity to point to the activity that caused it. In that case, Akkoma will receive an activity that has both actor and attributedTo, but they will not be the same.

a commented

2024-05-16 03:15:35 +00:00

Author

Merged upstream in MR 4105 https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4105 and commit e944b1529862a2a40158803da5fe04a024f7aa4f e944b15298

Merged upstream in MR 4105 https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4105 and commit e944b1529862a2a40158803da5fe04a024f7aa4f https://git.pleroma.social/pleroma/pleroma/-/commit/e944b1529862a2a40158803da5fe04a024f7aa4f

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#770

No description provided.

Stop putting actor on non-Activity objects #770

Stop putting `actor` on non-Activity objects #770