Live data from Hacker News

XMPP: The Gem of Instant Messaging

adele.pages.casa

21–30 of 138 posts

Re: XMPP: The Gem of Instant Messaging

#21
post #5

We evaluated some options at work for self-hosted chat about a decade ago. XMPP lost out due to the lack of a good iPhone client. Not sure if things are any better now.

There are now a lot of XMPP extensions to fit the mobile messaging use case better (usage of push notifications instead of a persistent TCP connection etc.), and at least two clients using them: ChatSecure (although the push server seems to be broken currently) and Monal.

Due to the lack of anyone to chat with on XMPP, I can't really speak to the day-to-day usability unfortunately...

Re: XMPP: The Gem of Instant Messaging

#23

I think the big issue with XMPP are the clients. Element is so much better that it's hard not to recommend Matrix to people despite its bloat and metadata leakage problems. JMP/Snikket for tying a normal phone number to your XMPP @ are really convenient, but the clients remain a problem. Plus, SIP dialers are not supported on IOS afaik. I am really surprised there isn't a venture backed company pushing XMPP forward.…

Sure, Element syncs much faster than other clients (FluffyChat is unusable for Instant Messaging) but leaving the browser tab open still thrashes one CPU core.

Re: XMPP: The Gem of Instant Messaging

#24
post #9

I really miss the days of being able to use pidgin to talk to everyone

These days I can't even use pidgin for xmpp, because the omemo plugin is too wonky. Now someone I'm sure will say I'm just holding it wrong and that may be so.. but I doesn't work for me despite trying for a reasonable amount of time to get it working.

And regarding other protocols I'm too scared these days. Every company is running algorithms looking for deviants to perma-shadow-ban and I just can't risk something like that.

Re: XMPP: The Gem of Instant Messaging

#25
post #6

XMPP lost because the spec is overcomplicated and hard to implement. As a result, good clients never materialized and innovation was really hard to do. Everything in this article is an offshoot of the overcomplicated spec.

Not sure I buy that explanation. More likely is thst there's too little business advantage to being compatible with others and too much business advantage to having people inside your own ecosystem. Simple as that. There's just very little motivation for compatibility between these systems unless you are open source.

This. Thinking that the complexity of a spec is the primary obstacle to adoption seems logical at first. But it can't be true if you consider that the specs of all kinds of "foundational technologies" we use daily - HTML/CSS/JS/the DOM, IMAP, USB, IP, etc - are not just complicated but often downright messy, full of overengeneered, inconsistent or contradictory features.

I'd argue that the "beauty" or "ugliness" of a spec can make the life of the particular programmer who has to implement it slightly easier or harder - but it has very little effect on whether it is implemented or not. That's a product decision which follows completely different considerations.

Re: XMPP: The Gem of Instant Messaging

#26

Earlier quoted context omitted.

Is there a “modern” equivalent to XMPP? How does it compare to the matrix protocol?

The modern equivalent to XMPP is XMPP. Like every other healthy and alive protocol it evolves over time to meet new needs.

Is it actually "alive" still?

Re: XMPP: The Gem of Instant Messaging

#27

Earlier quoted context omitted.

Is there a “modern” equivalent to XMPP? How does it compare to the matrix protocol?

The modern equivalent to XMPP is XMPP. Like every other healthy and alive protocol it evolves over time to meet new needs.

Given the context above, does that mean the modern version is no longer "overcomplicated and hard to implement?"

Re: XMPP: The Gem of Instant Messaging

#28
post #6

XMPP lost because the spec is overcomplicated and hard to implement. As a result, good clients never materialized and innovation was really hard to do. Everything in this article is an offshoot of the overcomplicated spec.

Not sure I buy that explanation. More likely is thst there's too little business advantage to being compatible with others and too much business advantage to having people inside your own ecosystem. Simple as that. There's just very little motivation for compatibility between these systems unless you are open source.

Agreed.

Back in the 2011 timeline, I printed and read the spec front-to-back to implement what was effectively an "early Microsoft Teams" (a real-time, chat-oriented client connected to SharePoint)[0] using XMPP.

The spec is very easy to read, understand, and implement.

I think on top of your points (and maybe adjacent or extended from that point) is that I think some entities like Google were probably seeking more wire efficiency over the XMPP protocol and possibly wanted to innovate/iterate faster. There was a wave of "real-time" collaborative apps at that time and I can appreciate the need for teams to innovate faster.

[0] Short video: https://www.youtube.com/watch?v=WG_W0VxjzbM

Re: XMPP: The Gem of Instant Messaging

#29
post #9

I really miss the days of being able to use pidgin to talk to everyone

Haha yeah. Within Pidgin I used ICQ, XMPP (over my own VPS), Skype, Facebook messenger, ... Now I have to use different apps for Signal, Element, Slack, Discord, WhatsApp, Telegram, ...

Facebook via xmpp was the last thing Facebook was good for. It was nice to be able to strike up the occasional conversation with an old school friend or acquaintance. It really does feel like everyone is online more than ever yet somehow more isolated.

Re: XMPP: The Gem of Instant Messaging

#30
post #24
post #9

I really miss the days of being able to use pidgin to talk to everyone

These days I can't even use pidgin for xmpp, because the omemo plugin is too wonky. Now someone I'm sure will say I'm just holding it wrong and that may be so.. but I doesn't work for me despite trying for a reasonable amount of time to get it working. And regarding other protocols I'm too scared these days. Every company is running algorithms looking for deviants to perma-shadow-ban and I just can't risk something l…

The problem here is that Pidgin's development didn't manage to keep up with the changing times. Stable branch is 10-15 years behind XMPP features. The developers are working on a Pidgin 3.0 (rewrite?) but that still has quite some way to go.

Unfortunately Pidgin was one of the most popular ways to use XMPP back in the day, and this had a knock-on effect on XMPP's reputation as an out-of-date technology. People still install Pidgin today and tell me, yep, XMPP hasn't changed since 2006. Which couldn't be further from the truth.

Post reply on HN