this post was submitted on 15 Sep 2025
317 points (98.2% liked)

sh.itjust.works Main Community

8240 readers
506 users here now

Home of the sh.itjust.works instance.

Matrix

founded 2 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] moseschrute@lemmy.world 6 points 9 hours ago* (last edited 9 hours ago) (8 children)

How should it work in your opinion? Like technically, how would you federate but also vote privately?

[–] remon@ani.social 7 points 8 hours ago* (last edited 8 hours ago) (7 children)

You use a one-way hash instead of the current identifiable key that is used to store the vote value.

[–] jet@hackertalks.com 7 points 8 hours ago (6 children)
[–] remon@ani.social 1 points 8 hours ago* (last edited 8 hours ago) (1 children)

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.

[–] jet@hackertalks.com 8 points 8 hours ago* (last edited 8 hours ago) (2 children)

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?

[–] Aceticon@lemmy.dbzer0.com 1 points 4 hours ago* (last edited 4 hours ago) (1 children)

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.

[–] jet@hackertalks.com 6 points 4 hours ago (1 children)

In your model Remote server would still know about User's votes, which is what we have now with lemmy.

[–] Aceticon@lemmy.dbzer0.com 2 points 3 hours ago

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 :/

[–] remon@ani.social 4 points 7 hours ago

I see, guess I underestimated the problem a bit, I have to think about it some more.

load more comments (4 replies)
load more comments (4 replies)
load more comments (4 replies)