You can now easily find an XMPP provider based in the European Union (EU)!
We have updated our filter options.
Previously, you could filter for the server location of an XMPP provider.
That filter now allows to select EU-only hosted services.
Try it out!
Click the Filter list drop-down menu on the main page.
The location-based filter allows to select the server location.
There are many other properties you can filter for, too.
In addition, there is an overview table of providers with column filters and sorting options.
Looking forward to more European Union XMPP chat providers and beyond!
You can also consider to run your own XMPP server and become a public provider.
With our automated XMPP server setup, you can operate a fully-featured XMPP server with minimal effort.
We are pleased to announce a new minor release from our stable branch.
Welcome to another minor release from our stable branch!
We encourage any deployments using 13.0.3 to upgrade, partly due to a bug that
was introduced into UUID generation in that release. We’re not aware of any
direct consequences of this bug, but it may cause compatibility problems with
other software.
Although not strictly bug fixes, we sneaked in some configuration-related
improvements to this release which help make configuring Prosody a little
easier and more reliable. We’re highlighting them because these changes have a
chance to impact some rare configurations.
The first change is to prevent mod_pubsub from being loaded on a VirtualHost
(easily done if you accidentally add it to your global modules_enabled list).
Loading mod_pubsub on a normal user host can lead to unexpected behaviour. Now
it will log an error and refuse to load if you do that.
The second change is to simplify configuration of archiving in MUCs.
Practically all modern clients now use XEP-0313 to synchronize message
history. For VirtualHosts this is implemented in mod_mam, and for MUC
components it is implemented in mod_muc_mam. From this release, things get
much simpler: loading mod_mam (globally or directly on a MUC component) will
automatically load mod_muc_mam on the MUC component. This means most people
(e.g. who have mod_mam loaded globally on their server) can now remove
“muc_mam” from modules_enabled in their MUC component configuration. It will
be loaded automatically.
This last point does mean that if you have mod_mam enabled globally, but do
not want it enabled on your MUCs, you now have to state that explicitly
by adding “mam” to modules_disabled under the MUC’s Component. Be aware that
such a configuration may lead to missing messages in group chats.
A summary of changes in this release:
Fixes and improvements
mod_s2s: Fix traceback when outgoing s2s queue is full
util.uuid: Fix padding of group 2 of UUIDv7 to use zeroes
Minor changes
core.modulemanager: Fix shell commands on components
mod_s2s: Explicitly prevent sending recursive error replies when queue is full
modulemanager: Allow component modules to specify additional inherited modules
prosodyctl check features: Use modulemanager to calculate modules that will actually be loaded
prosodyctl check features: change recommendation from mod_muc_mam to mod_mam
prosodyctl check config: Fix traceback when zero modules are enabled
mod_pubsub: Fail early if loaded outside of a component to prevent misconfiguration
doap: Add XEP-0486
mod_pubsub/commands: Fix listing item numbers along with item names
mod_account_activity: Handle authentication provider returning no user info
mod_mam: Automatically load mod_muc_mam if loaded on a MUC component
mod_muc: Inherit mod_mam if globally loaded
Download
As usual, download instructions for many platforms can be found on our download page
If you have any questions, comments or other issues with this release, let us know!
We’re sharing a sneak peek at the visual design of the upcoming release of
Snikket’s Android app - what we’ve changed, why, and how we got here. The new
app will be released on 25th January 2026. To learn more about using Snikket
for your communication, check our homepage.
The foundational principles of good user interface design never really change.
People should be able to easily find common actions, text should be clear and
legible, buttons should be large enough to press, to name a few. But around
these pillars, aesthetic conventions are always shifting and evolving.
Android 2009
Android 2014
Android 2026
Years ago, square corners used to be lauded as “crisp”. Today, rounded
edges are marvellously “smooth”. Where shadows used to add a three-dimensional
realism to our interfaces, flat designs are now the norm in most apps.
One of Snikket’s goals is to be approachable and familiar to people who are
used to other popular messaging ecosystems. It should be a welcoming gateway
to the world of decentralized messaging. This means, where reasonable, keeping
up with the conventions established by other widespread communication apps. We
can’t stand still.
Snikket’s Android app has been looking increasingly out of place in recent
years, compared to the rest of the apps on a typical Android phone. A
large reason for this is the shift towards Google’s Material design -
the latest design framework that Android uses, and provides to developers, to
help with the design, colours, typography and user interface controls in applications.
For the next release, the Snikket app has been updated to Material 3. This is
largely thanks to the work done by Daniel on the upstream Conversations app
which underlies the Snikket Android app. On top of the work in Conversations,
we have put a Snikket spin on the new interface, aligning it with our colours,
and making adjustments to various elements to ensure the design feels familiar,
friendly and accessible.
A sample of our updated colour palette
While our brand colour remains our iconic yellow, we have designed a new
colour palette for this release. This is derived from Material 3 guidelines,
with assistance from the ever-helpful folk at Superbloom,
plus a custom-built utility to ensure excellent colour contrast across all our
new colours and ensure sufficient legibility.
Speaking of colours, the app now also supports “Material You”, which is a
feature of modern Android that allows apps to adapt to a user-chosen colour
scheme or wallpaper image without sacrificing usability. If enabled in the
settings, Snikket will automatically follow your system’s dynamic colour
scheme.
Chat bubbles can now follow your system theme colours
…in both light and dark mode
Chat bubbles have been given additional space to more clearly separate
individual messages, and default font sizes have been slightly increased.
These changes were made after carefully reviewing the interfaces of other similar
messaging apps. The goal is to allow anyone to feel as “at home” when using
Snikket as they would any other app on their device.
The original Snikket Android
The new Snikket Android
Snikket continues to follow the system font preferences as in the past, but
during our research we found our default font size was slightly smaller than
other messaging apps we compared with. Our default size now matches what other
similar apps use, and an in-app setting allows you to further boost the font
size of messages in case you just need that little bit of extra clarity in
your chats.
Old font size, new size, and optional extra large size
We hope that each aspect of the new design helps people feel even more at home
when using Snikket. The new release will be available on the 25th January!
If you are upgrading from a previous version, there are no mandatory changes in SQL schemas, configuration, API commands or hooks. However new mod_invites uses a new table in databases, see below.
Below is a detailed breakdown of the improvements and enhancements:
Database Serialization
This feature adds new way for migrating data between database backends by exporting data from one backend to a file and importing that into different backend (or possibly to same backend but on different machine).
Migrating data using this can be executed by first exporting all data with export_db command, changing configuration of ejabberd and switching modules to use new database backend, and then importing previously exported data using import_db command.
This mechanism works by calling those new command from ejabberdctl, for exporting data:
ejabberdctl export_db <host name> <path to directory where exported files should be placed>
ejabberdctl export_db_abort <host name>
ejabberdctl export_db_status <host name>
and for importing:
ejabberdctl import_db <host name> <path to directory with exported data>
ejabberdctl import_db_abort <host name>
ejabberdclt import_db_status <host name>
Exporting and importing work in background after starting them from ejabberdctl (commands executed by ejabberdctl have time limit for how long they can work, with this setup there should be not issue with export or import getting aborted by that), and current progress of background operation can be tracked by calling corresponding *_db_status command. Operation in progress can be also aborted by executing *_db_abort command.
Roster Invites and Invite-based Account Registration
Until now the canonical method to register an account in ejabberd was to let anybody register accounts using In-Band Registration (IBR) (mod_register) or Web Registration (mod_register_web), and then try to limit abuse with access limitations or CAPTCHAs. Often this process got abused, with the result that account registration had to be disabled and rely on manual registration by administrators.
The new mod_invites implements support for invite-based account registration: administrators can generate invitation URLs, and send them to the desired users (by email or whatever). Then the user that receives an invitation can visit this invitation URL to register a new account.
On top of that, mod_invites lets you create Roster Invites: you can send a link to some other person so they can connect to you in a very user-friendly and intuitive way that doesn&apost require any further interaction. If account creation is allowed, these links will also allow to setup an account in case the recipient doesn&apost have one yet.
If you plan to use the landing page included with mod_invites, install JavaScript libraries jQuery version 3.7.1 and Bootstrap version 4.6.2. This example configuration will assume they are installed in /usr/share/javascript. The ejabberd container image already includes those libraries. Some quick examples, in case you need some help:
Debian and related:
apt install libjs-jquery libjs-bootstrap4
AlpineLinux and other operating systems where you can install npm, for example:
Configure ejabberd to serve the JavaScript libraries in path /share; serve mod_invites in any path of your selection; and enable mod_invites with some basic options. Remember to setup mod_register to allow registering accounts using mod_invites. For example:
The destination user (or yourself) can visit that invitation URL and follow the instructions to register the account and download a compatible client.
If the user has installed already a compatible XMPP client, you don&apost no need to install JavaScript libraries and setup a landing page. In that case, when generating an invitation you will get only the XMPP URI; when the user opens that URI in a web browser, it will automatically open the XMPP client and the corresponding registration window.
Probably you don&apost want to expose the port directly, then you need to setup Nginx or Apache to act as a "reverse" proxy and change your landing_page parameter accordingly, for example just https://@HOST@/invites/{{ invite.token }}
There is a new table invite_token in SQL schemas, used by the new mod_invites. If you want to use this module, there are two methods to update the SQL schema of your existing database:
If using MySQL or PosgreSQL, you can enable the option update_sql_schema and ejabberd will take care to update the SQL schema when needed: add in your ejabberd configuration file the line update_sql_schema: true
Notice that support for MSSQL in mod_invites has not yet been implemented or tested.
If you are using other database, or prefer to update manually the SQL schema:
MySQL singlehost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
invitee text NOT NULL DEFAULT (&apos&apos),
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
expires timestamp NOT NULL,
type character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token(191))
) ENGINE=InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE INDEX i_invite_token_username USING BTREE ON invite_token(username(191));
MySQL multihost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
server_host varchar(191) NOT NULL,
invitee text NOT NULL DEFAULT &apos&apos,
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
expires timestamp NOT NULL,
type character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token(191)),
) ENGINE=InnoDB CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE INDEX i_invite_token_username USING BTREE ON invite_token(username(191));
PostgreSQL singlehost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
invitee text NOT NULL DEFAULT &apos&apos,
created_at timestamp NOT NULL DEFAULT now(),
expires timestamp NOT NULL,
"type" character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token)
);
CREATE INDEX i_invite_token_username ON invite_token USING btree (username);
PostgreSQL multihost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
server_host text NOT NULL,
invitee text NOT NULL DEFAULT &apos&apos,
created_at timestamp NOT NULL DEFAULT now(),
expires timestamp NOT NULL,
"type" character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token)
);
CREATE INDEX i_invite_token_username_server_host ON invite_token USING btree (username, server_host);
SQLite singlehost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
invitee text NOT NULL DEFAULT &apos&apos,
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
expires timestamp NOT NULL,
type character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token)
);
CREATE INDEX i_invite_token_username ON invite_token(username);
SQLite multihost schema:
CREATE TABLE invite_token (
token text NOT NULL,
username text NOT NULL,
server_host text NOT NULL,
invitee text NOT NULL DEFAULT &apos&apos,
created_at timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
expires timestamp NOT NULL,
type character(1) NOT NULL,
account_name text NOT NULL,
PRIMARY KEY (token)
);
CREATE INDEX i_invite_token_username_server_host ON invite_token(username, server_host);
New replaced_connection_timeout toplevel option
The new replaced_connection_timeout toplevel option enables new session to wait for termination of session that it replaces.
This should mitigate problems where old session presences unavailable sometimes were delivered after new session sent it&aposs presence available.
Improved mod_http_fileserver docroot option
mod_http_fileserver is a module to serve files from the local disk over HTTP, useful if you just want to serve some HTML or binary files that don&apost need PHP, and don&apost need to setup or configure a separate full-blown web server.
Now the docroot option may be a map of paths to serve, allowing this module to serve several paths with different directories for different purposes.
For example, let&aposs serve some public content from /var/service/www, also shared JavaScript libraries, and for base URL let&aposs serve from /var/www:
Notice that ejabberd includes many modules that serve web services, that may be useful to save you from setting up a full-blown web server, see ejabberd_http.
Supported XEP versions
ejabberd supports close to 90 XMPP extension protocols (XEPs), either directly implemented in ejabberd source code, in the libraries that implement many of the internal features, or in other ejabberd modules available in other repositories like ejabberd-contrib.
Those XEPs are updated regularly to bring major improvements, minor changes, fixing typos, editorial or cosmetic changes... and this requires a regular review of those XEP updates in the software implementations to keep them up to date, or at least to document what exact version of the protocols are implemented.
In this sense, we have reviewed all the XEP versions that ejabberd and erlang xmpp library were not up-to-date, and have identified which ones are already up-to-date in their DOAP files. Now the pages at XMPP.org describe more accurately the supported protocol versions, see ejabberd at XMPP.org and erlang-xmpp at XMPP.org.
Erlang, Elixir and Container
ejabberd can be compiled with Erlang/OTP from 25.0 up to the latest 28.3.1. Regarding Elixir support, ejabberd supports from Elixir 1.14.0 up to the latest 1.19.5
Right now ejabberd compiles correctly with Erlang/OTP from git development branch and Elixir 1.20.0-RC1, so hopefully compatibility with the upcoming Erlang/OTP 29 and Elixir 1.20 will be easily achievable.
Binary installers and the ejabberd container now include Erlang/OTP 28.3.1 instead of 27.3, and Elixir 1.19.5 instead of 1.18.4.
Speaking of the container images, both ejabberd and ecs bring other minor changes: they expose more ports: 5478 UDP (STUN service), 7777 (SOCKS5 file transfer proxy) and 50000-50099 UDP (TURN service).
The container images in their ejabberd.yml file use new macros PORT_TURN_MIN, PORT_TURN_MAX, and STARTTLS_REQUIRED that you can setup easily without modifying ejabberd.yml, see macros in environment.
That Erlang Distribution has historically used the epmd program to assign listening ports and discover ports of other nodes to connect. The problems of using epmd are that:
epmd must be running all the time in order to resolve name queries
epmd listens in port 4369
the ejabberd node listens in a random port number
How to avoid epmd since Erlang/OTP 23.1 and ejabberd 22.10 ? Simply set the ERL_DIST_PORT environment variable in the ejabberdctl.cfg file:
ERL_DIST_PORT=5210
Since now, ejabberdctl passes arguments to Erlang to listen for erlang distribution connections in TCP port 5210, and establish erlang distribution connections to remote ports 5210. That way you know exactly, in advance, what port number to open in the firewall or container.
This ejabberd release introduces some small improvements that facilitate using the ERL_DIST_PORT environment variable:
ejabberdctl prints an informative message when it detects that there may be a port number collision, which may happen if you start several ejabberd nodes in the same machine listening in the same ERL_DIST_PORT and same INET_DIST_INTERFACE.
When ejabberd is starting, now it prints the address and port number where it listens for erlang distribution:
[info] ejabberd 26.01 is started in the node ejabberd@localhost in 1.90s
[info] Elixir 1.19.4 (compiled with Erlang/OTP 28)
[info] Erlang/OTP 29 [DEVELOPMENT] [erts-16.2] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit:ns]
[info] Start accepting TCP connections at 0.0.0.0:5210 for erlang distribution
[info] Start accepting TCP connections at [::]:5222 for ejabberd_c2s
[info] Start accepting TCP connections at [::]:5269 for ejabberd_s2s_in
...
A new make relivectl is introduced, which uses ejabberdctl script to start ejabberd (not like make relive), and starts ejabberd immediately without building a release (not like make dev).
make relive was introduced in ejabberd 22.05. It allows to start ejabberd in path _build/relive/ without installing it, by using rebar3 shell and mix run. It automatically compiles code at start and recompiles changed code at runtime. But it doesn&apost use the ejabberdctl script, and doesn&apost read ejabberdctl.cfg, this means that depending on what you are testing, it may not be useful and you had to switch to make dev.
A new make target is now introduced: make relivectl. This is similar, as it starts ejabberd without requiring installation, using path _build/relivectl/ to store the configuration, database and log files. The benefit over relive is that relivectl uses ejabberdctl and reads ejabberdctl.cfg. The drawback is that it doesn&apost recompile code automatically. The benefit over make dev is that relivectl doesn&apost build an OTP release, so it&aposs faster to start.
Let&aposs summarize all the make targets related to installation to determine their usage differences:
As seen in the table, make install / uninstall seem unnecessary nowadays, because install-rel / uninstall-rel allow to install and uninstall correctly all the files. Maybe in the future the implementation of make install / uninstall could get replaced with make install-rel / uninstall-rel...
In the same sense, make dev now apparently falls short between make prod (which is absolutely indispensable to build a full OTP release) and make relive/relivectl (useful, featureful, and fast for development and testing purposes).
WebAdmin Menu Links
Do you remember that ejabberd 25.07 introduced a link in WebAdmin to the local Converse.js page in the left menu when the corresponding mod_conversejs is enabled?
Technically speaking, until now the WebAdmin menu included a link to the first request_handler with mod_conversejs that the admin configured in ejabberd.yml. That link included the authentication credentials hashed as URI arguments if using HTTPS. Then process/2 extracted those arguments and passed them as autologin options to Converse.
From now, mod_conversejs automatically adds a request_handler nested in WebAdmin subpath. The WebAdmin menu links to that converse URI; this allows to access the HTTP auth credentials, no need to explicitly pass them. process/2 extracts this HTTP auth and passes autologin options to Converse. Now scram password storage is supported too.
In practice, what does all that mean? Just enable the mod_conversejs module, and WebAdmin will have a private Converse URL for the admin, linked in the WebAdmin menu, with autologin. No need to setup a public request_handler!
For example, let&aposs configure conversejs only for admin usage:
With that configuration, what is the corresponding URL?
Login to the WebAdmin and look at the left menu: now it displays links to all the configured HTTP services: ejabberd_captcha, ejabberd_oauth, mod_conversejs, mod_http_fileserver, mod_register_web. Also mod_muc_log_http and mod_webpresence from ejabberd-contrib show links in the WebAdmin left menu. Additionally, the menu shows a lock if the page is encrypted HTTPS, and an ! if it is not.
Acknowledgments
We would like to thank the contributions to the source code, documentation, and translation provided for this release by:
Stefan Strigler for new feature Great Invitations aka mod_invites
And also to all the people contributing in the ejabberd chatroom, issue tracker...
Improvements in ejabberd Business Edition
Customers of the ejabberd Business Edition, in addition to all those improvements and bugfixes, also get the following changes:
New module mod_push_gate that can act as target service for mod_push, and which can deliver pushes using configured mod_gcm or mod_applepush instances.
New module mod_push_templates that can be used to have different push notifications for message class matching configured data patterns.
New database conversion routines targeting p1db backends
ChangeLog
This is a more complete list of changes in this ejabberd release:
Compile and Start
Remove dependencies, macros and code for Erlang/OTP older than 25
Require Elixir 1.14 or higher, that&aposs the lowest we can test automatically
ejabberdctl: Support NetBSD and OpenBSD su (#4320)
ejabberdctl.template: Show meaningful error when ERL_DIST_PORT is in use
ejabberd_app: Print address and port where listens for erlang node connections
Makefile.in: Add make relivectl similar to relive but using ejabberdctl
Databases
Add db_serialize support in mnesia modules
Add db serialization to mod_muc_sql
New database export/import infrastructure
Add commands for new database export/import
Apply timestamp pass in ?SQL_INSERT queries
Update p1_mysql to bring fix for timestamp decoding
Extend timestamp type handling in sql macros
Revert changes to conversion of pgsql int types
Installer and Container
make-binaries: Bump Erlang/OTP 28.3.1 and Elixir 1.19.5
Dockerfile: Bump Erlang/OTP 28.3.1 and Elixir 1.19.5
Dockerfile: Expose also port 7777 for SOCKS5
Dockerfile: Configure TURN ports and expose 5478 50000-50099
Dockerfile: Try to fix error with recent freetds Alpine package
Container: Setup new macro STARTTLS_REQUIRED to allow easy disabling
MUC
Add muc_online_rooms_count API command
Set enable_hats room option true by default
Allow vcard queries even when IQ queries are disabled (#4489)
Announce stable-id feature from XEP-0045 1.31, supported since long ago
I am excited to share that members of the IgniteRealtime community will be heading to Brussels, Belgium, from January 29th to February 1st to take part in two important events for the open-source and real-time communications ecosystem: the annual XSF Summit and FOSDEM.
XSF Summit: Connecting the XMPP community
The XSF Summit, organized by the XMPP Standards Foundation, brings together developers, maintainers, and contributors from across the XMPP ecosystem. IgniteRealtime community members will be there to collaborate with peers, discuss the current state and future direction of XMPP, and share insights from ongoing IgniteRealtime projects.
These face-to-face discussions are invaluable for aligning on standards, exchanging implementation experience, and strengthening the relationships that keep open, decentralized communication thriving.
FOSDEM: Celebrating open source at scale
Following the XSF Summit, our community members will also attend FOSDEM (Free and Open source Software Developers’ European Meeting), one of the largest and most influential open-source conferences in the world.
FOSDEM is a unique opportunity to:
Learn about the latest developments across a wide range of open-source technologies
Meet contributors and users from diverse projects and communities
Represent IgniteRealtime and real-time communication technologies within the broader open-source ecosystem
You’ll likely find us at the XMPP & Realtime Lounge (building AW, level 1).
Meet us in Brussels
If you’re attending the XSF Summit, FOSDEM, or will be in Brussels during this time, we’d love to connect. These events are a great chance to meet fellow IgniteRealtime users and contributors, exchange ideas, and talk about where we’re headed next.
We look forward to productive discussions, new connections, and bringing fresh energy and ideas back to the IgniteRealtime community. See you in Brussels!
For other release announcements and news follow us on Mastodon or X
Our latest release 6.5.0 of MongooseIM focuses on easier integration with your applications while continuing to deliver a scalable and reliable messaging server built on top of the extensible and battle-proven XMPP protocol.
For integration with other services, you can use the Admin or User GraphQL API. Another example is the interaction of MongooseIM with a database. A relational DB such as PostgreSQL, MySQL or CockroachDB can be used to store user accounts, message archives, multi-user chatrooms, publish-subscribe nodes, cluster nodes and much more. Other supported databases and storage services include Cassandra or Elastic Search for message archive, Redis for user sessions and LDAP for authentication.
There is another important way to let MongooseIM interact with your distributed system: event pushing. The core of this functionality is the event pusher module, which can push selected events to services like Amazon SNS, RabbitMQ or MongoosePush. In the most recent release 6.5.0, we have improved the event pushing mechanism, focusing on better integration with RabbitMQ.
Event pushing in MongooseIM 6.5.0
The diagram below explains the event pushing architecture in the latest version of MongooseIM:
Events utilize the concept of hooks and handlers. Currently, events are triggered for a few selected hooks, e.g. when a user logs in/out or sends/receives a message. There are almost 140 different hooks defined in MongooseIM though, so there is much room for adding custom events. A module called mod_event_pusher_hook_translator handles the selected hooks, creating events and passing them to the main event pusher API function, mod_event_pusher:push_event/2.
Then, a hook called push_event is triggered, leveraging the hooks-and-handlers mechanism for the second time. This hook is handled by configurable service-specific backend modules, such as:
sns – for sending notifications to Amazon SNS,
rabbit – for sending notifications to RabbitMQ or CloudAMQP,
http – for sending notifications to a custom service,
push – for sending push notifications to mobile devices with the help of MongoosePush.
These modules act as interfaces to the corresponding external services. A key feature of this design is its extensibility. For example, one can easily add a kafka backend module that would deliver the events to Apache Kafka as shown on the diagram above.
Push notifications
Let’s focus on the push module as it is a bit more complex. In general, it uses hooks and handlers once again – the push_notifications hook in particular. In order to actually deliver push notifications to a mobile device, a module called mod_push_service_mongoosepush handles that hook by sending the notifications to a separate service called MongoosePush. Finally, MongoosePush will dispatch the notification request and send the notifications to configured services such as APNs or Google FCM.
Each stage of this process is configurable and extensible. Firstly, we have assumed that a virtual pubsub host is used, but there is also an option to use a separate pubsub node for push notifications as described in XEP-0357: Push Notifications, adding another step before running the push_notifications hook. Speaking about that hook, you can implement your own module handling it by calling your own service instead of MongoosePush. Additionally, if you need to extend the notification logic with additional filtering and processing, you can implement a plugin module to mod_event_pusher_push.
Pushing events to RabbitMQ
The RabbitMQ backend module was improved and made production-ready in version 6.5.0, and our full blog post shows how you can easily configure MongooseIM to push events to RabbitMQ - you can literally set up a working dockerized solution in a few minutes.
Summary
The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself, but of course don’t hesitate to contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and – if necessary – customise it to fit your particular needs. For more information about the latest improvements, see the release notes.
MongooseIM 6.5: Open for Integration is now available. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server.
For such integration, you can use the Admin or User GraphQL API. Another example is the interaction of MongooseIM with a database. A relational DB such as PostgreSQL, MySQL or CockroachDB can be used to store user accounts, message archives, multi-user chatrooms, publish-subscribe nodes, cluster nodes and much more. Other supported databases and storage services include Cassandra or Elastic Search for message archive, Redis for user sessions and LDAP for authentication.
You can see the complete list in our documentation. There is another important way to let MongooseIM interact with your distributed system: event pushing. The core of this functionality is the event pusher module, which can push selected events to services like Amazon SNS, RabbitMQ or MongoosePush. In the most recent release 6.5.0, we have improved the event pushing mechanism, focusing on better integration with RabbitMQ.
Event pushing in MongooseIM 6.5.0
The diagram below explains the event pushing architecture in the latest version of MongooseIM:
Events utilize the concept of hooks and handlers. Currently, events are triggered for a few selected hooks, e.g. when a user logs in/out or sends/receives a message. There are almost 140 different hooks defined in MongooseIM though, so there is much room for adding custom events. A module called mod_event_pusher_hook_translator handles the selected hooks, creating events and passing them to the main event pusher API function, mod_event_pusher:push_event/2.
Then, a hook called push_event is triggered, leveraging the hooks-and-handlers mechanism for the second time. This hook is handled by configurable service-specific backend modules, such as:
rabbit – for sending notifications to RabbitMQ or CloudAMQP,
http – for sending notifications to a custom service,
push – for sending push notifications to mobile devices with the help of MongoosePush.
These modules act as interfaces to the corresponding external services. A key feature of this design is its extensibility. For example, one can easily add a kafka backend module that would deliver the events to Apache Kafka as shown on the diagram above.
Push notifications
Let’s focus on the push module as it is a bit more complex. In general, it uses hooks and handlers once again – the push_notifications hook in particular. In order to actually deliver push notifications to a mobile device, a module called mod_push_service_mongoosepush handles that hook by sending the notifications to a separate service called MongoosePush. Finally, MongoosePush will dispatch the notification request and send the notifications to configured services such as APNs or Google FCM.
Each stage of this process is configurable and extensible. Firstly, we have assumed that a virtual pubsub host is used, but there is also an option to use a separate pubsub node for push notifications as described in XEP-0357: Push Notifications, adding another step before running the push_notifications hook. Speaking about that hook, you can implement your own module handling it by calling your own service instead of MongoosePush. Additionally, if you need to extend the notification logic with additional filtering and processing, you can implement a plugin module to mod_event_pusher_push.
Pushing events to RabbitMQ
As the RabbitMQ backend module was improved and made production-ready in version 6.5.0, let’s use it as an example of how you can easily configure MongooseIM to push events to RabbitMQ. The simplest way to demonstrate this is with Docker containers. Firstly, we need a container for RabbitMQ:
docker network create example
docker run --rm -d --network example --name rabbit rabbitmq:management
The management tag is used because we will need the rabbitmqadmin command. The default port 5672 will be used by MongooseIM. The connection is unencrypted for simplicity, but it is recommended to use TLS in a production environment.
As the next step, let’s obtain the default mongooseim.toml configuration file from the MongooseIM 6.5.0 image:
This default configuration file uses the Mnesia internal database. Although we recommend using CETS and a relational database instead of Mnesia, in this example we will try to keep it as simple as possible – so you only need to add the following to mongooseim.toml:
The first section configures a pool of connections to RabbitMQ with the default settings, while the second one enables the event pusher module with the rabbit backend, and includes chat_msg_exchange in order to enable the exchange for one-to-one chat messages (called chat_msg by default – see all options). If you are wondering where to add these lines to mongooseim.toml – you can put them anywhere, but it is recommended to group them by section (e.g. outgoing_pools, modules etc.) for readability.
Having the configuration file ready, we can start the MongooseIM container:
docker run --rm -d --network example -e JOIN_CLUSTER=false \
-v ./mongooseim.toml:/usr/lib/mongooseim/etc/mongooseim.toml \
--name mongooseim erlangsolutions/mongooseim:6.5.0
After it starts, the chat_msg exchange should be automatically created in RabbitMQ. In order to see its messages, we need to bind a queue to it.
The routing key *.chat_msg_recv means that only the events for received messages will be routed – in this example we skip all events for sent messages. Now let’s create two user accounts in MongooseIM:
You should get the “User … successfully registered” message for each of them. Next, send the message from alice to bob – we could do that with an XMPP client, but the simplest way here is to use the admin CLI:
This simple example shows how easy it is to extend the functionality of MongooseIM beyond XMPP – as soon as you have the events in a message queue like RabbitMQ, you can perform various actions on them such as calculating statistics for billing purposes, performing analytics or storing them in an external database separate from MongooseIM.
Summary
The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself, but of course don’t hesitate to contact us if you are considering using it in your business – we will be happy to help you install, configure, maintain, and – if necessary – customise it to fit your particular needs. For more information about the latest improvements, see the release notes.
On the 13th of January I was invited back to play for the Trolley Barn Contra
Dance’s first dance of 2026.
For the first time since I’ve been DJing for the Tuesday night dances at the
Trolley Barn I was working with a caller (or “callers”, plural, in this case)
other than my friend Valerie.
I’ve heard Rob and Amanda call plenty of times and even spent some time with
them at caller workshops, so we’re not exactly strangers, but I still have much
less knowledge of their capabilities, likes, and dislikes than I do with
Valerie.
This adds a set of complications over working with a close personal friend.
The night was a bit rougher, in my estimation, than previous nights when I’ve
DJed, and I think a large part of that comes down to how I prepare and work with
the caller.
This is something I hadn’t considered previously, and something I’m going to
have to work on getting better at for future engagements.
That said, the evening was still a lot of fun and I think the dancers had a good
time.
The Set
The evening started out with “Push the Button” by an unknown choreographer.
I used a mix that I had done previously, Basketball / FIDDLE DISCO! by
Countercurrent and Elias Alexander.
Like last time I let it run a little long before the caller had signaled the
end of the song and had to jump around a bit in a way that was a bit jarring.
I was also a little disappointed with the pairing, as I had previously decided
to use something else with this dance that I think would have been much more
fun.
The callers and I had exchanged sets (dances and music) in advance specifically
to make the musical pairings for the dance a little better and so that Rob and
Amanda could practice to unfamiliar and, sometimes, more challenging music.
Unfortunately Rob was having trouble calling to my original medley, and asked me
to change it last minute.
I’m not sure that I will share the set this way again, instead I might send
callers samples of things I’ve played in the past, ask if they have any requests
(if it’s early enough to do so), but otherwise ask to be treated just like a
normal band.
I may also ask how experienced the caller is and if they’re comfortable calling
to music that may not sound like a traditional contra tunes.
At the very least, even if I do send someone the set in advance in the future, I
will set a hard deadline for when changes can be requested (and it will not be
“the night before”).
Next Amanda called “Al’s Safeway Produce” by Robert Cromartie.
I tried something that I knew would be a tiny it harder with this one and did a
mix of “Morrison’s” and “Quarry Cross”, both by The Gaslight Tinkers.
We got a bit off at one point and wound up off the phrase, but Amanda did a
great job of continuing to call and I doubt the dancers noticed that they were
perpetually 4 bars behind.
Rob was up again next and called “The Nice Combination” by Gene Hubert.
I had originally planned a fun and very high energy mix for this dance, but
Amanda had vetoed it saying she just didn’t like the music and that it was too
difficult to call to.
Since this was another last minute change, I swapped in another medley that I
had performed previously: Muscles / Garbage in A by Buddy System and
Great Bear, respectively.
This one I was excited to do again because I had broken it a bit last time, and
I felt that it went much smoother this time around.
Next was Amanda calling “Happy Birthday” by Dean Snipes.
This dance is fairly smooth so I played Serenity Knoll and Will Drive All
Night, both by Buddy System.
I screwed up the mix a little bit by leaving loop running after mixing in to
Will Drive All Night, so we ended up jumping back to the beginning of the
song.
What should have been a build up followed by a high energy part of the next tune
turned into a jarring leap back to a low energy intro.
Nothing really to learn here, mistakes will happen and I’ll just have to
practice more next time.
Afterwards Amanda stepped away and forgot to hand the mic to Rob.
I covered by playing a waltz (Salish Sea by The Faux Paws) since we were
overdue for a waltz break anyways so we took an unintended late break.
Once Rob found the mic he called “Spring Break” by Nils Fredland.
I assumed this would be the second to last dance of the evening given how close
we were to the end, so I decided to break out the show stopper I had planned
even though the transition from slow waltzing to the highest energy tune of the
evening felt a bit iffy.
The last time I had played my medley of Griffin Road, Trip to Moscow,
and Rasputin by Kingfisher and Boney M. I had failed to get a recording
of it, so I was excited to have a live recording this time around.
Unfortunately, this one ended up falling apart completely.
Despite having practiced it (and it being a very simple mix), I repeatedly
screwed up and am still not entirely sure what I did.
Whether it was me getting off during the initial mix in of Rasputin, or me
breaking the beat and the phrasing trying to fix it, or me letting it get way
too fast to dance to at a point in the song when I should have been riding the
tempo, it was just a mess.
The dancers got off the music, Rob got off in his calling, and eventually he
just decided to end it early while I was still scrambling to get the song under
control.
I don’t have much to say about this one other than it kind of killed the energy
of the evening and was entirely my fault.
Sorry Rob (and dancers)!
Amanda was up again and called “The Eyes Have It” by Becky Hill.
This dance is another smoother one, and (if I hadn’t killed the energy on the
last one) I had planned to bring the energy down just a touch after the show
stopper, so I did a mix of “Waiting for Earl / Calamity” both by Elixir.
Finally, Rob ended the evening with “Simplicity Swing” by Becky Hill.
Since I’d just done a low energy dance, relaxing dance, I wanted to bring it
back up again so I did Devil / The Druid by Countercurrent.
This one did okay, except that Rob and I had a miscommunication about how many
times through were remaining and it ended up going a bit long.
I’m not sure if it was bad communication on Rob’s part or me just being tired
and misunderstanding, so chalk this one up to the night just being full of
mistakes and move on.
In the end it didn’t really sound bad, it just meant we looped a particular
section one or two more times than I would have liked and it got a bit
repetitive towards the end.
Sadly, we were way over time at this point and had no time for the traditional
closing waltz.
Lesson’s Learned
The main thing I learned from this evening was that I need to have a list of
things to discuss with callers up front when I’m working with them for the first
time.
In the future when working with a caller that I haven’t worked with before I
think I’ll do the following:
Don’t send a set list or practice recordings in advance, only sample
recordings from past events.
Ask if the caller is comfortable calling “off phrase”, and ask how they stay
on phrase as a caller (by listening for phrasing, counting beats, a mix of
both, etc.)
Ask about the types of dances they do (all 32-bar contras? Triplets in A.B.C.
form, etc.)
Any special requests? It’s also important to make it clear that requests are
fine (from the caller, not the dancers) but that they may or may not be able
to be honored and there is a hard cutoff beyond which I will be practicing and
unwilling to make changes.
Ask them to always give at least 3x through before ending the dance if
possible (sometimes there will be emergencies where this can’t happen, that’s
fine).
Ask how they do calling over lyrics or if they expect to drop out on most
songs.
Make sure they know that some songs will be non-traditional.
Ask them how long they like to run dances in this hall (if they’ve called
there before).
This is almost certainly an incomplete list, and if any other called social
dance DJs want to chime in I’d love to know what you do when working with a
caller.
This got me thinking about how I interface with the sound folks / organizers
too.
A few things I should have a chat about with them include:
Do you prefer that I run sound off my board, or do you have someone who will
run sound?
Ask if the sound person can record the evening or has an extra place to plug
up a multi-track recorder (and check if it’s digital, XLR, pre or post mix,
etc.)
Ask if they have a position in mind for the DJ in the hall and is it near the
caller (preferably in the center with visibility across all lines)?
Any obstructions in the hall that will mess with sound?
And of course give them my own requirements: 3 power outlets, monitor speaker with 1/4" TRS
input, 1 XLR mono input to whatever board they’re using, a mic that doesn’t
require phantom power if I’m running sound.
I haven’t run into problems with this yet since I only DJ for a single
dance/venue, but it’s worth thinking about.
Again, I’d be curious to get other social dance DJs (called or no) opinions on
this list; I’m sure I’m missing something important.
Conclusion
Something that I didn’t mention in my thinking about what went wrong above is
that the “energy” of the evening felt off almost from the very beginning.
None of my song choices were landing the way I wanted them to, I had to shuffle
some around in ways where I didn’t really feel like they flowed from one dance
to the next, and the dancers in general just didn’t seem as excited as they
normally would be.
I felt a bit bummed afterwards, but it’s also important to remember that it
really doesn’t matter.
At the end of the day, even if the event wasn’t as good as it could have been,
dancers still showed up and had a good time.
There were still a ton of smiling faces, friends catching up between songs,
chatting, and general merriment even if there were some problems.
So give yourself a break and do better next time, me.
The XMPP Community is very excited to announce its presence at the coming FOSDEM 2026!
Once again, many members of the XMPP community will be attending, and will happily welcome you!
Realtime Lounge: UPDATE!
The XMPP community invites you to the join the Realtime Lounge, where you can come and meet community members, project developers, see demos and ask all the questions.
This year the XMPP & Realtime Lounge has been reallocated to the AW building, Level 1.
Map of the AW building, Level 1
Decentralized Communication Devroom
We would like to invite you to join the technical talks around decentralised communication.
There will also be talks on various messaging and Real-time communication (RTC) projects such as ActivityPub, ATProto, Automerge, DeltaChat, Matrix and of course XMPP in the Decentralised Communication developer room.
Engineering XMPP Federation: Building Messaging, Voice & Social Features Across Independent Projects: The XSF is a standards body that sits at the core of a development ecosystem of independent implementations by different individuals and organizations that actually work together, all highly interoperable, shipping new features at a high pace. This talk, by Jérôme Sautret will share how things work at this scale and will be co-presented by a server and client developer, showing how they work together to fine-tune their implementations. This talk starts at 13:15 and ends at 13:45 hs. (UTC+1:00)
Movim: Building a Decentralized Social Network on XMPP: In this talk, Timothée Jaussoin will present how Movim leverages the XMPP standard and its extensions to deliver features users expect from modern social platforms (communities, IM, group chats, video calls, blogging and a complete publishing platform into a unified experience), without giving up your data to a centralized platform, while remaining fully federated, interoperable with other XMPP clients like Conversations and Dino, and capable of bridging to centralized platforms like Discord, Telegram, and WhatsApp!. This talk starts at 13:45 and ends at 14:15 hs. (UTC+1:00)
What are you listening to now?: Implementing “Now Playing” feature in modern XMPP: In this talk, Özcan Oğuz will share the journey on his research on implementing this feature in modern XMPP clients, the protocols of certain operating systems to read the currently playing media, the current status of the support of XEP-0118 (User Tune) and the PoC of a modern “Now Playing” feature. This talk starts at 14:15 and ends at 14:45 hs. (UTC+1:00)
What to expect
The chance to meet and engange in face to face conversations with the developers of the XMPP client that you use, the server that you may be selfhosting, the libraries and/or tools that you may be using in your project.
Promotional and informational material: XMPP 2025 highlight Flyers, DI.DAY for XMPP Flyer …
Free candy!
And .. say what? Sticker? You are in for a treat! XMPP logo stickers, OMEMO, Movim, Dino, Monocles Chat, Conversations IM, Libervia, … you name it! ( And who knows? Maybe somebody will even be there presenting the new mascot for their project!! ).
Don’t forget to come by our stand, please believe us: you really won’t want to miss it!
Prior to FOSDEM, the XSF will also traditionally hold its 28th XMPP summit.
This is where community members gather to discuss protocol changes and the XMPP roadmap.
Everyone is welcome to join, just kindly list yourself free of cost as there is only limited space.
Please make yourself known by filling out your details on the wiki page for Summit 28.
Check the official online presence and communication, too (see the media links in the footer).
We are living in an economy that rarely sleeps. Payments clear late at night. Payroll runs in the background. Businesses expect every digital touchpoint to work when they need it.
Most people do not think about this shift. They assume the systems behind it will hold.
That assumption carries weight.
Fintechs, including small and mid-sized ones, now sit inside the basic infrastructure of how money moves. Their uptime affects cash flow. Their stability affects trust. When something breaks, real businesses feel it immediately.
Expectations changed faster than most systems did.This follows on from our earlier piece, From Prototype to Production, which explored how early technical shortcuts surface as systems scale. Here, we look at what happens next, when those systems become part of the infrastructure businesses rely on every day.
When “tech downtime” becomes infrastructure failure
Outages no longer feel contained. A single failure can affect services that millions of people and businesses depend on.
Large providers experience this as much as small ones. When a shared platform falters, the impact spreads quickly. More than 60 percent of outages now come from third-party providers rather than internal systems, highlighting how tightly connected the ecosystem has become.
The true cost is trust
For fintechs, the impact is immediate because money is involved.
A payment delay blocks cash flow. A failed identity check stops onboarding. A stalled platform damages credibility.
For an SME, this can play out over the course of a single day. Payroll does not process in the morning. Supplier payments stall in the afternoon. Customer support queues fill up while teams wait for systems to recover. Even short interruptions create knock-on effects that last far longer than the outage itself.
40% of customers consider switching providers after a single outage.
Fintech revenue losses account for approximately US$37 million of downtime-related costs each year.
At this level of dependency, downtime stops being a technical issue. It becomes an infrastructure failure.
Fintechs have become infrastructure whether they intended to or not
Fintech services have moved beyond convenience. They now underpin everyday economic activity for businesses that depend on constant access to money, credit, and financial data.
This shift shows up in uptime expectations. Platforms that handle financial activity are measured against standards once reserved for mission-critical systems. Even brief disruption can have outsized consequences when services are expected to remain available throughout the day..
Customers do not adjust expectations based on company size or stage. If money flows through a service, users expect it to be available around the clock. When it is not, the failure feels systemic rather than technical. What breaks is not just functionality, but confidence.
That is the environment fintech leaders are operating in now.
Where resilience typically breaks down
Most fintech systems do not fail because the idea was weak. They fail because early decisions prioritised speed over durability.
Teams optimise for launch. They prove demand. They ship quickly. That works early on, but systems designed for experimentation often struggle once demand becomes constant rather than occasional.
Shortcuts that felt harmless early on start to surface under pressure. Shared components become bottlenecks. Manual processes turn into operational risk. Integrations that worked at low volume become fragile at scale. Recent analysis shows average API uptime has fallen year over year, adding more than 18 hours of downtime annually for systems dependent on third-party APIs.
Common pressure points include:
Shared components that act as single points of failure
Manual operational work that cannot keep up with growth
Third-party dependencies with limited visibility or control
Architecture built for bursts of usage instead of continuous demand
These are not accidental outcomes. They are the result of trade-offs made under pressure. Funding milestones, launch timelines, and growth targets shape architecture as much as technical skill does.
When outages happen, they rarely trace back to a single bug. They trace back to earlier choices about what mattered and what could wait.
From product thinking to infrastructure grade systems
Product thinking is about features and speed. Infrastructure thinking is about continuity.
Infrastructure-grade systems assume failure will happen. They are built to contain it, recover quickly, and keep the wider platform running. The goal is not perfection. The goal is staying available.
The goal is not perfection. The goal is staying available.
Continuous availability is now expected in financial services. Systems are updated and maintained without noticeable downtime because users do not tolerate interruptions when money is involved.
This approach does not slow teams down. It reduces risk. Deployments feel routine instead of stressful. Engineering effort shifts away from incident response and toward steady improvement.
Over time, this changes how organisations operate. Teams plan differently. Roadmaps become more realistic. Reliability becomes part of delivery rather than a separate concern.
Elixir and the always-on economy
Elixir programming language is designed for systems that are expected to stay available. It runs on the BEAM virtual machine, which was built in environments where downtime carried real consequences.
That background shows up in how Elixir applications are structured. Systems are composed of many small, isolated processes rather than large, tightly coupled components. When something fails, it fails locally. Recovery is expected. The wider system continues to operate.
Elixir in Fintech
This matters in fintech, where failure is inevitable and interruptions are costly. External services misbehave. Load changes without warning. Elixir applications are built to absorb those conditions and recover quickly without cascading outages.
Teams working in Elixir tend to spend less time managing fragile behaviour and more time improving core functionality. Systems evolve instead of being replaced. Reliability becomes part of the foundation rather than a promise teams struggle to maintain.
For fintechs operating in an always-on economy, that approach aligns with the expectations already placed on them.
Reliability as a competitive advantage
Reliable systems can completely change how a fintech operates day to day.
For growing fintechs, uptime supports trust and regulatory confidence. Customers stay because the platform behaves predictably. Growth becomes steadier because teams are not constantly reacting to incidents. Downtime costs make this real, especially for small businesses that lose revenue when systems are unavailable.
For larger providers, reliability reduces operational strain. Fewer incidents mean fewer emergency fixes and fewer difficult conversations with partners and regulators. Teams spend more time improving core services and less time managing fallout.
Reliability also shapes perception. Platforms that stay up become easier to trust with deeper integrations and higher volumes. Over time, that trust compounds and turns stability into a real advantage, even if it is rarely visible from the outside.
To conclude
The always-on economy creates real opportunity for fintechs, but it also raises expectations that many platforms were not originally built to meet.
The question is whether your system has the resilience to operate as infrastructure day after day. If you are a fintech and want to build with reliability in mind, get in touch.
Designing for resilience early makes it far easier to scale without introducing fragility later on.
n8n is a platform for workflow automation. Let&aposs see how interface n8n workflows with an XMPP network. As an example on how to use XMPP to receive data from n8n, let&aposs build a simple workflow that publishes into a MUC room some information about each commit pushed to a GitHub repository.
Simple workflow to display Git commits in a MUC room
To receive the information about each Git push, we use the GitHub Trigger node. You need to set up some GitHub credentials with access to the repository you want to monitor. Then, set the Repository Owner and Repository Name accordingly. The Events you want to receive are of type Push. At this point, you can execute the workflow (just containing this unique node), do a couple of commits on your repository, and push them to test that it&aposs received by the GitHub Trigger node. When it works, pin the output data of the node so you don&apost have to push some more commits while you test the rest of the workflow. Don&apost forget to unpin it once you want to use the workflow for real.
Information Formatting
As you can see in the output data of the GitHub Trigger node, the list of commits in the push are in body.commits. We use a Split Out node on this field to process each one of these commits.
We then use an Edit Fields (Set) node to format the information we will display about each commit in the final message posted in the MUC room, using a Manual Mapping. Just check the input data coming by the previous Split Out node to choose what data you want to send to the MUC room. We name the output field Commit (type: String). Here is an example of such a template:
If you are using a Fluux instance, you can get an OAuth token from your Fluux console, in the API Tokens section.
Self-hosted ejabberd
To create the credentials on your own ejabberd server, you&aposll need to use the oauth_issue_token command to get an OAuth token. Be sure you have an access rule that allows you to create such a token.
For the scope parameter of oauth_issue_token command, use the one defined in your api_permissions acl (ejabberd:admin in the example below) and be sure the user you issue the token for has the right to call the send_message command.
Extract of an example of an ejabberd.yml file that allows to call send_message using OAuth:
Create a new Bearer Auth and put your token in the Bearer Token field.
For the other fields in the HTTP Request node:
Method: POST
URL: Full URL of the send_message command as defined by your ejabberd_api listener, for example https://process-one.net:5281/api/send_message. If you are using Fluux, the URL should be https://NAME.m.in-app.io:5281/api/send_message where NAME is your Fluux instance name.
The n8n workflow should now be working: it will publish all commits pushed on the repository defined in the first node into the MUC room defined in the last node (don&apost forget to unpin everything).
This is a variant of the above workflow to illustrate how to create and send a custom stanza instead of the simple message that send_message API permits. This is needed for example if you want to add an element in a custom namespace into your message stanza.
<message type="groupchat">
<body>
List of commits
</body>
</message>
We don&apost need to set the from, to or id attribute, it will be handled by the API call done in the last node. Let&aposs say we want to add a sub-tab containing the timestamp of the moment the message was sent by n8n. The stanza we want to create looks like this:
<message type="groupchat">
<body>
List of commits
</body>
<n8n xmlns="p1:custom:timestamp">2025-12-17T11:16:13.071-05:00</n8n>
</message>
Create a custom stanza
We want to create that stanza just before the last one, between the Aggregate node and the HTTP Request node. To ensure that all strings from the git commit are correctly encoded for XML, we use the JSON to XML node. This means we have to construct the stanza in JSON first.
This is done in the Make Stanza in JSON node of type Edit Fields (Set). We use the Manual Mapping to ensure all special characters from the git commit are correctly escaped.
We set a $ field (which is the default Attribute Key) to set the type attribute on the root element. The name of the root element, message, will be set in the next node, JSON to XML.
We create a body field of type String that will contain the list of commits, one per line. We can use the same template used in the last node of the previous workflow:
The stanza is converted in XML in the Convert stanza in XML, XML node:
The Mode is JSON to XML
Property Name is the name of the field in the output data, let&aposs name it stanza.
We have to enable the Headless option to prevent the XML header to be added before the message.
The Root Name is set to message (the root element of the stanza) as the JSON received from the previous node is just the content of the XML document.
Sending the XMPP message using send_stanza
The configuration of the HTTP Request node is the same than for the previous workflow, except that the URL must call send_stanza instead of send_message. The body parameter is replaced by the stanza one, in which we just have to set the stanza field from the previous node:
{{ $json.stanza }}
Be sure to adapt your ejabberd configuration accordingly, specifically to allow send_stanza to be called.
I had the pleasure of giving a talk on "XMPP and Metadata" during the last
Chaos Communication Congress, in the Critical Decentralization Cluster area.
It was my first public presentation in a very long while (also in english), so
the talk went okay-ish at best. The end of the year was also hectic and I did
not manage to prepare or rehearse as much as I would have liked to.
This blog post will be a longer, more complete version of the talk. You can nonetheless find the talk slides on the CDC pretalx.
Thanks a lot to the people who proofread the blog post to fix stuff or suggest additional content.
This was about metadata, but also generally data retention and what the server sees in general.
Metadata
First I want to define the basics: metadata is data about the data. In a messaging system, data is usually considered to be the message contents (what is being exchanged),
and metadata is about the envelope:
who (sender and receiver)
when (timestamp)
hints about the what (e.g. payload size)
Outside of messages, you can additionally have data/metadata about the users themselves, like online status or location, which can be either sent in the clear to the server, or deduced from user activity.
Obvious message workflow
This might be too obvious for most people, but for clarity’s sake, I want to assert that to send a message to another entity, you need:
a sender
a message
a receiver
This is not technical, this is baked into the concept of sending a message. Those elements will always be present somewhere in the workflow.
Assuming a working encryption system, the message data itself will not be considered.
There are, however, some technical tricks that can hide a lot of things from the infrastructure layer.
XMPP
I cannot really make this an introduction to XMPP but to summarize, XMPP is an extensible federated protocol for messaging and presence.
It is using XML for the most part but nobody should care (except trolls, I guess).
It started in 1999 as Jabber, and grew to be an IETF standard under the name XMPP after Jabber got bought by Cisco (we can still use the Jabber name in many ways).
The protocol started server-heavy with light clients - and in fact, you will read as much in the "XMPP, the definitive guide" book -, but the trend got reversed in the last decade due
to the rise of mobile clients which can be updated very often and other circumstances.
There are clients and servers, and it is therefore a protocol made of client-to-server interactions and server-to-server interactions, each with their own privacy implications.
The key elements to remember in order to assess threats in the XMPP network fabric would be:
Your server is the only entity sending data to other servers. Every single bit of XML your XMPP client sends goes through your server.
Other servers will only see your interactions with their own users.
Those two points are true in most non-P2P models. Centralized models can be thought as a specialization of this model, but with only one single server.
That is why it is essential to rely on a server you can trust, either operated by people you trust, or at least who have some accountability in place, for example the services listed on providers.xmpp.net.
Threats
I can roughly point out four types of "passive" threats on metadata for XMPP:
A server compromise (present)
Correlation of data streams in real time
A server compromise (future)
Exploitation of the static data available on the server
An attacker present on the server network
Can see what the server does (both with clients and servers)
An attacker on the client (your) network
Can see what your client does
Network metadata threats
Client network attacker
Only a bit of metadata is visible on the client network:
Timing and size of every network call
HTTP(s) interactions that cross the XMPP boundary, like file upload
On XMPP, one client - with only one account - will only ever connect to the XMPP server the account is living on.
Some services might go through HTTP, which then cross the boundary and create networks calls outside of the XMPP TLS stream, like HTTP Upload (XEP-0363).
Likewise, application like audio, video calls or direct file transfers will also cross that boundary.
STUN and TURN servers are used to bypass NAT restrictions which are everywhere nowadays. STUN can be described as a way for clients to find out their reachable address from behind the NAT, and then use that to establish a peer-to-peer connection, and TURN is used in the more restricted networks where a relay is necessary to be able to communicate. In the case of TURN it creates yet another server overseeing the -encrypted- communication, and in most modern XMPP setups the server operator also operates a TURN server; a network attacker will also see the encrypted stream to the TURN server from the client.
In the STUN case, clients will do a short network call to find out their external address, then establish the direct session to the other user, making that metadata available to an attacker as well.
I do not know of any work related to fingerprinting encrypted client-to-server XMPP traffic, but I would guess that it is fairly easy if no precautions are taken.
Some examples:
Ping (XEP-0199) as connectivity check: periodical request/answer to your server, with a fixed size
Room join (XEP-0045): send disco, receive disco info, send join request, receive plenty of presences in a short period of time
Sending messages: composing chat state (somewhat fixed size), sometimes followed by other chat states (e.g. paused), followed by a longer payload, the message, which size can often be predicted by the time since the chat state.
etc…
This metadata will depend on the XMPP client used and how much it is customized, because while protocol workflows are mostly the same for all clients, some might do different or extra steps in common cases.
Server network attacker
If an attacker can eavesdrop on the server network, it gets access to a lot more info than on the client network:
It has a view on both open client and server connections
It can then correlate quite easily the destination of stanzas sent by the client (since it will see something go from the client to the server, then immediately something from the server to another server)
If the server has lots of active users, it makes it harder to correlate, but metadata of single-user servers are a very easy target!
If there is plenty of activity on the server, it will be much harder to find out what the source of the activity is:
All stanzas are going through a single stream for each destination server which makes it difficult for an observer to find out which payload is going where provided there is enough activity, and luckily XMPP is a somewhat chatty protocol.
Server compromise
On-disk data and metadata
In an event where a server gets compromised later (or even a backup gets compromised), it is important to know what kind of data and metadata will be visible to the attacker.
There is a lot of data available on servers with normal XMPP usage, and a few categories stand out.
User accounts
Accounts are tied to a specific server; they can in some ways be migrated to another server but the process is currently not fun.
For a normal user, one of the important troves of metadata is the roster (contact list): it contains all the people you have added to the list, which allows you to put them in groups, as well as letting the server broadcast your online presence when you get online.
Another important piece of information is your bookmarks list: this allows you to sync the chatrooms you are in between all your clients, but incidentally that information stays in cleartext on the server as well.
The most identifying piece of information about the user on the server can be the vcard, as it is litterally a collection of personal data (including the user’s avatar).
And the server will usually store some useful information it can know without asking the user: date of last connection, last seen IP address, etc… Some of this data can be very useful to assist manual account recovery!
Groupchats
Groupchats in XMPP are hosted on a specific server, which does not have to be (and often isn’t) the user’s server. The room identifiers are in the form room@a-groupchat-server.net, where a-groupchat-server.net gives the information of where the room is hosted.
The server hosting a persistent room needs to keep, on-disk:
A message archive - not mandatory but very nice to have -
A members/admins/onwers/ban list; only the owner list is mandatory, as long as everyone else is fine with being a "normal" participant
Data related to the room, like configuration, access control (which can be tied to membership), topic, etc
There are two types of rooms:
Semi-anonymous rooms, where only room admins (and their servers, as well as the room server) can see the real addresses of the users exchanging messages, creating a pseudonymous situation.
Non-anonymous rooms, where everyone sees everyone’s addresses; here all participants and their servers can know who is in the room and authors messages.
In terms of live data, due to how XMPP is designed, all servers of all the active participants will be able to see who is sending messages:
But in semi-anonymous rooms, they only get a nickname, and not the real address.
Live stream interception
As stated earlier, choosing a server you trust is the very first step, and if you
do not trust your server (and operators) at all, why are you there?
If the server itself is compromised, the point-to-point TLS encryption between client and servers, and between servers, becomes very much useless, which means "server network attacker" scenarios can now be matched with 100% precision, and more:
Correlation between sender and receiver is exact
The user’s XMPP address can be mapped to an IP and port
Stanza type is exposed, whether , , stanzas are sent, everything is known
Activity patterns can get a lot more detailed
E2EE still works to protect data - but can get disrupted -
Some solutions for XMPP
Remediation of network metadata leaks
I do not see magic bullets here, and everything has a cost.
The idea would be to add noise that is not easy to filter out when parsing network activity at scale.
Inserting random padding in server-to-server and client-to-server communications would help, of course, but network data is not always cheap, and processing XML also has a cost.
Another solution would be "garbage" stanzas sent in various manners to other servers, but again there is a cost here, and since very little litterature exists on such attacks, it remains to be seen that there is an upside to this.
Another one would be to allow stanzas to be grouped on the wire when possible (e.g. presence updates or groupchat messages)
The last one I can see would be to induce random delays in stanza delivery when processing them on a server. This has of course a usability cost, but for large servers, adding random delays < 0.3s would probably be enough to make correlation quite hard, but of course ordering must be preserved.
Remediation of roster issues
Presence-based messaging has been going downhill for a while thanks to a smartphone-centric population and apps, which means the roster is not as useful as it could once be.
It still provides useful information in my opinion, and is also very useful for abuse prevention, since you do not receive abuse from your contacts - hopefully -.
The roster could be stored on devices instead of servers, and we could find a way to share it encrypted and cross-signed with the user’s other devices. This does not change the fact that your server will see who you are chatting with or sending presence to.
The bookmarks could likely be shared in the same way, and removed from the server as well.
Fixing groupchat metadata
As mentioned earlier, if we phase out presences in many cases, being passively inside a room would at least prevent being exposed to servers looking at the traffic, as long as nobody requests the participants list.
I do not see a good way out of this for metadata.
Fixing many types of metadata issues
The most deployed end-to-end encryption solution on the network is OMEMO, but not in its latest version, which allows for Stanza Content Encryption. The version most people use only encrypts the message’s body tag, which is the text sent by the user. By extension, uploads are also encrypted there because they are encrypted using OMEMO Media sharing which is really just encrypted using AES-GCM with a key and IV shared inside the URL sent through the OMEMO session.
This means people wanting to use nice features like composing chat states and the like have the choice to either generate this metadata in the clear, or disable the feature, which is not ideal.
Other interesting solutions
Serverless messaging
XEP-0174 describes how to operate XMPP inside a trusted network, which bypasses the need for a server by using mDNS on this network and advertising your address with your local IP.
I liked it a lot and had fun at the time, but it was from a blissful era where encryption was not seen as the foundation upon which everything should be built. It means that everything transits unencrypted on the network, both metadata and data are unprotected. Data could be encrypted using OTR, but some required bricks for the modern XMPP experience like the Personal Eventing Protocol are unavailable, making OMEMO in its current form a no-go.
Implementations are scarce nowadays, as an incomplete XMPP layer inside a normal client is usually pretty convoluted to maintain and after a while it was removed from most clients where it existed.
The modern replacement is RELOAD, but implementation and deployment is just starting, so it is a bit early to know if it is a good solution or not.
XTLS
XTLS describes a way to create a direct and encrypted TLS stream between two entities using jingle, which could be then used to exchange stanzas in a secure manner, without going through the server.
That means that the metadata threats shift from server-based to client-based, which can be an upside or not at all. The layer used for the channel is also quite important, as it could be In-Band Bytestreams (which means the data goes through the usual client-server-server-client route) which would then provide additional E2EE cloaking of all data exchanged between clients, but still going through all the entities to route data.
Cryptographic identities
Strong cryptographic identities as outlined in XEP-0416 could serve as a framework for removing some of the requirements for trust in the server.
I do find X.509 a bit too complex for what we want to do with it, but I did not dive very deep into this spec.
Other services/protocols
Signal
Signal is a pioneer in encryption systems at scale, and keeps pushing the boundaries of what is possible to do securely. Nonetheless, their messenger is centralized, with systems running on AWS and Azure (as far as I can tell), which makes them very dependent on the US political wasteland as well as the tech landlords’ whims.
They do a lot of things to ensure things are as secure as it can be within the constraints they imposed on themselves, and as such while I trust them for now, their servers certainly have a lot of opportunities to collect and store a ton of metadata, simply due to the fact that this is a centralized system. While their cryptography work is class-leading, which makes my data secure (as long as someone does not bust the secure enclave which protects my "recovery code" I guess), keeping my metadata volatile and secure there is only a leap of faith on my part, as I can have no guarantees.
Matrix
Matrix is a federated protocol which has many of the same flaws as XMPP with regards to metadata.
One notable difference is that matrix is more like a distributed database with built-in conflict resolution, which leads to every participant’s server replicating the state (data and metadata) of the rooms they are in. This creates a more difficult situation for metadata than XMPP, because while XMPP servers can see what goes through them, in Matrix the servers are required to store this information.
Matrix also has two different sets of APIs for client-to-server and server-to-server communication, which should allow it to batch messages when appropriate.
SimpleX
SimpleX is a protocol with a lot of cryptography baked in, and has interesting properties such as the absence of user accounts and therefore identifiers (which means very little data on the servers can be compromised).
One of its more interesting properties is that it has 2-stage onion routing baked in, which allows it to sidestep many issues around metadata due to connecting to servers.
The whitepaper stresses that it is still important to choose your servers well, but that is still less critical than in XMPP since you can easily switch at very little cost.
(P.S.: calling your protocol "SMP" is not nice if it is not based on the Socialist Millionaire Protocol, I haven’t checked but skimming did not reveal any mention of it)
Conclusion
As Daniel noted on mastodon, there are some low-hanging fruits to improving the metadata issues around XMPP (and some higher-hanging fruits as well).
I agree that this is not going to be even a blip on XMPP adoption, but we should do what we can nonetheless to improve the situation, in order to improve the standard and the ecosystem.
That said, I can perfectly understand that since a lot of the work is purely volunteer-driven and our time and energy is limited, it can appear to be a waste of time to dedicate them to removing bits of metadata here and there.
As we previously described here, your Fluux.io service can send push notifications to your xmpp user&aposs browsers when they are offline. It includes Safari on iOS devices. But before enabling it your users need to add your Progressive Web App (PWA) on their home screen.
You can test the whole process with our "Test Client" from your fluux.io console. First, sign in fluux.io console and go to WebPush App list. Like in previous blog post open test client.
This file provides a name, an icon and so on to the PWA. It also fixes display mode to "standalone" which is required to enable push notification on a Progressive Web App on iOS.
With such configuration, end-user has to tap on "share button" :
Then iOS user has to scroll and tap on "Add to Home Screen".
It will open a form prefilled with data from manifest.json
Once registration form submitted, a new icon will appear on iOS device home screen and will act as a new app.
Launch it, sign in your fluux console, and move back to test client and connect using a test user. You can now tap on "Enable webpush"
You will be prompted to allow your device to receive push notification from your fluux platform (through safari/apple server).
Like other push worflows a notification for new message will be sent to xmpp user&aposs device when offline :
the XSF Communication Team is pleased to announce a new initiative to help evolving the XMPP ecosystem in a broader and aligned perspective.
This should cover discussions, development but also extended public communication and presence.
As this initiative is being setup in an iterative way, participants will be able to form and steer its direction over time.
Why the Chat of the Future Initiative?
XMPP exists for more than 25 years now, with world-wide implementations across various applications and more than 500 published and public specifications.
At xmpp.org, software of more than 35 clients, 20 libraries and 8 servers are listed.
This rich history is only possible through the federation endorsed since 1999.
Although this is an advantage, maintaining a federated and decentralised network also requires significantly higher efforts for cross-network alignment, adoption and also quality of the XMPP technology.
This initiative intends to support such activities along different actors.
What is the Chat of the Future Initiative about?
Participants will try to identify, collect, and formulate activities that apply to the XMPP ecosystem that needs efforts around today’s status quo.
This new collaboration space is considered to formulate along user and developer needs.
From the discussions common ground on where we can act should be found.
Far thinking, this could lead to community vision and strategic thinking that every actor can decide to contribute individually.
In the past, possible topics named have been for example an interoperability session, to work on encryption or having a landing page for developers.**
Of course, the scope should be limited to the actors capabilities.
How will the Chat of the Future Initiative work?
The Chat of the Future initiative will begin with a series of open-ended and interactive collaboration sessions and open up for discussion, alignment and collecting of thoughts and ideas.
This can happend across multiple session and is always a quarterly activity.
It’s for example planned to ask you about your perspective on the status quo of the XMPP ecosystem.
What are we getting right, what are we not?
Where is it that we see room for improvement?
Can we formulate any activities out of this?
The participants will have the chance to contribute with their perspective, feedback and discussion topics via a BigBlueBotton session, both in spoken and written form.
For notetaking a HedgeDoc pad will be used.
If other organisation spaces - such as a group chat - be necessary, the development of the initiative will show.
At its best, this interactions are integrated in what is available in the existing XMPP channels.
Who can participate the Chat of the Future Initiative?
Anyone interested and willing to contribute to the XMPP ecosystem of any level of experience can join with their perspective.
This also involves newcomers and bare users as well as professionals of the XMPP technology.
If you cannot participate, consider to provide your thoughts in a written statement to the organiser.
There are multiple sessions and more planned, so one can join at another time or phase.
When & Where will the Chat of the Future Initiative take place?
Currently a first set of sessions is planned and listed below with more sessions to work on actual topics to come.
This can be matter of change based on feedback.
The session link can be found here: BigBlueBotton.
Access code: 932872
The password code and the pad will posted on the day in the XSF Chat (see below).
Meeting netiquette: Please keep a respectful, constructive and positive tone and statements.
Event name
Date
Time
Agenda
Kick-off Session
Tue, 13 Jan 2026
19:00 - 20:00 (CET)
About the Initiative, Check-in & Warm-up, Retrospective on XMPP today
Q1 Focus Session
Tue, 20 Jan 2026
19:00 - 20:00 (CET)
Check-in & Warm-up, Focus topic from previous session
Q1 Activities Discussion Session
Tue, 3 Feb 2026
19:00 - 19:45 (CET)
Activities March - May 2026
Q1 Check-in Session
Tue, 11 + 25 Mar 2026
19:00 - 19:30 (CET)
Review of activities
Q1 Check-in Session
Tue, 8 + 22 Apr 2026
19:00 - 19:30 (CET)
Review of activities
Q2 Planning Session
Tue, 7 May 2026
19:00 - 20:00 (CET)
TBA
Q2 Check-in Session
Tue, 6 & 20 May 2026
19:00 - 19:30 (CET)
Review of activities
If you have further questions, please join the XSF chat.
We hope this will positively contribute to the community and technology as a whole.
See you soon,
— The XSF Communication Team
Note: In a previous statement another tool and setup has been named. Through dicussions this has been changed.
Just like any other product or project by the XSF, the Newsletter is the result of the voluntary work of its members and contributors. If you are happy with the services and software you may be using, please consider saying thanks or help these projects!
The XSF is planning the XMPP Summit 28, which will take place during Thursday 29th & Friday 30th, January 2026, in Brussels (Belgium, Europe). Following the Summit, the XSF is also planning to be present at FOSDEM 2026, which will take place during Saturday, January 31st & Sunday, February 1st, 2026. Find all the details in our Wiki. Please sign-up now if you are planning to attend, since this helps organizing. The event is of course open for everyone interested to participate. Spread the word within your circles!
The XSF is proud to announce that the official XMPP logo has been accepted into Font Awesome and will be bundled up in their source tarball starting from their next release!
Engineering XMPP Federation: Building Messaging, Voice & Social Features Across Independent Projects: The XSF is a standards body that sits at the core of a development ecosystem of independent implementations by different individuals and organizations that actually work together, all highly interoperable, shipping new features at a high pace. This talk, by Jérôme Sautret will share how things work at this scale and will be co-presented by a server and client developer, showing how they work together to fine-tune their implementations. This talk starts at 13:15 and ends at 13:45 hs.(UTC+1:00)
Movim: Building a Decentralized Social Network on XMPP: In this talk, Timothée Jaussoin will present how Movim leverages the XMPP standard and its extensions to deliver features users expect from modern social platforms (communities, IM, group chats, video calls, blogging and a complete publishing platform into a unified experience), without giving up your data to a centralized platform, while remaining fully federated, interoperable with other XMPP clients like Conversations and Dino, and capable of bridging to centralized platforms like Discord, Telegram, and WhatsApp!. This talk starts at 13:45 and ends at 14:15 hs. (UTC+1:00)
What are you listening to now?: Implementing “Now Playing” feature in modern XMPP: In this talk, Özcan Oğuz will share the journey on his research on implementing this feature in modern XMPP clients, the protocols of certain operating systems to read the currently playing media, the current status of the support of XEP-0118 (User Tune) and the PoC of a modern “Now Playing” feature. This talk starts at 14:15 and ends at 14:45 hs. (UTC+1:00)
XMPP at 39C3 CCC: the Critical Decentralisation Cluster (CDC) returned to the 39th Chaos Communication Congress in Hamburg (Germany) during this last December 27-30 2025. The CDC provided a friendly space for discussions and exchanges on technology and politics with other communities working towards decentralization. The XMPP assembly was part of it thanks to neox and mathieui active involvement, with the latter being responsible for the sparkly XMPP stickers!!
Left: the highly coveted XMPP sparkly stickers! Right: XMPP assembly at the 39C3 Critical Decentralisation Cluster!
JMP newsletter - More Cheogram Apps: this latest edition of your pseudo-monthly JMP update brings you news about port-out PIN self-service, data-only registration, a collection of selected recent Cheogram Android changes, a word of advise about some changes to the official distribution mechanism for Cheogram apps and all you need to know about the highly anticipated Borogove based Cheogram WWW and Cheogram iOS clients!
The XMPP newsgroup on Usenet: The NNTP protocol is still in use, and there is an active Usenet group about the XMPP/Jabber topic at alt.chat-programs.jabber. NNTP is a standard application-level protocol that enables the exchange of messages in distributed systems such as Usenet — a protocol worth revisiting. Some free public servers are available; one of them is Eternal September, which has open free registration. You may use Thunderbird, PAN or TIN as a client.
XMPP Software News
XMPP Clients and Applications
Cheogram has released version 2.19.0-4 for Android. A bugfix release that introduces fixes to tablet view, account filters for starting new chat, some crashing bugs, WASM in WebXDC, show an extra piece of context on call status/failure, align message text size with upcoming Snikket release, among many others! Make sure to check out the list of changes for all the details across releases.
Conversations has released versions 2.19.6 and 2.19.7 for Android. This version introduces a setting to always use relays, sends delivery receipts by default and turn setting into “Read receipts” and fixes avatar caching issue and DNS occasionally not resolving when Private DNS is enabled. You can take a look at the changelog for all the details.
Gajim has released version 2.4.1 of its free and fully featured chat app for XMPP. This release brings previews for GIFs and similar animation file formats, and many smaller changes and bug fixes. Thank you for all your contributions! You can take a look at the changelog for all the details.
Animated previews in Gajim.
Kaidan has released version 0.14.0 and it includes some great new features and fixes! Advanced media sharing, filtering XMPP providers for account creation, highlighted messages, XMPP URIs, and many other new features and bugfixes! You can find a detailed list of new features, bugfixes and notes in the changelog.
Monocles has released version 2.0.18 of its chat client for Android. And it comes loaded! It introduces a VCard4 profile editor, a VCard QR code generator to account editor, a drag and drop account reordering, improves input field text color visibility, an option to save media to downloads folder in media viewer, introduces chat history calendar, updates TLSv1.3 setting (Default on), adds wasm extension and application/wasm MIME and more!. Make sure to take a look at the changelog for all the details!
Initial development of MankalaNextGen, a graphical user interface to play Mancala games was done during Google Summer of Code 2025 by Srisharan VS. The application uses QXMPP to enable remote play.
XMPP Servers
MongooseIM has released version 6.5.0 of its Enterprise Instant Messaging Solution. This release brings new features, changes, various fixes and improvements. For more information, make sure to check out the changelog and the documentation.
The Ignite Realtime community is happy to announce the release of Openfire 5.0.3! This release brings a number of stability improvements and bug fixes. Notably, a number of improvements were made to Multi-User Chatroom (MUC). Please refer to the full changelog for more details.
Snikket Server - December 2025 release: Snikket is rounding off the year with another small release of its server software. The main purpose of this release is to fix a couple of small bugs which were discovered and reported after the previous release was announced. Some notable changes include offline message compatibility and web portal debug information.
python-nbxmpp, a Python library that provides a way for Python applications to use the XMPP network, version 7.0.0 has been released. Full details on the changelog.
QXmpp, the cross-platform C++ XMPP client and server library, version 1.13.0 has been released. Full details on the changelog.
Slidge versions 0.3.4 ‘Christmas special’ and 0.3.5 have been released. This releases incorporates conversion of vector animated stickers in the lottie format to webp. Slidgram and slidcord already did such conversion, but now it’s done via an optional (“extra”) dependency of slidge: rlottie-python, which makes packaging/distribution easier. And many other features, improvements and bugfixes! You can check the release changelog or the intermediate changelogs from 0.3.3 to 0.3.5 for the full list of changes.
matridge, the Matrix to XMPP gateway based on Slidge and nio, versions 0.3.2 has been released.
xmpp-ap-bridge, a lightweight Fediverse to XMPP implementation based on client bots to enable chat-like conversations between any Fediverse application and any XMPP client, from your usual client applications, versions 0.7.3 and 0.7.4 have been released.
xmpp-dns, a CLI tool to check XMPP SRV records, version 0.5.5 has been released. Full details on the changelog.
Extensions and specifications
The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).
Proposed
The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.
This specification defines a protocol for discovering if the SASL2 <authenticate> can be pipelined safely along with the stream open, and if so allows the client to perform this pipelining safely.
Version 0.1.0 of XEP-0509 (Initial Authentication Pipelining)
Accepted as Experimental by council vote (dg)
Deferred
If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.
muc#roomconfig_allowinvites doesn’t restrict owners but enables additional permissions for members. (spw)
Version 0.7.0 of XEP-0353 (Jingle Message Initiation)
Remove local redefinition of jingle <reason/> element in XML schema and reference existing.
Make usage of <reason/> element optional in schema, as specified in the text.
Add missing definition of ’empty’ type in XML schema. (lnj)
Last Call
Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.
Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.
Newsletter Contributors & Translations
This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):
Contributors:
To this issue: emus, cal0pteryx, Gonzalo Raúl Nemmi, Adrien ’neox’ Bourmault, Ludovic Bocquet, Benson Muite, Mario Sabatino, XSF iTeam
This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF GitHub repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.
Tasks we do on a regular basis:
gathering news in the XMPP universe
short summaries of news and events
summary of the monthly communication on extensions (XEPs)
review of the newsletter draft
preparation of media images
translations
communication via media accounts
Unsubscribe from the XMPP Newsletter
For this newsletter either log in here and unsubscribe or simply send an email to newsletter-leave@xmpp.org.
(If you have not previously logged in, you may need to set up an account with the appropriate email address.)
It is now possible to select media to be shared while being offline.
Once you are connected, all media is automatically uploaded.
Even downloads can be enqueued to be started as soon as you are online.
In addition, ongoing transfers are canceled on disconnecting and automatically restarted once connected again.
Up- and downloads can be manually canceled and restarted as well.
Filtering XMPP Providers for Account Creation
Kaidan’s manual registration now allows to filter all XMPP providers by various properties.
For example, you can choose whether only providers are shown that store their data in a specific country or whose service runs on renewable energy.
That is possible because Kaidan uses the data from XMPP Providers.
Highlighted Messages
Messages are now precisely highlighted on various actions.
A border is displayed around a message if you open its context menu, search it, or jump to if from a reply.
That makes it possible to quickly see the relevant message.
XMPP URIs
If you received an XMPP URI such as xmpp:alice@example.org, you can paste it directly into the field for adding a new contact.
There is no need to remove any characters that are required to be machine-readable.
The same applies to XMPP group chat URIs.
Changelog
There are several other improvements.
Have a look at the following changelog for more details.
Features:
Keep draft messages on top of pinned/unpinned chat list items (pehg)
Optimize thumbnail creation (fazevedo)
Display border around searched/referenced message instead of bar (melvo)
Display border around message if its context menu is shown (melvo)
Highlight message’s avatar if hovered (melvo)
Display provider chat (used for welcome messages and service announcements) as such (melvo)
Always display same name and proper avatar initials for notes chats (melvo)
Allow to cancel downloads/uploads (fazevedo)
Allow to restart canceled uploads (fazevedo)
Allow to resend failed message via context menu (melvo)
Retrieve support addresses from server instead of provider list (XEP-0157: Contact Addresses for XMPP Services, XEP-0128: Service Discovery Extensions) (melvo)
Allow adding contact by entering XMPP URI (including authentication of OMEMO 2 keys) (melvo)
Allow joining group chat by entering XMPP URI (melvo)
Add option for allowing SASL PLAIN (needed for servers using LDAP) to custom connection settings (melvo)
Add filtering options to choose provider for registration (melvo)
Cancel file transfers on disconnecting from server (fazevedo)
Add support for offline media sharing queue (fazevedo)
Restart downloads canceled on logout once logged in (melvo)
Remove all related data on message removal (such as reactions and media) (melvo)
Bugfixes:
Fix displaying message reaction details (melvo)
Fix adding unneeded separator on mention after new line (melvo)
Wrap hint for actions needing user to be connected to server (melvo)
Fix displaying icons on Windows (pehg)
Fix adding new line at cursor position (melvo)
Ensure that own encryption devices are not removed if notes chat is removed (melvo)
Notes:
Kaidan requires KIconThemes (for Windows) now
Kaidan requires Qt6GuiPrivate (for Qt 6.10 or above) now
As the year draws to a close and the holiday season surrounds us with warmth and joy, I wanted to take a moment to look back at what an incredible journey 2025 has been for the Ignite Realtime community.
This year we’ve seen so much activity, innovation, and collective effort across our projects and forums. From major releases to exciting technical explorations, the contributions from developers, documenters, testers, and users have reminded me (time and again) what makes this community special.
Looking back through the year’s blog posts and discussions, a few moments stand out:
Openfire 5.x Series: We welcomed multiple releases within the 5.0 line. From the early beta builds to the full releases of Openfire 5.0.0 and 5.0.1, to the stability-focused 5.0.2 and most recently 5.0.3. These milestones are the result of countless hours of debugging, testing, and refinement.
New Features & Plugins: Several new features and plugins made their way into our ecosystem, like the Push Server plugin and advancements in XEP-0483 for HTTP Online Meetings, expanding what’s possible with our projects.
Smack Community Progress: The continued evolution of Smack was marked by the 4.5.0 Release Candidate, giving developers an even stronger foundation for building XMPP clients.
Broadening Perspectives: Insightful posts on interoperability, WebRTC audio/video integration, and real-world use cases highlighted the vibrant technical discourse happening here.
Community Recognition: It was also wonderful to celebrate achievements beyond our own projects - like members being elected to roles within the broader XMPP Standards Foundation.
All these efforts show not just code being written, but ideas shared, challenges overcome, and friendships formed along the way. What’s especially meaningful to me isn’t just the software we build, but how we build it: together. Whether it’s through lively technical threads, helping a newcomer in chat, or sharing a blog post that unpacks a tricky feature, this community genuinely embodies open collaboration.
The forums, blogs, and group chats are more than repositories of knowledge - they’re where we connect, learn from one another, and celebrate each success together.
So, as we step into the holidays and prepare for the new year, I want to express my deepest gratitude:
Thank you to every contributor, big or small, for your time, passion, and patience.
Thank you to those who reported bugs, wrote documentation, asked questions, or helped others find answers.
And thank you to every user who deploys, experiments with, or builds on Ignite Realtime software: you give our work purpose.
Here’s to 2026! May the coming year bring even more collaboration, innovation, and joy. Whether you’re building a new feature, solving a tricky XMPP problem, or just dropping into the group chat to say hello. We’ll be glad to see you there!
Wishing you all a happy holiday season and a wonderful New Year!
Welcome to the latest edition of your pseudo-monthly JMP update!
In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client. Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.
End of a Year
Wow, another year has come and gone. Not many newsletters this year, but rest assured we’ve just been too busy building to write! We know one of the biggest questions we get every year is about a Cheogram-like app for other platforms, and this year we’ve come much closer to having two more of those ready for release, besides also maintaining everything you’ve already come to know and love. Below are a few highlights.
Port-out PIN Self-Service
Users can now set their own port-out PIN through the account settings bot, only shown to users with a number eligible for automatic set up (#fe75c33, #a953751, #a18b326).
Data-Only Registration
Support for data plan registration during sign-up process without a phone number (#5cdf6c0).
Cheogram WWW
We’ve been working for years on a browser-based Progressive Web App client for the Cheogram family, based on Borogove. Community members have been testing various versions of this under many names, but this fall we finally began alpha testing under the Cheogram WWW name at app.cheogram.com. Expect more to come for this app, but it is already very usable for many of the needs JMP customers have, including a Command UI / “app” view for account settings. It is also one of the only browser-based apps with native multi-account support.
You’ll note above I said “browser-based” and not quite “web app”. There is no server side component required for this app, as it connects directly to your Jabber service. This requires a special browser protocol to be supported by the service, and a few other things are needed for it to work very well. Of course we’ve worked with Snikket to make sure their offering supports everything needed for a best in class experience and more.
This app works well in a desktop/laptop/tablet form factor, but also has a mobile-optimized view. Along with support for Web Push notifications (if supported by your Jabber service; of course latest Snikket has support) this can make it a viable option on mobile platforms without a good native solution yet (to try this on iOS you’ll need to use the “add to home screen” option for notifications to work). The biggest limitation for Web Push is it cannot make a device “ring” so if you get a call while the app is not open you’ll get only a simple notification like for a message which is not always ideal.
Cheogram iOS
Also in alpha testing starting earlier this fall is Cheogram iOS. Also based on Borogove but with a native Swift UI and deeper OS integration than the PWA can muster, this app is still in a bit of an earlier stage than Cheogram WWW, but some very adventurous people are daily driving it already. Come by the community chat if you want a TestFlight link.
Distribution for Cheogram Apps
Cheogram apps area also making some changes to official distribution mechanisms. For Android the most recommended and official distribution will of course remain F-Droid. And for people who need it the app will remain available on Play Store as well. Pre-release debug builds will still be distributed in the community and custom repo. So what is changing? There will no longer be official distribution of debug APK builds tied to releases. This practise has, quite honestly, been confusing to many people who expect release-tied builds to be release builds. Releases will now come with official distribution of first-party release builds for sale at itch.io (free to JMP customers or with a free JMP month for non customers along with the purchase). Builds of future Cheogram app releases (including Cheogram WWW, desktop, etc. releases) will also be available as part of the itch.io package. Android apps from itch.io can be kept up to date using Mitch.
Other alternative app stores and distributions we have supported in the past (such as Aptoide) will no longer be official.
Unfortunately this does mean that anyone running the release-tied debug builds will either need to move to pre-release or to the new release builds in order to get updates.
Selected Recent Cheogram Android Changes
UI Improvements
Default options in command grids look less like headers (#b156e93)
Fixed account colors on item lists including start conversation (#957df4f)
Reorganized contact details layout for better narrow device support (#8780945)
“Manage Phone Accounts” button now scrollable (in list footer) (#b3bcfbb)
Chat & Messaging
Users can now see themselves in group chat participants list (#f240e52)
Can view own hats/roles in conference details (#3984516)
Improved button labels in group chat context menus (#37c504b)
Enhanced call failure UI with more informative displays (#4985523)
Hello again! We’re rounding off the year with another small release of the
Snikket server software. The main purpose of this release is to fix a couple
of small bugs which were discovered and reported after the previous release
was announced.
Notable changes
Offline message compatibility
It was reported that Conversations 2.19.2 and later did not reliably receive
offline messages after being offline for an extended period of time. This also
affected the upcoming Snikket Android release (which is based on Conversations).
This issue has been fixed in this server release.
Web portal debug information
The per-user debug information became inaccessible in the previous release due
to a minor bug that slipped in during refactoring. It should now work.
Upgrading
Upgrading an existing installation is super simple and takes less than a
minute! You can find instructions in the ‘Upgrading’ section
of the release notes.
If you have any questions or feedback about the new release, come and join the
discussion in our community chat.
In this new series, I want to shine some light onto specific parts of Monal’s internals. It’s dedicated to programmers or people curious about how Monal works internally.
If you want to give some feedback, feel free to send an email to thilo@monal-im.org
XMPP as a protocol is, as most protocols are, inherently asynchronous.
In Monal we therefore use the popular PromiseKit library
to let the UI know when a XMPP action finished or failed.
But this has a huge drawback: PromiseKit-based promises aren’t serializable, so we can’t respond to events
that got handled by the Notification Service App Extension while the app was suspended.
The serializable promise framework is a new framework in Monal, which exactly fills that gap.
Overall Process
For instance, imagine you want to remove the avatar of a group chat in Monal, while on a slow, unreliable network.
You submit the request, and the loading screen appears over the view (0:03)
Because the network is slow, the loading screen persists for a long time
You get frustrated and switch apps, sending Monal to the background (0:06)
After 30s in the background, Monal gets suspended (0:36)
The server fails to remove the avatar and sends an error to Monal
The response is handled by Monal’s app extension in the background (0:51)
You switch apps back to Monal (0:57)
Without the promise framework, the app would have continued to show the loading screen indefinitely, requiring you to fully close and open the app.
However, with the promise framework, when you switch back to the app, the loading screen disappears and correctly shows the error returned by the server:
The promise framework allows any such interaction, where the UI has to update in response from the server, to be handled in a general way.
Background
We will briefly describe the important parts below. But these links provide more detailed context and are recommended reading:
In Monal there are two separate processes: the “main app” (MonalAppDelegate) and “app extension” (NotificationService), which is sometimes abbreviated to “appex”.
Since they do not share memory, they hand over to each other via the handler framework.
An xmpp stanza can be processed by either, depending on whether the app is running or not:
App states
Below is a slightly simplified diagram of the app’s lifecycle. A more detailed lifecycle from Apple’s perspective is available here.
State
Description
App not running
App is not running, and when it is opened, it will start afresh
App active
App is open and in the foreground
App in background
App is running, but in the background
App suspended
App is not running, but its state is saved for when the app is reopened
The app moves from “active” to “in background” when it is swiped away without being closed
It continues to run and process stanzas for ~30s in the background
Once the 30s are complete, it moves to “suspended”
Apple saves the UI’s state
When the app is reopened, it returns to the same screen as before
Any stanzas that were processed in the meantime were processed by the appex
Appex states
Meanwhile, the appex has a more simple lifecycle - it is either running, or not running:
Once the appex starts, it will connect to the server and run for 30s
If the app is opened while the appex is running, the appex will return to “not running” state in deference to the app.
Serializable promise framework
Ok, now the background is out of the way, time to explain the promise framework!
While promises are very useful in SwiftUI, there is one problem: they only exist in that particular process, and cannot easily be passed between the app and appex.
This means that, if the promise was resolved in the appex, once the app is reopened (moves from suspended to active), it will not be consumed. This is because the appex has no way of tying the result back to the promise that updates the UI.
Since the handler framework is what allows the seamless handoff between the app and appex, we need a way to trigger consumption of a promise as a result of processing in the handler. This is precisely what the promise framework does!
High-level overview
We create a “serializable promise” class called MLPromise. This class stores a “UI promise” which is an AnyPromise from PromiseKit. Consumption of this AnyPromise is what ultimately causes the UI to update.
Whenever we want to bind a UI action to the result of a handler, we create an MLPromise and pass it as an argument to the handler. We then return the MLPromise’s AnyPromise to the UI.
Unlike the AnyPromise it contains, the MLPromise is (mostly) serializable. When the MLPromise is created, and whenever it is resolved, it persists itself to a new promises table in the database.
Meanwhile, whenever the app or appex is unfrozen, and the promise table is read into memory, the resolved arguments of any already existing promises are overwritten.
This means that, while the resolved argument can be passed betwen the app and appex, the UI promise itself cannot. The consequence of this is that a promise cannot be consumed in the appex - it can only be resolved there, leaving consumption for when the app becomes active again:
Process
Can resolve?
Can consume?
App
Yes
Yes
Appex
Yes
No
This makes some sense, as the whole purpose of the AnyPromise is to update the UI as a result of some backend action. It only makes sense to update the UI from the process which manages the UI - the app itself.
As a result, whenever the app becomes active again, all outstanding MLPromises check the version retrieved from the DB if they have been resolved in the meantime, and if so, consume themselves. This is how the loading overlay gets removed in the above example.
Step-by-step overview
Let’s return to the initial scenario of removing the avatar of a group chat. The user chooses the new avatar and presses submit. Then, the following happens:
The UI code responding to requests to remove the avatar calls the backend method to do this.
Once the backend function completes, it will return an AnyPromise, allowing the UI code to continue immediately:
showPromisingLoadingOverlay(overlay, headlineView:Text("Removing avatar..."), descriptionView:Text("")) {
// this returns an AnyPromise used by the loading overly to hide itself once it gets resolvedself.account.mucProcessor.publishAvatar(nil, forMuc: contact.contactJid)
}
The core code creates a new handler, and passes the MLPromise to it as an argument. Recall that handlers serialize their arguments - this means that, even if the app is suspended and the handler is called in the appex, the MLPromise will be available.
Internally, the MLPromise has created an AnyPromise. This is a type provided by PromiseKit that can be returned directly to the UI, and that the SwiftUI code understands. It gets returned to the UI code.
return [promise toAnyPromise];
(6) XMPP server provides response
This happens on the server side and is not relevant to Monal.
However, while waiting for the response, the user puts the app into the background, and the app gets suspended.
Now, the response from the server activates the appex, since the app was suspended.
The handler is called with the response from the server. It resolves the promise (via either reject or fulfill) - passing that response to the promise.
If the promise had been resolved from the app, it could have been consumed immediately. However, since it was resolved from the appex, the AnyPromise was not available to call at that time.
Therefore, the promise does not consume itself yet - it instead waits for the app to return to active state.
This waiting is performed by the following observer - whenever either the app or appex is unfrozen, the deserialize method is called:
deserialize calls attemptConsume on each run. attemptConsume checks if we are inside the appex (in which case we do not consume the promise), and only if we are inside the app does it consume the promise:
-(void) attemptConsume{
DDLogDebug(@"Intend to consume promise %@ with uuid %@ and argument %@", self, self.uuid, self.resolvedArgument);
if([HelperTools isAppExtension])
{
DDLogDebug(@"Not consuming promise %@ with uuid %@ as we are in the app extension", self, self.uuid);
return;
}
// ...
}
Note that both reject and fulfill also call attemptConsume after resolving the promise. This would let the promise be consumed immediately if we are inside the app instead of the appex.
Once we progress past the checks in attemptConsume, we finally consume the promise by calling the resolve callback tied to the PromiseKit AnyPromise returned earlier. This in turn prompts the UI to hide the loading overlay.
The XMPP assembly for the Chaos Communication Congress 39C3 has been confirmed!
The Chaos Communication Congress is a hacker conference that takes place every year barring specific world-ending events, and in which more than 10 000 hackers come together in Hamburg (previously Leipzig and Berlin).
We will have a space inside the Critical Decentralization Cluster habitat this year, which will provide a friendly space for discussions and exchanges on technology and politics with other communities working towards decentralization.
We will also come with a bunch of sparkly XMPP stickers that look like this:
Sparkly XMPP stickers
If someone plans to stay a while at the assembly, please make sure to register with the assembly on your ticket, as described in the info pages, so that we have enough room for everyone.
You can join the XMPP chatroom (web) as well as support organisation via the related XMPP Wiki page.
Regarding the article contact mathieui if you have remarks or suggestions concers.
The IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.3 brings a number of stability improvements and bug fixes. Notably, a number of improvements were made to Multi-User Chatroom (MUC). Please refer to the full changelog for more details.
You can obtain the new version of Openfire for your platform from its download page. The checksums for the binaries are:
The Chaos Communication Congress is a hacker conference that takes place every year
barring specific world-ending events, and in which more than 10 000 hackers come
together in Hamburg (or previously Leipzig or Berlin).
We will have a space inside the Critical Decentralization Cluster habitat this
year, which will provide a friendly space for discussions and exchanges on
technology and politics with other communities working towards decentralization.
I will come with a bunch of sparkly XMPP stickers that look like this:
If someone plans to stay a while at the assembly, please make sure to register
with the assembly on your ticket, as described in the info pages, so that
we have enough room for everyone.
On December 9th I returned to the Trolley Barn to DJ again for my friend Valerie
Young.
This time around my goal was to have a better mix of high energy and lower
energy “groovy” tunes, and I wanted to be better prepared for tying in endings
at any time, no matter how many times through the caller requested.
Prep
While I still prepped by marking each time through the dance with whether it
looped cleanly or not, this time I (mostly) marked it with a cue instead of a 64
beat loop.
I also named the cue based on what other cues I could jump to cleanly from it.
For example, if I were on the last time through the dance I would mark if it
looped cleanly itself, but also that I could jump backwards 3 times to cue 6 (or
whatever the case may be).
This way if I’m nearing the end of the dance but the caller is running it a bit
longer I can reset without a single 32 bar phrase starting to get repetitive.
I can also plan ahead by seeing that cue 6 lets me jump back to cue 8 or 9
afterwards (let’s assume these are the last two cues), which means that if the
caller immediately calls 2 more times through I know that I can cleanly jump
back to 2 more times without incident.
I also mark a handful of things in the music such as if this time through the
dance is a big recognizable build up (which I might not want to repeat even if
technically it sounds okay), or if I shouldn’t jump back before a cue because
the energy is significantly lower and we don’t want to kill the energy that had
already been built up on the dance floor.
This made it much easier to always follow the callers instructions and not have
to scramble to wrap up the song or ask if we can do 4 times through the dance
instead of 2 or what not.
The Set
I started out the set with a slowed down mix of “Whelan’s”, “Baghad Gus”,
and “Congress Reel” all by Wild Asparagus.
This was a medley that I had planned for my previous set but hadn’t managed to
use, but it worked quite well to “Whoever is Right is Right” by Jim Hemphill.
The only iffy moment I had in this medley was in one of the transitions where I
thought I executed it perfectly, only to have the tune I was introducing jump
half a beat ahead, breaking the rhythm.
I had left the Quantize option on (which locks the two beat grids together even
if you’re a little bit off) and unfortunately the beat grid on the song in
question was about half a beat off at the point I was doing the intro.
Lesson learned: pay more attention to what options you’ve got selected (and
reset them between songs, this would be a problem several times during the
evening) and in a song where the beat grid can’t be right through the entire
song (ie. because of tempo changes), make sure it’s correct at the point you’re
going to mix in.
Whelan's / Baghad Gus / Congress Reel by Wild Asparagus, DJ mix
For the second dance Valerie picked “Made Up Tonight” by Erik Hoffman.
This dance is relatively easy and in some ways similar to the previous dance so
I decided the dancers could handle a little bit higher tempo and energy level.
I did a mix of “Bus Stop!” by The Free Raisins and “Rec Hall” by Kingfisher.
This is another mix I had prepared for my previous set and one of the ones I was
most excited about performing.
Unfortunately I completely broke the transition by just forgetting to bring the
volume up on Rec Hall, so I ended up killing the music entirely for a few beats
before I realized what was happening and brought it back in.
It sounded terrible, and this one the dancers couldn’t help but notice, but
Valerie kept calling so they were on beat still when I finally realized what was
happening.
Lesson learned: go ahead and beat match and mix in a few bars early, then do
the transition by bringing the volume up instead of just hitting play, or just
remember to have the volume up first.
Bus Stop! / Rec Hall by The Free Raisins and Kingfisher, DJ mix
At this point Valerie decided to take the evening in a different direction from
the modern, improper and becket contras that the Trolley Barn normally asks
callers to stick to.
She called “The Steps of Waterloo”, a traditional Sicilian circle, which I’ve
never seen done at the Trolley Barn before.
Since this one is both easy and a bit silly I used “Flying Ice Cream” by Giant
Robot Dance which starts out very slow and groovy, then ramps up dramatically in
the second half.
Once the dance ramped up I mixed it with “The Randomainians” by The Great Bear
Trio to make it last a little longer.
This was the one mix and dance combo of the night that I was mostly extremely
pleased with, when the tempo and energy ramped up half way through the song the
dancers cheered and started frantically rushing to try and get to the basket
swing in the limited time the (normally too fast) music allowed which was a lot
of fun.
Lesson learned: prepare about twice as much music as you think you’ll need
for the evening (to be fair, I already knew this, I was just struggling with the
preparation for this set and didn’t end up with enough time to finish the other
mixes I was considering).
Flying Ice Cream / The Randomanians by Giant Robot Dance and The Great Bear Trio, DJ mix
Continuing Valerie’s theme of not doing modern contras she picked “The Hand
Jive”, a proper ceilidh, by Colin Towns next.
Because this dance is a bit more “fun” and contains some patty-cake like hand
games I decided to do a simple but fun mix of “Raccoon” by Wake Up Robin and
Disco Snails by Vulfmon and Zachary Barker.
Unfortunately I hadn’t considered that, easy as the hand clapping is, it
required Valerie to do a significant amount more calling than she normally would
do and never drop out, so picking a song with lyrics was a bad idea.
A few people still got a chuckle out of the “Disco Snails” cameo though.
Lesson learned: make sure to pay attention to how much the caller will have
to talk and ask if they plan on dropping out before introducing something with
lyrics.
Racoon / Disco Snails by Wake Up Robin and Vulfmon and Zachary Barker, DJ mix
We took our mid-dance waltz break at this point for which I played “Waiting for
Landfall” by Julie Vallimont, “Indifference” by the String Beings, and
“Norwegian Reinlender / Schottis From Idre” by Wild Asparagus.
I’d hoped that some of the dancers would know the schottische for the second
part of the medley, but mostly it just confused everybody who kept trying to
waltz even though it was no longer a waltz.
Coming back we were running a bit late so I decided to drop the show-stopper for
the evening, a mix of “Rainy Night” by The Dam Beavers, “Tween Spirit” by
Giant Robot Dance, and “Smells Like Teen Spirit” (which, of course, the
previous tune is a cover of) by Nirvana.
This was paired with “Birminghams” by Gary Nelson.
I played the first two tunes as a normal medley, then when Valerie indicated that
she was ready for three times left through the dance I mixed in the actual
Nirvana version just for the ending.
I was worried this crowd wouldn’t care for it, but when the tune first came in
(as “Tween Spirit”) a lot of the dancers started singing along, and when actual
Nirvana came in at the end the energy really ramped up and there was a lot of
cheering and stomping, so apparently even the younger members of the crowd were
still excited about 90s grunge!
The only real problem with this dance is that I had one moment where I had a
clean loop that I wanted to repeat but as I did so some of the dancers, knowing
what came next in the song, started singing the next verse and then had to stop
when the music wasn’t what they expected.
Lesson learned: when doing a pop song don’t do transitions that would break
the progression of the song that people are already used to, even if they sound
okay.
Rainy Night / Tween Spirit / Smells Like Teen Spirit by The Dam Beavers, Giant Robot Dance, and Nirvana, DJ mix
At this point I realized that I hadn’t prepared enough mixes for the dance and I
was more or less out of material.
For the next one Valerie asked to do a very short square dance, the “Cumberland
Square Eight”.
Since it was going to be so short and timing didn’t matter I played “Heather’s
Concussion” by The Great Bear Trio without mixing it into a medley.
This tune is itself very short (only three times through) and far too fast for
a normal contra, so I slowed it down (though still keeping it too fast) and sped
it up slowly through the dance to mess with the dancers.
They looked like they had a good time!
Heather's Concussion by The Great Bear Trio, DJ mix
This left us with just enough time for a no-walk-through contra.
I had nothing else prepared but wanted to send us out on an easy-tempo dance
after the various fast shenanigans from the rest of the night, but still have
some good energy.
I dug around in my library and ended up playing “Apple Blossom” by Great Bear.
Since I didn’t have anything to mix this with I just played it through and
looped once or twice near the end to keep the high-energy ending going.
The dance Valerie picked was an easy ending dance that is unfortunately called
“Unnamed Contra” and she didn’t know who wrote it.
Apple Blossom by Great Bear, DJ mix
We then closed down the evening (very late, much to the chagrin of the
organizers) with “Mending” by “The Little Mercies”.
Stuff I Learned
A recap of the things I need to take away from the evening:
Be thoughtful about resetting all controls, levels, mixing, effects, etc.
between tunes.
Possibly write down the initial state for each song so that you can re-set the
board at a glance.
Beat match early then use the volume sliders for transitions, don’t just start
playing immediately at the entry point (or just remember to turn up the volume
as you approach the mix point).
Consider how much the caller will have to talk in any given dance and how soon
they’re dropping out before mixing in vocals.
For pop songs, don’t violate the order of the verses or breaks that people
expect, even if the final result sounds okay.
It’s jarring for the dancers who are used to it being a certain way.
And finally: relax and enjoy it! While I spend the entire evening worrying about
how the sound dropped out for a moment, or my transition was a beat off and I
saw the dancers stumble and catch back up, or whatever other disaster might have
befallen, no one remembers any of that.
I got a very nice message from the organizer the next day telling me how excited
everyone was and how many conversations she’d had with people telling her how
much they enjoyed the music!
(credit: 
Thank you to every contributor, big or small, for your time, passion, and patience.
