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.
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.
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).
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.
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...
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'.
What are your thoughts on Matrix?
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.