This is a custom ejabberd module which allows to bridge all archived messages (from Message Archive Management/XEP-0313) to actual Sidekiq jobs on a Redis database. This enables third party applications to work and react on messages without implementing a XMPP presence application which must subscribe to all multi user chats. Furthermore this module allows direct messages to be processed the same way as multi user chat messages on third party applications. This module requires an activated ejabberd mod_mam to work, because we listen for the storage hooks. They do not suffer from message dupplication. (Copies, changing sender/receiver side)
- ejabberd (=18.01)
- Compiled Redis support (
--enable-redisor erlang-redis-client package on hausgold/ejabberd image)
- Compiled Redis support (
- Redis (>=3.2)
- GNU Make (>=4.2.1)
- Docker (>=17.09.0-ce)
- Docker Compose (>=1.22.0)
See the detailed installation instructions to get the ejabberd module up and running. When you are using Debian/Ubuntu, you can use an automatic curl pipe script which simplifies the installation process for you.
We make use of the global database settings of ejabberd, but you can also specify a different database type by setting it explicitly.
# Global Redis config
# See: https://docs.ejabberd.im/admin/configuration/#redis
redis_server: "redis.server.com"
redis_port: 6379
redis_db: 1
modules:
mod_mam2sidekiq:
sidekiq_queue: "default"
sidekiq_class: "SomeWorker"The project bootstrapping is straightforward. We just assume you took already care of the requirements and you have your favorite terminal emulator pointed on the project directory. Follow the instructions below and then relaxen and watchen das blinkenlichten.
# Installs and starts the ejabberd server and it's database
$ make start
# (The jabber server should already running now on its Docker container)
# Open a new terminal on the project path,
# install the custom module and run the test suite
$ make reload testWhen your host mDNS Stack is fine, you can also inspect the ejabberd admin
webconsole with
[email protected] as username and defaultpw as password. In the
case you want to shut this thing down use make stop.
If you running Ubuntu/Debian, all required packages should be in place out of the box. On older versions (Ubuntu < 18.10, Debian < 10) the configuration is also fine out of the box. When you however find yourself unable to resolve the domains or if you are a lucky user of newer Ubuntu/Debian versions, read on.
Heads up: This is the Arch Linux way. (package and service names may
differ, config is the same) Install the nss-mdns and avahi packages, enable
and start the avahi-daemon.service. Then, edit the file /etc/nsswitch.conf
and change the hosts line like this:
hosts: ... mdns4 [NOTFOUND=return] resolve [!UNAVAIL=return] dns ...Afterwards create (or overwrite) the /etc/mdns.allow file when not yet
present with the following content:
.local.
.localThis is the regular way for nss-mdns > 0.10 package versions (the
default now). If you use a system with 0.10 or lower take care of using
mdns4_minimal instead of mdns4 on the /etc/nsswitch.conf file and skip
the creation of the /etc/mdns.allow file.
Further readings
- Archlinux howto: https://wiki.archlinux.org/index.php/avahi
- Ubuntu/Debian howto: https://wiki.ubuntuusers.de/Avahi/
- Further detail on nss-mdns: https://github.com/lathiat/nss-mdns
The test suite sets up a simple environment with 3 independent users. (admin, alice and bob). A new test room is created by the admin user, as well as alice and bob were made members by setting their affiliations on the room. (This is the same procedure we use on production for lead/user/agent integrations on the Jabber service) The suite sends then multiple text messagess. The Redis database/queue contains then a job for each sent message.
The test suite was written in JavaScript and is executed by Node.js inside a Docker container. We picked JavaScript here due to the easy and good featured stanza.io client library for XMPP. It got all the things which were needed to fulfil the job.