• ruffsl@programming.devEnglish
    0·
    1 year ago

    Personally, I think that a sufficiently large instance does represent a major risk. But now I think it’s a risk we have to take.

    If we had to white board a decision matrix on Facebook federation, what would be the number of risk’s and rewards for either approach? How would you weight or quantify them? Just trying to approach this from a little more of an analytical angle, given most of us are developers anyway.

    • o_o@programming.devEnglish
      01·
      1 year ago

      Risks/rewards for whom?

      For programming.dev? If all we care about is the survival of this website, then yeah maybe Meta poses a risk and we should defederate.

      But (with respect to the admins), no one cares about programming.dev. We care about the vision of a “fediverse”, where all instances’ users can talk to one another if they choose. If that’s what we care about, there’s no choice here: federate, or you’ve already broken the vision.

      Look, no one is saying that programming.dev should promote Meta’s content on their home page. Let’s beef up our moderation/content filtering tools:

      • Let users block all @meta.com and all @meta.com communities if they choose.
      • Let community mods block posts/cross-posts from @meta.com communities or users.
      • Let community mods decide never to let @meta.com users subscribe or see posts on their communities.
      • Let the instance owners decide never to feature a @meta.com user’s post or a @meta.com community post on “all” or “local”. Make it so that the only way to find a Meta post/user is by actively searching for it or subscribing to their communities. That’s all well and good.

      But defederation is worse than that. What defederation really means is: “Even if programming.dev users want to see Meta content or post there, we won’t allow it. Go create an account there instead.”. As soon as you do that, it’s not a fediverse anymore.