Hacker News Reader

Comment by Camillo | Hacker News Reader

XMPP lacks a fundamental feature: it does not echo your messages back to your other devices. This made it uniquely unsuitable for the mobile world: if you start a conversation with someone on your computer, and then move to your phone, all you see on the phone are the other person's messages, as if they had been talking to themselves. (Yes, someone did eventually write an extension for that, which nobody ended up supporting.)

I can't even say that XMPP failed to adapt to mobile. It's more that XMPP was a terrible protocol with a gigantic flaw that should not have been there in the first place, and mobile just made the flaw obvious to everyone.

View on HN

All these problems have been solved in XMPP years ago, and there are some clients fully supporting the mobile experience and usage of multiple clients.

On the Desktop, Swift and Gajim come to my mind, on Android Conversations is getting really awesome (and yaxim, which I am the author of, supports the basic multi-client/mobile use case you are interested in).

That said, the XMPP protocol is not perfect, and it is lacking some important elements for a 2010+ mobile chat developer, but considering that it was initially developed in 1999, that mobile chat is only one of its many use cases, and that there are extensions covering all you have asked for, the critique is not appropriate.

[0] http://swift.im/swift.html

[1] http://gajim.org/

[2] http://conversations.im/

[3] https://yaxim.org/

That's exactly the problem, though. There are so many extensions that it's about as much work finding out which ones are even needed and how they interact for your case (in this case the replay) as is implementing, say, a good chunk of IRC.

And no, I'm not exaggerating, I've done both and decided that writing XMPP clients is not for me a long time ago.

Addendum: I really love XMPP, but I do think the many many extensions have hurt it more than one defined spec. And yes, I know it supports many use cases, but I simply only care for 1:1 and multi user chat.

You are right. The XMPP Standards Foundation is currently preparing to create a list of "must-have" client and server XEPs for certain use cases, like Instant Messaging or IoT. This will hopefully make the path easier for future application developers.

Just for the record, we are also working on a next-gen XMPP client, with decentralized blogging, file sharing, end 2 end encryption and all, and planing to do an Android port. Other projects like Movim also do similar things too, XMPP is definitely very alive these days.

Sending message to other devices is managed by message carbons which is in last call for being a standard XEP, and support is becoming more and more common.

XMPP is all but deprecated, very active, working well, with a large ecosystem. But is really badly known by most of people(I have by the way started a series of article to explain it: http://www.goffi.org/tag/talk_xmpp).

It's really difficult to be heard these days, but there is a new wave in XMPP world (check our project: http://salut-a-toi.org or movim: http://movim.eu).

Is there any way to handle message histories that survive the XMPP server (ejabberd) being restarted?

At the moment all the MUC room histories vanish if I need to restart ejabberd which is a farce in a cloud world...

And message carbons work, but since ejabberd only seems to support a single auth token meaning that if users connect with multiple devices they can't actually log out of only a single one without pulling the plug on all connected devices.

Are these only ejabberd issues or issues in the XMPP specs?

BTW this is for realtime chat on for an app, nothing federated... I'm open to non-XMPP options too.

> Is there any way to handle message histories that survive the XMPP server (ejabberd) being restarted?

Message Archive Management (XEP-0313) is supposed to do that.

> And message carbons work, but since ejabberd only seems to support a single auth token meaning that if users connect with multiple devices they can't actually log out of only a single one without pulling the plug on all connected devices.

Not sure to understand: if you disconnect a device, all the other devices with the same jid are disconnected? If so, it's definitely not normal, and not a spec issue. I'm also surprised to see ejabberd having this behavior, you should talk to the dev team.

> Message Archive Management (XEP-0313) is supposed to do that.

Thanks, I'll check that out.

> if you disconnect a device, all the other devices with the same jid are disconnected?

No, not on disconnection - I can't seem to find a way to tie multiple auth tokens to a single user (one per device) to allow them to log out on different devices individually. At the moment logging out one device would disconnect all clients.

XMPP is all but deprecated...

Just a short English usage note: "all but" means something like "almost". Judging by the rest of your post, you probably mean "XMPP is far from deprecated" here.

yes indeed, I'm not a native speaker as you can guess.

Thanks for the correction :)

I usually read "X is all but Y" as "X is Y in all but name", but there are subtle distinctions that could be hard for a non-native speakers[1] to grasp without knowing about them.

1: http://english.stackexchange.com/questions/9967/all-but-idio...

