• jadero@programming.devEnglish
    0·
    1 year ago

    You’ve officially changed my mind.

    Up until now, I’ve been harping on the concept of “controlling interest” in which a single entity is large enough to control the direction taken. But I hadn’t considered that the new direction might be one that limits the potential for a negative result.

    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 this federation experiment fails, then what is learned can be used in the next experiment.

    Now to track down and add a note to all those comments I made…

    • 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.

    • o_o@programming.devEnglish
      02·
      1 year ago

      I appreciate your reconsidering your position! Thanks for taking my argument in good faith hahaha. I was worried I’d get some hate for it.

      Cheers!