
XMPP Myths - AndrewDucker
http://wiki.xmpp.org/web/index.php?title=Myths
======
joepie91_
Meh. None of these are claims I really see particularly often. The claims I
_do_ see are:

1\. XMPP is not battery-friendly on mobile devices (this primarily has/had to
do with the absence of push notifications, it seems).

2\. XML is unnecessarily complex for this kind of usecase, and too hard and
time-consuming to work with (and I agree). That is most likely what 'slow'
refers to - not slow in _parsing_ it, but in _developing_ for it.

Neither of these are addressed.

I also don't really understand the comparison with "JSON over HTTP" \- why
would you _ever_ use that for a realtime application?

The correct technology is JSON-over-WebSockets, and it doesn't really make
sense to compare XMPP to a known-bad implementation and say "see? XMPP isn't
that bad!"

Another issue with XMPP is the strange implementation of both resources and
the existing options for sending to _all_ resources (especially when taking
into account tools like OTR). People _want_ device synchronization, and it
just isn't viable with XMPP right now.

~~~
vog
While I agree that XMPP is not the future for app-to-app communication, I do
so for a slightly different reasons.

 _> XML is unnecessarily complex for this kind of usecase_

XMPP is too complex, but the XML stuff is really the smallest issue, compared
with other complexities in the protocol. For example, every client that
successfully connected to an XMPP server must first send a "<presence>"
message. Otherwise, it won't receive any messages despite their successful
connection. And there are more such surprises in XMPP. Good luck in
understanding which "devices" (#xxxx) of the same Jabber ID will receive a
message targeted at that ID.

It's really annoying and discouraging to debug that kind of issues -
especially since these aren't bugs. These work as specified, but the
specifications were obviously designed with direct human chatting or direct
human collaboration in mind, programs being an afterthought.

 _> The correct technology is JSON-over-WebSockets_

Not really. Whenever I saw someone trying this "in the wild", I see them
quickly switching to HTTP long-polling. (Not to be confused with polling! We
are still talking about instant push notifications with very low network
overhead.)

For example, there are some libraries that used to provide wrappers around
WebSockets, which switched to HTTP long-polling as fallback for old browsers.
Nowadays, it seems they use long-polling by default, even though browser
support becomes better and better.

Don't underestimate the role of firewalls and HTTP proxies! Many firewalls are
aggressive configured, and many companies have forced HTTP proxies in place.

~~~
Flowdalic
> For example, every client that successfully connected to an XMPP server must
> first send a "<presence>" message. Otherwise, it won't receive any messages
> despite their successful connection.

That statement is wrong. Sending an initial presence merely indicates your
availability to entities subscribed to your presence. Not sending the initial
presence does _not_ prevent you from receiving message stanzas.

~~~
vog
IIRC, the ejabberd server will wait until you are "present". Only then it will
send you all messages so far received for you.

~~~
davecridland
Really? The old Google Talk service used to do this, but I didn't think
ejabberd did. There's a bunch of non-IM use-cases which need presence-less
messaging.

------
davecridland
FWIW, I added the following to the Wiki page when I saw it was on HN, which
might help give some context to what you're reading:

Hi. I'm Dave Cridland. There's a note just up there which says "(Draft blog
post)", and that's been there from the start - but when I asked for some
feedback from the public standards@xmpp.org mailing list, people posted it on
Twitter, and then it got onto Hacker News. Which is all cool, it's not secret,
but...

This has not been properly reviewed yet (though the community is starting to),
and so may contain inaccuracies, errors, or simply bad wording that's
inadvertently as misleading as some of the comments I'm trying to rebut, and
so feedback is genuinely welcomed.

Also equally welcome is feedback of the kind that says "Yeah, but I think that
XMPP is entirely made by KILLING KITTENS", or whatever, so I can either write
a rebuttal, or agree with you and try to get the community to fix it.

This is, currently, my personal opinion, and may not represent that of the
XMPP community or the XMPP Standards Foundation.

Just for the record, I don't think we kill any kittens.