My understanding is that it is not the clients that are the problem but rather there is patchy support in open source XMPP servers to utilize the new mobile friendly features.

[1] - https://www.process-one.net/en/ejabberd/protocols/

[2] - https://prosody.im/doc/xeplist

[3] - https://github.com/esl/MongooseIM#features-and-supported-sta...

Not true, XMPP does have that feature and there are multiple clients which implement this. It works amazingly well. It's not an extension, but part of the standard.

Example:

http://conversations.im/

Doesn't excuse Google, Facebook, WhatsApp, and Apple, from building closed protocols and actively thwarting attempts to make third-party apps.

(Yes, I know they're for-profit companies who have every reason not to want to relinquish any control over their network. Doesn't mean I can't hate on them for not even pretending to support consumer choice.)

> not even pretending to support consumer choice

By my way of thinking, your choice of language (not because of you, the person, but of how the words have become ingrained) is indicative of the problem: "consumer" versus "customer." We consume what the various companies choose to offer to us in the way they offer it. We are not treated as customers, valued or otherwise, in a competitive landscape. There exists a one-way flow, from the company doing the advertising to our eyeballs to consume it.

Look at the businesses people claim to like: local shops, service providers like Fastmail, and the like. In those cases the people giving them money are treated as customers who have other choices and who have made the voluntary choice to continue to associate with that business.

That's what is missing. Customer instead of consumer.

I wonder, if we were proper customers of Facebook and paid them to transport our messages, whether it would open the possibility of a Ma Bell-style antitrust lawsuit. Force interconnectivity to allow the little guys to play too.

WhatsApp is paid (after a year), but it doesn't help with supporting any open IM standard.

Yeah, I've never understood this. I've seen it now-and-then when installing WA for family members, but I (and they) have never, ever had to pay for it after using it for multiple years.

It's free since Facebook bought them. I've had Android friends mention payment screens are still on their WhatsApp though.

It was free before Facebook brought them too. It just nagged people to pay once a year, but if one didn't pay, it just kept working.

What about Comcast? What about airlines?

s/Customer/Citizen/ and you've hit on a large portion of the problem with representative democracy.

When someone raises this concern, I ask who hosts their personal email. 30-50% use a legacy free Google Apps account or Gmail. When I ask why, it's a variation on "because FastMail costs ~$40/year."

Of the rest, more than half host their own MX. While that's totally reasonable, it means the percentage of people willing to pay just $3/month to be a customer is even smaller than it seems. And $40/year is the cheapest that one could ever hope "being a customer" would cost.

So, lots of people say they want to be customers, but even when doing so is close to free, very few actually do.

(Nothing wrong with using Google because it's free, only while concurrently claiming to want to be a customer. I agree with your point and I'm a happy FastMail customer. I'm amazed FastMail can make a profit at $40 and it's a huge credit to them that they can.)

While it's not like xmpp/jabber protocol is perfect, it leaves lots of space for extensions. Any company serious about it could either implement (post 2011) or propose (pre 2011) extension like XEP-0280 (message carbon copy). There's another one for accessing archives, googlable if anyone wants it.

> It's more that XMPP was a terrible protocol with a gigantic flaw that should not have been there in the first place...

What is that flaw? Is it the flaw that you mentioned in your opening sentence?

Edit: For the downvoters: This is a serious question. I don't ask non-serious questions. :)

I think the flaw was mentioned in the first sentence of the parent's response: "XMPP lacks a fundamental feature: it does not echo your messages back to your other devices." This capability was indeed one of the major selling points of Apple's messaging system in the most recent iOS & OS X releases. If XMPP cannot keep track of multiple clients then that is a huge flaw in todays mobile world.

Unfortunately it is not true. XEP-0280 [0] (Message Carbons; since 2010) forwards your conversation to all your online clients, and XEP-0313 [1] (Message Archive Management; since 2012, but only recently implemented) allows a client to "catch up" with the history when it goes online.

[0] http://xmpp.org/extensions/xep-0280.html

[1] http://xmpp.org/extensions/xep-0313.html

Whatsapp never supported this "fundamental feature" and is globally the most used messenger in "todays mobile world" by a wide margin.

Whatsapp is built on XMPP I believe. :)

A closed proprietary non-interoperable extension on XMPP.

> I think the flaw was mentioned in the first sentence of the parent's response...

We can speculate all we want, but this just leads to confusion. :)

Reply on news.ycombinator.com