Edit: obligatory explanation (thanks mods for squaring me away)…

What you see via the UI isn’t “all that exists”. Unlike Reddit, where everything is a black box, there are a lot more eyeballs who can see “under the hood”. Any instance admin, proper or rogue, gets a ton of information that users won’t normally see. The attached example demonstrates that while users will only see upvote/downvote tallies, admins can see who actually performed those actions.

Edit: To clarify, not just YOUR instance admin gets this info. This is ANY instance admin across the Fediverse.

  • @Aceticon
    link
    English
    13611 months ago

    Well, yeah, it’s put on the database.

    It’s the only way to avoid double voting from the same account or to remove the reverse vote if one changes one’s mind and votes the other way.

    Did you think that it was any different on Reddit and that no random employee with access to their database could run a similar SQL query with a couple of joins and end up with nicknames, e-mails and IP addresses?!

    Do you know who are the Reddit employees with access to their database or a copy of it? Have you had a chance to vet them? I don’t think so.

    At least here it’s a bit more transparent.

    The only shocking thing in this is that anybody is shocked by it.

    • @haventbeenlistening
      link
      English
      2611 months ago

      It is only shocking if the expectation was set that your votes are private. If you wanted to avoid linking an identifiable account with their votes then you could use a de-identified user account to track a user’s votes.

      You could to perform deterministic hashing prior to persisting a vote to ensure that those looking at the database can’t go backwards to find the specific users who voted on a post. But any service that knows the salt and hashing algorithm can start with a user account and determine that user’s voting history.

      This allows you to track up/down votes per user without allowing over-priviledged DBAs or malicious actors from poking around voting histories of identifiable users.

      • @MindCap
        link
        English
        1811 months ago

        Something like Monero’s Ring Signatures might provide some inspiration for truly private upvote history without duplication.

        • @haventbeenlistening
          link
          English
          411 months ago

          Right. Applying any form of application-level encryption to the account IDs stored in the voting tables would prevent anyone without the secret from being able to find out who voted for what by peeking at the voting tables.

          The more I think about this problem, the more solvable it seems to be.

    • @[email protected]
      link
      fedilink
      English
      15
      edit-2
      11 months ago

      Another way to be more private is to only federate upvote/downvote count, instead of the detail of the upvote/downvote. This is not only lighter but more private. When the count needs to be updated just broadcast the new upvote count.

      But I see why they want to do it the current way, as it is more aligned with activitypub protocol, and allow other platform like mastodon to participate without problems.

      I cannot think of much problem in implementing a “hidden upvote system” in activitypub. Basically, it will work like this:

      • user on instance A upvotes a post in instance B: instance A tells instance B the user upvoted the post, but not anyone else.
      • instance C trying to fetch a post from instance B: B will only communicate the upvote/downvote count, but not the detail
        • if instance C is not a threadiverse instance (like mastodon) it will show “xx number of upvote from B is hidden.”
      • @nova
        link
        English
        1911 months ago

        Wouldn’t it be easy to lie though? Instance B could report 1000 upvotes to Instance C and Instance C would have no way of verifying that. An instance could boost its own numbers pretty easily, pushing agendas to the front page.

        The transparency allows for accountability. It would be pretty easy to detect an instance making up user upvotes versus a “just trust this number” system.

        • @[email protected]
          link
          fedilink
          English
          911 months ago

          It would be equally as easy to lie either way. Instead of reporting 1000 anonymous upvotes, report 1000 fake upvotes from fake users or users who didn’t actually upvote. Any instance that gets caught abusing the protocol would get blocked pretty quickly though. Even though it’s theoretically possible, I’ve never seen it happen.

        • @[email protected]
          link
          fedilink
          English
          211 months ago

          A instance can always generate bunch of fake user and use them to upvote their own stuff. With LLM I would imagine it would be trivial to make them sounds semi-human.

          Unless fediverse implements some sort of smart contract system using proof of work/stake system, i don’t really see much way to fix faking upvote. Even so, it is hard to make the implementation correct, and probably abusable (for example, most user only use a phone with 128G of storage, people can just buy couple 4TB drive and pretend each of them are 40 real users).

      • @QuadratureSurfer
        link
        English
        111 months ago

        No, if you go to old.reddit.com/prefs/ the “make my votes public” defaulted to keeping votes hidden from other users.

        Most users from Reddit that are coming here are voting while not realising that their votes are completely public to anyone that simply uses kbin to browse through any instance.

    • Reclipse
      link
      fedilink
      English
      -911 months ago

      It’s the only way to avoid double voting from the same account or to remove the reverse vote if one changes one’s mind and votes the other way.

      A better way is to store only who has voted. No need to store how they have voted.

      • @bitbybit
        link
        English
        2611 months ago

        Then people won’t be able to change their minds once they’ve voted, or even see what their previous votes were.

      • Colonel Sanders
        link
        English
        14
        edit-2
        11 months ago

        A better way is to store only who has voted. No need to store how they have voted.

        Unfortunately, as they mentioned it would still need to know which way they voted so one can “unvote” or change their vote.

      • Łumało [he/him]
        link
        fedilink
        English
        3
        edit-2
        11 months ago

        Then either up or down votes would cease to exist, the website has to somehow differentiate between those votes to properly count them.

        • AstralWeekends
          link
          fedilink
          English
          211 months ago

          I think it would be possible not to tie up/down votes to a particular user and still be able to allow votes, but you would probably need to disallow changing a vote (unless there are some fancy uses of cryptography I don’t know about). You could use a bit field to indicate whether or not a particular user voted on a particular post, whether up or down doesn’t matter. You could register the up/down count to the table that has the post id and not tie it to the user that voted. But then a user couldn’t change their vote because of that arrangement.

          I don’t personally care how my votes are recorded, I just like databases.

          • Łumało [he/him]
            link
            fedilink
            English
            111 months ago

            Yeah now that you wrote about it and I thought about it, yeah there is a way to have both. But as you’ve said it would remove the ability to change votes, and I don’t feel like thinking further into this to solve this problem. I just don’t care that much :P