Ask HN: State of XMPP and open and extensible alternatives? | Hacker News Reader

Ask HN: State of XMPP and open and extensible alternatives?

15 pointspeey5 comments

I'm not at all aware of current stakeholders in the XMPP world. Who funds the development of new standards? Which technical people participate, develop, and champion proposals? Are new proposals getting enough feedback from organizations which large number of users that implement them?

I guess the ultimate question I'm trying to answer through these sub-questions is how active is XMPP development and what parts are failing. I do think that the world needs a chat protocol that's open and extensible, and the question is about health of the de-facto protocol I know of which was designed around these principles.

There has been a recent resurgence in interest for chat protocols, but I don't know of any that are designed with extensibility in mind. This [HN comment thread](https://news.ycombinator.com/item?id=17064616) discusses how XMPP/Jabber and Matrix compare. If XMPP currently stands to fail, are there attempts to standardize protocols that supersede it and aren't affected by the same problems?

IME, XMPP just works. I recently setup ejabberd+Conversations.im+gajim. There's definitely baggage (the basic idea of routing messages to specific prioritized endpoints, rather than a foundational shared history), but extensions have patched that up to satisfaction. And OMEMO seems to just work.

This doesn't answer your direct question, but does speak to the general "health" of the project. If a project doesn't have much activity, it can be because it simply works to satisfaction rather than being abandoned.

There is a lot of excitement around Matrix, but having evaluated it at the same time as XMPP, I just don't get it. I wanted to like it based on the community excitement, but ended up not. Riot.im on Android is laggy and unresponsive. No feedback when trying to start a chat, then when the server finally caught up hours later, multiple rooms popped up at once. Messages are "sent" with no indication whether that actually happened, and "synchronizing" notifications randomly pop up as if I care. The eventually consistent synchronization layer seems interesting, but without being fleshed out, creates more problems than it solves.

I didn't bother trying a desktop client because the poor flagship phone client was a blocker. Basically the project felt right in line with the poor quality of web apps in general. Perhaps like physical goods, we've collectively forgotten how to build decent software as well, and XMPP is the best we'll have for a long while.

> Riot.im on Android is laggy and unresponsive.

Riot/Android hasn't been developed in over a year. We rewrote it as RiotX/Android, which is unrecognisably better, and will be exit beta shortly.

I suspect you also suffered from the default homeserver (matrix.org) being horribly overloaded.

Sorry this put you off the rest of the ecosystem.

The greatest weakness of the XMPP is... it's main advantage - it's extensibility. Because of that, which you can "pick and choose", it's more difficult to offer "consistent IM solution" because there is no one party/company that offer complete environment (server + clients for all platforms).

XMPP evolves and is developed by volunteers (and developers contributing to XMPP software) and there has been a lot of work done to improve it (some say "catch up with IM landscape"): chat synchronisation (same conversation in all clients), E2E encryption (OMEMO), Audio/Video Calls (with Jingle), improvements on mobile (push) and groupchat (persistent membership / MIX).

Surprisingly enough, XMPP is quite popular and there is a lot of deployments but... XMPP is not exposed or advertised as being used, so you may be using XMPP without even realising it.

(sorry if this is a bit vague but I'm not sure I can give more details as I'm involved with one XMPP project)

>... what parts are failing.

Client usability is one thing.Conversations for Android is an example of how to do things well. An example:

You start a multiuser chat and Conversations just picks the options that will allow OMEMO encryption by default. You do the same thing on Gajim and it picks the wrong options and then uses completely different terminology in the error message when OMEMO is attempted. There is no way to know how to change the options to make things work.

Supposedly iOS XMPP clients could use some work but I have no direct experience.

The protocol itself is reasonably good and there are lots of implementations out there.

Have you visited xmpp.org? To me it already has been extended, the x in its name is for extendable. That said I would start with xmpp.org

Reply on news.ycombinator.com