This page is about planning the implementation of an XMPP service for Debian.org users.
Although no product has been formally selected, there seems to be a preference for using Prosody. This is based on feedback from a number of people including DSA and the XMPP operators we consulted with.
This list of issues is roughly based on the experiences we had integrating the SIP proxy with Debian infrastructure to be supported by DSA.
Using packages from the stable (or stable-backports) release
The DSA team always prefer to use packages from the stable distribution (or the stable backports), is there any compelling reason we should not use those versions for this project?
Using HA1 password hashes
Debian Developers have been given RTC passwords for TURN and SIP and hopefully XMPP. They are hashed using HA1 for DIGEST/HMAC algorithms such as SIP and TURN.
The user passwords are available in two ways: we can supply a text file directly to the server (see the format used by reTurn, link below) or via a FreeRADIUS server with the rlm_digest module - can Prosody use either of these solutions or do we need to come up with something else?
reTurn users.txt sample (we use HA1 in the third column now): [https://github.com/resiprocate/resiprocate/blob/master/reTurn/users.txt]
FreeRADIUS rlm_digest: [http://freeradius.org/radiusd/man/rlm_digest.txt]
Any new stuff we do in Debian has to be dual stack, should this be fine with Prosody?
Other dependencies, e.g. databases
Debian infrastructure currently uses PostgreSQL (no MySQL) but if possible, using no database at all, keeping each process somewhat self-contained. Looking at the package dependencies, I see that several databases are suggested. Could anybody comment on just how compelling it is to use a full SQL database, can we happily use the sqlite3 driver, etc?
Collaboration with the SIP infrastructure
Is there any practical way to share presence services, chat messages or anything else just yet? We don't have any presence server for SIP right now, it would be nice to plan the strategy for that alongside the XMPP planning.
Default XMPP does not acknowledge receipts of messages. If a TCP connection breaks, messages get lost. XEP-198 addresses this, but it needs support from clients and servers.
ejabberd in jessie does implement XEP-198 (since version 14.05)!
Many of us will want to use multiple clients and while XMPP supports that (via "resources"), the history is not shared. Thus, if you write to a friend from your laptop, you won't see what you wrote when you read the reply on your mobile device later.