So from my understanding, I can block an instance which prevents it from showing in my feed.

However, if the instance I post to (.world) is not blocked on the receiving instance’s end (Meta), they will still get my post (unless defederated)?

If so, doesn’t that open up the idea that Meta will be able to scrape and take ALL the data from ALL the (still federated) instances’ posts that are not blocked by the Meta instance(s)? How can I protect my information from Meta while still being federated, or is that not possible?

  • marsara9@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Using threads / ActivityPub does make it easier though.

    If they’re using a traditional crawler you could in theory block them at the user agent level (i.e. Cloudflare). If they’re using the public APIs, they’d have to write an interface for each distinct piece of software (Lemmy, Kbin, Mastodon, etc…) (How my search engine works)

    But with ActivityPub were essentially just sending them the data in near real-time all using the same rough structure. Individual instances may block them but it wouldn’t be hard to setup proxies/relays that the community as a whole just isn’t aware of. (i.e. a new “Lemmy” instance comes online that just looks like a single user server, but it’s actually just a relay to Meta). The only real gotcha with ActivityPub is that there’s no real way to get historical data (nothing from the past).

    Now I still have mixed feelings about Meta joining the fediverse, but if we’re just talking about blocking them from getting the content we have here, then things get difficult.

    • mr47@kbin.social
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Hear me out. Why don’t we create a paywalled API for 3rd party apps (like Threads), that will end up costing, say, $20 million annually to use at Meta’s rate… And then use the proceeds to keep all the instances running, and for other shenanigan.