this post was submitted on 23 Jun 2023
72 points (100.0% liked)

/kbin meta

16 readers
2 users here now

Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign

founded 1 year ago
 

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?

you are viewing a single comment's thread
view the rest of the comments
[โ€“] wagesj45@kbin.social 2 points 1 year ago (1 children)

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!"

[โ€“] Jo@readit.buzz 7 points 1 year ago

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.