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@lemmy.world
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year 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.

    • baseless_discourse@mander.xyz
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year 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@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year 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.