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.

  • chris@l.roofo.cc
    link
    fedilink
    English
    arrow-up
    15
    ·
    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.dev
        link
        fedilink
        English
        arrow-up
        5
        ·
        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.

    • dukk@programming.dev
      link
      fedilink
      English
      arrow-up
      2
      ·
      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.

      AFAIK, the ActivityPub specification has no requirements on how likes should be stored. The two things that is requires are that likes are added to the user’s liked collection, and that the post’s like count is updated.

      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.

      Mastodon actually just stores all this data on the server containing the post itself. Instance admins get as much information about the post as the client does. Both Lemmy and Mastodon use the same protocol, but Mastodon chooses to only to trust the server the user is using, and not the third-party servers.

      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.

      Creating that many users wouldn’t be hard to do(you don’t need to use the GUI, just a little SQL is all that’s needed). And you don’t need to “send” the upvotes; you can sidestep the protocol entirely and just update the database. That’s the problem.

      And while yeah, the instances would block me, they probably wouldn’t notice if I did it at a much smaller scale. In fact, there’s no real easy way to check whether these upvotes from an instance are actually real.