Is kbin.social anti-corporation? Should it be?

shepherd@kbin.social to /kbin meta@kbin.social – 72 points –

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?

78

You are viewing a single comment

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.

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.

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.

I say they can, this is kind of what we have seen with Chrome tbh.

Google came in, made an awesome browser got market majority and started just implementing things to the point where its hard to keep up and the various specification bodies kind of just have to ratify things that is already in the browser or become obsolete, afaik this happened with components such as the in browser DRM which by design makes it hard to implement.

I think this can come true as long as we let them insert themselves into the ecosystem. The difference here is that we have the option to keep our part of the fediverse pristine by not federating with these servers, even if we doom ourselves to obscurity by doing it.

this is the closest someone has come to convincing me that this would be a big problem. i still happen to think that the smaller instances will be fine in the long run. big consolidated instances are inevitable because people like being where people are. look at twitter and facebook. i suspect the worst problem we'd have is people switching from "facebook" to "federated facebook".

now maybe meta will be able to fuck with the standards body that is responsible for the standard. that would be very bad. then i'd be on board. until they do that, i won't worry. i'm open to having my mind changed, but i've found most arguments to be unconvincing as they basically boil down to "but they're big!"

because people like being where people are

That's exactly the problem with mega-instances. From the link posted above:

As expected, no Google user bated an eye. In fact, none of them realised. At worst, some of their contacts became offline. That was all. But for the XMPP federation, it was like the majority of users suddenly disappeared. Even XMPP die hard fanatics, like your servitor, had to create Google accounts to keep contact with friends. Remember: for them, we were simply offline. It was our fault.