With Meta starting to actually implement ActivityPub, I think it would be a good idea to remind everyone of what they are most likely going to do.
With Meta starting to actually implement ActivityPub, I think it would be a good idea to remind everyone of what they are most likely going to do.
Man, I’m not gonna relitigate this but no, Google Talk didn’t kill XMPP. XMPP is not, in fact, dead. WhatsApp killed Google Talk and pretty much every other competitor and XMPP would have been in that boat with or without Google Talk.
This is gonna keep coming up, it’s gonna keep being wrong and I’m really not gonna bother picking this fight each and every single time.
This needs to be higher for visibility. The story of Google killing XMPP is a good one but it’s utterly bullshit. XMPP was a mess, Google didn’t kill it, it killed itself by having fucked ecosystem that didn’t do anything better than numerous proprietary standards at the time.
It’s not like XMPP was EVER dominant, nor was Google talk - even man messenger was more popular at the time and that’s also dead.
Yeah I kept thinking these people must be incredibly young if they think this is what happened. As if Google Talk was anyone’s problem (in the big picture), nevermind XMPP’s.
Well, people like to think that the fediverse is a genuine threat to Meta. And they like to feel they’re doing important work defending it from Meta. So this will indeed pop up again, and again, and again.
They do? I mean, a few times I did have to point out that Meta has multiple products breaking 2 billion active users, so the “fediverse” is a drop in the ocean, but not many people seem to stick with that argument after a quick bout of googling.
I mean I think it will be if they really to end up federating. Why sign up for an ad-ridden data-hoarding service when you can use services that don’t have that nonsense but still allows you to do all the things you want to do on social media?
And Reddit killed phpBB (kind of).
And phpBB killed the newsgroups.
Etc.
You are right. Convenience killed the previous “protocol”.
You saying that XMPP is not dead?
Name 10 active generalist servers.
No, really, it would be good to know. I haven’t been able to find active XMPP communities since ca. 2015.Hah. Alright, it’s not deader than it would have been had Google not stepped in and then stepped out. We’re grading “dead” late 2000s instant messaging apps on a bit of a curve here.
Server 1, server 2, server 3, server 4
Both you and the writer claim to have been there back then, but have wildly different ideas for what happened… Were you a dev on XMPP too?
Oh, absolutely not. Let me be clear, I do not question that the author was involved in the project and interacted with Google. I do not question any of the factual details in the article and my argument is not that he’s lying. Total respect for him, his work at the time and even his opinions on how annoying and frustrating it was working with Google around.
What I’m saying is his perspective on the alleged failure of XMPP is specifically biased by his insider experience, that many of the examples he gives do not apply to AP, that the process he describes there is not EEE, that it’s not the reason XMPP and Google Talk failed and that, as he admits throughout the piece, XMPP didn’t in fact disappear or “die” after Talk’s failure or because of their intervention.
An XMPP developer would likely have been delusional about the protocol he himself developed. But at the time I can assure you XMPP was completely irrelevant. AIM/ICQ/MSN/Yahoo! and maybe IRC were the tools of the day back then.
Because of actual competition (which XMPP had absolutely no part in) multi protocol messengers had their golden age then.
Did you bother to read the article or did you only decide to write this argument w/o any substantial basis?
Oh, I read it when it came out back in June. Many times, as it kept being shared as an explanation of the first Threads backlash.
It’s full of incorrect assessments and false equivalences.
Threads doesn’t really have the volume (yet) to subsume ActivityPub. The process it describes for standards drifting towards the corporate actor doesn’t apply to ActivityPub, which is engineered from the ground up to support multiple apps with differnent functionality (hence me writing this in Kbin and others reading it in Lemmy and being able to link it and follow it from Mastodon), the article only acknowledges that XMPP survived and kept on going at the very end as a throwaway and doesn’t justify how it “never recovered” and, like I said, it doesn’t acknowledge the real reasons Talk and every Google successor to Talk struggled and collapsed.
So yes, I read it. Past the headline and everything. I just didn’t take it at face value. This piece keeps getting shared because XMPP wasn’t ever that big to begin with, so this sounds erudite and informed while the similar arguments being made at the time about SMTP and RSS were more obviously identifiable as being wrong for the same reasons.
I mean that’s basically what every protocol is. ActivityPub abstracts concepts, that apps implement in their own way (for example the concept of group). If you manage to deliver changes, even improvements, to the protocol, apps need to keep up and comply with it. This is what means “drifting towards the corporate actor”. I propose changes to the protocol to a rate that only me (the corporate actor) can keep up with. This way only my users will have certain features and eventually some apps will become incompatible with the recent version(s) of the protocol.
That is already how ActivityPub apps work.
It’s also not what happened to XMPP and, interestingly, not what the article claims happened to XMPP, even. You’ll note in the postmortem about it the recollection is that Google was too slow to adopt features and fix bugs, not the other way around.
I guess once you get enough confirmation bias in play you can embrace, expand and extinguish both by doing that and the opposite of that.
You still fall behind on compatibility with the original protocol. Doesn’t matter if you pull up or down, it still breaks compatibilty.
It absolutely matters under ActivityPub because, as I said earlier, it comes down to the client to manage the incoming packets. If Meta is out of date with the protocol but the rest of the federation is not (and retains backwards compatibility at all), then everybody else gets nicely formatted but feature-limited Meta content and they get garbled stuff.
It’s only relevant if we get garbled stuff and they get nicely formatted content. Which should be entirely avoidable if they “pull down”.
So no, not the same. And crucially people are still misquoting the article and the article is still misrepresenting the so-called “EEE” strategy.
The difference here is that, one, people are more aware now than they were back then (privacy wasn’t as big an issue then as it is now, thus people are more aware and are on the Fediverse for a reason), two, now the Fediverse has the upper hand (because of Mastodon mostly… they are somewhat of a player in the social media market), three, devs won’t allign with Meta’s moral compass just because it’s Meta (like it was with Google back then… people actually believed that company’s slogan back then).
So, what might have worked back then, probably won’t now, but it’s still good to approach Meta with caution.
Huh. I was just saying up here that I don’t think anybody genuinely believes the fediverse is a Meta competitor, but… guess I was wrong.
Mastodon does not have the upper hand by any metric. Threads alone has an order of magnitude more active users than the entire fediverse and Meta has multiple platforms with billions of users (and have signaled that they want Threads to reach that size).
You can absolutely argue that ActivityPub is a tech trendsetter and has an edge over BlueSky in that it’s already up and running. You can’t seriously argue that Mastodon or the fediverse are a threat, a competitor or have an advantage over Threads or Meta. One of the biggest hints that Meta isn’t going for “EEE” here is that it’s probably not worth the effort.
This is a core problem of distributed systems though. Signal even cites this as their reason to not federate with anyone.
Once you get decentralization going you need everyone to stay kind of up to date or stuff will just not work.
It is not. Discord’s protocol has been tailormade to suit Discord and the developers will not give a single thought about keeping it stable because only the Discord server&client are meant to use it.
This misses the point in my opinion. The point of a protocol is to establish a set of rules that need to be followed, that’s it. After this, it can be managed in many ways, it can be open or it can be closed, etc. The fact that ActivityPub is “engineered from the ground up to support multiple apps with different functionality” it’s because ActivityPub is an open protocol. Every protocol is designed to support whoever implements it. This doesn’t have any inherent “the protocol (changes) will suit everyone” or “everyone will be able to keep up with it” property, though. If changes to a protocol happen very fast, apps that are compatible today - and can be compatible tomorrow too - still need to implemented those changes, or at some point they will not be compliant anymore. This is not because the protocol loses the property of supporting multiple apps, but because a protocol still needs to be implemented, which is responsibility of the consumers, which requires time.
So my point was to challenge OC perspective that since ActivityPub is designed to support multiple apps, then there is no risk that it gets messed up and breaks compatibility with those apps (because it’s generic) due to - in this case -Threads influence. This is just nonsense, in my opinion.