Hacker News Reader

Comment by K0SM0S | Hacker News Reader

People who worked extensively with XMPP in the past told me that it just wasn't cut for the current paradigm, with real-time and asynchronous communication, network hopping (mobile, wifi, etc) and just the way things evolved since... 1999. There were some changes planned but apparently the whole thing would be better off rewritten in a new form, and the effort never really kicked off, much like the protocol itself faded from use as we moved towards more and more hybrid networks and uses.

It's a sad realization, I always thought XMPP would save the day some day, but apparently there's a lot of work between now and there. And it might just as well be called something else. I think the latest move towards HTTP/3 enforcing SSL1.3 is one way to envision a fully secured web, 10 years from now.

View on HN

We work extensively with XMPP, so I can speak with some authority on this topic.

It is true, the protocol was invented in 1999 for then-relevant conditions. There are good things - everything that is related to federation works remarkably well, and bad things - multi-device usage, reconnection, etc.

However, the very thing that is mostly panned here by Matrix proponents - modularity and extensibility - allows to uplift it for the modern world. Actually, we recently did just that, by developing a bunch of new protocols and implementing them on an XMPP server. I'll spare the verbose details, but in short, we redesigned reconnection process from a resumption of an XML stream to restoration of messenger state, and it works rather well. That set of protocol extensions greatly helps to improve the performance of our upcoming XMPP client.

Who are "we" and what client/projects are you working on? Are these changes new public XEPs that others can/will implement?

"We" are makers of Xabber, a popular XMPP client for Android. It had gotten a bit stale lately: a few years ago we figured out that XMPP improvement should start on the server-side, so we diverted all our resources towards creating a set of protocol and implementation it on a server, an alpha version of which was released last month, it has a built-in an insanely great web version of Xabber, which likely offers the best XMPP UX ever, on any platform. We also plan to release an iOS version of Xabber soon - this month or next.

Our protocols are public, and we plan to submit them to XSF, once we're done translating them from our native language. Hopefully, these XEPs would be supported one day by other clients. We believe they are crucial for XMPP future.

Very interesting. Which server are you enhancing? Do you provide xmpp hosting?

We forked ejabberd because it's the best existing XMPP server. We do provide XMPP hosting (at xabber.com/xabber.org domains), but currently, it's just standard ejabberd, a transition to our own build will come later, hopefully, this year. We also plan to provide domain hosting.

(also in relation to your other response w. details) This is very, very promising! I'm so glad to hear XMPP is alive and kicking; I'll definitely explore these packages of yours. Thanks for the work and for sharing.

It's been about a decade since I had the oh-so-common billion-dollar idea (read: extremely costly but nowhere near profitable) of "hey, how about we used private servers/clients in peer to peer to communicate? Like MSN and descendants but without a central server?" I think me and the 100,000 others with the same idea felt the challenge of improving XMPP + working on conversion from existing platforms was too tall an order.

Now, if guys like you have been/are improving XMPP 'enough', then I can see a path for the open ecosystem to grow anew. And that, provided alternatives like Matrix etc. provide a path for data (API, URLs etc), is just what we need to massively disrupt the basic communication space.

Really, thanks. Spark re-ignited for social apps and a new social paradigm fitting our times.

> apparently the whole thing would be better off rewritten in a new form

It seems to me that this is basically describing Matrix [1]. Funnily enough, since its current transport is HTTP, it looks like by the time HTTP/3 becomes a thing, network hopping would be solved essentially for free.

[1]: https://matrix.org

Was wondering what you mean by network hopping. Assuming that by http3 we mean quic, does it provide some functionality for message routing that I’m missing?

I’m most likely either misunderstanding what you mean by hopping or completely missing a feature if quic.

Thank you

From what I understand, QUIC allows for IP roaming, much like how mosh does.

Matrix is a fundamentally broken protocol held up by the prowess of it's UI design team.

How is it fundamentally broken?

Can you explain why? (Not looking for any great detail, just a starting point.)

As someone who has worked extensively with XMPP in the last ~6 years let me tell you that it works fine with network hopping, multiple devices and everything else you'd come to expect from a modern IM experience in the likes of WhatsApp and Signal.

I have written a lengthy article in 2016 in the state of mobile XMPP: https://gultsch.de/xmpp_2016.html

The situation has only improved from there.

I'll read it with much interest, thanks a lot.

You know, I like the sound of you and the makers of Xabber. The "myth" of XMPP being unsuited to mobile / IM is clearly overblown if you're only even half-right about it all (because then that means there's no "fundamentally broken" paradigm). It's great to hear the community is active nonetheless! ~

Ever looked at internet bill for things like GPS loggers using http?

Even most barebone request often eats more bits than data

That's why nor HTTP nor XMPP will be going anywhere

It’s funny... I have, sort of. A place I used to work at had a bunch of old serial devices connected to the internet via Ethernet-serial gateways. To query them, we connected over Telnet (heh). The original devices had a CLI, and the polling was done by sending a series of keystrokes to the devices. Each keystroke was one byte, and was wrapped in an entire TCP packet (~40 bytes, if I recall).

We were blowing through our 1MB (yes...) SIM cards quite quickly, and it was 98% just packet overhead. I can only imagine what it would have been like over http.

Reply on news.ycombinator.com