1Observations on implementing XMPP
 2=================================
 3After spending the last two and a half month basically writing my own XMPP
 4library from scratch I decided to share some of the observations I made in the
 5process. In part this article can be seen as a response to a blog post made by
 6Dr. Ing. Georg Lukas. The blog post introduces a couple of XEP (XMPP Extensions)
 7which make the life on mobile devices a lot easier but states that they are
 8currently very few implementations of those XEPs. So I went ahead and
 9implemented all of them in my Android XMPP client.
10
11### General observations
12The first thing I noticed is that XMPP is actually okish designed. If you were
13to design a new chat protocol today you probably wouldn’t choose XML again
14however the protocol basically consists of only three different packages which
15are quickly hidden under some sort of abstraction layer within your library.
16Getting from zero to sending messages to other users actually was very simple
17and straight forward. But then came the XEPs.
18
19### Multi-User Chat
20The first one was XEP-0045 Multi-User Chat. This is the one XEP of the XEPs I’m
21going to mention in my article which is actually wildly adopted. Most clients
22and servers I know of support MUC. However the level of completeness varies.
23MUC actually introduces access and permission roles which are far more complex
24than what some of us are used to from IRC but a lot of clients just don’t
25implement them. I’m not implementing them myself (at least for now) because I
26somewhat doubt that someone would actually use them (however this might be some
27sort of chicken or egg problem). I did find some strange bugs though which might
28be interesting for other library developers. In theory a MUC server
29implementation can allow a  single user (same jid) to join a conference room
30multiple times with the same nick from different clients. This means if someone
31wants to participate in a conference from two different devices (mobile and
32desktop for example) one wouldn’t have to name oneself `userDesktop` and
33`userMobile` but just `user`. Both ejabberd and prosody support this but with
34strange side effects. Prosody for example doesn’t allow a user to change its
35name once two clients are “merged” by having the same nick.
36
37### Carbons and Stream Management
38Two of the other XEPs Lukas mentions — Carbons (XEP-0280) and Stream Management
39(XEP-0198) — were actually fairly easy to implement. The only challenges were to
40find a server to support them (I ended up running my own Prosody server) and a
41desktop client to test them with. For carbons there is a patched Mcabber version
42and Gajim. After implementing stream management I had very good results on my
43mobile device. I had sessions running for up to 24 hours with a walking outside,
44loosing mobile coverage for a few minutes and so on. The only limitation was
45that I had to keep on developing and reinstalling my app.
46
47### Off the record
48And then came OTR... This is were I spend the most time debugging stuff and
49trying to get things right and compatible with other clients. This is the part
50were I want to help other developers not to make the same mistakes and maybe
51come to some sort of consent among XMPP developers to ultimately increase the
52interoperability. OTR has some down sides which make it difficult or at times
53even dangerous to implement within XMPP. First of all it is a synchronous
54protocol which is tunneled through a different protocol (XMPP). Synchronous
55means — among other things — auto replies. (An OTR session begins with “hi I’m
56speaking otr give me your key” “ok cool here is my key”) And auto replies — we
57know that since the first time an out of office auto responder went postal — are
58dangerous. Things really start to get messy when you use one of the best
59features of XMPP — multiple clients. The way XMPP works is that clients are
60encouraged to send their messages to the raw jid and let the server decide what
61full jid the messages are routed to. If in doubt even all of them. So what
62happens when Alice sends a  start-otr-message to Bobs raw jid? Bob receives the
63message on his notebook as well as his cell phone. Both of them answer. Alice
64gets two different replies. Shit explodes. Even if Alice  sends the message to
65bob/notebook chances are that Bob has carbon messages enabled and still receives
66the messages on both devices. Now assuming that Bobs client is clever enough not
67to auto reply to carbonated messages Bob/cellphone will still end up with a lot
68of garbage messages. (Essentially the entire conversation between Alice and
69Bob/notebook but unreadable of course) Therefor it should be good practice to
70tag OTR messages as both private and no-copy (private is part of the carbons
71XEP, no-copy is a general hint). I found that prosody for some reasons doesn’t
72honor the private tag on outgoing messages. While this is easily fixed I presume
73that having both the private and the no-copy tag will make it more compatible
74with servers or clients I don’t know about yet.
75
76#### Rules to follow when implementing OTR
77To summarize my observations on implementing OTR in XMPP let me make the
78following three statements.
79
801. While it is good practice for unencrypted messages to be send to the raw jid
81and have the receiving server or user decide how they should be routed OTR
82messages must be send to a specific resource. To make this work the user should
83be given the option to select the presence (which can be assisted with some
84educated guessing by the client based on previous messages).  Furthermore a
85client should encourage a user to choose meaningful presences instead of the
86clients name or even random ones. Something like `/mobile`, `/notebook`,
87`/desktop` is a greater assist to any one who wants to start an otr session then
88`/Gajim`, `/mcabber` or `/pidgin`.
89
902. Messages should be tagged private and no-copy to avoid unnecessary traffic or
91otr error loops with faulty clients. This tagging should be done even if your
92own client doesn’t support carbons.
93
943. When dealing with “legacy clients” — meaning clients which don’t follow my
95advise — a client should be extra careful not to create message loops. This
96means to not respond with otr errors if a client is not 100% sure it is the only
97client which received the message