Embrace: Join the fediverse with your existing user base that dwarfs the fediverse’s existing user base, and with infinitely more money.
Extend: Use your size, in terms of users and capital, to steer the direction of the ActivityPub fediverse standard to your advantage and your competitors’ disadvantage. You see everyone else as a competitor because you are a corporation seeking to monopolize the user base for profit.
Google is adding code to Chrome that will send tamper-proof information about your operating system and other software, and share it with websites. Google says this will reduce ad fraud. In practice, it reduces your control over your own computer, and is likely to mean that some websites will block access for everyone who’s not using an “approved” operating system and browser. It also raises the barrier to entry for new browsers, something Google employees acknowledged in an unofficial explainer for the new feature, Web Environment Integrity (WEI).
That’s a common misconception actually, any and all data available via federation is already public and easily scrapable even without running an instance of one’s own. Defederating only hides (in this case) Threads content from users on the instance doing the defederating, but the data is still public. Not to mention copies of it would still be fully available on any extant federated instances.
But they would still be unable to embrace (and, by extension, extend and extinguish) because users from Threads would be unable to interact with users from other instances. Basically, they’d be unable to get rid of a potential competitor using the EEE method.
But how could interoperability lead to extinguishing? That’s the part I don’t understand. By what means could Threads “extinguish” the network of instances that stay federated?
It prevents that specific strategy that would culminate in extinguishing. The idea being to siphon users away from other platforms, then add features that other platforms won’t or can’t implement, and use that to create an image of their own platform being better, having more features.
If they succeed at having a lot of users oblivious to what’s happening, they will use those features, and when they don’t work for people on other platforms, they will blame the other platforms instead of their own, further cultivating the image that other platforms are broken/unreliable.
In the end, they leave other platforms unable to compete, forcing users to either have a “broken”/incomplete experience, or migrate to their platforms. (Or leave the fediverse entirely). Or they can simply stop federating at that point, after users have left for their platform, cutting off the rest of the fediverse from content hosted on their platform.
The way defederating prevents a strategy like that is by cutting them off before they can get a foothold - they can’t make users feel left out if they don’t get to influence their experience in the first place.
Can you explain what that means in this context? How does defederating Threads prevent Meta from extinguishing anything?
Or what Google does right now with Chrome and web standards.
For those unaware of Google’s latest web browser malarkey: Web Environment Integrity
EFF/Cory Doctorow/Jacob Hoffman-Andrews: Your Computer Should Say What You Tell It To Say
The XMPP article was good, thanks!
But how would defederating prevent any of that?
It would make Threads unable to see content from instances defederating it and vice versa, preventing the Embrace step.
That’s a common misconception actually, any and all data available via federation is already public and easily scrapable even without running an instance of one’s own. Defederating only hides (in this case) Threads content from users on the instance doing the defederating, but the data is still public. Not to mention copies of it would still be fully available on any extant federated instances.
But they would still be unable to embrace (and, by extension, extend and extinguish) because users from Threads would be unable to interact with users from other instances. Basically, they’d be unable to get rid of a potential competitor using the EEE method.
But how could interoperability lead to extinguishing? That’s the part I don’t understand. By what means could Threads “extinguish” the network of instances that stay federated?
The same way we prevented any of that up ’till now: by doing our own thing on our own terms.
It prevents that specific strategy that would culminate in extinguishing. The idea being to siphon users away from other platforms, then add features that other platforms won’t or can’t implement, and use that to create an image of their own platform being better, having more features. If they succeed at having a lot of users oblivious to what’s happening, they will use those features, and when they don’t work for people on other platforms, they will blame the other platforms instead of their own, further cultivating the image that other platforms are broken/unreliable. In the end, they leave other platforms unable to compete, forcing users to either have a “broken”/incomplete experience, or migrate to their platforms. (Or leave the fediverse entirely). Or they can simply stop federating at that point, after users have left for their platform, cutting off the rest of the fediverse from content hosted on their platform.
The way defederating prevents a strategy like that is by cutting them off before they can get a foothold - they can’t make users feel left out if they don’t get to influence their experience in the first place.
Also, if the best people are on the instances threads can’t see, their userers will feel left out.