this post was submitted on 18 Aug 2024
814 points (97.9% liked)
Fediverse
28380 readers
1083 users here now
A community to talk about the Fediverse and all it's related services using ActivityPub (Mastodon, Lemmy, KBin, etc).
If you wanted to get help with moderating your own community then head over to !moderators@lemmy.world!
Rules
- Posts must be on topic.
- Be respectful of others.
- Cite the sources used for graphs and other statistics.
- Follow the general Lemmy.world rules.
Learn more at these websites: Join The Fediverse Wiki, Fediverse.info, Wikipedia Page, The Federation Info (Stats), FediDB (Stats), Sub Rehab (Reddit Migration), Search Lemmy
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Many people in this thread seem to not realize that votes are essentially public already - this is only about whether the Lemmy UI should make it a bit easier to see the votes. They can already be seen quite easily if you know how.
However, there is an easy solution to this problem. This is clearly a controversial decision, so don't make a choice for everyone. Make it an option. Any admin can decide for themselves whether their instance should allow users to see votes.
That also means that users can decide to go to instances where the votes are hidden or public.
This approach leaves the choice to the individual, rather than forcing the choice on everyone.
It's confusing enough understanding how federation works for the less technically inclined. I don't think we should also expect them to figure out which instance is privacy-conscious. Privacy of votes should be baked into Lemmy. Even kbin users shouldn't be able to see it.
If users want to advertise their approval/disapproval of posts they can use public comments in tandem with private votes.
This is impossible. The underlying protocol, ActivityPub does not have the concept of private votes. It is not up to Lemmy to decide. You'd need to revise the protocol for this and good luck with that.
ActivityPub can't evolve? Is there some insurmountable technical blocker?
I suspected this would be an issue and have avoided voting on controversial posts. But if everyone did as I do, there would be no open discussions about pressing topics.
It is possible that ActivityPub could add this feature. But it's not certain you'd even want that. Private votes would mean private for admins and mods too, so no more analyzing votes to look for down vote bots or manipulation or down vote brigading and all that stuff. Votes could lose all meaning. Admins and mods are unlikely to say goodbye to those moderation tools.
Even if it could be added, it's probably years away.
Fair points. I'm warming up to the idea of making votes public so that people don't have a false sense of privacy. I wish votes were actually private, but maybe it's not a big deal if your account can't be easily traced back to you in real life.
Pseudonymous voting doesn't mean a unique ID for every vote. It just means the user string itself is tokenized. You can still ban participation for that token without revealing the actual user. Literally the only thing this stops is easily seeing users who use the same name across several instances.
If the token is the same for the user across different posts, it would be easy to figure out who is actually behind the token by correlating voting patterns.
It would at least provide a means for obfuscating identity for users who care to make an effort. All you'd have to do is not vote when you comment and vice versa.
Evolving ActivityPub is not easy, any additions to the protocol take a lot of time and discussions between the various implementers.
You don't even need to upstream the protocol changes imo. An instance could decide to participate with tokenized user IDs. Other instances could decide to defederate because this is out of spec behavior, but as far as I am concerned it is perfectly aligned with the core spec. Nothing says user activity cannot be anonymized.
How would this work in practice? I upvote a post and it sends the upvote via a token user to another instance. Then I remove my upvote or downvote instead. My instance would then need to send an undo or dislike for the token user too. How would you ensure you have enough token users to fill up all the votes on a single post? You'd need thousands if not tens of thousands of these token users. How does it work when I ban one of these users? How do I prevent a user from participating if they use these token users?
Also, this could be used to make vote manipulation easier I bet.
The simplest form of this is literally just a token which replaces the universal identity. So you ban the token, you ban the user. This only applies for voting anyway, since commenting and posting follows the plaintext user agent.
A more robust trust model with rotating tokens would fully move ban enforcement to the home instance, which I actually believe is already the case in some situations. Eg, when I am banned from a specific community on another instance it seems as if my host instance knows not to even display a vote on the UI, which suggests that it has knowledge of my federated ban. With this trust model it would be possible to fully enforce cryptographically secure forward security as well.