------
jacobolus
As always, when making these kind of statements, the question is: relative to
what, and for what purpose? Without knowing that, it’s quite hard to know what
the author of this page is getting at. Who is he arguing against, and what’s
the context for these “myths”?

XMPP is sort of similar to all the browser technologies (HTML/DOM/CSS/etc.):
it’s a large and complex spec which takes a large amount of work to implement
even a basic version of, with lots of possible things to screw up.

It mixes various concerns together into a big jumble without the cleanest
layering, which makes certain types of systems a pain to build on top of it.
It’s based on a technology (XML) which is inherently heavyweight and not all
that well suited to streaming applications. Tooling which exists around XML is
mostly fairly irrelevant to an XMPP-like use case. If someone wanted to make
an open IM protocol from scratch, they could make something much simpler,
cleaner, and better organized.

On the other hand, all the other popular person-to-person IM protocols are
proprietary, and XMPP is at least open, reasonably well documented, and with a
relatively large community built up around it. Which counts for a lot.

If someone wants to build a new protocol, for example Google Wave, I would
very strongly recommend against trying to shoehorn it into XMPP. On the other
hand, if someone wants to make their chat client or server interoperate with
existing chat networks, then XMPP is great.

~~~
slasaus
Don't forget Whisper Systems protocol used by TextSecure[1] which is based on
Google's protobuf[2] and JSON in a REST api.

