What’s stopping me from doing this? Here we go:

I’m going to start an instance and federate with everyone who will allow it, which is most instances including this one, I believe.

Then I’m going to feed all that data into my new website, called Open Lemmy Stats, where anyone can query the user data ive accumulated. The homepage will be ripe with insights, leaderboards and all kinds of data on prolific users.

Additionally, I’ll display a snapshot/profile of a random user by feeding that users data to GPT4 to make inferences about the user’s political affiliations and display the results.

Worst of all, I’m not going to out my instance for everyone to know it as the one to defederate. In fact, I’m spinning up a few instances that will host innocuous communities that I plan to mod and support to give my instances cover for their true purpose: redundant fediverse datastreams for my site, Open Lemmy Stats.

I’ll also have a store where anyone can buy my collected fediverse data for a handsome sum.

Just kidding I’m not doing any of this. But someone absolutely will or already is working on it. They’ll make a good bit of money too, I’d bet.

This is inspired by a recent post on youshouldknow@lemmy.world where someone highlighted what kind of data instance admins have access to, even for users not on their instance.

I wanted to share this to start a discussion that I find interesting. I’m interested in your thoughts, or to hear more on why this may or may not be possible and if it is, maybe some ideas how to fix that? because obviously such a site would be problematic, but no doubt popular for oh so many reasons.

Edit: typo, I called admins adminis. Corrected.

Edit 2: wanted to credit the post I was referencing from YSK, here it is - https://lemmy.world/post/1033769

  • zinklog@lemmy.fmhy.ml
    link
    fedilink
    English
    arrow-up
    12
    ·
    2 years ago

    Was with you until the money point. It’s extremely easy to get this data and there will be many open source versions doing this thing.

    But I agree that who upvoted a post shouldn’t be federated.

    • booty_flexx@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      7
      ·
      2 years ago

      I totally get what you’re saying.

      I think there is (unfortunately) value to be mined from packaging the data conveniently, or offering a subscription service to make it trivial to query for anyone without sysadmin or database skills. Or just throw porn ads on it or some shady ad network that doesn’t mind being placed on questionable sites.

      • zalack@kbin.social
        link
        fedilink
        arrow-up
        7
        ·
        edit-2
        2 years ago

        I really think Lemmy, Kbin, and Mastodon need to figure out a way to have a default terms of service that ship with their product which forbids using the API to collect data for commercial purposes.

        Additionally, there should be a way for users to indicate licensing for individual posts, with a default license instance admins can set.

        That way for-profit instances could be forced to filter out posts with licenses that do not allow for-profit use. Honestly, even just a simple check mark “[ ] allow for-profit republication”, and have two licenses that can be attached: one that allows for-profit use and one that does not.

        • FaceDeer@kbin.social
          link
          fedilink
          arrow-up
          4
          ·
          2 years ago

          Whoever’s doing this wouldn’t be using Lemmy, Kbin, or Mastodon code. They’d likely write up some custom ActivityPub service that listened in on that protocol. ActivityPub is an open protocol so trying to put some kind of “no profit” restriction on it at this point would be impossible, and having it on there from the start would have killed its adoption.

          Lemmy, Kbin, and Mastodon are all currently licensed under the GPL so good luck trying to retroactively put that genie back in the bottle too. The GPL allows for-profit companies to run the code with no further restrictions.

          Europe’s got the GDPR, if you really want to try some kind of legal route to counter this, but I don’t think it’s very likely to work well.

    • OnionFutures@vlemmy.net
      link
      fedilink
      English
      arrow-up
      4
      ·
      2 years ago

      But I agree that who upvoted a post shouldn’t be federated.

      This also surprised me. I wonder is it necessary for technical reasons to prevent repeated upvoting of a submission by the same user?

      • ColonelPanic@lemmy.ml
        link
        fedilink
        English
        arrow-up
        5
        ·
        2 years ago

        I’m pretty sure there is no particular reason why it’s done this way. It’s just the easiest method to coomunicate upvotes across different servers. There are already a lot of ideas for doing it differently or more efficient (e.g. vote aggregation) but that requires a more sophisticated architecture:

        • Vote aggregation also makes faking votes much more efficient and requires different detection methods. Of course, a spam server can also invent users or votes but it’s a bit more complicated.
        • Aggregation in any form can be hard to implement because it should be flexible enough to reduce load but not increase delay or make tracking a consistent state even harder. Finding the right configuration will be difficult and go through a lot of trial and error. Should be easier though now that more people are working on the code.
        • Keep in mind that Lemmy should also be able to communicate with other services across the Fediverse like Mastodon via ActivityPub. I’m not sure if there is something in the standard for message aggregation yet. It’s definitely being discussed because Mastodon, Pixelfed and Peertube all have or went thorugh the same growth problems as Lemmy in terms of scaling, spam and security concerns. If there’s a good solution it will likely come through the AP standard.