Introduction

The Debian runs an XMPP service using Prosody. This choice was based on feedback from a number of people including DSA and the XMPP operators we consulted with.

Questions about the server should be addressed to members of the RTC team.

The rest of this page documents various technical decisions and integration work that was required during the integration, and only remains here for reference purposes.

Technical issues

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?

For Prosody:

|stable|0.9.7-2+deb8u1|

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.

Can XMPP use these password hashes or do we need to hash them in some other format? mod_auth_ha1 But with some modifications. Version provided by prosody-modules package provides it patch

Password database/RADIUS

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]

IPv6

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.

Message reliability

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.

Prosody supports XEP-198 using mod_smacks, which is community-contributed and currently included in the prosody-modules Debian package.

ejabberd in jessie does implement XEP-198 (since version 14.05)!

There are bug reports for BitlBee, for Xabber (Android), and maybe more (please extend…).

Android clients that support XEP-198 include (though have not been tested): ?https://github.com/siacs/Conversations, Tigase, Yaxim, ChatSecure, please extend.

Message carbons

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.

XEP-280 provides the concept of "message carbons" and XEP-313 works on the idea of server-side history storage.

mod_carbons included in the prosody-modules Debian package.

There are bug reports for ?BitlBee (XEP-280), Xabber (XEP-280 and XEP-313), and any more you may add…