Unpopular opinion but defederating Meta is a terrible idea. What are people thinking will happen? Allow them to federate and you’ll have mastodon users able to view and interact with posts from Threads without needing to be concerned about ads or tracking, without giving over any more control of privacy than they would to any other fediverse instance, and without needing to possess accounts homed within the Meta infrastructure.
Defederate them, and anyone who wants to interact with anyone on threads will most likely need to maintain a presence on both and handover more personal data to Meta than they otherwise would.
Defederating is actively hostile to fediverse users.
Threads is new - unless you meet someone who for some reason only has a threads account, just talk to them elsewhere.
Otherwise, why is it the Fediverse user who has to get the threads account? Tell your people to make an account elsewhere. If you are conscientiously avoiding threads, you’re probably the only one in the relationship with a principle boundary to cross in this situation.
They have also already declared that if you federate with them, your instance has to abide by their code of conduct, so they already throwing their weight around.
You’re acting like there’s only two situations: The entire Fediverse defederates with them, or the entire Fediverse federates with them. That’s not the case.
I, personally, do not want to interact with anyone using Threads, because Meta has a proven history of poor moderation and of manipulating the narrative for political gain on Facebook and I see no reason to think they won’t do the same here. I am not the only one who holds this opinion. Those of us who feel this way can use instances that defederate with them, and have our way.
If you want to interact with them, you can maintain an account on an instance that does federate with them. You do not need to have a Threads account, nor does anyone else.
Instances can defederate from meta at any point they choose, should it become necessary in the future. Until then, it is a huge boon to the more decentralized parts of the fediverse to get content from where all the “normies” are, as well as giving more visibility to non-meta instances and giving said normies a road to the less data-hungry parts of the network.
honestly, i think only half-accepting them would be beneficial. it gives meta users a taste of the fediverse but locks them out of a whole bunch of cool stuff that they could have, if they just make an account on one of the instances that they already know because it’s in the half that does federate. we just need to ensure we never repeat xmpp’s mistake: meta users should never be a majority.
i’ll have to discuss this with our admin team, but my initial plan is to defederate meta if usage by them hits 25%. if a critical mass of the fediverse does that, in the worst case we’ll split off from them before taking damage, and in the best case we’ll actively siphon away their user base. (and if any other tech giant enters the fray, we’ll just have to include them in the 25% quota as well.)
update: we discussed the topic and went for an immediate defederation
Plus, the more entwined threads is with the rest of the fediverse, the harder it’ll be for them to break off. Users will be following Mastodon accounts and posting in Lemmy communities and if Meta does something to break that, they’re the ones that’ll get the backlash, not the fediverse. We’ll just continue along as normal.
If they become so ubiquitous that all you see are Threads messages, all they have to do is start adding their own extensions to ActivityPub and degrade the experience of everyone who is not using their app.
What kinds of extensions should the typical activitypub user be worried about? I don’t care if Meta adds payments or virtual avatars or whatever–if the core functionality of the Threads app is simple microblogging, it should be perfectly interoperable with that side of the fediverse.
The more likely effect IMO (if Meta holds to their word on enabling federation on their side) is that other large social media companies (e.g. reddit, twitter) will feel pressured to federate and that will make the fediverse better, not worse.
My account is on kbin.social but I’m working on getting kbin self hosted. When I do, I’ll absolutely be federating with Threads whether or not kbin.social does.
A cool post pops up in your feed. You click it. You are met with an overlay that says “Sorry, this post isn’t compatible with your browser. Please log in to Threads.”
Embrace, they join the fediverse seemingly in good faith. Bringing their larger userbase to massively increase the size of the fediverse.
Extend, they add some features that are convenient when interacting with their base across the fediverse. But these conveniences require proprietary software integration.
Extinguish, once enough users and platforms are tied into the conveniences of extend, they use that to force compliance. Stricter and stricter rules on their proprietary software. Comply or die.
The fediverse won’t be gone afterwards, but if it EEE works then we will end up very stifled.
You’re severely underestimating the budget Meta can throw at this. Mastodon/Lemmy/etc. right now are largely volunteer-run as opposed to full-time employees.
I wouldn’t underestimate them though. After all, they own some of the biggest social network platforms on the globe and have the formula to hook people up down to a t.
While Threads is federated social circles and communities will have time to form. Thread users will by nature of having the support of a corporate juggernaut, be the lions share of users on the 'verse. When threads pull the plug, the Fedverse becomes a ghost town overnight and everyone not on Threads will be forced to migrate if they want to keep their social circles and communities intact.
I think few people would migrate away in that scenario. Some might create additional accounts (none of this is zero-sum). It’s not unlikely that Mastodon itself will become bigger because of it, and it’ll get hard for Meta to unilaterally pull the plug - a bit like email.
Here is an example of a corpo dealing a blow to an open source project. The article covers an example of Microsoft and Google killing a competing open source project(s).
The idea is that at first threads.net will seem “normal”, like all the other fediverses
Then they start adding features that either break against other servers, or straight up aren’t supported, making threads.net seem more enticing just because all the neat features aren’t on the other sites.
Think how Internet Explorer killed Netscape with all the Page Load errors caused by ActiveX, yet everyone wanted ActiveX sites.
Once they’ve walked through the path of least resistance and grabbed the bulk of the traffic, they just defederate from everyone.
Couldn’t any instance or app do this already? Like #peertube does videos in a way that isn’t necessarily fully federated with #mastodon. We get partial functionality everywhere and some places will have some extra things. If it is popular enough, then add it to the standard and let everyone who wants it add the functionality.
Yep - best option is to defederate them well before they gain traction & start creating problem by not contributing back to the protocol in a way that benefits everyone.
I think after the community got burned by Microsoft & then google we’re finally learning.
meta is not here to promote open networks. They will do more harm than good. If you want to learn more about how google achieved it with the XMPP you can read the story here https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html written by one of the core developers.
This is an interesting article, but I don’t think it’s fair to blame Google for the death of XMPP. Google were the largest consumers of XMPP at one point, sure, but Google was in no way (and never has been) the market leader in communications applications. Google talk came and went, Hangouts came and went and so on. The argument of “When google pulled the plug, XMPP users had to use something else to keep in touch with friends” is equally true of Google messenger users as well. I don’t know anyone that ever exclusively used a Google messenger app, now or then.
Google isn’t entirely innocent here, they definitely didn’t treat the protocol with the respect it deserved, but the development of XMPP was/is fraught with its own problems. I remember setting up an XMPP network for use in a small office as an internal chat tool, it was a nightmare of an experience. Different XMPP Clients had different levels of compatibility with different XMPP servers, many of the clients were just poor overall and the user-experience left a lot to be desired. All we wanted was a simple instant messenger for work, in the days before Slack and Teams. We ended up using OpenFire because it was developed in tandem with Spark, it was basic but worked well for our needs but any time I tried to adopt a different messenger, half the features didn’t work.
While I think I agree we shouldn 't just defederate them. This is for a user to block them.
And if you tell users how they can block them, it will maybe take a bit of pressure away from admins to do it.
During the first wave of Twitter refugees , there was a lot of explaining about ignoring and blocking users. Which can never hurt IMHO. Certainly because it can decrease the load on the volunteers that run an instance
Lots of naivety here. Big corps only act in their own interest. They view the world in terms of opportunities and threats. Eating Twitter’s lunch is an opportunity. The Fediverse is too small to be worth much today, but someday it might grow up and challenge the status quo. That makes it a threat.
It isn’t the people. It’s just if I already decided not to use Facebook or twitter. Why would I get back into bed with the devil on an experimental product?
I’m all for federating with them. But give the user the ability to defederate their posts/comments based off their settings. I would rather my information not be supplied to any company owned by Facebook, that’s just me.
That’s completely fine, but just because a knob can be lockpick doesn’t mean you leave it unlocked.
Granted I have very little experience with activity pub, but I would expect that it should be very possible to have something similar to how defederating Works where if you don’t allow it to be sent to a specific Community it just won’t communicate.
edit: Looking back at it though, it wouldn’t stop them from just opening a secondary instance nobody knows about, having it set to private and then just running it as an info collector I don’t think.
I’m with you. What’s the hate with Threads? It’s going to basically just be like another Mastodon instance anyway, right? Just keep using whichever instance you want and Threads will end up adding more content to the fediverse. I don’t really see the downside.
The Fediverse is a decentralized network of servers communicating through the ActivityPub protocol.
Large corporations like Google and Microsoft have a history of either trying to control or make decentralized networks irrelevant.
Google joined the XMPP federation initially but implemented their own closed version, causing compatibility issues and slowing down the development of XMPP.
Eventually, Google stopped federating with other XMPP servers, leading to a decline in XMPP’s popularity and growth.
Microsoft used similar tactics to hinder competing projects, such as the Samba network file system and open source office suites like OpenOffice and LibreOffice.
The strategy involves extending protocols or developing new ones to deny entry to open source projects.
Proprietary formats and complicated specifications are used to maintain dominance in markets.
Meta’s potential entry into the Fediverse raises concerns as it could lead to fragmentation and a loss of freedom.
The Fediverse should focus on its values of freedom, ethics, and non-commercialism to avoid being co-opted by large corporations.
How a new federated decentralized platform can avoid this fate:
Stay true to the principles: The platform should prioritize and uphold the values of freedom, openness, and decentralization.
Develop open and robust protocols: Use open standards and ensure the protocol’s specifications are transparent, well-documented, and not controlled by a single entity.
Foster a strong community: Encourage collaboration, participation, and diversity within the community to avoid reliance on any single company or organization.
Emphasize user control: Give users control over their data and privacy, allowing them to choose which servers and communities to join and ensuring their content is not subject to corporate surveillance.
Focus on user experience: Create a user-friendly interface and provide features that attract and retain users, making it easy for them to engage and connect with others.
Avoid centralization of power: Design the platform in a way that distributes authority and influence across the network, preventing any single entity from gaining too much control.
Promote interoperability: Support compatibility with other decentralized platforms and protocols to encourage communication and collaboration across different networks.
Educate and raise awareness: Educate users about the benefits of decentralized platforms, the risks of centralized control, and the importance of supporting independent, community-driven initiatives.
By following these principles, a new federated decentralized platform can strive to maintain its integrity, preserve user freedom, and resist the influence of large corporations seeking to control or make it irrelevant.
My reading of that isn’t that Google killed XMPP, it’s that they thought XMPP would be useful for the userbase they brought in, they realised it wasn’t, and they ditched it. There’s no indication that XMPP had the userbase and lost it to Google, or even that XMPP had features that were stolen by Google
For what it’s worth, I agree with your reading, and nobody has described what I consider to be a plausible scenario for how exactly “embrace, extend, extinguish” would actually work here.
I don’t think Meta should be given the benefit of the doubt or anything and people may have differing opinions about the likely user base for Threads, but I don’t think this is any real concern to the fediverse in general.
The point is simple, the moment you have the biggest chunk of the userbase, you have more weight in establishing praxis for standards & protocols. In fact, the protocol needs to catch up with you, rather than viceversa. Google did the same with Chrome, for example. Try to start a browser today, and with all the stuff that Google forced into standards and that your browser need to comply with, you will fail. Even just forcing a pace in changes to ActivityPub can mean that a number of tools that are developed by volunteers won’t be able to keep up.
Imagine Meta brings in 100m users. This is a fraction of their userbase, but it is 8x the whole fediverse. Imagine now that they make some change that doesn’t comply with ActivityPub, what do you do, break the tool that is used by the 90% of the users, or adapt? And what if they push changes to ActivityPub, so that everyone needs to catch up quickly: lemmy, mastodon, pixelfed, etc. How soon before some tools with less active development will die because non-compliant? (Similarly to how some browser break with some sites)
Been saying exactly this for ages now, defederating causes far more harm than good, and is just shitty to do as an instance owner to be honest, anyone can defederate client side from meta if they wish to, this is entirely possible in mastodon, but if the owner of the mastodon instance defederates from meta, you as a user cannot make that decision for yourself.
Which is a bit ironic because people escape meta due to censorship, yet a lot of instances are blocking off meta for all their users due to their own ideologies. If you’re defederating from an instance due to legal issues, by all means do so. But if you’re defederating all your users from meta because you personally dislike facebook… come on.
If you defederate from meta, you’re forcing your users to either switch instances or worst case… installing meta’s invasive applications. If you federate with meta, you can optionally communicate with meta users, without having to use meta’s applications along with their ads/tracking.
When Thread finally enable federation, just unleash the Lemmy meme community there. We’ll see how fast they roll back the federation feature on their own after their feeds are getting flooded with beans.
Unpopular opinion but defederating Meta is a terrible idea. What are people thinking will happen? Allow them to federate and you’ll have mastodon users able to view and interact with posts from Threads without needing to be concerned about ads or tracking, without giving over any more control of privacy than they would to any other fediverse instance, and without needing to possess accounts homed within the Meta infrastructure.
Defederate them, and anyone who wants to interact with anyone on threads will most likely need to maintain a presence on both and handover more personal data to Meta than they otherwise would.
Defederating is actively hostile to fediverse users.
Threads is new - unless you meet someone who for some reason only has a threads account, just talk to them elsewhere.
Otherwise, why is it the Fediverse user who has to get the threads account? Tell your people to make an account elsewhere. If you are conscientiously avoiding threads, you’re probably the only one in the relationship with a principle boundary to cross in this situation.
They have also already declared that if you federate with them, your instance has to abide by their code of conduct, so they already throwing their weight around.
I think that’s essentially true for any instance, though. You don’t federate with instances you don’t want to.
Meta joining the fediverse is like Raytheon joining anti-war protests. They are not there for sincere participation.
Maybe, but smart tactics means abusing their current good will and shutting them down when. It runs out.
You’re acting like there’s only two situations: The entire Fediverse defederates with them, or the entire Fediverse federates with them. That’s not the case.
I, personally, do not want to interact with anyone using Threads, because Meta has a proven history of poor moderation and of manipulating the narrative for political gain on Facebook and I see no reason to think they won’t do the same here. I am not the only one who holds this opinion. Those of us who feel this way can use instances that defederate with them, and have our way.
If you want to interact with them, you can maintain an account on an instance that does federate with them. You do not need to have a Threads account, nor does anyone else.
No worries once threads becomes big enough they will defederate from fediverse /s That sure will be hostile to fediverse users.
I agree with you.
Instances can defederate from meta at any point they choose, should it become necessary in the future. Until then, it is a huge boon to the more decentralized parts of the fediverse to get content from where all the “normies” are, as well as giving more visibility to non-meta instances and giving said normies a road to the less data-hungry parts of the network.
Yes exactly
This is something I can’t understand. There’s obviously no profit motive to push fediverse to everyone, and most content is dogshit.
Can you explain why you find either to be preferable?
Reading material: https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
deleted by creator
honestly, i think only half-accepting them would be beneficial. it gives meta users a taste of the fediverse but locks them out of a whole bunch of cool stuff that they could have, if they just make an account on one of the instances that they already know because it’s in the half that does federate. we just need to ensure we never repeat xmpp’s mistake: meta users should never be a majority.
i’ll have to discuss this with our admin team, but my initial plan is to defederate meta if usage by them hits 25%. if a critical mass of the fediverse does that, in the worst case we’ll split off from them before taking damage, and in the best case we’ll actively siphon away their user base. (and if any other tech giant enters the fray, we’ll just have to include them in the 25% quota as well.)
update: we discussed the topic and went for an immediate defederation
Plus, the more entwined threads is with the rest of the fediverse, the harder it’ll be for them to break off. Users will be following Mastodon accounts and posting in Lemmy communities and if Meta does something to break that, they’re the ones that’ll get the backlash, not the fediverse. We’ll just continue along as normal.
People are concerned about Facebook/Meta trying to Embrace, Extend, Extinguish ActivityPub - if I’ve understood correctly.
People keep saying EEE as if that’s a point in and of itself without really explaining how in this instance
If they become so ubiquitous that all you see are Threads messages, all they have to do is start adding their own extensions to ActivityPub and degrade the experience of everyone who is not using their app.
What kinds of extensions should the typical activitypub user be worried about? I don’t care if Meta adds payments or virtual avatars or whatever–if the core functionality of the Threads app is simple microblogging, it should be perfectly interoperable with that side of the fediverse.
The more likely effect IMO (if Meta holds to their word on enabling federation on their side) is that other large social media companies (e.g. reddit, twitter) will feel pressured to federate and that will make the fediverse better, not worse.
My account is on kbin.social but I’m working on getting kbin self hosted. When I do, I’ll absolutely be federating with Threads whether or not kbin.social does.
A cool post pops up in your feed. You click it. You are met with an overlay that says “Sorry, this post isn’t compatible with your browser. Please log in to Threads.”
Over half your feed are Threads posts.
Speculative example.
Embrace, they join the fediverse seemingly in good faith. Bringing their larger userbase to massively increase the size of the fediverse.
Extend, they add some features that are convenient when interacting with their base across the fediverse. But these conveniences require proprietary software integration.
Extinguish, once enough users and platforms are tied into the conveniences of extend, they use that to force compliance. Stricter and stricter rules on their proprietary software. Comply or die.
The fediverse won’t be gone afterwards, but if it EEE works then we will end up very stifled.
The outcome then would be that Meta’s instance would be defederated/defederate itself - how would that be different from now?
They’d probably attract more people (even people that are here right now) before doing so. Thus creating another centralized platform.
If the Threads product was so superior, and Mastodon so unable to respond that millions would leave Mastodon - sure. I doubt it though…
You’re severely underestimating the budget Meta can throw at this. Mastodon/Lemmy/etc. right now are largely volunteer-run as opposed to full-time employees.
That argument suggests open source products couldn’t possibly compete with a closed-source alternative.
I wouldn’t underestimate them though. After all, they own some of the biggest social network platforms on the globe and have the formula to hook people up down to a t.
While Threads is federated social circles and communities will have time to form. Thread users will by nature of having the support of a corporate juggernaut, be the lions share of users on the 'verse. When threads pull the plug, the Fedverse becomes a ghost town overnight and everyone not on Threads will be forced to migrate if they want to keep their social circles and communities intact.
I think few people would migrate away in that scenario. Some might create additional accounts (none of this is zero-sum). It’s not unlikely that Mastodon itself will become bigger because of it, and it’ll get hard for Meta to unilaterally pull the plug - a bit like email.
Here is an example of a corpo dealing a blow to an open source project. The article covers an example of Microsoft and Google killing a competing open source project(s).
Most comprehensive article on this topic I’ve seen since this Meta shenanigan started. Thanks for the read
that’s exactly what I was thinking
The idea is that at first threads.net will seem “normal”, like all the other fediverses
Then they start adding features that either break against other servers, or straight up aren’t supported, making threads.net seem more enticing just because all the neat features aren’t on the other sites.
Think how Internet Explorer killed Netscape with all the Page Load errors caused by ActiveX, yet everyone wanted ActiveX sites.
Once they’ve walked through the path of least resistance and grabbed the bulk of the traffic, they just defederate from everyone.
Couldn’t any instance or app do this already? Like #peertube does videos in a way that isn’t necessarily fully federated with #mastodon. We get partial functionality everywhere and some places will have some extra things. If it is popular enough, then add it to the standard and let everyone who wants it add the functionality.
Yep - best option is to defederate them well before they gain traction & start creating problem by not contributing back to the protocol in a way that benefits everyone.
I think after the community got burned by Microsoft & then google we’re finally learning.
Some instances will federate and some will block them. It doesn’t have to be all one or the other.
meta is not here to promote open networks. They will do more harm than good. If you want to learn more about how google achieved it with the XMPP you can read the story here https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html written by one of the core developers.
This is an interesting article, but I don’t think it’s fair to blame Google for the death of XMPP. Google were the largest consumers of XMPP at one point, sure, but Google was in no way (and never has been) the market leader in communications applications. Google talk came and went, Hangouts came and went and so on. The argument of “When google pulled the plug, XMPP users had to use something else to keep in touch with friends” is equally true of Google messenger users as well. I don’t know anyone that ever exclusively used a Google messenger app, now or then.
Google isn’t entirely innocent here, they definitely didn’t treat the protocol with the respect it deserved, but the development of XMPP was/is fraught with its own problems. I remember setting up an XMPP network for use in a small office as an internal chat tool, it was a nightmare of an experience. Different XMPP Clients had different levels of compatibility with different XMPP servers, many of the clients were just poor overall and the user-experience left a lot to be desired. All we wanted was a simple instant messenger for work, in the days before Slack and Teams. We ended up using OpenFire because it was developed in tandem with Spark, it was basic but worked well for our needs but any time I tried to adopt a different messenger, half the features didn’t work.
While I think I agree we shouldn 't just defederate them. This is for a user to block them. And if you tell users how they can block them, it will maybe take a bit of pressure away from admins to do it.
During the first wave of Twitter refugees , there was a lot of explaining about ignoring and blocking users. Which can never hurt IMHO. Certainly because it can decrease the load on the volunteers that run an instance
Lots of naivety here. Big corps only act in their own interest. They view the world in terms of opportunities and threats. Eating Twitter’s lunch is an opportunity. The Fediverse is too small to be worth much today, but someday it might grow up and challenge the status quo. That makes it a threat.
Strongly disagree here, better to cast them down now while the chance is there. No mercy or quarter provided to Meta considering their track record.
If anyone is foolish enough to go there, let them, but do not drag us towards them.
This opinion doesn’t seem unpopular to me.
I don’t want to interact with anyone on Threads. It is new and it is Facebook.
Was about to say just that. I’ll love to reject people that only follows big corpos.
It isn’t the people. It’s just if I already decided not to use Facebook or twitter. Why would I get back into bed with the devil on an experimental product?
I’m all for federating with them. But give the user the ability to defederate their posts/comments based off their settings. I would rather my information not be supplied to any company owned by Facebook, that’s just me.
The information they could get is already public. That’s how Activity Pub works.
That’s completely fine, but just because a knob can be lockpick doesn’t mean you leave it unlocked.
Granted I have very little experience with activity pub, but I would expect that it should be very possible to have something similar to how defederating Works where if you don’t allow it to be sent to a specific Community it just won’t communicate.
edit: Looking back at it though, it wouldn’t stop them from just opening a secondary instance nobody knows about, having it set to private and then just running it as an info collector I don’t think.
yep, your edit is correct - and is what the previous poster meant by public info
I’m with you. What’s the hate with Threads? It’s going to basically just be like another Mastodon instance anyway, right? Just keep using whichever instance you want and Threads will end up adding more content to the fediverse. I don’t really see the downside.
In case you’re wondering why all the down votes, it’s because of this concept:
https://ploum.net/2023-06-23-how-to-kill-decentralised-networks.html
Edit: Heres a summary I had in another post.
Summary:
The Fediverse is a decentralized network of servers communicating through the ActivityPub protocol.
Large corporations like Google and Microsoft have a history of either trying to control or make decentralized networks irrelevant.
Google joined the XMPP federation initially but implemented their own closed version, causing compatibility issues and slowing down the development of XMPP.
Eventually, Google stopped federating with other XMPP servers, leading to a decline in XMPP’s popularity and growth.
Microsoft used similar tactics to hinder competing projects, such as the Samba network file system and open source office suites like OpenOffice and LibreOffice.
The strategy involves extending protocols or developing new ones to deny entry to open source projects.
Proprietary formats and complicated specifications are used to maintain dominance in markets.
Meta’s potential entry into the Fediverse raises concerns as it could lead to fragmentation and a loss of freedom.
The Fediverse should focus on its values of freedom, ethics, and non-commercialism to avoid being co-opted by large corporations.
How a new federated decentralized platform can avoid this fate:
Stay true to the principles: The platform should prioritize and uphold the values of freedom, openness, and decentralization.
Develop open and robust protocols: Use open standards and ensure the protocol’s specifications are transparent, well-documented, and not controlled by a single entity.
Foster a strong community: Encourage collaboration, participation, and diversity within the community to avoid reliance on any single company or organization.
Emphasize user control: Give users control over their data and privacy, allowing them to choose which servers and communities to join and ensuring their content is not subject to corporate surveillance.
Focus on user experience: Create a user-friendly interface and provide features that attract and retain users, making it easy for them to engage and connect with others.
Avoid centralization of power: Design the platform in a way that distributes authority and influence across the network, preventing any single entity from gaining too much control.
Promote interoperability: Support compatibility with other decentralized platforms and protocols to encourage communication and collaboration across different networks.
Educate and raise awareness: Educate users about the benefits of decentralized platforms, the risks of centralized control, and the importance of supporting independent, community-driven initiatives.
By following these principles, a new federated decentralized platform can strive to maintain its integrity, preserve user freedom, and resist the influence of large corporations seeking to control or make it irrelevant.
My reading of that isn’t that Google killed XMPP, it’s that they thought XMPP would be useful for the userbase they brought in, they realised it wasn’t, and they ditched it. There’s no indication that XMPP had the userbase and lost it to Google, or even that XMPP had features that were stolen by Google
For what it’s worth, I agree with your reading, and nobody has described what I consider to be a plausible scenario for how exactly “embrace, extend, extinguish” would actually work here.
I don’t think Meta should be given the benefit of the doubt or anything and people may have differing opinions about the likely user base for Threads, but I don’t think this is any real concern to the fediverse in general.
The point is simple, the moment you have the biggest chunk of the userbase, you have more weight in establishing praxis for standards & protocols. In fact, the protocol needs to catch up with you, rather than viceversa. Google did the same with Chrome, for example. Try to start a browser today, and with all the stuff that Google forced into standards and that your browser need to comply with, you will fail. Even just forcing a pace in changes to ActivityPub can mean that a number of tools that are developed by volunteers won’t be able to keep up.
Imagine Meta brings in 100m users. This is a fraction of their userbase, but it is 8x the whole fediverse. Imagine now that they make some change that doesn’t comply with ActivityPub, what do you do, break the tool that is used by the 90% of the users, or adapt? And what if they push changes to ActivityPub, so that everyone needs to catch up quickly: lemmy, mastodon, pixelfed, etc. How soon before some tools with less active development will die because non-compliant? (Similarly to how some browser break with some sites)
Really appreciate the detailed response. Makes more sense why people would be wary of it after reading through that.
Been saying exactly this for ages now, defederating causes far more harm than good, and is just shitty to do as an instance owner to be honest, anyone can defederate client side from meta if they wish to, this is entirely possible in mastodon, but if the owner of the mastodon instance defederates from meta, you as a user cannot make that decision for yourself.
Which is a bit ironic because people escape meta due to censorship, yet a lot of instances are blocking off meta for all their users due to their own ideologies. If you’re defederating from an instance due to legal issues, by all means do so. But if you’re defederating all your users from meta because you personally dislike facebook… come on.
If you defederate from meta, you’re forcing your users to either switch instances or worst case… installing meta’s invasive applications. If you federate with meta, you can optionally communicate with meta users, without having to use meta’s applications along with their ads/tracking.
When Thread finally enable federation, just unleash the Lemmy meme community there. We’ll see how fast they roll back the federation feature on their own after their feeds are getting flooded with beans.
THIS IS THE WAY…