Corporations don’t just sit out on new technologies, and no matter how hard you try you can’t force them to. Defederating from Meta’s new project preemptively is naive, and will not do much of anything.
Protocols are going to be adopted by corporations, whether we like it or not. SMTP, LDAP, HTTP, IP and 802.11 are all examples of that. If it ends up that meta is able to destroy the fediverse simply by joining it, that is a design flaw on OUR end. Something would then clearly need to be different in order to prevent future abuse of the protocol.
FOSS is propped up by corporations. By for profit corporations. If you want to stop those corporations from killing projects, you put safety guards up to make sure that doesn’t happen. You don’t just shut them out and put your head in the sand.
When this was linked a previous time, I wrote up a reply to it which I think applies here as well, so I’m gonna shamelessly copy and paste myself 🙂
To your point, many of us will defederate, either out of politics or financial necessity. There’s rumors milling around that Meta / Threads will only initially federate with a few trusted larger instances and be monetarily compensated for it (aka those who will make a deal with the devil to moderate - more on my thoughts on that here).
It may come to the point where a lot of us are running on our own smaller “Fediverse”, intentionally divorced from Meta and those instances which have federated with Meta and taken their advertisements and paid posts. If this is the case, we must take the bad with the good - we will always be smaller and niche, and our less techno-idealistic friends will not join our tiny Fediverse because the barrier to entry will remain high.
It will follow the EEE flow along with their normal anti-competition tactics. First, they embrace: their interest in federation is only to give them the access to content that will make their platform not look empty, allowing them to put their coffers to work on drawing the majority share of users. Then they will extend: they will make sure their platform is compatible with ingesting other server content but others will be unable to federate their content (they will become “incompatible” later, due to “features”). Then they will extinguish competition: they’ll cut off what little engagement is left with those (inbound only) federated servers because they no longer need them and the majority of the remaining users will move to their platform because that is where the activity is.
Then Kbin/lemmy will be just like all the other random phpbb instances that no one really uses. Being naive won’t make things any less likely, yet there will always be gullible people who argue that “of course they will embrace the technology” and that everything else is just non-sense/wouldn’t have worked anyway/blah.
It doesn’t take long for the largest servers to have operating costs that they will happily allow Meta to burden in exchange for nearly any concession. The main problem is that, while Kbin/Lemmy is federated, it is federated in a manner that still places content in silos and allows single servers to “own” those spaces. It hasn’t really fixed the problem yet, it just spreads the problem out over a few more servers. Until spaces are universal (every server owns a slice of that community, spreading out the community instead of just the users), it will remain ripe for EEE.
Completely agreed on the concept of needing to federate out entire spaces (magazines / communities) - this is a huge gap currently, especially on kbin where nearly every community (and nearly every user) is on kbin.social .
My thought is that Lemmy and kbin, after fixing and updating core functionality (easier said than done), need to jump on the idea of instances having magazines/communities that pull from multiple other sources, rather than federating each community independently - e.g. I could have an @android which is pulling from @android , @android , etc, and the experience is relatively seamless - if someone drops out, yes we lose a lot of content, but others pick up the slack.
This would require more overhead from admins and instance owners to manage which other communities their own communities are pulling from, but I think it would be worthwhile for a better overall user experience and to help decentralize these communities in general.
I can’t edit and have my edits federated out (edits federate if someone is following you, not if you are following them) so I want to point out that those links are somehow pointing to users instead of communities, whoops. I was referring to e.g. https://the.coolest.zone/m/android being a collection including contents on that magazine, contents from https://kbin.social/m/android , contents from https://lemmy.world/c/android , etc.
… so I could host an instance with a magazine that is essentially a digest of federated instances, and I can add/remove based on whatever aligns with my principles?
I don’t think I have that right, sorry but if you could explain it a little differently, I’m still trying to understand how the fediverse is.
So, as an example. I am on the.coolest.zone which is where my account is registered. I have a magazine on it called [email protected], which is where I am viewing this thread. In fact, you will be able to view it here: https://the.coolest.zone/m/[email protected]
I have only three actual magazines on my own instance - random (this is necessary for all kbin instances to collect uncategorized posts), BestOfBlind, and Android (which was my attempt to create a magazine that collects threads based on hashtag, but it’s not working right). Everything else is a magazine which is actually a federated version of either a kbin magazine from another kbin community or a Lemmy community from a Lemmy instance.
The couple of things that seem to be missing or broken right now:
kbin and Lemmy are both very new applications, so these will likely shake themselves out over time, but it’s a bit of a rough experience right now. 😅
But kbin.social is fully compatible with Lemmy with almost the same number of users and many more communities (dozen of them has more subscribers than most-subscribed /kbin magazine). Maybe /kbin as a platform is much centralised. Threadiverse, not so much.
I’m afraid we will lose if we accept them until they do something bad. Given their track record, that’s just a matter of time. If we let them become important to the fediverse as long as they play nice, the final decision could be disastrous for the fediverse when they stop playing nice.
So the right thing to say seems for me: “No, this is our house. We don’t federate with you.”
That is a completely valid take here. My partner who runs our Mastodon instance will be preemptively defederating with Threads (on my suggestion), so I do agree with you, but I realize not everyone in the Fediverse may share that take - it’s a weighted scale where one end is “mass adoption of a Web 3.0 decentralized Fediverse” and the other end is “but adoption in which most people are on Threads will be centralization anyway, so we will have already failed.”
I think in any case it may not matter, as I believe Meta / Threads will only federate with instances that agree to follow their moderation standards - after all, Meta likely doesn’t want porn and Nazis federated to their communities because then they can’t run advertisements. As a Fediverse community, we’re pretty good at taking care of the Nazi thing, but Mastodon’s got an awful lot of porn on it.
It will really depend on which admins take that deal to be beholden to Meta’s standards, potentially opening themselves up not only to huge moderation concerns but to a future requirement of taking advertisements. I hope large instances will not. I would prefer to see the Fediverse operate separate from Threads, who will be using the ActivityPub protocol but not part of the larger Fediverse. Similar to how the conservative “truth.social” uses the Mastodon application and ActivityPub but is not part of the Fediverse because it is closed off.
A little off topic, but I was very surprised Reddit didn’t pursue a similar approach of “we will lower greatly the costs of API but we will serve advertisements in the API as regular posts, so you must display them and can’t strip them out.”