[1] [https://github.com/WhisperSystems/TextSecure-
Server/wiki/API...](https://github.com/WhisperSystems/TextSecure-
Server/wiki/API-Protocol#user-content-sending-messages)

[2] [https://developers.google.com/protocol-
buffers/](https://developers.google.com/protocol-buffers/)

------
SFjulie1
Apparently for me it is a myth that XMPP teams can make anything that works.
And their site is logically down.

I am gonna make my grumpy old man. It still takes 1 day for an apprentice
coder to :

\- make an irc bot; \- program a rs232 port; \- to draw a pitcure accessing a
framebuffer; \- to make hello world in Tcl/Tk that is centered horizontally
and vertically in a bigger canvas.

But seasoned devs cannot easily do the same with:

\- xmpp; \- usb; \- css/js...

Either the quality of the devs is going down, or some progresses are not.

ADDENDUM technical issues in jabber:
[http://webcache.googleusercontent.com/search?q=cache:yGdLTF4...](http://webcache.googleusercontent.com/search?q=cache:yGdLTF4J8DEJ:about.psyc.eu/Jabber&hl=en&gl=ca&strip=1&vwsrc=0)

~~~
anon4
Protocols are getting more complicated. Sometimes needlessly - XMPP; sometimes
out of necessity - we can't let you poke bits in the framebuffer directly,
because the graphics card is now this almost-blackbox superscalar coprocessor
that only incidentally maybe has a display hooked to a tiny little region of
memory that you could perhaps think of as a "framebuffer", but the framebuffer
is actually not linear, but tiled in some weird way for performance.

Actually making the complex and simple stuff coexist on the same system is a
very... complicated challenge.

~~~
colechristensen
So here's a question (and a personal manifesto)

Would things be better if they were worse?

That is, what if we gave a little bit less of a shit about optimizations and
preferred simple over fast?

We live in a world of magical black boxes that even experts in the field have
trouble manipulating. We need to protect and promote the Freedom to Tinker and
that means carefully considering when optimizations are really critical
hindrances.

------
legulere
The advantage of JSON is that it's way easier to handle because it maps
directly to structures that are available in every common programming
language.

------
ape4
I agree that XML is only slightly more verbose than JSON but they should still
make a JSON version of the spec or it will die. It should be pretty straight
forward to mechanically change the XML into JSON.

~~~
insertnickname
They did: "XEP-0295: JSON Encodings for XMPP"
[https://xmpp.org/extensions/xep-0295.html](https://xmpp.org/extensions/xep-0295.html)

:-)

~~~
ape4
How about that! Then they need to publicize it. Make a website, say, jmpp.org
(pronounced "jump") and a reference implementation.

~~~
davecridland
You might want to read it. :-) The problem has mostly been that nobody's come
up with a better JSON representation than one in a April 1st XEP (and they
have been proposed - as ralphm says, they're mostly XML-with-curly-brackets,
which makes them have the disadvantages of both).

On the other hand, both stanza.io and XMPP-FTW both use the same fixed-format
(ie, inextensible) JSON format for XMPP just fine. They can do this because
they drop unknown namespaces and don't intend to provide round-trip
conversions, etc. So if you're after a JSON "interface" to XMPP, there is one,
and it's pretty good.

Worth a look.

~~~
ape4
Oh yeah (about it being a joke). Thanks for the other pointers.

------
nickpsecurity
Here's an old critique of XMPP by author of PSYC protocol:
[http://about.psyc.eu/XMPP](http://about.psyc.eu/XMPP)

I think it showed how its complexity vs value delivered tradeoff isnt so good.
Decided against trying to implement the protocol.

~~~
davecridland
Worth noting that two of the people fairly heavily quoted on the shortcomings
of XMPP both serve on the XMPP technical Council at the moment. (One of them
is me, the other is Philipp Hancke).

~~~
nickpsecurity
That is interesting. My initial guess would be one of the two:

(a) it's improved remarkably and such short comings don't exist

(b) it won in adoption, it's getting all the labor, and you two are simply
trying to improve it on the technical council.

I'm going with (b) for now. Was I right? Or is XMPP now efficient, easy to
understand, and easy to implement?

~~~
davecridland
Actually a mixture. Some shortcomings have vanished because while they're
problems, they're solved problems. And adoption etc, too.

I'd note that I was never against XMPP, though; I just don't see the need to
pretend it's perfect. I do, however, object when problems are claimed for it
that it doesn't have.

~~~
nickpsecurity
Makes sense. Is there an up-to-date reference on the problems it currently
has? I'm not talking whatever technical papers or submissions to committees.
More an article like the one I cited.

------
lep
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.

[1]: [https://github.com/louiz/biboumi](https://github.com/louiz/biboumi) [2]:
[https://github.com/siacs/HttpUploadComponent](https://github.com/siacs/HttpUploadComponent)

------
jessaustin
_From where I sit typing this, I can look out of my window and see Bryn
Myrddin - Merlin 's Hill - underneath which, legend says, Merlin lies asleep,
awaiting a time when England in is peril once more. This is a problematic
myth, since Bryn Myrddin isn't in England..._

"Merlin" might or might not be based on any historical figure, and such figure
might or might not lie under that hill, and if so he probably knew a few
Angles, but he never heard of "England", because it didn't exist for centuries
after he might or might not have been active.

~~~
davecridland
Thanks for picking up on the important content there. ;-)

If you want to be pedantic, Merlin - assuming he existed in the most likely
timeframe - probably was aware of Angleland to his east, and would have been
defending against its encroachment. (This based on the rise of Arthur as a
popular name around 550AD as I recall, during the "Saxon" invasion largely
carried out by Angles). The country he lived in was probably called something
like Britain, though may have simply been closer to Cymru.

But I was largely paraphrasing T.H. White's Once And Future King, which in
turn cribs the La Morte d'Arthur, which forms the basis for the "modern"
Arthurian legend, and recasts it in an idealized England.

------
fbellag
I'm always playing around with messaging for pet projects, and tried xmpp a
couple of times.

Honest question for edification and future play around projects: what
alternatives do exist, fixing the issues presented here?

I'd love a lean, multiplatform api, with presence, multi-user chat, extensible
for my use case, etc.

Recommendations?

------
dhaneshnm
I find it strange that, nobody has mentioned MQTT so far in this discussion.
Isn't MQTT also a 'competitor' for XMPP, besides JSON-over-Websockets?
especially on mobile devices ?

~~~
detaro
It is not really a competitor for XMPP. It transports messages and you could
build a chat service on top of it, so it is in a somewhat related space, but
XMPP and MQTT aim at very different things.

