| The main issues with XMPP that drove us in this direction were: * Not particularly web-friendly – you can’t easily speak XMPP from a web browser. * Single server per MUC is a single point of control and availability * History synchronisation is very much a second class citizen feature * Stanzas aren’t framed or reliably delivered (without extensions) * Multiple device support is limited * Baseline feature set is so minimal that good user experience cannot be guaranteed * No strong identity system * Not particularly well designed for mobile use cases (push; bandwidth-efficient transports) disclaimer: I'm involved with this project! |
> Not particularly web-friendly – you can’t easily speak XMPP from a web browser.
Is Bosh (http://xmpp.org/extensions/xep-0124.html) not good enough ?
> Single server per MUC is a single point of control and availability
Very true. There has been attempts to federate MUCS (http://xmpp.org/extensions/xep-0289.html) but the problem here is about human roles and who can do what (notwithstanding end-to-end integrity)
> History synchronisation is very much a second class citizen feature
Not yet standard, but everyone is betting on Message Archive Management (http://xmpp.org/extensions/xep-0313.html).
I could cite counterpoints for every one of your points but that's not interesting. The real issues I see with XMPP are:
* No efficient support for binary -- The official way to do it is to setup another transport with Jingle. Which is sad because a transport was already setup, and now we need another one...
* Because of previous point, any potential cryptography will waste a lot of space
* No framing (a point you cited), which is absurd considering that XMPP is a routing protocol
* XML is a non-joy to work with (Note: JSON would not be a complete solution, see previous points)
Even though it has deficiencies, I'm still betting (and working) on it. What we really lack is software, and tools built on a protocol, not a new protocol.