this post was submitted on 04 Jul 2023
723 points (99.2% liked)
You Should Know
33100 readers
443 users here now
YSK - for all the things that can make your life easier!
The rules for posting and commenting, besides the rules defined here for lemmy.world, are as follows:
Rules (interactive)
Rule 1- All posts must begin with YSK.
All posts must begin with YSK. If you're a Mastodon user, then include YSK after @youshouldknow. This is a community to share tips and tricks that will help you improve your life.
Rule 2- Your post body text must include the reason "Why" YSK:
**In your post's text body, you must include the reason "Why" YSK: It’s helpful for readability, and informs readers about the importance of the content.
**
Rule 3- Do not seek mental, medical and professional help here.
Do not seek mental, medical and professional help here. Breaking this rule will not get you or your post removed, but it will put you at risk, and possibly in danger.
Rule 4- No self promotion or upvote-farming of any kind.
That's it.
Rule 5- No baiting or sealioning or promoting an agenda.
Posts and comments which, instead of being of an innocuous nature, are specifically intended (based on reports and in the opinion of our crack moderation team) to bait users into ideological wars on charged political topics will be removed and the authors warned - or banned - depending on severity.
Rule 6- Regarding non-YSK posts.
Provided it is about the community itself, you may post non-YSK posts using the [META] tag on your post title.
Rule 7- You can't harass or disturb other members.
If you harass or discriminate against any individual member, you will be removed.
If you are a member, sympathizer or a resemblant of a movement that is known to largely hate, mock, discriminate against, and/or want to take lives of a group of people and you were provably vocal about your hate, then you will be banned on sight.
For further explanation, clarification and feedback about this rule, you may follow this link.
Rule 8- All comments should try to stay relevant to their parent content.
Rule 9- Reposts from other platforms are not allowed.
Let everyone have their own content.
Rule 10- The majority of bots aren't allowed to participate here.
Unless included in our Whitelist for Bots, your bot will not be allowed to participate in this community. To have your bot whitelisted, please contact the moderators for a short review.
Partnered Communities:
You can view our partnered communities list by following this link. To partner with our community and be included, you are free to message the moderators or comment on a pinned post.
Community Moderation
For inquiry on becoming a moderator of this community, you may comment on the pinned post of the time, or simply shoot a message to the current moderators.
Credits
Our icon(masterpiece) was made by @clen15!
founded 1 year ago
MODERATORS
Not to sound harsh or anything, but those of you saying that it's okay that all this data is public are insane. This completely goes against the entire philosophy of the Fediverse and FOSS in general. The reason we all are fleeing from Big Tech is because they collect so much data on us. At least, they keep it hidden from public view. This is a major issue in my opinion, and needs to be addressed ASAP before we can claim to have superior platforms on the Fediverse. Why can't this data at least be encrypted?
I don't think it's possible to encrypt the data.
Say we have a rogue user that sends to the server multiple upvote requests for the same comment, how can the server reject the subsequent requests? After all, we can't let a user upvote a post or comment multiple times.
If that data is encrypted, the server cannot tell whether the user has upvoted a comment before.
There might be possible technical solutions to this using hashing. Hashing is like encryption in that the original cannot be extracted, but the hashed result is unique.
For example, a solution would be to have a VOTES table with an indexed column that is a hash of a combination of the user ID, post ID, (and perhaps another "salt", not sure). When a vote is made, the VOTES table is checked that the record (vote) does not already exist, gets an insert, and then a COUNTER is triggered for the actual vote count. (COUNTER is a db command that simply updates a counter). The hash would prevent multiple votes from the same user (as the salted hash is unique), and it would also prevent identifying who the user is from the table.
Yeah, I admit that sounds reasonable.
Although that still leaves the question of "is it scalable/performant?" on the table... Lemmy already suffers a lot from server overloading, adding the overhead of cryptographic hashing (anything less than that is not going to ensure uniqueness/true anonymity) to each act of voting surely isn't going to help.
Hashing is a normal part of the web, it's easily scalable.
Still you can easily and quickly check if a user has voted on a particular post. While your method makes the tracking process quite a bit slower, it doesn't make it unrealistic. There just aren't that many users and posts as is the case with passwords. Still 100% better than the current approach, I hope this gets implemented.
I really don't even think the votes table would need to itself be federated; it could just be on the user's instance. Upvote/downvote would be a call, but it should really only require the post or comment ID and voter instance. If an instance spams votes, those upvotes/downvotes could be deleted and the instance defederated