I’m seeing discussions on other instances about how a “federated” corporate instance should be handled, i.e. Meta, or really any major company.

What would kbin.social’s stance be towards federating/defederating with a Meta instance?

Or what should that stance be?

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

    I’ve seen this article circulating and I think it’s a really good cautionary tale. If meta arrives here in full force it’s completely going to take over the fediverse, they are already splitting the community as it is.

    https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html

    Note that this is different subject from being anti-corporate. I don’t think there’s an issue if companies start booting their instances and creating communities for their games or content, whether its EA, Bioware, CDPR or something like pcgamer, LTT, gamersnexus, etc. They want the PR and visibility on a social network but their goal probably wouldn’t be take over the AP, and could add some validity and get other bigger names to be active here. That is assuming we want growth at all.

    • 50gp@kbin.social
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      I wonder if theres any way to pre emptively stop them from taking over activitypubs development and direction

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

        They can’t do a hostile take over of ActivityPub. The trap is that they would come in with open arms and an army of developers. ActivityPub maintainers would at first welcome the help and guidance from such an experienced team. Then, once they have the community hooked, they spring the trap and start making changes that are actively hostile to small sites. The community flocks to the big site because everything works better there, and the dream is dead.

        Now maybe it’ll never happen, but it’s hard to tell. Even if Facebook joined with the best intentions, that doesn’t mean the project isn’t going to be taken over by a power hungry manager later who could still activate the trap card.

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

          This is why the big threat is Meta, because they are a tech company. I think any instances spun up by Silicon Valley should be blocked preemptively, but other corpora can have a probationary period.

          • Kichae@kbin.social
            link
            fedilink
            arrow-up
            3
            ·
            1 year ago

            Honestly, it Meta spun up a Mastodon site to host Meta employees and just have a corporate presence, the way they might have a Twitter account, that wouldn’t be an issue at all.

            The issue is that they’re arriving as platform developers, not social participants. And that’s their business.

            We should be super suspicious of people showing up to sell the Fediverse, because you can’t profit off of community. Community costs money, not generates it. To generate money, you need to exploit people, and exploitation is anti-social. Anti-community.

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

    The safest and most effective way to prevent Meta from destroying ActivityPub is to never give them so much as an inch. They WILL embrace, extend, extinguish if given the chance. Defederate from ALL Meta-owned instances. Be vocal about it. Tell other instances to do the same.

  • codybrumfield@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    I don’t think there should be blind hostility but it should be clear that any hint of embrace, extend, extinguish will result in hostile actions like defederation. I also don’t think targeted ad tech companies share the goals of the Fediverse. I wouldn’t be bothered if instances had sponsors (as in, “/Kbin is made possible by support from Cloudflare”) like all non-profit media. But any sort of targeted ads based on user activity/data should be ruled out as a way to fund the metaverse.

  • shepherd@kbin.socialOP
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    It seems unlikely to me that corporate instances would ever actually federate in good faith.

    They may appear to be compliant initially, but in the long term they just have different goals.

    I’m not sure where exactly the line gets drawn, but at the far extreme, I say we treat money-making instances as bad actors. If they stand to gain profit from their actions, they need to be defederated to prevent the sabotaging or enshittification of the fediverse.

    • !deleted208326@kbin.social
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      would ever actually federate in good faith.

      How does one federate “in bad faith”? What do you see that looking like?

      edit: It’s nice to see that genuine questions get downvoted here, just like reddit. I was getting worried that this community was better than that! Fuck me for not knowing how this federation stuff works. :D

      • shepherd@kbin.socialOP
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        @Biscuit Very reasonable question!

        I highly recommend this article, How to Kill a Decentralized Network (such as the Fediverse) by Ploum as a relevant factor in this discussion. Even if there’s parts you disagree with, I think that’s worth discussing too!

        To grossly oversimplify the contents of that article, I think federating in bad faith could look like:

        • Joining the ActivityPub protocol, intending to drown the initial userbase with their own so that the fediverse begins catering to the needs of the majority aka their users.
        • Introducing subtle bugs that make certain instances function suboptimally, but putting the onus on minor developers to fix it because major portions of the user base comes from them.
        • Adding features to the ActivityPub protocol that benefit all users, but forces most instances to adopt their practices.
        • Creating their own version of the protocol “ActivityPub+”. It’s initially open source and well documented, but increasingly deviates from ActivityPub, until it’s functionally closed source fully under their control. It’s also mandatory to interact their instances.
        • Defederating everyone who doesn’t fall in step, but that’s okay because 99% of content is now on MetaPub anyways. This fractures the Fediverse into confused micro shards (or compliant loyalists).
        • lml@remy.city
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          That’s a good breakdown, thanks! The bad thing is that I could see these issues happening even unintentionally, with the fact that we have a few large instances vs. many smaller ones. So far we seem to have everyone running the same code, straight from the repositories (at least functionality wise). For my own kbin instance though, I have technically changed things. I changed some code to make a custom logo appear nicely, I’ve added some padding here and there, etc. I have also thought about implementing an automatic job that clears posts tagged with ‘nsfw’ or other related things in the microblog feed.

          I might implement that, and then submit it to the kbin devs if it works well. There’s no guarantee that other admins/devs would do that as well. If they implement a feature that makes their community more popular, they would seem to have incentive to keep it private. And that’s where stuff like Meta comes in. If they implement rigorous content filtering, I doubt that would make it into the actual AP protocol. It would be the differentiating factor between using their ‘safe’ instance, vs. going rugged on an independent instance.

          They could say “we implement the ActivityPub protocol as specified” and they wouldn’t be wrong. They would just have some extras added onto the top to make their experience more polished. Easy to do when you are a for-profit and have plenty of devs. They would just argue that those are the features that make their interface different, like kbin and lemmy are different.

          The only way around it is for communities to agree that they will run the software as released, maybe with only cosmetic changes. Any improvements to functionality should be submitted to the devs so that the wider community can benefit.

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

            Kbin and Lemmy are licensed under the AGPL, so instance source code changes are required to be shared with those that connect to that instance (I assume that includes peer instances as well as users). Corpos can make their own proprietary instances, but they’ll have to start from scratch and not just piggyback on top of our work.