> Some sort of open protocol.
XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…
XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…
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.
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.
The problem is, there are far too damn many XMPP extensions and too few of them see any kind of real adoption.
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.
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.
This is why nobody wants to touch XMPP with a ten-foot pole.
Honestly, there's some days I wonder if there's any way to win.
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.
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.
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.
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!
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).
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 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.
Now we have more bandwidth, and sending XMPP as a server is negligible.
I just would prefer JSON to XML. :-)