Hacker News Reader

Comment by dabedee | Hacker News Reader

This reminds me of the "embrace, extend, extinguish" strategies Microsoft used extensively with Linux and open source software in the 90s. From [1]: "a phrase that the U.S. Department of Justice found that was used internally by Microsoft to describe its strategy for entering product categories involving widely used standards, extending those standards with proprietary capabilities, and then using those differences in order to strongly disadvantage its competitors."

[1] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

View on HN

There's a lot of discussion about that! Here's a very good article on the EEE threat. https://ploum.net/2023-06-23-how-to-kill-decentralised-netwo...

Personally I think it's more an "embrace, extend, and exploit" approach; a decentralized model could work well for Meta, for example if they do revenue-sharing on ads hosted by other instances (think Disney or LA Lakers).

Update: here's another good article looking at how Meta could embrace and extend -- again, not extinguish. https://darnell.day/heavy-meta-four-business-reasons-why-ins...

In my personal (subjective) opinion, XMPP died because of entirely different primary reason: it, by design, had trouble working on mobile devices. Keeping the connection was either battery-expensive or outright impossible, and using OS native push notifications had significant barriers. At the very least, that's why I stopped.

It's not like Google had "extinguished" anything, it's more like the "largest server went uncooperative and removed themselves". Sucked for people who were able to chat before and got separated, but I disagree with painting this as some sort of fatal blow.

I don't think there's some statistics on reasons why people stopped using XMPP, but I don't believe Google is the reason for it. I'd speculate that it just coincided with the beginning of the smartphone era and this whole "Google killed XMPP" is a convenient myth.

It's more that there is more to a complicated story than that, but that Google dropped it when it did surely was important at the time. To put it the other way around, had Google continued to run a federated chat, Android would have had first class support in no time. The fact that third party real time messaging never worked well in Android, and really bad in GApps, is related to this decision.

Agreed that these other issues were a problem for XMPP. Christina Warren made this exact point on Mastodon a few hours ago -- in response to a post from Evan Prodromou that talked about the role that spam and harassment played and how he and others in the XMPP community didn't diversify the network. So, there are multiple factors. That said, I still think the post I linked to is very much worth reading.

It is a valid opinion, and the events described there took place, I just - personally - don't believe the outcomes were caused by the events described, they feel more like coincidences to me. Although Google dropped XMPP at least partially for the same reasons it died - trouble with architecture that made it problematic mobile.

And the comparison is not fair. XMPP was meant to be extended, so complaining about the second "E" in "EEE" is IMHO questionable. Google left a bunch of useful XEPs and even a Free Software codebase (libjingle) that others still use to the day, and I don't see anything wrong with this (and I'm surely no fond of Google, but that's not something I'd bash them for). This is feels very different from what may possibly happen in the whole Meta/Threads/Fediverse/ActivityPub situation - I mean, it's not likely Meta starts contributing to Mastodon project or something. In my understanding, EEE is more applicable to Microsoft and IE (where it surely happened, and a lot) than to Google and XMPP.

IMHO the article is a good read to at the very least be familiar with the events and understand the argument - but personally I find myself disagreeing with the presented arguments, thinking it's quite a stretch. Of course, that's my own, purely subjective opinion.

Yeah when there are multiple causes it's hard to know how much each contributed.

AcitivityPub's also meant to be extended, there are FEPs, and it's likely that the working group will come up with a new version as well. That said there certainly are differences between XMPP and ActivityPub, most people say the ActivityPub ecosystem is significantly farther along than XMPP was.

I could imagine Meta doing an open-source AP server (and with a fresh start it would be cleaner base than Mastodon). I also wouldn't be surprised if the release a app building toolkit / framework / whatever ... there isn't a good one now, they do that stuff well, and as they introduce proprietary AP extensions then they toolkit is a good way to get people to adopt them. But it's very hard to know at this point, it's also possible it's just PR spin and they won't really invest in it. We shall see.

Anyhow, good discussion, thanks much!

As many others have said before, this isn't very likely to happen for many of the reasons it never happened with the web or Linux.

- ActivityPub is an open protocol. If Meta goes all-in on it, they'll be implementing a transparent spec everyone knows. Modifying that would send obvious shockwaves through the network and signal their non-cooperation. There isn't a covert way for them to really try this.

- Mastodon itself is AGPL licensed, meaning any Meta fork (for whatever reason) would be subject to "provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version."[0]

- Meta has no reason to. If they decide the app is sufficiently popular without ActivityPub integration, then things return to the status-quo for Mastodon. Meta loses what little control they had over the direction of the standard/protocol/applications and nothing really changes.

[0] https://www.gnu.org/licenses/agpl-3.0.html

There's no reason for Meta to use Mastodon in order to federate, so I don't see why the license of Mastodon is relevant.

Then there's nothing for them to extend or extinguish. If they're not able to manipulate the client and they can only control the content on their own server, what leverage does Meta have to extinguish the fediverse?

They can potentially try to make changes to the protocol, and try to leverage their users numbers to force people to accept it. I think, though, that they'll find that a lot of us are stubborn and don't like them and will not react well to that.

Which is what mastodon already does. It has extended the ActivityPub protocol in a few places. Everyone copies because you must work against Mastodon to really participate.

Change is fine when they make sense and are made by a party people aren't extremely suspicious and at times hostile to. Even sometimes if you don't fully agree with every aspect.

It doesn't have to be a technical strategy, but a UX path to EEE.

I've been thinking about this in terms of Lemmy (also built on ActivityPub), which I understand isn't currently on the table for interop (but if Facebook is after Twitter's lunch, why shouldn't they be after Reddit's). It could even be the same application - Kbin is another AP service which has separate tabs for "link aggregation" and "microblogging" (Reddit and Twitter, respectively).

With Lemmy, the way a large corp could come in and push it around is by simply creating it's own version of the top 100 (or N, whatever) communities, and automatically subscribing users into them based on their interests (already known, due to existing accounts/profiles elsewhere). c/linux on lemmy.ml has ~6k subscribers, and is the largest Linux community on Lemmy, afaict. It's not unreasonable to think a large corp willing to pull in its existing userbase couldn't increase that by an order of magnitude in very short order. Overnight, those communities become the place where conversations are happening on those topics (maybe even with some pre-seeded content) and the existing lemmy communities stagnate.

Fast forward a while and one day BigCorp decides to pull the plug. Existing non-BigCorp Lemmy users are now separated from the communities they've been in and need to create BigCorp accounts. You could argue that those non-BigCorp Lemmy users are no worse off than they are pre-BigCorp-federation, but they're effectively migrating their communities all over again.

As far as why, I think it's pretty invaluable for Facebook to:

1) appear to be "playing ball" from a regulatory aspect 2) eat a competitor's lunch 3) control a (potentially!) up and coming federated service

remember the glory days when both google chat and facebook chat used XMPP (jabber?) and you could chat with people with any client you wanted.. (ahh, i miss pidgin). that lasted until they had 'converted' enough users to their systems to then close off all connections and make a walled garden.

I assume they will do the same with the ActivityPub compatibility. I don't see it as a permanent plan.

Reply on news.ycombinator.com