| I see your problems are that core XMPP provides very little and you need extensions to actually build something interesting. Which is very true, however we have come to a state where some of them are included by default in any good server or client implementation) > 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. |