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.

  • dukk@programming.devEnglish
    51·
    1 year ago

    Couldn’t we just use a hash for the usernames instead?

    Nothing too over the top, but just a simple hash and match that instead?

    Also, there’s way too much trust in instances. Like, one person could easily make a post on lemmy.world, go on their personal instance, and just give themselves, say, 2000 upvotes.

    Instances should have their own settings on what instances are allowed to keep a local copy. (Default behavior should be to get the post itself from the instance “hosting” it).

    • chris@l.roofo.ccEnglish
      1·
      1 year ago

      If that is a solution you’d need to change the ActivityPub specification. You are more than welcome to submit your idea.

      Also, there’s way too much trust in instances. Like, one person could easily make a post on lemmy.world, go on their personal instance, and just give themselves, say, 2000 upvotes.

      I’d first have to create 2000 users, then I’d have to send 2000 upvotes. And then I’d get blocked by all instances.

      Instances should have their own settings on what instances are allowed to keep a local copy.

      This is also not compatible with the ActivityPub spec but even if it were you’d win nothing because as soon as you fetch the post it is still on the server.

        • dukk@programming.devEnglish
          2·
          1 year ago

          They’d have to check the upvotes, notice most of them came from one instance, look at the instance, check multiple users, and if they realize that these users were just created to get upvotes then they can defederate. However, it’s too big of an assumption that moderators will go through that kind of effort to validate all the upvotes.

    • grimsolem@lemmy.dbzer0.comEnglish
      0·
      1 year ago

      Couldn’t we just use a hash for the usernames instead?

      The hash function would still need to be public to share data between instances.

      • dukk@programming.devEnglish
        11·
        1 year ago

        That’s the point of a hash function. You have a public hash function, say SHA-256. It’s easy to check a username against it’s hash, but virtually impossible to reverse the hash back to the username.

        Edit: Instead of storing, say, eddie, we’d store 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d. Then when the instance gets a Like from eddie, it hashes his username to get 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, realizes there’s a match, and doesn’t update the count.

        Note that when given 3b9d8298f1b5086d012618feebb2da1a394357c1dab7523443c9f6a743c4c84d, it would take millions of CPU years to compute the original username from it. Therefore, we can check for duplicates without actually checking the name itself (a similar method is used for checking passwords; Lemmy is open source, we know the hashing algorithm, but we can’t unhash user passwords, only check them).