I’m changing my stance on the whole Meta/project92 thing after reading this article. I think the entire* fediverse should block project92 by default. Later, some instances can re-evaluate whether to maintain those blocks, once we have a better idea of what the benefits and consequences of federating will be:

Of course, it’s possible to work with companies you don’t trust. Still, a strategy of trusting the company you don’t trust until you actually catch them trying to screw you over is … risky. There’s a lot to be said for the approach scicomm.xyz describes as “prudently defensive” in Meta on the Fediverse: to block or not to block?: “block proactively and, if none of the anticipated problems materialise within time, consider removing the block.” Georg of lediver.se frames it similarly:

We will do the watch-and-see strategy on our instance in regards to #meta: block them, watch them, and if they behave (hahahahaha) we will see if we unblock them or not. No promise though

Previously, I’d thought “some block, some federate” would be the best approach, as described in this post by @atomicpoet:

My stance towards Meta is that the Fediverse needs two types of servers:

  1. Lobby servers that explicitly federate with Meta for the purposes of moving people from Meta to the rest of the Fediverse

  2. Exit servers that explicitly defederate with Meta for the purposes of keeping portions of the Fediverse out of reach from Meta

Both approaches not only can co-exist with each other, they might just be complementary.

People who use Meta need a way to migrate towards a space that is friendly, easy-to-use, and allows them to port their social graph.

But People also need a space that’s free from Meta, and allows them to exist beyond the eye of Zuckerberg.

Guess what? People who use Meta now might want to be invisible to Meta later. And people who dislike Meta might need a bridge to contact friends and family through some mechanism that still allows them to communicate beyond Meta’s control.

And thankfully, the Fediverse allows for this.

  • SJ_Zero@lemmy.fbxl.net
    link
    fedilink
    English
    arrow-up
    15
    ·
    1 year ago

    Say what you will, certain communities won’t have a problem either way because there’s no way Facebook will willingly federate with them for longer than an hour.

    • laurens@kbin.social
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      yeah, this. I find the assumption that Meta is even interested in federating with most servers to be quite optimistic, to say the least. Especially the servers that have signed the fedipact. Its great for them that they have the freedom of associating, and thus say that they do not want to federate with Meta. Thats the system working as intended. But they by and large have different, more relaxed rules about content thats most likely against Meta’s CoC, especially around nudity.

      Instagram has around 1.3 BILLION users posting thirsty pictures at each other all day long, and they still dont allow nudity. I’m not sure why Meta would suddenly be okay with another of their platform showing nudity because a masto server with 20 people who hate Meta does like to post nudity.

    • Double_A@kbin.social
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Exactly. Why would facebook even care about the existing, tiny, fediverse? They are probably doing this because the infrastructure maybe makes sense somehow for geographic reasons to save on server costs.

      • SJ_Zero@lemmy.fbxl.net
        link
        fedilink
        English
        arrow-up
        2
        ·
        1 year ago

        I was thinking about that, it makes sense for Facebook to try federation so you can access the Instagram, Facebook, whatsapp and meta accounts universally from whatever account you have.

        So how do you do that if you’re meta? Start with activitypub, an existing standard, and then once you’ve learned how it works reprogram it to be proprietary. Same story as Google and xmpp.