573
The mod banning these users is the same mod who made the posts they downvoted. This is mod abuse, turning the downvote button into an auto-self-ban button.
The message is "If you disagree with me, you will be banned"
Monitoring and banning users for using lemmy as intended to signal boost your opinion should be grounds to have all mod privileges removed. This behaviour undermines the integrity of the server and the wider fediverse.
There's not really a way to do votes privately on a federated system. Unless you're suggesting no votes at all, which could be interesting, but I'm not able to envision a functional way to do that.
didn't piefed or some other alternative to lemmy add that feature
Kbin shows votes i believe. Piefed doesn’t show you who voted. It does show users “attitude” which is a ratio of upvotes to downvotes that the user has given but it isn’t granular to show what they’ve voted on.
Piefed implemented it, but it didn't work out for some reason and they ended up having to remove it.
I'm not talking about blocking users from seeing votes - the nature of federation requires, at the very least, that admins are able to see the data flowing into their instance, which includes voting records. All it takes at that point is a purpose-made instance to be spun up that will catalogue all the votes that it federates with and publish them. In fact I'm pretty sure this already exists.
It's a minor technical problem.
How should it work in your opinion? Like technically, how would you federate but also vote privately?
You use a one-way hash instead of the current identifiable key that is used to store the vote value.
What about double spending?
I don't see how replacing a unique id with a unique hash would have any effect on that. Even if you use a variable hash (that would change every time you change your vote) you just have to make sure that the backend properly removes the old value on a new call.
My point is that if a U user is on L local instances and R remote instance gets the vote, how does R know if U is double spending or not?
I see, guess I underestimated the problem a bit, I have to think about it some more.
Hash the whole fucking thing and store it with the entity being voted on.
UserID, UserServerID, EntityID, EntityServerID all together hashed.
Mind you, I'm assuming those pieces of information exist because thingID + thingServerID makes sense as a way to identify "thing" (user, comment, post) in a federated system.
Server is the server that hosts "thing": the server where the user is registered, or the server hosting the forum where a post was made or a comment was made under a post.
On an incoming vote, server calculates the hash. If the same hash is already present, server doesn't accept another vote if it's the same way or changes the existing vote if the new one is different.
Mind you, this is all blue sky thinking based on how I myself would design such a system as I can't be arsed to go learn Lemmy's API and data model just for this.
In your model Remote server would still know about User's votes, which is what we have now with lemmy.
So in the data-model the votes are linked to the User rather than to the entity being voted on?
I supposed it makes sense considering that the user him/herself does get displayed in a prominent way where they voted and how.
I hadn't considered that side of the data flows :/
Thinking out loud, one way hashes would work as a way to keep the id of user votes secret whilst avoiding vote duplication.
Not to remote servers