There may be similar issues with other outbox activity side-effect specifications, but this is one that I've recently encountered.
Section 6.8 describes the outbox processing side-effect:
The side effect of receiving this in an outbox is that the server SHOULD add the object to the actor's liked Collection.
That's fine, but what about the likes count/collection on the liked object?
The AP spec describes that side-effect only in the Server-to-Server side-effects in section 7.10:
The side effect of receiving this in an inbox is that the server SHOULD increment the object's count of likes by adding the received activity to the likes collection if this collection is present.
Again, this is Server-to-Server (Federated) inbox behavior and ActivityPub provides little or no specifications for local delivery. However, that means the outbox Like side-effects for local likes will result in lower-than-expected likes counts (because the likes count/collection is not updated).
Shouldn't there should be an outbox side-effect for updating the likes count/collection when the liked object is local?
I'm also wondering about Like addressing and what it means. Is it valid to have a non-public directly-addressed outbox Like? It seems like the addressing indicates the actor only wants specific recipients to be aware of the Like. How does that affect the local and remote like counts?
Should we only allow public Likes where any other recipients are specified only for remote delivery purposes?
There are also seems to be side-effect issues with inbox Like (although it's not an ActivityPub API issue, per se). The way the requirement is phrased, each time a remote Like is received in (delivered to) an inbox, the side-effects should be performed. If an incoming remote Like is delivered to multiple, possible many, local inboxes, that would locally overcount the likes for the remote object.
There may be similar issues with other outbox activity side-effect specifications, but this is one that I've recently encountered.
Section 6.8 describes the outbox processing side-effect:
That's fine, but what about the
likescount/collection on the liked object?The AP spec describes that side-effect only in the Server-to-Server side-effects in section 7.10:
Again, this is Server-to-Server (Federated) inbox behavior and ActivityPub provides little or no specifications for local delivery. However, that means the outbox
Likeside-effects for local likes will result in lower-than-expectedlikescounts (because thelikescount/collection is not updated).Shouldn't there should be an outbox side-effect for updating the
likescount/collection when the liked object is local?I'm also wondering about
Likeaddressing and what it means. Is it valid to have a non-public directly-addressed outboxLike? It seems like the addressing indicates the actor only wants specific recipients to be aware of theLike. How does that affect the local and remote like counts?Should we only allow public
Likeswhere any other recipients are specified only for remote delivery purposes?There are also seems to be side-effect issues with inbox
Like(although it's not an ActivityPub API issue, per se). The way the requirement is phrased, each time a remoteLikeis received in (delivered to) an inbox, the side-effects should be performed. If an incoming remoteLikeis delivered to multiple, possible many, local inboxes, that would locally overcount the likes for the remote object.