Hacker News new | past | comments | ask | show | jobs | submit login

I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?



Having used and developed with XMPP day in and out for the past 9 years I'd have to agree with the sentiments towards XMPP being on life support.

It's a real damn shame because XMPP is pretty awesome. It's open for one, can be made super secure with OTR (client-2-client encrypted chats), has numerous protocols and implementations for stuff as diverse as message archiving, Audio/Video signalling, file transfer, chat (of course), presence and an absolute boat load of other stuff: http://xmpp.org/extensions/index.html.

There are two big issues as far as I can see with XMPP which really hurt it:

1. XMPP was incredibly poor at handling high latency, intermittent network connections (like cellular). Connections would time out, reconnections would take ages and all in all it really hammered battery life. As a consequence mobile app developers moved very quickly onto REST/JSON (yes there was XEP-0198 - Stream Management - but implementations of it were thin on the ground and even then it wasn't perfect).

2. There just isn't any interest amongst new developers or newer projects at least in an XML based chat protocol when REST/JSON is so attractive. Anyone who has had to write a god damned XML parser knows what I'm talking about.

Things are a whole lot better now. XMPP has fixed a lot of session and battery life issues since then but to be honest I'm just not feeling it when I go to XMPP meetups. Feel like I'm attending a wake for an old friend and it really is sad because if there was ever gonna be one protocol to rule them all XMPP was far and away the best candidate.

Who knows, a couple years from now large companies and governments might finally wake up to the fact that they have 100 different sucky (probably) REST based APIs amongst all their apps which are not remotely compatible and offer poor archiving and retrieval (like they did in the 90s when they forced Microsoft to open up their Office document format). XMPP might come to the fore again then (wouldn't put money on it though). More likely something similar (and not XML based) will take its place.

It's anyone's guess really, suffice to say the present situation does feel like a complete and utter mess and will really start biting us in the ass when compliance asks 'how do I archive/retrieve this pot pourri of data'.


Thanks for the insight. It reflects what I often hear from other people close to XMPP.

What are your thoughts on Matrix?


Looks like they're making all the right noises in order to be a viable successor to XMPP. Really does look good, but seems to be in its very early stages.

Reminds me of what the Layer guys were trying to do (at least in their initial mission statement). https://layer.com

Pros of Matrix are that it looks like they have full chat support, are working on adding end to end encryption, and of course have federation which is super important for interoperability.

Only concerns with Matrix are that I don't see any large projects or companies spearheading it. Also seem resource constrained. For example it looks like they planned on rewriting their existing basic server side app in C and then ended up just writing a proxy. So clearly it's still a small project. Also see verbs in their URIs...I'm not super up to date on REST best practices but isn't that a no-no?

Anyways early days - and it's easy to nit pick. Matrix certainly looks compelling enough that I'd be interested in trying it and seeing them succeed. God knows we need something like it and soon.


There are quite a few large/huge companies building stuff on Matrix - looking at the copyright statements of the code in github.com/matrix-org reveals a few. Many of them are using it in commercial stuff which hasn't launched yet - and meanwhile Matrix is still in beta, so understandably they don't publicise their activity too loudly about their activity atm.

In terms of resources: a bunch of us are paid by our dayjobs to work on Matrix fulltime, and meanwhile there's a pretty active wider community surrounding the project. However, the 'core' project of building a spec, reference server, reference+glossy web and native ios/android clients, as well as loads of bridges really is a significant amount of work, and we're going as fast as we can. https://www.openhub.net/p/matrixdotorg gives an idea of progress (although only seems to spider a few of the core projects). I wouldn't really call Matrix a 'small' project :)

In an ideal world we'd stop the world and take N months to entirely rewrite Synapse (~40KLOC of rather dense Python/Twisted) to Go/Rust/C++/Java/Node/whatever, but that's N months we don't have right now. It's not really the lack of resource, but the fact that the window is rapidly closing to provide an interoperable fabric between all of these proprietary communication apps (be they open source or commercial licensed), and we want to get a stable solution out there before it's too late and we end up in a world where the silos have won (c.f. social networks).

Hence the pragmatic decision to do an incremental migration from Synapse to Dendron, which is our next-gen homeserver written in Go (not C). Dendron is indeed mainly 'just' a proxy for now, but this is actually incredibly cool as it can act as a Matrix-aware loadbalancer across multiple Synapse backends. The horizontal scalability and HA this gives is a huge deal. Meanwhile, it gives us a way to gradually migrate endpoints from Synapse into Dendron and provide a way to replace the Synapse codebase without having to do a stop-the-world rewrite. Personally, I think this pragmatism is ftw.

In terms of verbs in URIs... we've been pragmatic rather than religious about REST naming conventions; if someone can give concrete reasons to rename endpoints before we freeze the spec, please tell us! Bugs to http://matrix.org/jira/browse/SPEC and PRs to http://github.com/matrix-org/matrix-doc please ;)

And whatever, please do come hang out on #matrix:matrix.org and #matrix-dev:matrix.org eitherway if you want to find out more and help us escape beta!


>I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?

Well, it failed to be the preferred solution for its problem domain, and is universally ignored by big players.

Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).


> Well, it failed to be the preferred solution for its problem domain,

Google Talk, Facebook Chat, Origin (EA), Playstation, Cisco WebEx, WhatsApp all use/used XMPP for instant messaging.

That sounds like it's the preferred solution for realtime messaging, with vendor lock-in and NIH syndrome decisions being the major reasons that it isn't used in even more situations.

> and is universally ignored by big players.

As evidenced by the above list of major deployments, it is absolutely not "universally ignored". The problem (as someone else pointed out) is that for many of the "big players" a federated protocol is not what they want, so they don't allow federation, and don't allow/publicise the use of standard XMPP clients.

> Google also killed Talk in favor of Hangouts (and the later doesn't talk to XMPP).

This is a reason to stop using Google services, not a reason to claim XMPP is ill-suited to the task at hand.


The thing is that Google moved from XMPP to something proprietary specifically to avoid federation. The big players don't want federation and any protocol will suffer the same fate unless it becomes popular without reliance on the big players. I think it is fair to say that XMPP isn't any more dead than any other protocol in this respect.


An interesting point. There was a similar issue with SMS (federating with big telcos), and Whatsapp (among others) did a nice job of routing around that (by piggybacking on SMS). It's interesting to think about how a genuinely open player might route around that.

For example, suppose you want to send an IM to your friend. You believe in XMPP or some other open/federated protocol, but you don't know which friends use the protocol. Piggyback off email. Note that identities are backed by email. Also, if any identity-providers refuse to join the federation, then route through a trusted fallback service (Trent.com). Pseudocode:

function send_im(toEmailAddr, messageText) { // See if the user's domain already supports OpenChatProto. if (nslookup(toEmailAddr.hostname, 'SRV', 'OpenChatProto')) return OpenChatProto.deliver(toEmailAdrr, messageText);

  // If user's domain doesn't support it, see if the user has
  // registered+authenticated with a trusted third-party.
  var proxyAddr = http.get('https://trent.com/proxyAddr?email='+toEmailAddr + authCode);
  if (proxyAddr) {
    return OpenChatProto.deliver(proxyAddr, messageText);
  }

  // If the user doesn't exist in OpenChatProto, then
  // fallback to email.
  var emailText 
    = messageText
    + "To continue this discussion in real-time chat, go to:"
    + "https://trent.com/setup?email=" + toEmailAddr + authCode
    + "To block messages from this person, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + senderEmail + authCode
    + "To opt-out of all messages, go to:"
    + "https://trent.com/optout?email=" + toEmailAddr + authCode

  Email.deliver(toEmailAddr, emailText);
}

Note: It's most efficient if members of the federation agree on the identity of trent.com, but it's not required. Any outbound MTA could use a different Trent, but that fragments the brand and identity databases.

This feels pretty obvious, so maybe it's already being done or I'm missing something...


Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.


All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.


What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.


Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue.

XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.


> chat archiving for example

This requires a central server though. This is more a function of the service providing XMPP to you than the client. If you want the functionality on the client, it presumably requires some sort of interop between client and server that I'm not sure it part of the XMPP spec.


Sounds like XMPP isn't the solution then, only {???,XMPP} is.


Well, extending the spec could be the solution too. What I was trying to convey was more that there will be a lack of such clients until there is either an agreed-upon extension to the standard, or a popular enough fork of the standard. (at least as far as XMPP is concerned)


There is an XMPP extension for it: http://xmpp.org/extensions/xep-0136.html

The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.


XEP-0136 was pretty complex, and didn't see that much adoption.

XEP-0313 is a modern replacement, focusing on just the things that people actually need. It's implemented in many servers and clients already (see https://www.zash.se/mam.html ). It's still under development, but it's already in active use by many people.


Great, there's even two extensions on it!

This is why nobody wants to touch XMPP with a ten-foot pole.


So either XMPP is bad because it hasn't changed for years and is therefore old, or else XMPP is bad because there's new replacements for stuff that didn't work so well.

Honestly, there's some days I wonder if there's any way to win.


Pretty much this. Openfire for instance only recently had XEP-0136 implemented across the board on the server side. In the meanwhile I couldn't find a single client with decent support for chat archiving (XEP-0136) on the client side. Not one (and I really looked).


What? Openfire has had XEP-0136 for literally years. I think a little over a decade, actually. It's only recently implemented XEP-0313.


Hi Dave, firstly thanks for all the hard work on Openfire over the years, very much appreciated.

Secondly regarding XEP-0136 support in OF. I did state that Openfire has only recently had 'XEP-0136 implemented across the board'.

Whilst the Open Archive plugin which provided support is a fine piece of work it was an incomplete implementation with only 1-to-1 chats (no group chat support).

I worked on merging the monitoring and open archive plugins to provide support for both MUC and 1-to-1 using XEP-0136. That work was only fully finished a couple years ago in 2013 so think my comment's still accurate.


Adium has a UX and UI from the 90s, for one.


btw. very much agree most of the clients are inadequate but if I could humbly pimp Openfire (I'm a dev there): https://github.com/igniterealtime/Openfire

And ejabberd of course (powering WhatsApp): https://github.com/processone/ejabberd

You'll see that on the server side at least XMPP is very well catered for.


What are the advantages of OpenFire over ejabberd/prosody?


Super easy to use, nice admin pages, great plugin architecture for 3rd party developers to extend its functionality. Means there's a LOT of cool plugins which add video, screen sharing, chat archiving, etc.

Deal breaker against it (depending on your use case) is lack of support for multiple domains. It can only handle one per deployment.

It also does need at least 512MB RAM which rules it out on embedded devices.


I've used both and moved on to prosody. Ejabberd is just too arcane to configure and debug; and openfire is a damn resource hog for no apparent reasons.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: