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.
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.
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?
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.
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?
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.
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.
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.
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)
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.
