on my journey to automated federation testing (https://mro.name/activitypub), I’d like to read the ‘like’ counter before and after Like and Dislike activities.
How would I do that with activitypub et al.?
1 Like
I ask all the implementers for help, what do you think about that?
@nutomic @chocobozzz @diogo @nightpool @trwnh @pukkamustard @tcit @mayel @Sebastian
Background: I think of a monitoring a la https://updown.io/4kug to demonstrate both usage and availability of some basic usecases and some servers.
If you have implemented the likes Collection for the object, then you just have to count the number of items in that collection 
1 Like
It’s about querying other servers. That’s meant with federation, isn’t it? Otherwise I wouldn’t bother the implementers.
Well then, the standard way to find the like count is also to look at the likes collection. But this collection is optional, so it will work for softwares that chose to implement it.
2 Likes
solved: likes collection as done in https://codeberg.org/mro/activitypub/src/branch/master/monitor.cgi.
Caveat: optional.
AFAIK nobody but peertube implements it.
Maybe peertube is the only thing that needs it
Since other servers could easily lie about how many Likes have been sent, both Mastodon and Pleroma have chosen to only display the like count that is local to that server, not considering Likes that are claimed by the remote server.
I don’t read DE but the basic idea is to query for all posts with type = “Like” and object->id = x, where x is the id of the post whose likes are being counted, and return only the count of those results (although you might wish to enumerate the list of actors as well). The precise details will depend of course on your storage implementation and desired user interface.
I would have done exactly the same thing for Question ; which is in my opinion the most sensible approach but no longer practical and is off topic.
Currently GNU social does the same as Mastodon and Pleroma (like count = to likes local to current server).
But Lemmy has “unlisted likes” (@nutomic), and these are federated with as:Public in CC. We haven’t yet implemented support for unlisted likes in GS v3, but we intend to. These should increment the like count and not be added to the like collection of an object.
Spec-wise there isn’t a difference in delivery or visibility between to/cc, so the concept of “unlisted” Likes doesn’t really make sense. It would make more sense to have “private” Likes, where the likes Collection is filtered by the authority of the requester – you would want to deliver the Like to the actor, possibly cc to your followers or some other actors, and maybe set an audience equal to the addressing on the activity to avoid any ambiguity.
Actually it was a mistake to implement it like this. We are currently migrating to remove the cc: Public from vote activities.
1 Like