Anonymous Likes/Dislikes or other activities via proxy user

[tesaguri]

@SorteKanin

What do you mean notify? As in a notification? No you don’t want that. The Like obviously needs to be somehow communicated to the instance of the author of the Liked object so that it can do a +1 to the vote count, but you definitely don’t want a notification for every single (Dis)Like. A single popular post or comment could get you hundreds of notifications if that was the case haha. But just because the like is targetted via to or something like that, I don’t think that necessarily means that the actor in question should get a notification.

My wording was misleading (it’s poorly mixed up with Linked Data Notification jargon). I was thinking about sending unanonymized Likes to the author of the original post rather than to the server (or possibly moderators of the community) alone.

Also, I was thinking in terms of the protocol rather than UX. At the protocol level, delivering an activity to an actor’s inbox implies the addition of the activity in the inbox collection, which is why I think it’s not good idea to target (unanonymized) Likes to the author of the object. At the UI level, yes, you don’t necessarily want to generate “notification” for every vote. That’s completely up to the implementation.

@SorteKanin

I don’t really see how that changes the privacy situation in any way - you’re still dependant on the remote server respecting the privacy of the Like.

But in this way, you would only trust the server of the original object, which explicitly opts in the extension mechanism (and its contracts). I thought your concern was that you cannot practically trust arbitrary audience servers to respect the targeting of Like activities, and I think that limiting the recipient of the activity to a single server of the sender’s choice could reasonably enforce the targeting.

If an implementation opts into the extension mechanism and still ignore the targeting of the activities, you could safely defederate the implementation for its malicious behavior, just as you’d defederate an implementation that intentionally expose private replies.

@SorteKanin

I don’t think this happens currently? Does it? My understanding is that activities like Likes are sent directly from instance A to instance Z - no instance B is forwarding one activity from instance A to instance Z as a “middle-man”.

I was conservatively assuming the likes collection and an inbox forwarding-like convention, but if there’s no such convention in the real-world Threadiverse (again, I’m not familiar with the Threadiverse), that’s just fine.

@SorteKanin

Not necessarily and this could be used maliciously. You don’t have to trust the sender’s server, you can instead go through the Likes collection and fetch each Like activity in the collection - but of course this requires 1 request per vote instead of just 1 request per Likes collection and there can be a lot of votes so… yea it’s kind of a pain if you need to do that. But in principle you have to do that if you don’t want to trust the origin server’s Like count.

You’d need to filter the Like count from the origin in any case, as some Likes that it counts may be from instances that you have defederated and thus you would not want to count those votes.

Yes, you’d need to get the Like activities from the voters’ servers if you don’t trust the server of the original object, but what’s the point of that exactly? If the sending users of the Likes are anonymized by the sending servers, the only information the audience servers can get is the “voting patterns” (as the piefed.social post you liked in the OP puts) with no “reputation” information. To me, this seems to rather increase the number of SPoFs that can manipulate the vote count.

You might be able to detect obviously bad voting patterns (like mass-voting in a narrow time window, though note that malicious servers could easily fake published of Like activities), but I expect (well, it’s just a wild guess) many of bad behavior are not that obvious by the voting patterns alone. Perhaps statistical analysis helps with a reasonable accuracy, but ought that to be the only solution to the moderation?

Also, I had an impression that Threadiverse implementations tend to put strong trust in the community, partly because Lemmy trusts the contents of posts forwarded by followed communities without any cryptographic verification (not that I like the idea), and PieFed’s Page objects seemingly embed remote objects in the replies collection (well, its replies seems to be a plain array of Notes instead of a Collection as specified in the Activity Vocabulary, but I digress) without cryptographic proofs. But, again, I’m not familiar with the Threadiverse and I might be misunderstanding the trust model there.

As a random idea, sending an unanonymized Like to the server of the original post and distributing an anonymized Like to the audience might be viable at the same time, by dropping the actor property (inspired by @trwnh’s idea) of the activity when fetched by an unauthorized client. The anonymized activity here would entail the fact that the sending server claims that an (unnamed) actor hosted by it has Liked the object. This wouldn’t expose the voting pattern information, for better or worse, but it would let the audience verify the count of votes claimed by the voting servers while allowing fine-grained moderation by the original server.