1) We are obviously aware of XMPP, having been developing client-side interfaces to it for years.
2) We started this project in 2001 - around the same time Jabber was in its infancy - and as smacktoward notes, the main reason we're not using XMPP today is inertia. XMPP is great, but XML just isn't our personal preference.
We figure being more open with our protocol can't be a bad thing and so it's out there for folks to pick apart and send us feedback, which we'd love! Alot of our protocol was built with an eye towards XMPP federation as well; I actually had Trillian interoperating with Google Talk one afternoon but it seems like that ship may have sailed. :-\
At the time when XMPP was getting standardized and was still mostly known as Jabber, I started implementing a Jabber chat client with a friend.
The problem with XMPP isn't that it was based on XML. No, what made it annoying was that the dudes who made it decided that instead of basing it on exchanging individual messages, i.e. XML documents like everyone else does, everything must instead be put inside a so-called XML stream.
IIRC it basically meant that the exchange started with a start tag that wasn't terminated until the connection was closed. Since nothing at the time was designed to work with unfinished XML documents (remember the end tag doesn't come until you're done), all the convenient standard XML tools/libraries wouldn't work.
So I don't think XMPP is a stellar piece of work. But it's of course much better than some proprietary crap, and it's sad to see it lose support, although I imagine to Google and Facebook who both probably couldn't care less about interoperability, having an open XMPP interface is probably more of a liability (spammers, enables people to skip their ads) than something they get much perceived value out of.
XMPP is pretty awful for practical communications these days. It can, with enough extensions and clients, do all the things other protocols do, but by and large weird stuff is broken.
Pure communications protocols are starting to feel like a losing game for me these days - the world is so carved up and walled again that I really need someone to build a new Trillian that instead of speaking protocols, hooks directly into the UI widgets on my desktop and phone so unify my view of communications and let me inject features (the only one I want being OTR messaging and I guess let's bring Zmodem back so we can stuff binaries to each other).
I wrote a Jabber client for OS X public beta back in 2000. It was a horrendous pain in the ass. I was also on the IMPP working group list for a few years.
The big standout problem with XMPP is "XML streaming", which is fairly difficult to handle tersely, correctly, securely, and reliably. Mostly this is because parsing streaming XML (using, say, SAX) usually involves writing a lot of one-off code. Most of that code is just going to be making sure your messages correspond to the spec, don't start getting too deep, are complete, etc.
Then there's the out of band data stuff, which at the time, was basically undefined. Now, it's defined, in a whole lot of specs.
Then there's RTF, which is used by several Windows clients as a message format.
That's what I remember, at least, and skimming the current RFC's suggests things haven't changed much.
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'.
As someone who implemented stuff for XMPP many years ago: it's a super complex, XML infested protocol that if implemented correctly can only result in a bad user experience. It gets a little bit better if you support only a subset of it (eg: you take away the federation aspect of it) and target a single server and assume you control all clients.
But it's really very tricky to get a good user experience with it and the protocol is just not at all fun to work with. If it would not be the darling of the open source community it would not have gone far.
As the author of xmpp-ftw I feel I should throw some comments into this discussion.
Firstly, xmpp-ftw is not about starting an XML/JSON holy war, its about lowering the barrier to entry as far as possible. So see it as more of a gateway drug :) *
At present the tiny amount of effort it takes to build a proprietary (legacy) chat system with other technologies means that XMPP is somewhat being left behind (on the web) despite offering a huge number of benefits. Xmpp-ftw tries to make it as easy as possible by providing developers a format they are comfortable with and the ability to send/receive data with the minimum of fuss.
This project actually came out of discussions at XSF summits I've been attending. No-one (myself included) believes that XML should be replaced with JSON in XMPP, that would be a foolish notion. Generic JSON <-> XML is awful and doesn't quite work. The idea with this project was to used named events to fill in some of the missing information for building stanzas, and telling the user what is happening.
The view of JSON with XMPP has changed over the last couple of summits has changed, going from being referred to as the J word' through to open discussions about what can be done (the XSF seems like a very progressive group). No more jokes about XEP-0295 :)
If you want to see a better client library trying to do something similar check out Lance Stout's stanza.io https://github.com/legastero/stanza.io which came out of the same meeting.
So in summary: Xmpp-ftw is attempting to drop the barrier to entry for XMPP as far as possible and make it quick and convenient for developers to implement. Its not about replacing the angle brackets :)
Cheers, Lloyd
FYI, yes I've used socket.io, but you can stick anything that implements an event emitter and has callbacks and have it work. Currently I'm looking at wrapping sockJS.
Thanks, we've started with XMPP, like many others, but it was not fitting our purpose, like for others, so instead of building our proprietary protocol (like others did) we tried to build on what we learnt and provide something others would like to use. The beta is almost feature complete now and we need enlighten feedbacks to make it fit most purposes and something everyone would find useful!
There were several members of the core team, pre-XMPP effort in IETF, who wanted to change it to have framing. If not a length-prefixed model, a nil-separated one.
There were ideas to separate out the addressing/routing from the actual messaging, so that servers did not need to process XML and so that messages did not necessarily need to be XML.
There were even some very preliminary ideas on using the servers to potentially negotiate peer connections for arbitrary traffic.
Back in the early 2000s there were a _lot_ of self-hosted Jabber servers though, and there was push-back from early commercial interests on any protocol-breaking changes resetting adoption to zero. This resulted in Jabber 1.0 pretty much becoming the basis of the XMPP RFC, with XMPP adding new authentication techniques and internationalized JIDs.
Later on, there were efforts to establish alternative transports to accomplish some of these alternative transports and forms - HTTP endpoints to poll for messages, JSON mappings of the core messages, etc.
I would argue against PSYC's claims (or would have, back in the day) that the usage of XML in XMPP is not proper, however. Its proper, it just wasn't the best idea.
Unfortunately, XMPP not a very good protocol. By virtue of its insane complexity, no client seems to quite interoperate with any other in anything beyond the most basic features. Essential features that I have never managed to get working properly over XMPP include:
* holding conversations with people who have intermittent network connections (mobile phone users)
* sending/receiving files
* multi user chat
Ideal scenario would be that Google will solve these problems and release their new protocol with open specifications.
Jabber core protocol (XMPP) is kinda like SMTP. It deals with transmission of messages between two peers. Just like with SMTP, you can federate servers, so they can exchange messages between each other.
And the similarities don't end here. XMPP doesn't have built-in support for encryption (apart from the basic TLS encryption for the transport layer), it doesn't have support for message archiving and chat history syncing, there is no support for group chats, and so on.
A lot of this functionality is added as extensions (e.g. group chats are XEP-045), but this simply caused a lot of fragmentation in the ecosystem. So you could never rely on your client (or server) interoperating with other clients properly.
Audio calls and video also never really worked well. Google tried to push them by releasing libjingle in 2006 (!!!) but it was kinda ignored by everyone.
I've been using ejabberd a lot lately and it's a really nice piece of software, and works very well.
My biggest problem with XMPP as a whole is... well, it's XML. Not only is it heavier than it should be across the wire, it feels to me that the XML way of thinking leads to unnecessary verbosity when designing protocol messages. And there seems to be no proper consensus on how to use it among the different XMPP RFCs -- do we re-use a node name or come up with something different? Or just make it an attribute? Do we namespace it?
XMPP works great for what it was designed for though. There are many robust client and server implementations, being able to federate is awesome, and it's pretty easy to extend. But if I were to re-invent it, I would use a binary transport format.
Ofcourse if i (or anybody else) would write a chat protocol today i would make
changes. But i'm not even sure if i would abandon xml. I'm in the same boat as
you and think xml is too verbose and all that other stuff but i've recently
programmed some xmpp projects and i came to the conclusion that xml actually
realy does work well. And i didn't even use a library like sleekxmpp because
i wanted to know everything.
I'll just say: good luck designing something that'll be able to grow for 20 years
and still work today. You can realy feel where the X in XMPP comes from.
I have to mention the Conversations people. For me they are a big reason why i
use xmpp. It's not only the client which is very good, but the stuff like http-uploads
fix some very real problems in very little amount of code.
Also once axolotl-xmpp works and prosody 0.10 is released i see no reason not
to use xmpp honestly, which i will regardless, even if everybody uses something
else (like WhatsApp) i will simply write myself a transport server and continue
to use Conversations.
While i don't use it, projects like biboumi are realy cool. With a simple
combination of biboumi[1] and httpuploadcomponent[2] you now can share files
in irc-rooms.
I still have more to say. I hope that once i have my perfect chat-setup i will
write about it.
Especially Jabber/XMPP was created to fix that issue by standardizing the protocol. The idea is that IM would be like email - no central server.
Others (GTalk, Facebook, WhatsApp, HipChat to name few) started implementing it but did not enable server to server communication (ok GTalk did, but as soon as they became popular they intentionally broke it with Hangouts).
So now we have bunch of services that use same protocol but still can't communicate with each other, the XMPP seems like it is dying.
A while ago there were plenty of server-side transports to help migrate to XMPP, but it doesn't seem like they are no longer being developed.
I don't understand why no one cares anymore about decentralizing and standardizing IM.
1) We are obviously aware of XMPP, having been developing client-side interfaces to it for years.
2) We started this project in 2001 - around the same time Jabber was in its infancy - and as smacktoward notes, the main reason we're not using XMPP today is inertia. XMPP is great, but XML just isn't our personal preference.
We figure being more open with our protocol can't be a bad thing and so it's out there for folks to pick apart and send us feedback, which we'd love! Alot of our protocol was built with an eye towards XMPP federation as well; I actually had Trillian interoperating with Google Talk one afternoon but it seems like that ship may have sailed. :-\
reply