Ejabberd is a very flexible and scalable XMPP server. We use it because it can be configured using a simple yaml configuration file and managed via ejabberdctl commands. This makes it a good fit for our infrastructure as code approach. That said, ejabberd does require one to understand the XMPP protocol/jargon as it does not abstract away any of it. So simple things like creating chatrooms, limiting access to them and playing history backlog to users who connected them can be an effort if you’ve never done it.

When using ejabberd in a company for multi-user chat (see my earlier blog post) people will quickly start complaining that they missed discussions because they had been offline. Ejabberd does play back last 20 messages when user joins a room, but that is too little for an active chatroom. The simplistic approach is to set history_size in mod_muc settings in ejabberd.yml to a higher value:

mod_muc:
  history_size: 200
  --- snip ---

This simplistic approach should work with any XMPP clients.

As mentioned in our earlier blog post we created an “email to XMPP bridge” called milter-xmpp for forwarding alert emails from monitoring systems to an XMPP chatroom. It was known that if the connection to the XMPP server ever died the bridge would stop working, but we wanted to know how fast that would happen. It took some days, but eventually the connection died.

The fix ended up being quite trivial, but we needed a way to break the connection. Fortunately the good folks at StackExchange already had a good solution: use the “ss” tool (“another utility to investigate sockets”) which provides output similar to netstat:

We have used XMPP (Jabber) for our internal discussions for years. In the recent years it seems that XMPP has lost some of its traction. For example, Google and Facebook used to use XMPP for instant message and Slack used to have an XMPP bridge in their service. All of those are now gone and have been replaced with proprietary messaging protocols. In the context of a big company having all the control over the protocol probably makes sense, but it of course makes life difficult for users who have to have a separate client for each or have to use a multi-protocol client such Pidgin just to keep their sanity. And none of the big players seems to “winning the war” for users.