Release Highlights:

This release includes the support for Hydra rooms in our Matrix gateway, which fixes high severity protocol vulnerabilities.

• Improvements in Matrix gateway
• Fixed ACME in Erlang/OTP 28.0.2
• New mod_providers to serve XMPP Providers file

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

Other contents:

• Improved Unicode support in configuration
• New option conversejs_plugins to enable OMEMO
• Easier erlang node name change with mnesia_change
• Colorized interactive log
• Document API tags in modules
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.08 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Improvements in Matrix gateway

The ejabberd Matrix gateway now supports Hydra rooms (Matrix room version 12). This fix some high severity protocol vulnerabilities. The state resolution has been partially rewritten in our gateway.

A double colon is used for separating a matrix server from a room ID in JID with Hydra rooms.

Other changes to the matrix gateway:

• The new option notary_servers of mod_matrix_gw can now be used to set a list of notary servers.
• Add leave_timeout option to mod_matrix_gw (#4386)
• Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)

Fixed ACME in Erlang/OTP 28.0.2

The ejabberd 25.07 release notes mentioned that Erlang/OTP 28.0.1 was not yet fully supported because there was a problem with ACME support.

Good news! this problem with ACME is fixed and tested to work when using Erlang/OTP 28.0.2, the latest p1_acme library, and ejabberd 25.08.

If you are playing with ejabberd and Erlang/OTP 28, please report any problem you find. If you are running ejabberd in production, better stick with Erlang/OTP 27.3, this is the one used in installers and container images.

New mod_providers to serve XMPP Providers file

mod_providers is a new module to serve easily XMPP Providers files.

The standard way to perform this task is to first generate the Provider File, store in the disk with the proper name, and then serve the file using an HTTP server or mod_http_fileserver. And repeat this for each vhost.

Now this can be replaced with mod_providers, which automatically sets some values according to your configuration. Try configuring ejabberd like:

listen:
  -
    port: 443
    module: ejabberd_http
    tls: true
    request_handlers:
      /.well-known/xmpp-provider-v2.json: mod_providers

modules:
  mod_providers: {}

Check the URL https://localhost:443/.well-known/xmpp-provider-v2.json, and finetune it by setting a few mod_providers options.

Improved Unicode support in configuration

When using non-latin characters in a vhost served by ejabberd, you can write it in the configuration file as unicode, or using the IDNA/punycode. For example:

hosts:
  - localhost1
  - locälhost2
  - xn--loclhost4-x2a
  - 日本語

host_config:
  "locälhost2":
    modules:
      mod_disco: {}
      mod_muc:
        host: "conference3.@HOST@"
  "xn--loclhost4-x2a":
    modules:
      mod_disco: {}
      mod_muc:
        host: "conference4.@HOST@"

This raises a problem in mod_http_upload if the option put_url contains the @HOST@ keyword. In that case, please use the new predefined keyword HOST_URL_ENCODE.

This change was also applied to ejabberd.yml.example.

New option conversejs_plugins to enable OMEMO

mod_conversejs gets a new option conversejs_plugins that points to additional local files to include as scripts in the homepage.

Right now this is useful to enable OMEMO encryption.

Please make sure those files are available in the path specified in conversejs_resources option, in subdirectory plugins/. For example, copy a file to path /home/ejabberd/conversejs-x.y.z/package/dist/plugins/libsignal-protocol.min.js and then configure like:

modules:
  mod_conversejs:
    conversejs_resources: "/home/ejabberd/conversejs-x.y.z/package/dist"
    conversejs_plugins: ["libsignal-protocol.min.js"]

If you are using the public Converse client, then you can set \"libsignal\", which gets replaced with the URL of the public library. For example:

modules:
  mod_conversejs:
    conversejs_plugins: ["libsignal"]
    websocket_url: "ws://@HOST@:5280/websocket"

Easier erlang node name change with mnesia_change

ejabberd uses by default the distributed Mnesia database. Being distributed, Mnesia enforces consistency of its file, so it stores the Erlang node name, which may include the hostname of the computer.

When the erlang node name changes (which may happen when changing the computer name, or moving ejabberd to another computer), then mnesia refused to start with an error message like this:

2025-08-21 11:06:31.831594+02:00 [critical]
  Erlang node name mismatch:
  I&aposm running in node [ejabberd2@localhost],
  but the mnesia database is owned by [ejabberd@localhost]
2025-08-21 11:06:31.831782+02:00 [critical]
  Either set ERLANG_NODE in ejabberdctl.cfg
  or change node name in Mnesia

To change the computer hostname in the mnesia database, it was required to follow a tutorial with 10 steps that starts ejabberd a pair of times and runs the mnesia_change_nodename API command.

Well, now all this tutorial is implemented in one single command for the ejabberdctl command line script. When mnesia refuses to start due to an erlang node name change, it mentions that new solution:

$ echo "ERLANG_NODE=ejabberd2@localhost" >>_build/relive/conf/ejabberdctl.cfg

$ ejabberdctl live
2025-08-21 11:06:31.831594+02:00 [critical]
  Erlang node name mismatch:
  I&aposm running in node [ejabberd2@localhost],
  but the mnesia database is owned by [ejabberd@localhost]
2025-08-21 11:06:31.831782+02:00 [critical]
  Either set ERLANG_NODE in ejabberdctl.cfg
  or change node name in Mnesia by running:
  ejabberdctl mnesia_change ejabberd@localhost

Let&aposs use the new command to change the erlang node name stored in the mnesia database:

$ ejabberdctl mnesia_change ejabberd@localhost

==> This changes your mnesia database from node name &aposejabberd@localhost&apos to &aposejabberd2@localhost&apos

...

==> Finished, now you can start ejabberd normally

Great! Now ejabberd can start correctly:

$ ejabberdctl live
...
2025-08-21 11:18:52.154718+02:00 [info]
  ejabberd 25.07.51 is started in the node ejabberd2@localhost in 1.77s

Notice that the command mnesia_change must start and stop ejabberd a pair of times. For that reason, it cannot be implemented as an API command. Instead, it is implemented as an ejabberdctl command directly in the ejabberdctl command line script.

Colorized interactive log

When ejabberd starts with an erlang shell using Mix, it prints error lines in a remarkable color: orange for warnings and red for errors. This helps to detect those lines when reading the log interactively.

Now this is also supported when using Rebar3. To test it, start ejabberd either:

• ejabberdctl live: to start interactive mode with erlang shell
• ejabberdctl foreground: to start in server mode with attached log output

You will see log lines colorized with:

• green+white for informative log messages
• grey for debug
• yellow for warnings
• red for errors
• magenta for messages coming from other Erlang libraries (xmpp, OTP library), not ejabberd itself

Document API Tags in modules

Many ejabberd modules implement their own API commands, and now the documentation of those modules mention which tags contain their commands.

See for example at the end of modules mod_muc_admin, mod_private or mod_antispam.

Unfortunately, many early API commands were implemented in mod_admin_extra, which includes commands related to account management, vcard, roster, private, ... and consequently those are not mentioned in their corresponding modules documentation.

Acknowledgments

We would like to thank the contributions to the source code provided for this release by:

• mod_matrix_gw: Don&apost send empty direct Matrix messages (thanks to snoopcatt) (#4420)
• Holger Weiß for improvements in the installers, HTTP file upload and mod_register
• marc0s for the improvement in MUC

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_dedup

This module removes duplicates of read receipts sent by concurrent sessions of single user, this will prevent both delivery and storage in archive of duplicates.

Limits in mod_unread queries

Queries issued to mod_unread can now declare maximum number and age of returned results. This can also be tweaked with new options of that module.

ChangeLog

This is a more complete list of changes in this ejabberd release:

API Commands

• ban_account: Run sm_kick_user event when kicking account (#4415)
• ban_account: No need to change password (#4415)
• mnesia_change: New command in ejabberdctl script that helps changing the mnesia node name

Configuration

• Rename auth_password_types_hidden_in_scram1 option to auth_password_types_hidden_in_sasl1
• econf: If a host in configuration is encoded IDNA, decode it (#3519)
• ejabberd_config: New predefined keyword HOST_URL_ENCODE
• ejabberd.yml.example: Use HOST_URL_ENCODE to handle case when vhost is non-latin1
• mod_conversejs: Add option conversejs_plugins (#4413)
• mod_matrix_gw: Add leave_timeout option (#4386)

Documentation and Tests

• COMPILE.md: Mention dependencies and add link to Docs (#4431)
• ejabberd_doc: Document commands tags for modules
• CI: bump XMPP-Interop-Testing/xmpp-interop-tests-action (#4425)
• Runtime: Raise the minimum Erlang tested to Erlang/OTP 24

Installers and Container

• Bump Erlang/OTP version to 27.3.4.2
• Bump OpenSSL version to 3.5.2
• make-binaries: Disable Linux-PAM&aposs logind support

Core and Modules

• Bump p1_acme to fix &aposAttributePKCS-10&apos and OTP 28 (processone/p1_acme#4)
• Prevent loops in xml_compress:decode with corrupted data
• ejabberd_auth_mnesia: Fix issue with filtering duplicates in get_users()
• ejabberd_listener: Add secret in temporary unix domain socket path (#4422)
• ejabberd_listener: Log error when cannot set definitive unix socket (#4422)
• ejabberd_listener: Try to create provisional socket in final directory (#4422)
• ejabberd_logger: Print log lines colorized in console when using rebar3
• mod_conversejs: Ensure assets_path ends in / as required by Converse (#4414)
• mod_conversejs: Ensure plugins URL is separated with / (#4413)
• mod_http_upload: Encode URLs into IDNA when showing to XMPP client (#3519)
• mod_matrix_gw: Add support for null values in is_canonical_json (#4421)
• mod_matrix_gw: Don&apost send empty direct Matrix messages (#4420)
• mod_matrix_gw: Matrix gateway updates
• mod_muc: Report db failures when restoring rooms
• mod_muc: Unsubscribe users from members-only rooms when expelled (#4412)
• mod_providers: New module to serve easily XMPP Providers files
• mod_register: Don&apost duplicate welcome subject and message
• mod_scram_upgrade: Fix format of passwords updates
• mod_scram_upgrade: Only offer upgrades to methods that aren&apost already stored

Full Changelog

https://github.com/processone/ejabberd/compare/25.07...25.08

ejabberd 25.08 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub.

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity.

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags.

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs. The alternative ejabberd container image is available in ghcr.io/processone/ejabberd.

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues.

MongooseIM is a scalable and efficient instant messaging server. It implements the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

The C2S interface was reworked and improved already in version 6.1.0 (see the blog post), making it more modern, organised and extensible. In the most recent version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

Simplified, unified and more complete

Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch, a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

Another unified and improved system aspect is the TLS encryption. The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

All these changes are reflected in the TOML configuration file. When compared with the previous version of MongooseIM, there are the numerous improvements such as the following:

• Components can benefit from TLS connections.
• S2S options are separate for the incoming (listen.s2s) and outgoing (s2s.outgoing) connections. Common options are placed directly in the s2s section (e.g. default_policy).
• Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
• S2S outgoing connections can have traffic shaping enabled.
• All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

Another improved layer is the instrumentation. Most changes affect XMPP traffic events. For example, there used to be an event called c2s_element_in, emitted when an XML element is received on a C2S connection. A separate event called c2s_xmpp_element_size_in was emitted to measure element size. Now, there is one event called xmpp_element_in - and it covers measurements from both previous events. Event names are now more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type. Additionally, event coverage got improved, e.g. xmpp_element_in now covers S2S and component connections as well. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic. For more information, see the documentation on metrics. Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

SASL 2, Bind 2, FAST

Over the past few releases, we have been implementing extensions speeding up the XMPP stream negotiation and authentication:

• XEP-0388: Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
• XEP-0386: Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
• XEP-0484: FAST allows a client to authenticate with a token as a part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

FAST features supported in MongooseIM

In version 6.4, additional advanced features of FAST are supported. One of them is token rotation: the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one. Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

What’s next?

You can read more about MongooseIM 6.4 in the detailed blog post. You can also find more information in the release notes. Don’t hesitate to visit our product page, try it online and contact us if you are considering using it in your business.

Read about Erlang Solutions as sponsor of the XSF.

MongooseIM is a scalable and efficient instant messaging server. With the latest release 6.4.0, it has become more powerful yet easier to use and maintain. Thanks to the internal unification of listeners and connection handling, the configuration is easier and more intuitive, while numerous new options are supported.

New features include support for TLS 1.3 with optional channel binding for improved security, single round-trip authentication with FAST (which can be even faster with 0-RTT or more secure with channel binding), reduced start-up time and many other improvements and bug fixes. Let’s take a deeper look at some of the most important improvements.

Reworked XMPP interfaces

MongooseIM uses the open, proven, extensible and constantly evolving XMPP protocol, which is an excellent choice when it comes to instant messaging. To communicate with other XMPP entities, the server uses three main types of interfaces, listed in the table below.

The C2S interface was reworked and improved already in version 6.1.0 (see the blog post), making it more modern, organised and extensible. In version 6.4.0, this trend is continued by reworking the S2S and component interfaces while unifying the whole connection handling logic.

Simplified, unified and more complete

Connection accepting and handling was simplified and unified in multiple ways, allowing the addition of new features along the way. All connections are now accepted by ranch, a state-of-the-art socket acceptor pool for Erlang. Modern gen_statem behaviour is then used to handle open connections using state machines. These changes allowed for improved handling of various corner cases, removing unexpected limitations and mishandled error conditions. There is also improved separation of concerns, resulting in easier extensibility and configurability.

Another unified and improved system aspect is the TLS encryption. The legacy fast_tls library is now fully replaced with the Erlang implementation, resulting in much more straightforward configuration and implementation without a drop in performance (as evidenced by rigorous load tests). This change made it possible to fill in some gaps in functionality, such as the support for channel binding as required for TLS 1.3 (see RFC 9266 for details). Additionally, TLS is now supported for component connections. Moreover, CA certificates can be provided by the OS, reducing the need for manual certificate provisioning. As a result of these changes, your MongooseIM installation will be more secure and robust.

All these changes are reflected in the TOML configuration file. As an example, the following snippet presents the configuration of S2S and component connections:

[[listen.component]]
  port = 8190
  shaper = "fast"
  ip_address = "127.0.0.1"
  password = "secret"
  tls.certfile = "priv/ssl/cert.pem"
  tls.keyfile = "priv/ssl/key.pem"


[[listen.s2s]]
  port = 5269
  shaper = "fast"
  tls.certfile = "priv/ssl/cert.pem"
  tls.keyfile = "priv/ssl/key.pem"


[s2s]
  default_policy = "allow"

  [s2s.outgoing]
    port = 5269
    shaper = "fast"
    tls.certfile = "priv/ssl/cert.pem"
    tls.keyfile = "priv/ssl/key.pem"

When compared with the previous version of MongooseIM, there are the following improvements:

• Components can benefit from TLS connections.
• S2S options are separate for the incoming (listen.s2s) and outgoing (s2s.outgoing) connections. Common options are placed directly in the s2s section (e.g. default_policy).
• Traffic shapers are configured the same way for all types of connections, and are always referenced by their names.
• S2S outgoing connections can have traffic shaping enabled.
• All TLS options follow the same pattern throughout the configuration file. This also affects multiple options that were omitted from this example for simplicity.

Another improved layer is the instrumentation. Most changes affect XMPP traffic events – they are summarised in the table below:

We can see that there are fewer event names now, and they are more concise, making them easier to remember and reason about. This was possible due to the use of labels like connection_type and host_type, and actually, the event coverage got improved – see the element_in and element_out events, which now cover s2s and component connections. Also, the events are emitted more consistently. For incoming data, there is always one event emitted as soon as an XML element (most often a stanza) is parsed. For outgoing data, there is always one event emitted just before sending an XML element out. As a result, the metrics are consistent with actual network traffic.

Another addition is the auth_failed event for s2s and component connections. For more information, such as the translation of event names and measurements to actual metric names, see the documentation on metrics. Our blog post about release 6.3.0 can also give you more details about the instrumentation layer and its integration with Prometheus.

SASL 2, Bind 2, FAST

Over the past few releases, we have been implementing extensions, speeding up the XMPP stream negotiation and authentication:

• XEP-0388: Extensible SASL Profile (SASL2) allows a client to authenticate, resume its session and more in one round-trip.
  
• XEP-0386: Bind 2 allows a client to bind the resource and enable selected extensions (SM, carbons, CSI) as part of SASL2.
  
• XEP-0484: FAST allows a client to authenticate with a token as part of SASL2. According to the specification, this is a token-based method for streamlining authentication in XMPP, enabling fully authenticated stream establishment within a single round-trip.

As an example, let’s assume that a user with the JID alice@localhost already has a FAST token obtained during previous authentication. When opening a new connection, the client sends the following:

<authenticate mechanism='HT-SHA-256-NONE' xmlns='urn:xmpp:sasl:2'>
  <initial-response>YWxpY0VfY2xpZW50X2F1dGhlbnRpY2F0ZXNfdXNpbmdfZmFzdF80MDYA5u2CpST(...)</initial-response>
  <bind xmlns='urn:xmpp:bind:0'/>
  <user-agent id='d4565fa7-4d72-4749-b3d3-740edbf87770'/>
</authenticate>

As a response, it receives:

<success xmlns='urn:xmpp:sasl:2'>
  <authorization-identifier>alice@localhost/1750-684128-573793-695021f052e299fe</authorization-identifier>
  <bound xmlns='urn:xmpp:bind:0'/>
</success>

This way, the whole connection and authentication process is performed in a single round-trip.

FAST features supported in MongooseIM

In version 6.4, additional advanced features of FAST are supported. One of them is token rotation: the server invalidates tokens after a configurable period, and provides a new token on reconnection if the current one is close to expiry (this period is also configurable). Additionally, a client can request immediate token invalidation – with or without requesting a new one.

Another addition is the support for 0-RTT (zero round-trip time) data in TLS 1.3 (see RFC 8446, section 2.3). The FAST token can be provided by the client during a subsequent handshake after reconnection, meaning that there is no additional round-trip needed after the handshake – hence the name “0-RTT”. A different extension is the tls-exporter channel binding in TLS 1.3 (see RFC 9266 for details) – it can be used with FAST, resulting in the channel binding data being passed with the FAST token, increasing the security. Note that currently it cannot be used with 0-RTT data. See the documentation for mod_fast_auth_token and the Hashed Token SASL Mechanism specification for more information.

Summary

MongooseIM 6.4.0 offers numerous improvements in various areas – from configuration to instrumentation. New features such as FAST tokens make it easier for your clients and services to connect, while TLS 1.3 makes it more protected against malicious attacks. You can discover much more in the release notes.

Don’t hesitate to visit our product page, try it online and 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

The post MongooseIM 6.4: Simplified and Unified appeared first on Erlang Solutions.

I’ve recently been using the Mixxx software for DJs. This page includes some personal notes on my own use cases, what’s good, what’s bad, etc. It is not really made for general consumption, but is thrown up here anyways. It will be a bit rambling and/or ranty at times, most likely.

Let’s get my overall impressions of the software out of the way up front: it’s absolutely great and I recommend it over the commercial alternatives for DJs of all stripes (except maybe Radio DJs, it’s not really for automatically scheduling radio programs, but people seem to love it for that use case anyways, but maybe that’s because it’s the closest thing that’s free?). This is one of the very few Open Source pieces of software that I can say is just good, and not just “yah, it’s not as good as commercial stuff, but for moral and ideological reasons I choose to make some sacrifices to use it”. No, Mixxx is actually just good, full stop.

My Use Case

My use case for Mixxx is two fold. The first is for DJing for social dances (Lindy Hop and Blues). This case is simple enough that I know DJs who just use two media players tied to different outputs (headphones and mains) and call that good enough: you preview tracks and build a potential playlist in the headphone software, then when a dance ends you drag the next one that you’ve cued up into the software playing on the mains and call it a day. The requirements for social dance DJing are such that this is perfectly fine, but having headphone cueing and waveform visualization is nice, so Mixxx adds what it can here even though something much less complicated than full DJ software would also be okay. I don’t even really need a controller here unless the dance doesn’t provide a sound board, in which case Mixxx also would let you use a small controller to provide software fade outs, which is a nice benefit.

My second use case is also for a social dance, but for one with slightly more complicated requirements. Contra dancing is traditionally always done with a live band, and the dance itself is more structured than improvisational dances like Lindy. A caller tells the dancers what moves to do in time with the music slightly ahead of the beat. They let the dance run as long as they like while the band plays a tune with a specific structure that fits the choreography of the dance. Bands traditionally switch tunes half way through a dance, and dances last until the caller signals when they should end (normally with 2 or 3 more times remaining through the dance).

There are contras that use recorded music, but they suffer from a few problems:

• Recorded music is often meant for a CD, so it is ~3 minutes instead of the 7–12 needed for a dance,
• the band needs to be able to respond to the caller and the caller needs to be able to respond to the band, this isn’t possible with recordings obviously,
• not being limited by dancers skill, bands sometimes make their recorded music much faster or slower than is appropriate for dancing,
• and recorded music is often “crooked”, meaning that it doesn’t strictly fit into the requirements for a contra dance (musicians often prefer to do something more interesting if they’re playing a tune for a recording and not for a dance).

Mixxx is perfect for this use case! Just like any DJ I can mix several tracks together (though the music does end so that people can find a new partner, this isn’t a full evenings set where music never stops like a club DJ would do), I can loop and play sections of the track over again to make it fit the contra structure (even if the original track didn’t), I can skip over between times through the dance that would break the timing, I can speed up or slow down a recorded tune to make it fit the dance better, and I can even keep a tune going until the caller signals how many more times through they want then mix in a nice ending for them.

Mixxx is absolutely perfect for this, and makes for a much more enjoyable dance than you’d get having the caller play music off their phone. It also means you can dance to the most well-known high-energy contra dance bands whenever you want instead of hiring the same handful of low-energy local bands every week (with apologies to those bands, it’s nice to have live music, but it’s also great to be able to get the big touring bands even if you can’t afford to hire them regularly)!

P.S. I don’t do “techno contra” (contra to pop music and rave lighting, it has nothing to do with actual techno music except that it might sometimes use that too), but Mixxx is good for that as well.

Good Stuff

• One of the best UI’s in any software (with the caveat that you probably have to be sighted to use it, as far as I can tell there are no accessibility features, see the problems section below).
• Absolutely rock solid audio handling (on Linux/Pipewire, can’t speak for other stuff)
• Great controller support. Keeping old controllers running that would otherwise be relegated to the landfill is one of the best things about Mixxx. That said, this one has some caveats:
  • the quality of the built-in mappings varies greatly, to say nothing of the user-provided mappings on the forums,
  • and the manual is very incomplete so it’s a bit hard to research what controllers work well and have solid mappings.

Bad Stuff

These are personal notes and while they are public, they are not meant to be an angry take-down of the developers or their process (who may have good reasons for doing the things they do that I disagree with). There’s a reason I’m not sending these on the forums.

I’m going to avoid “my favorite feature is missing”, even if it’s a major problem for me. Most of these are with the development process (plus one serious bug and the usual complaints about developers not taking accessibility seriously), but on the other hand, the software overall is very stable and good, so I suppose I shouldn’t critique a process that seems to be resulting in robust well-made software. If you are not a software developer, most of these probably won’t matter all that much and can be safely ignored.

I don’t contribute to the C++ side because I hate C++ and everything about developing with it, so be aware that most of this is me being hypocritical since it’s not like I’m helping (though also most of the complaints are about stuff they turn down anyways, so maybe it’s fine to complain while not doing it myself).

Anyways, this is all starting to sound defensive, so I’ll leave it at that and just get to the list. The point is: if you feel the need to reach out to me to tell me about how right/wrong/whatever this list is: don’t.

• The homepage is terrible (seriously, on the website you get what looks like a stock image of code on a terminal… there is literally not even a screenshot of the actual software, I imagine most people who aren’t developers see the website and never bother downloading the software; why would they?).
• Lack of accessibility features / disinterest from the developers. This seems like the kind of thing that we as software developers should always prioritize whether we like it or not. Their official response seems to be “we don’t use screen readers, therefore we shouldn’t have to try” and/or “maybe it will be easier with the Mixxx 3.0 interface”, which may very well be true but doesn’t help you if you use a screen reader now and it seems extremely problematic and unfair to ask users of accessibility software to wait for some nebulous future time to maybe be able to use the software. The best time to add accessibility features was yesterday, but if not, today will have to do. Stop putting it off until 3.0 (even if you have to re-write them all for 3.0). This is the closest I will come to demanding labor from developers doing this for free, I am aware of the vaguely problematic nature of that, but this really is the basics and everyone ignores it for ableism related reasons and it drives me up the wall (okay, rant over).
• As of 2.5.2 there is no hotplug for controllers, plus if it is unplugged it often results in a segfault which is pathologically bad behavior (see #14358)
• Development of a lot of new features that involve theming is stalled due to the maintainers wanting to write a new theme engine first which probably wont' be released until 3.0. Lots of small relatively easy fixes are put on the back burner for this reason (or at least, that’s what it looks like from reading through issues, I’m not sure what the reality of the situation is or if they’d accept PRs from other contributors).
• Extremely difficult to get code review if you do submit a contribution, plus they nitpick to death and every reviewer has their own criteria, one will tell you one thing, then one will demand you undo it. Asking for nits to be fixed is fine, we want to make good software, but what we don’t want is demanding that they be fixed immediately in a giant PR, or demanding that other semi-related features be fixed before your PR can be merged, etc. and then refusing to merge because of a small nit that could easily be fixed later and where it wouldn’t be a huge problem if it never did get fixed.
• There is talk of adding AI features. Absolutely fuck every single asshole who thinks this is okay. Hopefully these people never get their PRs merged, but it doesn’t sound like there’s a ton of pushback except from me, so I suspect I’m fighting a losing battle here and will at some point have to stop using their software. This really needs someone who can talk people around and explain why this will hurt the software, the planet, and the people utilizing it, but I’m not that person. I’m just angry at how dumb everything to do with AI is and that’s not a helpful way to bring people around to doing the right thing.

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of July 2025.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or helping these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before August 17th, 2025 00:00 UTC.

XMPP at FrOSCon 20

On August 16th & 17th, 2025, the FrOSCon will hold its 20th anniversary edition™. It will take place at the Hochschule Bonn-Rhein-Sieg in Sankt Augustin, Germany, and the XMPP community will be part of it!

While you are there, you may be interested in what is going on at the Devrooms.

The Gemeinsamer DevRoom von Gentoo e.V. und TroLUG will take place at Room C125, where Gentoo e.V. and TroLUG will offer a rich and varied 2-day program on various topics, including the Gentoo and Debian distributions and free software for smartphones. XMPP will play a special role. Short presentations, demos and workshops will encourage visitors to join in. There will also be plenty of time for spontaneous topics and social interaction. (Shh! Don’t tell anyone! … but you can take a look at all the nitty gritty details in here)

And, of course: make sure to come by the XMPP booth and say hi!. We promise there will be stickers. ;)

Videos

• Federated instant messaging, 100% debianized by Elena “of Valhalla” Grandi at the DebConf25.
• Why Aren’t You Using XMPP?
• FOSSY 2025: XMPP track at Room 327.
  • Setting Up A Simple XMPP Server by Root.
  • Telecomms for Preppers by Phillip.
  • Messaging interoperability with MLS, MIMI and XMPP by Marvin W..
  • Adventures in Onboarding: Helping New Users Navigate Federated Services by Gideon Mayhak.
  • How do you solve a problem like iOS? by Stephen Paul Weber.

XMPP Articles

• Empowering Digita:l Sovereignty with Openfire: A Secure and Customizable Communication Platform by guus.
• ProcessOne
  • XMPP: When a 25-Year-Old Protocol Becomes Strategic Again by Mickaël Rémond .
• XMPP Interop Testing
  • MOAR TESTS!: Ever heard of XMPP Interop Testing? It’s this cool project that helps make sure different XMPP servers can all work together smoothly. They have just released version 1.6.0 of all their test runners! The biggest chunk of work has gone into tests that verify parts of the basic XMPP protocol, notably for testing functionality that involves roster management (as specified in section 2 of RFC 6121) and for server rules for processing XML stanzas (section 8 of RFC 6121). Please get in touch if you have any ideas for improvement, or other feedback. They’d love to hear from you!
• JoinJabber now has a Governance document based on the Cooperative Development Guidelines governance template. It aims to be the authoritative document on what JoinJabber wants to do, how they are doing it, an overview of their structure (in few words; there is going to be a separate document to define it fully), and the RFC process for changes.
• Configure the Prosody XMPP-server for free communication on the network from exception.net.ua. [UA]
• Launch of the XMPP / Fediverse Bridge! by BarbaPulpe. [DE] [ES] [FR] [IT] [NL] [PT]
• Federated instant messaging, 100% debianized, a short and concise summary of the speak hosted by Elena “of Valhalla” Grandi at the DebConf25 for people who prefer reading text. [IT] [ES]
• XMPP Home Automation Demonstration Machine from Rainer’s Hilfeseiten [DE].
• Guia rápido e fácil para novos usuários de XMPP, a Brazilian Portuguese translation and adaptation of contrapunctus’ ‘The Quick and Easy Guide to Jabber/XMPP’, by Isadora Ribeiro for the DEV Community. [PT_BR]
• Introducing XOWS: a Javascript XMPP web client that makes use of the WebSocket protocol. A first Beta release, which is more or less an advanced Alpha, is already available for download.
• Join the XMPP-IT Community: Your Help Matters!. The XMPP-IT community is launching a call for active collaboration — no need to be an expert, and it’s not paid work, just shared participation. From translations to testing software, writing wiki content or contributing code, there’s room for everyone. [IT]

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.19.0, 2.19.1 and 2.19.2 for Android, adding support for moderated message retraction in public channels (XEP-0425), showing ‘Last seen’ prominently in chat title (when enabled), and various bug fixes. You can take a look at the changelog for all the details.
• Gajim has released version 2.3.3 of its free and fully featured chat app for XMPP. This release comes with many fixes for Windows and it brings some styling improvements, better performance and bugfixes. You can take a look at the changelog for all the details. Thank you for all your contributions!
• Monal has released version 6.4.12 for iOS and macOS.
• Monocles has released version 2.0.12 of its chat client for Android, featuring improvements and fixes. Take a look at the changelog for all the details.
• Movim has released version 0.31 (code named “Kameny”). This release comes loaded with new features ranging from the NLNet funded simultaneous webcam and screen sharing (and the first steps to SFU integration) to global chatroom search (XEP-0433), URL resolver worker, pronouns support in the profile (in compliance with RFC vCard4), quick switch between 1:1 chats and chatrooms and the ability to move the actions list in the ‘Contact’ or ‘Chatroom’ panel, among many other news!

Movim 0.31 (Kameny): Simultaneous webcam and screen sharing!

• XOWS 0.9.8, a lightweight and modern XMPP over WebSocket Web client, has been released.

XMPP Servers

• ProcessOne is pleased to announce the release of ejabberd 25.07. This release focuses on integration in a wider federated network, with support for spam fighting features, improved Matrix gateway, native support for PubSub Server Information to have your server count as part of the wider XMPP network (e.g. register your server on XMPP Network Graph), new modules, features, improvements and bugfixes. Make sure to read the changelog for all the details and a complete list of changes!
• Prosodical Thoughts: Debian repository key change. The Prosody Team has been working on some changes on the Debian/Ubuntu package repository. If you use this repository to keep up to date with new Prosody packages, you need to take action before 4th August 2025 to continue receiving updates smoothly. Please follow the instructions described in the article. If you have any questions about this change, the Prosody Team is always happy to help and answer them on their community chat!
• WebRTC based audio and video in Openfire 2025 by Dele_Olajide1.

XMPP Libraries & Tools

• slidge-whatsapp, the XMPP-to-WhatsApp gateway based on Slidge, version 0.2.7 has been released.
• peertube-plugin-livechat version 14.0.1 has been released.
• xmpp-ap-bridge versions 0.7.0, 0.7.1 and 0.7.2 have been released.
• xmpp-dns version 0.5.0 Beta 1 has been released.
• go-sendxmpp version 0.15.0 Beta 1 has been released.
• ignite realtime community: XEP-0483: HTTP Online Meetings by Dele_Olajide1.

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.

• No XEPs proposed this month.

New

• Version 0.1.0 of XEP-0504 (Data Policy)
  • Accepted as Experimental by Council vote on 2025-06-08 (XEP Editor: dg)
• Version 0.1.0 of XEP-0505 (Data Forms File Input Element)
  • Accepted as Experimental by Council vote on 2025-07-08 (XEP Editor: 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.

• No XEPs deferred this month.

Updated

• Version 1.10.0 of XEP-0080 (User Location)
  • Added <regioncode/> element. (jp)
• Version 1.2.0 of XEP-0363 (HTTP File Upload)
  • Add optional upload purpose when requesting slots (dg)

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.

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

Also check out our RSS Feed!

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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• German: xmpp.org
  • Translators: Millesimus
• Italian: notes.nicfab.eu
  • Translators: nicola
• Portuguese: xmpp.org
  • Translators: Paulo
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi

Help us to build the newsletter

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

XSF Fiscal Hosting Projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

Providers Survey

In May 2025, we ran a small survey to gather feedback from XMPP server operators. Our main concerns were XMPP Provider’s service and the project itself. First of all, we would like to thank almost 60 people who participated in this survey. While the XMPP Providers project currently lists a little more than 70 providers, this is a good turnout. At this point we can already tell that the general feedback is very positive!

Although we had quite a few participants, only about one third were actual server operators. Most of the responders were listed in category A or B or they were not listed yet.

Survey category result

Since we are curious about the general satisfaction with XMPP Provider’s service, we made these four aspects part of the survey: Service listing and its processes, transparency, documentation and communication. Across all these aspects, we see mostly satisfied to very satisfied participants. For the occasional question about project documentation, we recommend the FAQ as a starting point.

Survey general experience result

Since being listed as a provider may come with increased public visibility, we are interested in potential changes in registration count, usage activity, maintenance efforts or spam incidents. The results suggest that spam incidents, maintenance efforts and usage activity didn’t change much. However, registration count increased, which supports federation in the XMPP ecosystem.

Survey listing experience result

In addition to these survey results, we received a lot of written feedback. A good share of this feedback praises the project for empowering people to make a good and informed choice about their XMPP provider. We would like to address some of the points raised in the feedback separately:

• Which kind of providers do we list? Our goal is to list all publicly visible XMPP providers. XMPP Providers gathers information about all listed providers automatically, which may be helpful for registration purposes, for getting an overview about providers, or for looking up information about a specific provider, even if registration is closed.
• Why do you make in-band registration a requirement for a category A or B listing? XMPP Providers is a project made to simplify the users’ onboardings. Therefore, the criteria we use for the categorization are from a user’s perspective. This means users should be able to register directly from their XMPP client. Spam may be the most prominent reason to disable in-band registration, but that creates a barrier for newcomers.
• Why do I need to provide an extra file for XMPP Providers? We try to gather data automatically, but not all data is available in a machine-readable format. To reduce manual efforts until more data is available for automatic processing, we opted for a provider file containing additional information, which is hosted by individual providers. In the meantime, we continue to work on automating as much as possible.
• Why can I only get into category B and not into category A if my service is not free? We made this distinction to allow a completely automated registration without any user input. In the future, we would like to add payment and donation information.

Perspective

A year after introducing the provider file, more than 60% of the currently listed XMPP providers host such a file to offer additional information. We see this as a great success, since it helps to improve both transparency and quality of XMPP providers.

At the time of writing, about 60% of the 74 XMPP providers listed are category D providers. This is either due to closed registration, missing information, or both. We encourage all providers to offer a provider file to fill the missing information gap.

Furthermore, with the client monocles chat, now three active apps have integrated information from the XMPP Providers project.

Why Provider Categories?

The decentralized nature of the XMPP network allows for a wide variety of clients and servers. While the basic features might work in many cases, more advanced features might fail to work if a client or a server does not support the necessary feature set. On top of that, there can be servers configured with outdated settings or insufficient storage options, which may further degrade the experience.

Take for example file transfers: A provider offers file transfers via HTTP File Upload with up to 10 MB per file. Now there is a user trying to send a 12 MB file, but their client does not support alternative file transfer methods. In this case, the user cannot send their file via XMPP. While registering with their provider, the user might not be aware of potential limits or issues, which could be avoided otherwise.

To give newcomers the best possible experience, the XMPP Providers project groups providers into simple categories. Each category is based on a set of criteria a provider has to meet, and thus generalizes technical details into categories. This is the easiest way to offer newcomers a list of providers with little potential for frustration. Frustration during the first steps with a new service may turn users away from XMPP. That’s why frictionless onboarding and initial experience for first-time users is so important. But users don’t have to rely on categories alone. XMPP Providers offers plenty of details for tech-savvy users, which can be used to filter the list by further criteria.

Putting providers into categories may lead to conflicts, that’s true. Oftentimes providers can reach better categories by fixing configuration issues, and we are always glad to help where we can. There is an extensive FAQ with the most frequent configuration issues, and we offer a support chat for help with technical issues or related questions. Last but not least, categories give providers an incentive to improve their service for better first-time user experience.

Why Another Providers List?

There are many websites listing XMPP providers, ranging from wikis to user guides and personal websites. Many of them have a common problem: Information becomes stale. In order to have up-to-date information, they need a lot of manual maintenance. To avoid having to maintain a list manually, XMPP Providers builds on automation. As much of the data gathering and processing as possible has been automated. For data which cannot be gathered automatically, we are actively working on solutions.

Automating data processing and categorization needs transparency, accessibility, and good documentation to be sustainable. To reach these goals, and to improve the XMPP onboarding experience, we built the service around XMPP Providers with the following features in mind:

• an open-source interface which can be hosted by every interested party
• extensive service documentation
• offering automated and up-to-date information for listed providers, including categorization with soft and hard quality criteria
• helping to retrieve service information and support information beyond the registration process
• giving opportunities for providers to check and improve their service quality
• providing an API to include the list of providers in XMPP clients

While this project certainly leaves room for improvement, it’s a first step to make the registration process smoother and less error-prone. Providing a public service comes with great responsibility, and we would like to support service providers in that.

Remember: A rising tide lifts all boats!

The survey has been created with Formbricks.

Help the Project, Improve XMPP

For a good user experience, apps integrating XMPP Providers are as important as the providers themselves. If you are an XMPP developer, please consider adding XMPP Providers support to your app. If you are an operator of a public XMPP service, provide the information we need and add it to the list.

If you like to support XMPP Providers, please consider making a donation.

Feel free to reach out to us if you have any questions!

Spread the Word

The XMPP Providers project lives from the community and we are happy to hear your feedback. Follow us and spread the word!

XMPP Providers Logo

At Erlang Solutions, our support for the BEAM community is long-standing and built into everything we do. From contributing to open-source tools and sponsoring events to improving security and shaping ecosystem standards, we’re proud to play an active role in helping the BEAM ecosystem grow and thrive.

One way we’re putting that support into action is by offering free CI/CD-based security audits for open-source Erlang and Elixir projects. These audits help maintainers identify and fix vulnerabilities early, integrated directly into modern development workflows.

What the Free CI/CD Audits Offer

Our free CI/CD security audits for open source projects are powered by SAFE (Security Audit for Erlang/Elixir), a dedicated solution built to detect vulnerabilities in Erlang and Elixir code that could leave systems exposed to cyber attacks.

The CI/CD version of SAFE integrates directly into your development pipeline (e.g. GitHub Actions, CircleCI, Jenkins), enabling you to scan for vulnerabilities automatically every time code is committed or updated. This helps projects:

• Detect issues early, before they reach production
  
• Maintain a more secure and resilient codebase
  
• Improve visibility of risks within day-to-day workflows
  

Results are delivered quickly– typically within a few minutes. For larger codebases, it may take up to 20–30 minutes. The feedback is designed to be clear, actionable, and minimally disruptive.

Open source maintainers can request a free license by emailing safe@erlang-solutions.com and including a link to their repository. Once approved, we provide a SAFE license for one month or up to a year, depending on the project’s needs, at no cost.

For more information, read our full terms and conditions.

Expert-Led Audits for Production BEAM Systems

SAFE is just one way we help teams build secure, resilient systems. We also offer hands-on audit services for production systems, including:

• Code reviews focused on clarity, maintainability, and best practices
  
• Architecture assessments to help ensure systems are scalable and fault-tolerant
  
• Performance audits to identify bottlenecks and optimise how systems behave under load

These services are delivered by our in-house experts and are a great fit for teams working on complex or business-critical systems. They also pair well with SAFE for a full picture of how systems are running and how they could be even better.

Of course, supporting the BEAM community goes beyond security and audits. Our involvement spans education, events, and long-term ecosystem development.

“We’re proud to support the BEAM ecosystem not just with code, but with the infrastructure and insights that help it grow stronger,” says Zoltan Literati, Business Unit Leader at Erlang Solutions Hungary.

“Our free audits offer real, practical value to maintainers working in open source. It’s one of the ways we’re giving back to the community.”

A Broader Commitment to the BEAM Community

The BEAM ecosystem continues to grow across languages like Erlang, Elixir and Gleam, driven by a global community of developers, maintainers, educators and advocates. Erlang Solutions is proud to contribute across multiple fronts, including:

• Sponsoring various conferences, including Code Sync
• Supporting the Erlang Ecosystem Foundation (EEF), including participation in working groups focused on security, documentation, interoperability, and tooling
• Backing inclusion-focused initiatives such as Women in BEAM
• Sharing learning resources, contributing to open source libraries, and facilitating knowledge exchange through meetups, blogs and webinars
  

Our role is to support the ecosystem not only through expertise, but through action, and to help ensure that BEAM-based systems are not only scalable and reliable, but secure.

To learn more about our free CI/CD security audits or how we support the BEAM community, visit our community hub.

The post Supporting the BEAM Community with Free CI/CD Security Audits appeared first on Erlang Solutions.

Ever heard of XMPP Interop Testing? It’s this cool project that helps make sure different XMPP servers can all work together smoothly. Our XMPP Interop Testing project provides a suite of automated tests that can be integrated into CI/CD pipelines to verify the compliance and interoperability of XMPP server implementations.

Late last year, we reported that we had secured funding graciously provided by NLnet that allowed us to massively build out this project. This blog has been a bit quiet since then, but work has progressed. Significantly.

We have just released version 1.6.0 of all our test runners. With this release, we (again) more than doubled the total number of XMPP interop tests! By my count, our project now lets loose 933 tests on your XMPP server implementation!

The biggest chunk of work has gone into tests that verify parts of the basic XMPP protocol, notably for testing functionality that involves roster management (as specified in section 2 of RFC 6121) and for server rules for processing XML stanzas (section 8 of RFC 6121).

Additionally, a couple of new specifications are now being tested by our framework! Tests have been added for:

• XEP-0133: Service Administration
• XEP-0410: MUC Self-Ping (Schrödinger’s Chat)
• XEP-0421: Occupant identifiers for semi-anonymous MUCs
• XEP-0433: Extended Channel Search

This table gives a complete comparison of test coverage between versions 1.5.0 and 1.6.0.

To be clear: the work doesn’t end here. There is still significant improvement to be made (and we’ve not yet used up all of the grant either!) - we just liked to give you all an update. In the works are additional test implementations, and a couple of new test runners. That should both increase coverage, but also allow our tests to be executed on even more CI/CD platforms!

Please get in touch if you have any ideas for improvement, or other feedback. We’d love to hear from you!

• Splash image courtesy of Imagine Buddy, Unsplash

We have been working on some changes to our Debian/Ubuntu package repository. If you use our repository to keep up to date with new Prosody packages, you need to take action before 4th August 2025 to continue receiving updates smoothly.

New repository instructions

The ‘apt’ utility has been moving towards a new format for specifying package repositories. If you are familiar with putting deb lines in a sources.list file, that method is changing.

The new preferred format for package repository configuration, known as “deb822”, has a number of advantages. One of them is simplified configuration of additional package repositories such as ours.

The new configuration format is already supported in Debian 12 (bookworm) and Ubuntu 22.04 LTS (jammy), which means you can use it right now.

If you already have our package repository configured, simply remove it and use the new instructions to add our updated configuration.

Signing key update

The reason existing deployments should do this before the 4th August is because from that day, we will be rolling our repository signing key to a new key. The old key is being retired because it is using older and weaker algorithms which are being phased out.

If you do not update the repository configuration on your system, apt will complain that our repository is not signed by a trusted key (typically a NO_PUBKEY error).

Old key fingerprint:

107D65A0A148C237FDF00AB47393D7E674D9DBB5 (short version: 7393D7E674D9DBB5)

New key fingerprint:

AD3B912769C5F962DCBA7956F7A37EB33D0B25D7 (short version: F7A37EB33D0B25D7)

To ensure you are ready for the new key, remove the existing configuration for our repository from your system, and follow the new instructions to configure our repository.

Support and questions

If you have any questions about this change, we’re always happy to help answer them in our community chat. Come and join us!

After twenty-five years, XMPP (Extensible Messaging and Presence Protocol) is still here. Mature, proven, modular, and standardized, it may well be the most solid foundation available today to build the future of messaging.

And now, XMPP is more relevant than ever: its resurgence is driven by European digital sovereignty efforts, renewed focus on interoperability, and the growing need for long-term, vendor-independent infrastructure.

Against this backdrop, the recent funding round around XMTP (Extensible Message Transport Protocol), a newly launched blockchain-based protocol marketed as a universal messaging layer, raises questions. The name clearly evokes XMPP, yet there is no technological or community connection. And while XMPP could easily serve as a transport layer for blockchain-integrated messaging, XMTP chooses to ignore this legacy and start anew.

So the real question is:
Why rebuild from scratch when a solid, extensible foundation already exists?

A Protocol That Never Went Away

XMPP is an open protocol for real-time messaging, designed from the start for federation and decentralization. Standardized by the IETF (RFC 6120, 6121, 7622…), it has powered mission-critical systems for decades: enterprise communication, mobile apps at scale, online games, IoT control platforms.

What makes XMPP especially powerful is not just its architectural simplicity, but its modular extensibility. The protocol evolves through an ecosystem of open specifications (XEPs), covering:

• End-to-end encryption (OMEMO, OTR)
• Multi-device synchronization (Message Archive Management)
• Group chat with subscriptions (MUC and MUCSub)
• PubSub (XEP-0060) for real-time data and events
• Interoperability bridges (SIP, MQTT, Matrix)
• And more…

XMPP has never stopped evolving. Dozens of new extensions are proposed every year. It remains one of the most adaptable foundations for building secure, federated, and future-ready messaging systems.

XMTP: A New Protocol with a Familiar Name, but a Different Approach

XMTP is a blockchain-native messaging protocol developed by Ephemera. It aims to connect wallets and dApps, leveraging decentralized infrastructure (libp2p, IPFS-style storage) and cryptographic identities.

The ambition is clear: to build a censorship-resistant, peer-to-peer messaging layer for Web3, rooted in crypto-native identity and cryptography.

However, the naming is misleading. In an older interview, XMTP co-founder Matt Galligan said the name is a blend of SMTP and XMPP. It was chosen to evoke familiarity, perhaps even as a tribute. But the result is confusing: XMTP is not an extension, evolution, or even distant cousin of XMPP. There is no shared architecture, no interoperability, no community overlap.

Why This Matters Right Now

This naming issue would be minor if it weren’t happening at a critical time for protocol design. Governments, especially in Europe, are actively exploring how to regain control over digital infrastructure. Messaging is central to this effort, especially with upcoming interoperability mandates, data sovereignty requirements, and the need for long-term maintainability.

XMPP is uniquely well-positioned to meet these needs. It is mature, open, extensible, and governed through transparent standards. It has a community of engineers, operators, and developers actively maintaining and evolving it.

Instead of inventing closed messaging stacks around new ecosystems, the more pragmatic move would be to build on robust, extensible layers like XMPP:

• Need to integrate blockchain identities? XMPP can map public keys or wallet identifiers through custom namespaces or JIDs.
• Need cryptographic message-level guarantees? XMPP already supports message metadata, signatures, and encryption.
• Need better privacy ? XMPP can be run over privacy-preserving transports like Tor.

In short: XMPP can serve as a transport layer for Web3 communication without discarding two decades of protocol maturity.

I understand that the main focus of XMTP is to prevent censorship, but this really a situation that can be mitigated efficiently with XMPP. You can for example run your own server or develop a fully decentralized approach that you can leverage as needed (e.g. xmpp-overlay).

Yes, there is still work to be done. For example, integrating MLS (Messaging Layer Security) into XMPP would provide a strong foundation for interoperable, end-to-end encrypted group messaging. But that only reinforces the point: Why ignore what’s already working and extensible?

Use What Works

New ideas are always welcome. Innovation matters. But messaging protocols are infrastructure. Reinventing them lightly, is not harmless, especially when it is done without acknowledging existing efforts.

Instead of multiplying disconnected stacks, we should double down on what works.

XMPP is here. It works. It evolves. It can be extended, adapted, and integrated, even into blockchain-native systems, without sacrificing openness or interoperability.

That may be its most valuable trait today: Still standing, while so many overengineered protocols have come and gone.

Remote Patient Monitoring (RPM) is changing how care is delivered. By tracking health data through connected devices outside traditional settings, it helps clinicians act sooner, reduce readmissions, and focus resources where they’re most needed. With rising NHS pressures and growing demand for digital care, RPM is becoming central to how both public and private providers support long-term conditions, recovery, and hospital-at-home models. This guide explores how RPM works, where it’s gaining ground, and why healthcare leaders are paying attention.

What is Remote Patient Monitoring?

RPM refers to systems that collect patient data remotely using at-home or mobile devices, which clinicians then review. These systems can work in real time or at scheduled intervals and are often integrated with a patient’s electronic medical record (eMR) or practice management system (PAS). The goal is to monitor patients without needing in-person visits, while still keeping clinical oversight.

Devices Commonly Used in RPM

The success of any RPM programme depends on the devices that power it. These tools collect, track, and transmit key health data- either in real time or at regular intervals. Whether issued by clinicians or connected through a patient’s tech, they underpin the delivery of safe, responsive remote care.

These devices support the management of a wide range of conditions, including diabetes, heart disease, COPD, asthma, sleep disorders, high-risk pregnancies, and post-operative recovery.

These tools can either be prescribed by clinicians or integrated with consumer health tech like smartphones or smartwatches. 

For example, a cardiologist may use a mobile ECG app paired with a sensor to track arrhythmias from home.

Safety and Regulation

The boundary between wellness wearables and clinical devices is still being defined. While some tools simply gather data, others have therapeutic applications, such as managing pain or respiratory issues. This matters for compliance. Devices that influence treatment decisions must meet higher regulatory standards, particularly around safety, accuracy, and data security. Developers and suppliers need to stay aligned with MHRA or equivalent guidance to avoid risk to both patients and business continuity.

How Remote Patient Monitoring Works

RPM follows a structured process:

1. Data collection from connected medical devices
   
2. Secure transmission to a clinical platform
   
3. Integration with existing systems
   
4. Analysis and alerting via algorithms or clinician review
   
5. Intervention where thresholds are breached
   
6. Feedback to patients through apps or direct communication

RPM Adoption is Accelerating

Globally, the uptake of RPM is increasing. In the US, patient usage rose from 23 million in 2020 to 30 million in 2024 and is forecast to reach over 70 million by the end of 2025 (HealthArc). The NHS is also scaling digital pathways. Over 100,000 patients have been supported by virtual wards in England, with NHS England increasing capacity to 50,000 patients per month by winter 2024. RPM is central to this shift.

Core Technologies in RPM

These technologies work behind the scenes to capture, transfer, and make sense of patient data, so that clinicians have timely, accurate insights to act on.

Wearables and sensors
Track vital signs like heart rate, oxygen levels, and movement patterns.

Mobile health apps
Used by patients to report symptoms, manage medications, and receive support.

Telemedicine platforms
Enable direct communication between patients and clinicians through chat, phone, or video.

Analytics engines
Help identify risk trends or changes in condition using automated flagging systems.

Why RPM Matters for Healthcare Leaders

The NHS is under sustained pressure. According to the NHS Confederation, over 7.6 million people are currently on elective care waiting lists, while ambulance delays and A&E overcrowding persist. RPM supports care outside the hospital by freeing up beds, reducing readmissions, and improving patient flow. At a system level, RPM:

• Cuts avoidable admissions
  
• Shortens hospital stays
  
• Reduces time-to-intervention
  
• Frees up staff capacity
  
• Lowers infection risk
  

Cost savings are also significant. Some estimates suggest RPM can reduce total healthcare expenditure by 20–40%, particularly for chronic conditions.

RPM in Action: Key Use Cases

The real impact of RPM is seen in the way it supports different stages of the care journey. Here are some of the most common and most effective use cases.

Chronic Disease Management

RPM allows patients with diabetes, COPD, or hypertension to track metrics like blood pressure, oxygen levels or glucose and share results with care teams. Interventions can be made earlier, reducing the chance of deterioration or escalation.

Mental Health Monitoring

Wearables can capture signs of stress or low mood by tracking heart rate variability, sleep patterns, and daily activity. RPM helps clinicians spot early signs of relapse in conditions like anxiety and depression, particularly when patients are less likely to reach out themselves.

Post-Operative Recovery

Patients recovering from surgery can be monitored for wound healing, temperature spikes, or pain trends. A 2023 BMC Health Services Research study showed RPM helped reduce six-month mortality rates in patients discharged after heart failure or COPD treatment.

Elderly Care

For older adults, RPM supports safety without constant in-person contact. Devices with fall detection, medication reminders, and routine tracking can help carers respond quickly to changes, reducing emergency visits and supporting independent living.

Clinical Trials

RPM speeds up trials by reducing the need for travel, offering more continuous data, and improving patient adherence.

Pandemic and Emergency Response

During COVID-19, RPM enabled safe monitoring of symptoms like oxygen saturation or fever, supporting triage and resource allocation when systems were overwhelmed.

Benefits Across the System

RPM not only benefit patients, but it also improves outcomes and operations across every part of the health and care system. Here’s how you can gain from its use.

Where Tech Comes In

Behind every reliable RPM system is a reliable tech stack. In high-risk, high-volume environments like healthcare, platforms need to be built for stability, security and scalability. 

That’s why some platforms use programming languages such as Erlang and Elixir, trusted across the healthcare sector for their ability to manage high volumes and maintain uptime. These technologies are being adopted in healthcare systems that prioritise performance, security, and scalability. 

When built correctly, RPM infrastructure allows providers to:

• Maintain continuous monitoring across patient groups
  
• Respond quickly to emerging clinical risks
  
• Scale services confidently as demand increases
  
• Minimise risk from tech failure or data breach

To conclude

Patients recover better when they’re in a familiar place, supported by the right tools and professionals. Hospitals function best when their time and space are reserved for those who truly need them. Remote Patient Monitoring is not just a digital upgrade. It’s a strategic shift, towards smarter, more responsive care.

Ready to explore how RPM could support your digital care strategy? Get in touch.

The post What is Remote Patient Monitoring? appeared first on Erlang Solutions.

Release Highlights:

This release focus on integration in a wider federated network, with support for spam fighting features, better compliance with Matrix network and native support for PubSub Server Information to have your server count as part of the wider XMPP network (for example, you can register your server on XMPP Network Graph).

• Spam filter with block lists support
• Support for XEP-0485: PubSub Server Information
• Support for older Matrix rooms in ejabberd XMPP <-> Matrix Gateway

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

List of Contents:

• Workaround for zip module in unpatched Erlang
• Erlang/OTP 28 supported
• Erlang/OTP 25 required
• New mod_antispam with RTBL support
• New mod_pubsub_serverinfo
• Improvements in Matrix gateway
• XEP-0431: Full Text Search in MAM
• New rest_proxy options
• New auth_password_types_hidden_in_scram1 option
• New host_alias option
• New predefined keywords
• Link to Converse in WebAdmin
• Updates in source code formatting
• New target test-group
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.07 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Workaround for zip module in unpatched Erlang

A vulnerability was published three weeks ago that affects the zip library included in Erlang/OTP: CVE-2025-4748: Absolute path in zip module.

The ejabberd installers and the ejabberd container image already use a patched version Erlang/OTP 27.3.4.1, but the ecs container image uses Erlang/OTP 26.2.

ejabberd 25.07 includes a specific protection that workarounds that vulnerability regardless of what Erlang/OTP version you are using.

Erlang/OTP 28 supported

Updating ejabberd to support Erlang/OTP 28 has required quite some work due to the replacement of ancient ASN.1 modules from Erlang/OTP public_key library.

Improvements were done on ejabberd, fast_xml, p1_acme, xmpp libraries, and also rebar/rebar3 binaries were recompiled.

However, there is still one last problem not yet solved which implies that ACME support is broken when using Erlang/OTP 28.0.1. The fix will probably be included in the next Erlang/OTP 28 release.

Erlang/OTP 25 required

The minimum Erlang/OTP version supported since now is 25.0.

However, we are aware there are still a few specific cases where older Erlang/OTP versions are being used. For that reason, the source code support for those versions is still available, and static source code analysis tools like xref and dialyzer are still run with Erlang/OTP 20 in runtime.yml.

If you really need to use ejabberd with Erlang/OTP 20 - 24, you can bypass the version check during compilation with this ./configure option: ./configure --with-min-erlang=9.0.5

New mod_antispam with RTBL support

mod_antispam is a new module that filters spam messages and subscription requests received from remote servers based on Real-Time Block Lists (RTBL), text lists of known spammer JIDs and/or URLs mentioned in spam messages.

This module is based in mod_spam_filter which was originally published in ejabberd-contrib. If you were using that module, you can update your configuration and start using mod_antispam instead.

New mod_pubsub_serverinfo

mod_pubsub_serverinfo adds support for XEP-0485: PubSub Server Information to expose S2S information over the Pub/Sub service.

This module was originally published in ejabberd-contrib. If you were using that module, you can remove it, as now it&aposs included in ejabberd.

Improvements in Matrix gateway

While we are preparing another big update for the Matrix gateway. The most important change is that we added support to a larger number of room versions. It allows users to let them join a lot of rooms that were already created a while back and running an older version of the room protocol.

Here is the main list of changes to the matrix gateway:

• mod_matrix_gw: Support older Matrix rooms versions starting from version 4
• mod_matrix_gw: Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw: Fix key validation in mod_matrix_gw_s2s:check_signature
• mod_matrix_gw: When encoding JSON, handle term that is key-value list (#4379)

XEP-0431: Full Text Search in MAM

Support for XEP-0431: Full Text Search in MAM has been added. For now, it only works if mod_mam is using the MySQL storage backend.

New rest_proxy options

With those new options you can make modules using rest.erl module (like ejabberd_oauth_rest) use HTTP proxy when performing HTTP requests.

The related new top level options are:

• rest_proxy: Address of a HTTP Connect proxy
• rest_proxy_port: Port of a HTTP Connect proxy
• rest_proxy_username: Username used to authenticate to HTTP Connect proxy (optional)
• rest_proxy_password: Password used to authenticate to HTTP Connect proxy (optional)

New auth_password_types_hidden_in_scram1 option

This option was added to help with adding new password types in auth_stored_password_types option to existing installations. Adding new password type made server advertise it to clients, but that caused problems for users that didn&apost have new password type stored, and which clients used SASL1 authentication, if client tried to authenticate with it, authentications would fail.

With this new option, server admin can choose which password types should not be presented to SASL1 clients (they still will be offered to SASL2 clients for users that have password compatible with this type), to later after users update password to have new type, being able to enable them.

This option takes list of password types from auth_stored_password_types that should be disabled

auth_password_types_hidden_in_scram1:
  - scram_sha512
  - scram_sha256

New hosts_alias option

The new hosts_alias toplevel option is used by the ejabberd_http listener to resolve domain names into vhosts served by ejabberd.

For example, ejabberd is serving the vhost redacted.lan, but you configured DNS so xmpp.redacted.lan resolves to that host. If you configure in ejabberd:

hosts:
  - redacted.lan

hosts_alias:
  xmpp.redacted.lan: redacted.lan

listen:
  -
    port: 443
    ip: "::"
    tls: true
    module: ejabberd_http
    request_handlers:
      "/bosh": mod_bosh
      "/ws": ejabberd_http_ws
      "/conversejs": mod_conversejs

modules:
  mod_bosh:
  mod_conversejs:
    bosh_service_url: "https://xmpp.redacted.lan/bosh"
    websocket_url: "wss://xmpp.redacted.lan/ws"

then ejabberd_http will accept https://xmpp.redacted.lan/conversejs and deliver it to vhost redacted.lan

In previous ejabberd releases, an option called default_host was documented for the ejabberd_http listener, but it didn&apost work at all correctly.

New predefined keywords

A few months ago, ejabberd 25.03 introduced new predefined keywords like HOST, HOME, VERSION and SEMVER.

And now two more predefined keywords are added:

• CONFIG_PATH: Path to the configuration directory, for example "/home/ejabberd/opt/ejabberd/conf"
• LOG_PATH: Path to the log directory, for example "/home/ejabberd/opt/ejabberd/logs"

Those keywords are specially useful when configuring mod_antispam: you can copy text files to the configuration directory where the module will read them, and also configure the module to write the dump file on the log directory.

Link to Converse in WebAdmin

mod_conversejs has a new tiny improvement: it adds a link in the WebAdmin menu to the local Converse instance.

Additionally, when HTTPS with encryption is enabled, that link logins directly with the account used in WebAdmin.

Updates in source code formatting

A year ago, ejabberd 24.06 introduced make format and make indent.

Now that script uses Perl to work correctly in Mac OS too.

And there&aposs a new section in the documentation, see Format that describes how to use that feature, and tips for Git hooks and Git alias.

New target test-group

ejabberd includes a Common Test suite with 1456 test cases, which typically takes around 10 minutes to run.

When developing new source code, you may want to run only tests from a specific group and a specific storage backend, as documented in the ejabberd testing documentation:

CT_BACKENDS=mnesia rebar3 ct --suite=test/ejabberd_SUITE --group=antispam_single

To facilitate this usage, a new target is available:

CT_BACKENDS=mnesia make test-antispam_single

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Stefan Strigler and Holger Weiß for mod_antispam and the original mod_spam_filter
• Stefan Strigler for mod_pubsub_serverinfo and test-group target
• Bruno MATEU for the missing comma in postgres schema
• GiannosOB updated the Greek translation
• Tamil Neram updated the Tamil translation
• Максим Горпиніч updated the Ukrainian translation

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.

Monitoring

The following new metrics has been added to mod_mon:

• message_receive_packet: number of message stanzas of any type received by the server on c2s connections
• message_send_packet: number of message stanzas of any type send by the server on c2s connections
• iq_receive_packet: number of IQ stanzas received by the server on c2s connections
• iq_send_packet: number of IQ stanzas send by the server on c2s connections
• iq_get_receive_packet: number of IQ stanzas of type get received by the server on c2s connections
• iq_set_receive_packet: number of IQ stanzas of type set received by the server on c2s connections
• iq_result_receive_packet: number of IQ stanzas of type result received by the server on c2s connections
• iq_error_receive_packet: number of IQ stanzas of type error received by the server on c2s connections
• iq_get_send_packet: number of IQ stanzas of type get send by the server on c2s connections
• iq_set_send_packet: number of IQ stanzas of type set send by the server on c2s connections
• iq_result_send_packet: number of IQ stanzas of type result send by the server on c2s connections
• iq_error_send_packet: number of IQ stanzas of type error send by the server on c2s connections

The metrics c2s_receive & c2s_send now count all stanzas on c2s connections.

The cpu_usage probe now gives more reliable values.

Prometheus support has been improved.

A new mod_mon_dump command has been added to dump probe values to help debug the monitoring setup.r

Mobile push

It is now possible to use rest_proxy* options to use a HTTP proxy for mod_applepush & mod_gcm outgoing calls.

ChangeLog

This is a more complete list of changes in this ejabberd release:

Security fix

• ext_mod: Add temporary workaround for zip including absolute path

Compilation

• Raise the minimum Elixir tested version to 1.14.0 (#4281)
• Raise Erlang/OTP minimum requirement to 25.0 (#4281)
• configure.ac: Allow to specify minimal erlang version using --with-min-erlang
• Makefile.in: Add target test-<group>
• rebar3-format.sh: Replace csplit with perl
• Container: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4
• Installers: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4, libexpat 2.7.1, OpenSSL 3.5.1

Configuration and Tests

• Add rest_proxy* options to configure proxy used by rest module
• ejabberd_c2s: Add auth_password_types_hidden_in_scram1 option
• ejabberd_http: Remove unused default_host option and state element
• ejabberd_http: New option hosts_alias and function resolve_host_alias/1 (#4400)
• New predefined keywords: CONFIG_PATH and LOG_PATH
• Fix macro used in string options when defined in env var
• Use auxiliary function to get $HOME, use Mnesia directory when not set (#4402)
• ejabberd_config: Better lists:uniq substitute
• Tests: update readme and compose to work with current sw versions
• Update Elvis to 4.1.1, fix some warnings and enable their tests

Erlang/OTP 28 support

• Add workaround in p1_acme for Jose 1.11.10 not supporting OTP 28 ecPrivkeyVer1 (#4393)
• Bump fast_xml and xmpp for improved Erlang/OTP 28 support
• Bump xmpp and p1_acme patched with Erlang/OTP 28 support
• Fix make options in Erlang/OTP 28 (#4352)
• Fix crash in rebar3 cover with Erlang/OTP 28 (#4353)
• Rebar/Rebar3: Update binaries to work with Erlang/OTP 25-28 (#4354)
• CI and Runtime: Add Erlang/OTP 28 to the versions matrix

SQL

• Fix mnesia to sql exporter after changes to auth tables
• Update code for switching to new schema type to users table changes
• Add mssql specific implementation of delete_old_mam_messages
• Make delete_old_mam_messages_batch work with sqlite
• ejabberd_sm_sql: Use misc:encode_pid/1
• mysql.sql: Fix typo in commit 7862c6a when creating users table
• pg.sql: Fix missing comma in postgres schema (#4409)

Core and Modules

• ejabberd_s2s_in: Allow S2S connections to accept client certificates that have only server purpose (#4392)
• ext_mod: Recommend to write README.md instead txt (processone/ejabberd-contrib#363)
• ext_mod: Support library path installed from Debian (processone/ejabberd-contrib#363)
• ext_mod: When upgrading module, clean also the compiled directories
• gen_mod: Add support to prepare module stopping before actually stopping any module
• mod_antispam: Imported from ejabberd-contrib and improved (#4373)
• mod_auth_fast: Clear tokens on kick, change pass and unregister (#4397)(#4398)(#4399)
• mod_conversejs: Add link in WebAdmin to local Converse if configured
• mod_mam: Present mam full text search in xep-431 compatible way
• mod_mam_mnesia: Handle objects that don&apost need conversion in transform/0
• mod_matrix_gw: Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw: Support older Matrix rooms versions starting from version 4
• mod_matrix_gw: When encoding JSON, handle term that is key-value list (#4379)
• mod_matrix_gw_s2s: Fix key validation in check_signature
• mod_mix and mod_muc_rtbl: Support list of IDs in pubsub-items-retract (processone/xmpp#100)
• mod_pubsub_serverinfo: Imported module from ejabberd-contrib (#4408)
• mod_register: Normalize username when determining if user want to change pass
• mod_register: Strip query data when returning errors
• WebAdmin: New hooks webadmin_menu_system to add items to system menu

Full Changelog

https://github.com/processone/ejabberd/compare/25.04...25.07

ejabberd 25.07 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub.

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity.

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags.

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs. The alternative ejabberd container image is available in ghcr.io/processone/ejabberd.

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues.

In today’s interconnected world, digital sovereignty has become increasingly important for individuals and organizations seeking to maintain control over their data, infrastructure, and technologies. Openfire, an open-source, real-time collaboration (RTC) server that uses the XMPP (Extensible Messaging and Presence Protocol) protocol, offers a secure and customizable communication platform.

About Openfire

Openfire, produced by the IgniteRealtime community, is a mature, robust and scalable XMPP server that facilitates real-time communication and collaboration. It supports a wide range of features, including instant messaging, group chat, voice and video calls, and file sharing. Openfire’s open-source nature and extensive plugin architecture make it a versatile and customizable solution for organizations of all sizes. Openfire’s compatibility with various XMPP clients, including but not limited to IgniteRealtime’s own Pádè and Spark clients, further enhances its versatility and utility.

Data Privacy and Security

One of the key aspects of digital sovereignty is the ability to protect sensitive information and ensure data privacy. Openfire provides a secure communication platform that supports end-to-end encryption, secure authentication, and fine-grained access control. By hosting Openfire in-house or on a private cloud, organizations can maintain control over their communication data and reduce the risk of data breaches or unauthorized access. Additionally, Openfire’s open-source nature allows users to audit the code and verify the security of the platform, further enhancing trust and transparency.

Customization and Flexibility

Openfire offers a high degree of customization and flexibility, enabling organizations to tailor the platform to their specific needs and requirements. With a wide range of plugins and extensions, Openfire can be easily integrated with existing systems and workflows, allowing users to create a communication environment that aligns with their unique processes and preferences. This enables organizations to maintain control over their communication tools and adapt them to their evolving needs.

Compliance and Regulatory Control

Openfire’s customizable and secure nature makes it an ideal platform for organizations operating in regulated industries or jurisdictions with strict data protection laws. By hosting Openfire in-house or on a private cloud, organizations can ensure that their communication data remains within their control and complies with relevant regulations. Furthermore, Openfire’s extensive logging and monitoring capabilities enable users to demonstrate compliance and maintain a clear audit trail of their communication activities.

Interoperability with Other XMPP Solutions

Openfire’s interoperability with other XMPP-based platforms and clients is another significant advantage. By supporting the XMPP protocol, Openfire enables seamless communication and collaboration with users on other XMPP servers and clients, fostering a decentralized and open communication ecosystem. This interoperability allows organizations to maintain control over their communication infrastructure while still being able to connect and collaborate with external partners, customers, or stakeholders. Moreover, Openfire’s compatibility with other XMPP solutions reduces the risk of vendor lock-in and promotes a more open and competitive market for communication tools.

Conclusion

Openfire offers a powerful and secure communication platform that supports digital sovereignty by enabling organizations to maintain control over their data, infrastructure, and technologies. With its robust security features, customization capabilities, compliance-friendly nature, and interoperability with other XMPP solutions like Pádè and Spark, Openfire empowers users to create a communication environment that aligns with their unique needs and requirements. As digital sovereignty continues to gain importance in today’s interconnected world, Openfire provides a valuable solution for organizations seeking to enhance their autonomy, privacy, and security in digital interactions.

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of June 2025.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before August 17th, 2025 00:00 UTC.

XMPP Events

• DebConf25: The 26th Debian Conference in Brest, France, from July 14th to 19th 2025, will feature:
  • Federated instant messaging, 100% debianized by Elena Grandi. A short talk (20 minutes) that will take place at the Grand amphi room on Monday, July 14th at 18:00 hours.
  • Jabber/XMPP BoF session, hosted by Martin. A BoF (Birds of a Feather) meeting (45 minutes) that will take place at ‘Room: B03-035’ on monday July 14th at 14:00 hours.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM UTC+2 (online event, with web meeting mode and live streaming).

Videos

Comunicación Libre, Segura y Descentralizada: Taller abierto de XMPP by Gnuxero for the Club de Software Libre. [ES]

XMPP Articles

• Introducción a XMPP - Capítulo 1 by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 2 - OMEMO by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 3 - Grupos by Jacobo Da Riva Muñoz. [ES]
• Mensajería segura y abierta mediante CONVERSATIONS Xmpp on alt43.es. [ES]
• Recuperando a soberania e a privacidade da sua comunicação pessoal e corporativa by Isadora Ribeiro. [PT_BR]
• Mitigating MITMs in XMPP by Amolith for the JMP Blog.
• Setting up Slidge Gateway with Openfire for use with Whatsapp, Matrix and Telegram by surfbum for the Ignite Realtime Community.
• Per-application passwords in Tigase from the Tigase Posts.
• Join the XMPP-IT Community: Your Help Matters! The XMPP-IT community is launching a call for active collaboration — no need to be an expert, and it’s not paid work, just shared participation. From translations to testing software, writing wiki content or contributing code, there’s room for everyone. [IT]

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-2 for Android.
• Converse.js has released version 11.0.1 of its open-source and web-based XMPP chat client. The desktop version can be downloaded from here. Make sure to check out the release link for all the details!
• Gajim has released version 2.3.0 (2.3.1 and 2.3.2) with a fresh new look featuring Adwaita, adding new features, improvements, quite a few changes and bug fixes. Head over to their news section for more information. And don’t forget to read the changelog for all the details!

Gajim’s 2.3.0 sleek fresh new look featuring Adwaita

• Libervia has received NLnet funding to ‘Implement serverless (with RELOAD) and reduce metadata exposure’ (Serverless and Metadata Reduction for XMPP). This project will reduce metadata exposure and enable decentralized, serverless communication. Work will focus on end-to-end encryption specs for roster (contact list) information. These changes will be implemented in the Libervia ecosystem through Tor integration, which will help anonymize connections and reduce IP tracking. A second focus area is advancing serverless communication by implementing the RELOAD protocol XEP-0415 and leveraging end-to-end authentication via XEP-0416 and XEP-0417. This project will strengthen XMPP and Libervia’s privacy and availability, enabling their use in environments where servers may be unavailable or inaccessible.
• Monocles has released versions 2.0.8, 2.0.9, 2.0.10 and 2.0.11 of its chat client for Android, featuring many new functions and fixes.
• Prose has released versions 0.10.2 and 0.11.0 of its web frontend prose-web-app.

XMPP Servers

• The Ignite Realtime community is thrilled to announce the release of the latest versions of their popular open-source XMPP server. Openfire 5.0.0 just came out, immediately followed by Openfire 5.0.1 which should be its drop-in replacement. The new releases come packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. You can download Openfire 5.0.1 straight from the website and read the documentation to get started. Don’t forget to check out the changelog for a list of all the changes that have been made!
• MongooseIM has released version 6.4.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.

XMPP Libraries & Tools

• go-xmpp versions 0.2.15 and 0.2.16 have been released.
• peertube-plugin-livechat versions 13.0.0 and 14.0.0 have been released.

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.

• Data Policy
  • This document specifies metadata on how an entity handles its data (encryption, data retention, etc).
• Data Forms File Input Element
  • This specification defines an element which can be used with data forms to let users upload one or more files.

New

• No New XEPs this month.

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.

• No XEPs deferred this month.

Updated

• Version 0.1.4 of XEP-0284 (Shared XML Editing)
  • Fix the registrar section.
  • Format the glossary better.
  • Add missing <state/> wrappers in examples.
  • Write an XML Schema. (egp)
• Version 0.9.0 of XEP-0384 (OMEMO Encryption)
  • Device labels must be signed
  • Allow empty device list in XML schema
  • Reworded security consideration that could be interpreted as forbidding trust mechanisms like BTBV/TOFU
  • Added section about dealing with lack of presence subscription
  • Removed reference to omemo-session-healing (th)
• Version 1.0.3 of XEP-0388 (Extensible SASL Profile)
  • Add missing minOccurs=‘0’ to additional-data in <continue/> in XML schema. (lnj)
• Version 0.1.1 of XEP-0485 (PubSub Server Information)
  • Fixed references to XEP identifier. (gdk)
• Version 0.1.1 of XEP-0498 (Pubsub File Sharing)
  • Fix wrong shortname and add tags. (jp)

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.

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

Also check out our RSS Feed!

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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• German: xmpp.org
  • Translators: Millesimus
• Italian: notes.nicfab.eu
  • Translators: nicola
• Portuguese: xmpp.org
  • Translators: Paulo
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi

Help us to build the newsletter

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

XSF Fiscal Hosting Projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

In January 2007, Ignite Realtime released the red5 plugin for Openfire which added the flash based open source Red5 media server as a plugin to Openfire (Wildfire). A year later, we added red5Phone, the first open source SIP based soft phone in a web browser.

Eighteen years later, WebRTC is now well established as the leading standard for audio and video conferencing and all that leading edge pioneer work here at Ignite evolved into Pàdé the web client, it’s supporting Openfire plugin and other plugins and clients supporting other audio and video use cases beyond meetings.

XMPP is now back in fashion and Openfire has always been a choice XMPP solution because it has the X factor. It is eXperienced, eXtensible, fleXible, eXperimental and eXciting and allowing use to easily integrate it with a wider diversity of signalling and media protocols and services.

However, the new attraction for XMPP is the push for open standards and messaging interoperability. Consequently, being able to also provide media (audio and video) interoperability in XMPP through Openfire will become one of the things we choose to focus on at Ignite going forward with audio and video communications. As previously hinted, we are moving forward with simplified, easy to maintain open standards that make media interoperability possible.

For now, that will be Online Meetings for audio and video conferencing services that have a web front end UI like Jitsi, Galene and BroadcastBox. For deeper integration into XMPP, that will be the Media Streams which is the XMPP wrapper to WHIP and WHEP.

In practice, it means development will stop on the Pade plugin for Openfire and all Jitsi based development and integration will only continue with Openfire Meetings plugin (ofmeet) which will become XEP 483 compliant. The Galene plugin for Openfire will also become XEP 483 compliant and both plugins can serve the new Online Meetings plugin for in ConverseJS web client.

The Openfire plugin called Ohun for audio conferencing is deprecated and a new plugin called OrinAyo which supports both music streaming and audio conferencing is in development and will become available very soon.

For other release announcements and news follow us on Mastodon or X

2 posts - 2 participants

Read full topic

Openfire 5.0.1 has been released!

Openfire, created by the Ignite Realtime community is a powerful chat server that lets you communicate in real-time with your team or friends. It’s like having your own private messaging solution, but with more control and customization options.

Following the release of Openfire 5.0.0 last week, a few annoying issues were reported. These are addressed in this new release:

• The Windows Launcher works again
• The bundled ‘search’ plugin is updated to address an issue in the admin console
• Certificate-based authentication can be used again with client connections
• Improvements were applied to the detection of invalid (‘ghost’) group chat users that originate from federated domains.
• The Admin Console translations for the French and Dutch languages got a significant update. Many thanks to the community members that provided those translations!

This update should be a drop-in replacement for version 5.0.0. You can find the installers in the usual places, like our Downloads page!

The 5.0.1 release of Openfire is a direct result of receiving contributions and feedback from the community. Keep it coming! As you can see, your effort, no matter how big or small, can have a direct result! Please join our community forum or group chat and let us know what you think!

Finally: GitHub appears to claim that this is our 100th release of Openfire/Wildfire. We’re not at all sure that’s an accurate count, but we’ll take the opportunity to celebrate anyway! Come join the celebrations in our chatroom! The fiftieth person to join wins a no-expenses-paid day trip to the nearest park bench!

For other release announcements and news follow us on Mastodon or X

1 post - 1 participant

Read full topic

Slidge is an XMPP gateway designed to connect your account to third-party chat networks like WhatsApp, Telegram, or Matrix. It acts as a bridge, allowing you to send and receive messages with all your contacts directly from your single, preferred XMPP client.

This guide provides instructions to configure an Openfire XMPP server to work with Slidge and the Slidge WhatsApp plugin as an example.

Openfire requires configuration in its Admin Console to allow external components like Slidge to connect and to grant them the necessary permissions for features like file transfers.

Prerequisites

Before you begin, ensure you have:

• A running and accessible Openfire server.
• Administrative access to the Openfire Admin Console.
• Root or sudo access to the Debian/Ubuntu server where you will install Slidge.
• The Slidge Debian repository added to your system, as per the official Slidge installation instructions (Installation - Slidge documentation).

This guide used the below install method.

• (https://codeberg.org/slidge/debian)

Step 1: Configure Openfire Services

You must configure Openfire to accept the bridge connection and handle file transfers before you configure Slidge.

1.1. Install and Configure HTTP File Upload Plugin

Slidge requires a working XEP-0363 HTTP File Upload component to send and receive images, videos, and other files.

• Log in to your Openfire Admin Console.
• Navigate to Server → Plugins → Available Plugins.
• Find the plugin named “HTTP File Upload” and click the green + icon to install it.
• After installation, navigate to Server → Server Settings → HTTP File Upload.
• Ensure the box for “Enable HTTP File Upload” is checked.

Take note of the configuration. For a standard setup behind a reverse proxy, your public URL might be https://upload.your.domain while the internal service address is httpfileupload.your.domain.
We will use this internal address later.

• Click Save Settings.

1.2. Enable External Component Connections

This step allows Openfire to listen for incoming connections from bridges.

In the Openfire Admin Console, navigate to Server → Server Settings → External Components.

• Ensure the service is Enabled.
• Under the “Allowed to Connect” section, define your new WhatsApp bridge:
• Subdomain: whatsapp (This will create the JID whatsapp.your.domain).
• Shared Secret: Create a new, strong, random password.
• Copy this shared secret to a safe place. You will need it for the Slidge configuration.
• Click “Add”.

Your Openfire server is now ready for Slidge.

Step 2: Install and Configure Slidge

Now, on your server’s command line, we will install and configure the Slidge packages.

2.1. Install Slidge Packages

As per these instructions: slidge/debian: Debian (unofficial) package bundling slidge-based gateways. - Codeberg.org

2.2. Configure common.conf

This file contains settings shared by all your bridges.

• Edit the file: nano /etc/slidge/conf.d/common.conf
• Set the following parameters:

  admins=admin@your.domain
  upload-service=httpfileupload.your.domain
  user-jid-validator=.*@your.domain
  server=localhost
  #port=5347 #(default slidge setting)
  port=5275 #(openfire default)
  

2.3. Configure whatsapp.conf

This file contains the settings for the WhatsApp bridge specifically.

• Create or edit the file: nano /etc/slidge/whatsapp.conf
  (I just did mv /etc/slidge/whatsapp.conf.example /etc/slidge/whatsapp.conf)
• Add the connection details to match what you configured in Openfire:

  # The XMPP address of your bridge component
  jid = whatsapp.your.domain
  # The shared secret you created in the Openfire admin console
  secret = PASTE_YOUR_SHARED_SECRET_HERE
  legacy-module=slidge.plugins.whatsapp
  

Step 3: Start and Verify Slidge

Enable and start the Slidge WhatsApp service:

sudo systemctl enable --now slidge@whatsapp

Check the logs to ensure it started without errors:

sudo journalctl -u slidge@whatsapp -f

Step 4: User Registration and Login

From your XMPP client (e.g., Conversations, Gajim), discover the services on your server. You should see the “WhatsApp” bridge listed.

Register with the service.

The bridge (whatsapp.your.domain) will be added to your contacts. Send it the message login or qr.

(I just started a conversation with a new chat to whatsapp.you.domain and typed help, it gives a list of commands, follow these e.g register)

You may see warnings in the Slidge log about “IQ privileges not granted” for pubsub and bookmarks (XEP-0356).

Troubleshooting: Fixing Permission Warnings (not yet implemented in Openfire so can’t fix this just yet)

For good luck I also did this at the end.

sudo systemctl restart openfire
sudo systemctl restart slidge@whatsapp

3 posts - 2 participants

Read full topic

Say hello to Márton Veres, our new Business Unit Leader for London.
From international consulting to leading delivery teams, Márton’s journey to this role has been anything but ordinary. In our latest team interview, he shares what excites him most about this next chapter, his vision for growing our presence in London, and a personal challenge he’s set for the summer.

Get to know Márton and his take on leadership, community, and what’s ahead.

Congratulations on your new role as Business Unit Leader (BuL) for London. Could you share more about your new role at Erlang Solutions?

Thanks! I’m proud to take on the BuL role after four years in project and delivery management here. I’ll be leading the London team, shaping and executing our business strategy, and driving growth through client relationships and new opportunities.

 I’m looking forward to working more closely with our UK colleagues, connecting with the Erlang and Elixir communities, and strengthening our presence in the London market.

What have been some highlights of your career so far?

My journey has always been at the intersection of business and technology. I spent my first eight years as an IT consultant in FinTech and Telco, helping align business needs with tech solutions. Then, I led project management teams at Deutsche Telekom for eight years, gaining deep experience in large-scale delivery. 

At Erlang Solutions, I’ve worked alongside brilliant engineers on cutting-edge Erlang and Elixir projects. The mix of consulting, corporate, and agile tech environments has given me a well-rounded perspective that I bring into this new role.

What are you most looking forward to in your new position?

I’m especially excited to deepen our work in London’s FinTech, Digital Health, and Energy sectors. I’m passionate about supporting and growing our team using servant leadership and business coaching skills I’ve developed, including through a recent certification programme supported by Erlang Solutions. 

Digital Health is a particular interest of mine, and I’d love to expand on the work we’ve done with the NHS, HCA Healthcare, and Baxter. Being part of the Trifork Group also opens up opportunities to collaborate on end-to-end solutions, especially with their Digital Health expertise.

Outside of work, what are you most excited about this summer in London?

I’m training for the Wimbledon Half Marathon in September. My goal is to finish in under two hours! It’s a great way to stay focused and make the most of the summer. Balancing work and personal goals like this keeps me energised.

Final thoughts

It’s been a pleasure catching up with Márton and hearing about his journey, leadership vision, and what’s ahead for the London team. His story is a great reminder of the passion and purpose that drive our work at Erlang Solutions.

We’ll be sharing more team stories soon. So keep an eye out for the people behind the projects. If you’d like to connect with Márton or anyone on our team, we’d love to hear from you.

The post Meet the Team: Márton Veres appeared first on Erlang Solutions.

We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

The changelog lists all of the changes that have been made.

We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

Here’s to the future of real-time communication with Openfire 5.0.0!

For other release announcements and news follow us on Mastodon or X

40 posts - 14 participants

Read full topic

It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

• We’ve dropped support for Java 11. The minimum requirement is Java 17 now
• The embedded web server has received a major upgrade
• Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

We are looking for your help!

Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org.

Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org) to see if there are any issues.

You can obtain the beta from our download page for beta releases or from the GitHub Releases page.

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat. We are always looking for volunteers interested in helping out with Openfire development!

For other release announcements and news follow us on Mastodon or X

11 posts - 7 participants

Read full topic

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of May 2025.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XMPP Events

• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• The XMPP Sprint in Berlin took place during the 23rd-25th of May 2025. Developers from Germany, France & the United Kingdom representing Conversations, Dino, ejabberd, Kaidan, LiveDashboard, Macaw, Monal, Renga, and Prose gathered to make it happen! The sprint was sponsored by the XSF, Ammonit Measurement GmbH, and Wikimedia e.V..

A still from the XMPP Sprint in Berlin, May 2025

Videos

• Goffi, from Libervia, published a short progress overview of the new web frontend design on the Libervia video channel.

Talks

• On Friday, May 16, Vril hosted the Workshop di XMPP e Free Software all’AntiBiennale di Venezia (a workshop on XMPP and free software) at Cabasego, in Venice, Italy. The whole workshop lasted around one and a half hours and the slides are freely available for you to check out. The event took place in a most beautiful house, incredibly located in the center of Venice, inhabited by people who are always willing to leave their door open to Venice’s underground communities. [IT]

XMPP Articles

• El gran lío de la mensajería instantánea by Jacobo Da Riva Muñoz. [ES]
• Monocles, the project responsible for the XMPP Monocles chat Web and Android clients, started a crowdfunding campaign. The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from March 28 to June 30.
• XMPP is now featured on the list of the ‘Delightful Lists’.
• Towards a Password-Mukt XMPP for some thoughts and fantasies by Badri (Hippo) on how passwordless XMPP login could be achieved, either via an out-of-band mechanism or by authorizing from an already logged-in client.
• XMPP packages coming with Debian 13 as the freeze toward next stable Debian (13 or Trixie) has been engaged, an overview of the XMPP clients, servers and librairies coming with it is provided in this article from the Debian XMPP Team.

XMPP Software News

XMPP Clients and Applications

• Converse.js has released version 11.0.0 of its open-source and web-based XMPP chat client. The Desktop version can be downloaded from here. This release comes packed full of bugfixes, changes and new features. Way too many to list in here. Make sure to check out the release link for all the details!

Converse 11

• Gajim has released version 2.2.0. This release brings three new features: message retraction (via XEP-0424: Message Retraction), blocking participants in group chats, and updated support for modern group chat avatars (via XEP-0486: MUC Avatars), among many other improvements and bugfixes. Head over to their news section or check the changelog for all the details.
• Monal has released version 6.4.11 for iOS an macOS.
• Monocles Chat 2.0.7 for Android, has been released. This version brings fixes for lagging, pinned status message, I2P and more.
• Prose has released versions 0.10.1 of its web frontend prose-web-app.

XMPP Servers

• Prosody IM is pleased to announce version 13.0.2. This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well. Read all the details on the release changelog. As always, detailed download and install instructions are available on the download page for your convenience.

XMPP Libraries & Tools

• Pade plugin version 1.8.4 for Openfire has been released.
• peertube-plugin-livechat version 12.0.4 has been released.
• python-nbxmpp version 6.2.0 has been released.
• strophejs version 3.1.1 has been released.

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.

• No XEPs proposed this month.

New

• No New XEPs this month.

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.

• No XEPs deferred this month.

Updated

• No XEPs updated this month.

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.

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Lemmy instance (unofficial)
• Reddit (unofficial)
• XMPP Facebook page (unofficial)

Also check out our RSS Feed!

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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus

Help us to build the newsletter

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

XSF Fiscal Hosting Projects

The XSF offers fiscal hosting for XMPP projects. Please apply via Open Collective. For more information, see the announcement blog post. Current projects you can support:

• Mellium Co-op
• Bifrost bridge
• Prav
• diasp.in

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale. 

This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

The risks of rushing your tech stack decisions

Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

Common examples of early tech shortcuts

• Choosing tools based on ease rather than long-term fit
• Using third-party services without proper integration planning
  
• Avoiding proper system design to save time
  
• Stacking too many frameworks or libraries to plug gaps quickly
  
• Skipping documentation, testing, or version control in the name of speed
  

What could go wrong?

Here are some of the common risks that come with rushing tech stack choices:

The business cost of technical shortcuts

They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

The long-term cost of technical debt

We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

Let’s break down the long-term impact:

The hidden costs of technical debt

A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

When it gets out of control

Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

Here are a few real-world scenarios:

• Legacy overload: Systems running well past their intended lifespan, no longer supported or secure.
  
• Integration failure: Poorly connected tools and services that don’t talk to each other, slowing everything down.
  
• Scaling bottlenecks: Infrastructure so rigid that every new feature or user pushes it closer to breaking point.
  

Security crises: Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

What startups can do about it:

You can’t avoid technical debt entirely, but you can manage it by:

• Prioritising clean, maintainable code from day one
  
• Setting time aside for refactoring and testing
  
• Regularly reviewing architecture decisions
  
• Choosing tools that support long-term scalability, not just quick wins
  

Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

Why scalability matters from day one

Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

60% of startups face major scalability issues within their first three years (McKinsey). These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

Here’s why it’s critical to get it right from the start:

1. Scaling later is harder and more expensive

Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

2. Maintainable code accelerates growth

Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

3. Users don’t tolerate failure

Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

4. Bad tech choices can limit your future

Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late. Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

Doing it Right from the start: In practice

Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

1. Prioritise Root Cause

 Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

2. Adopt Agile

Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

3. Write Clean, Modular Code

Keep code simple and flexible. Use modular design to evolve without costly rewrites.

4. Test Early

Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

5. Review Regularly

 Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

6. Choose the Right Tech

Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

7. Document Clearly

Keep documentation up to date to help teams understand decisions and onboard new members fast.

8. Don’t skip security checks

It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir), helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises. 

Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

Balancing speed and quality without overengineering

Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding.

Build now, avoid startup tech mistakes later

Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk.

The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions.

We are pleased to announce a new minor release from our stable branch.

This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well.

A summary of changes in this release:

Fixes and improvements

• mod_storage_internal: Fix queries with only start returning extra items
• mod_invites_register: Stricter validation of registration events

Minor changes

• MUC: Ensure allow MUC PM setting has valid value (fixes #1933: PM does not work on new MUCs)
• mod_storage_sql: Delay showing SQL library error until attempted load
• mod_storage_sql: Handle failure to deploy new UNIQUE index
• mod_storage_sql: Add shell command to create tables and indices (again)
• mod_s2s: Fix log to use formatting instead of concatenation (fixes #1461: Logging issues uncovered by mod_log_json)
• modulemanager, util.pluginloader: Improve error message when load fails but some candidates were filtered
• prosodyctl check config: add recommendation to switch from admin_telnet to shell
• mod_storage_sql: Retrieve all indices to see if the new one exists
• prosodyctl check config: List modules which Prosody cannot successfully load
• net.http.files: Fix issue with caching
• util.jsonschema: Fix handling of false as schema
• mod_invites: Consider password reset a distinct type wrt invite page
• configmanager: Emit config warning when referencing non-existent value
• mod_admin_shell: Add role:list() and role:show() commands
• MUC: Fix nickname registration form error handling (#1930)
• MUC: Fix Error when join stanza sent without resource (#1934)
• MUC: Factor out identification of join stanza
• mod_invites_register: Don’t restrict username for roster invites (thanks lissine)
• mod_admin_shell: Fix matching logic in s2s:close (Thanks Menel)
• mod_authz_internal: Improve error message when invalid role specified
• mod_http_file_share: Add media-src ‘self’ to Content-Security-Policy header
• mod_admin_shell: Visual tweaks to the output of debug:cert_index()
• mod_http: Log problems parsing IP addresses in X-Forwarded-For (Thanks Boris)
• mod_http: Fix IP address normalization (Thanks Boris)
• util.prosodyctl.check: Improve reporting of DNS lookup problems

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!

Debian 13 "Trixie" full freeze has started 2025-05-17, so this is a good time to take a look at some of the features, that this release will bring. Here we will focus on packages related to XMPP, a.k.a. Jabber.

XMPP is a universal communication protocol for instant messaging, push notifications, IoT, WebRTC, and social applications. It has existed since 1999, originally called "Jabber", it has a diverse and active developers community.

Clients

• Dino, a modern XMPP client has been upgraded from 0.4.2 to 0.5.0
  Dino now uses OMEMO encryption by default. It also supports XEP-0447: Stateless File Sharing for unencrypted file transfers. Users can now see preview images or other file details before downloading the file. Multiple widgets are redesigned to be compatible with mobile devices, e.g. running Mobian.
• Gajim, a GTK+-based Jabber client has been upgraded from 1.7.3 to 2.1.1
  There are many new features in Gajim, e.g. XEP-0444: Message Reactions, XEP-0461: Message Replies, XEP-0425: Moderated Message Retraction, XEP-0490: Message Displayed Synchronization, voice message recording, migration to GTK 4, and a lot of UI changes.
• go-sendxmpp, a CLI tool to send messages to contacts or MUCs: 0.5.6 → 0.14.1
  New features are support for sending XEP-0066: Out of Band Data and support for several modern authentication features (XEP-0388: Extensible SASL Profile, XEP-0386: Bind 2, XEP-0484: Fast Authentication Streamlining Tokens). New support of modern SCRAM mechanisms (SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-515(-PLUS)) and SASL SCRAM Downgrade Protection (XEP-0474: SASL SCRAM Downgrade Protection) improve the security of the login process. Also a lot of bugfixes and smaller improvements found their way to the new version, for details see the changelog.
• Kaidan, a simple and user-friendly Jabber/XMPP client is upgraded from 0.8.0 to 0.12.2
  Kaidan supports end-to-end encryption via OMEMO 2, Automatic Trust Management and XMPP Providers. It has been migrated to QT 6 and many features have been added: XEP-0444: Message Reactions, XEP-0461: Message Replies, chat pinning, inline audio player, chat list filtering, local message removal, etc.
• Libervia is upgraded from 0.9.0~hg3993 to 0.9.0~hg4352
  Among other features, it now also contains a gateway to ActivityPub, e.g. to Mastodon.
• Poezio, a console based XMPP client as been updated from 0.14 to 0.15.0
  Better self-ping support. Use the system CA store by default.
• Profanity, a console based XMPP client has been upgraded from 0.13.1 to 0.15.0.
  Add support for XEP-0054: vcard-temp, Improve MAM support, show encryption for messages from history and handle alt+enter as newline char.
• Psi+, a QT based XMPP client (basic version) has been upgraded from 1.4.554 to 1.4.1456
• xmpp-dns, a CLI tool to check XMPP SRV records: 0.3.4 → 0.4.5
  It now supports showing connection targets defined by XEP-0156: Discovering Alternative XMPP Connection Methods/XEP-0487: Host Meta 2 - One Method To Rule Them All and testing of XEP-0206: XMPP Over BOSH and Websocket connections. A detailed list of changes can be found in the changelog.

Servers

• ejabberd, an extensible realtime platform (XMPP server, MQTT broker, SIP service) has been updated from Version 23.01 to 24.12
  Add support for XEP-0425: Moderated Message Retraction, XEP-0402: PEP Native Bookmarks, and XEP-0424 Message Retraction.
• Prosŏdy, a lightweight extensible XMPP server has been upgraded from 0.12.3 to 13.0.1
  Admins can disable and enable accounts as needed. A new role and permissions framework. Storage and performance improvements.

Libraries

• libomemo-c 0.5.0 to 0.5.1
• libstrophe, an XMPP library in C has been upgraded from 0.12.2 to 0.14.0
  It now supports XEP-0138: Stream Compression and adds various modern SCRAM mechanisms.
• omemo-dr, an OMEMO library used by Gajim is now in Debian, in version 1.0.1
• python-nbxmpp, a non blocking Jabber/XMPP Python 3 library, upgrade from 4.2.2 to 6.1.1
• python-oldmemo, a python-omemo backend for OMEMO 1, 1.0.3 to 1.1.0
• python-omemo, a Python 3 implementation of the OMEMO protocol, 1.0.2 to 1.2.0
• python-twomemo, a python-omemo backend for OMEMO 2, 1.0.3 to 1.1.0
• qxmpp 1.4.0 to 1.10.3
• slixmpp-omemo new 1.2.2
• slixmpp 1.8.3 to 1.10.0
• strophejs, a library for writing XMPP clients has been upgraded from 1.2.14 to 3.1.0

Gateways/Transports

• Biboumi, a gateway between XMPP and IRC, upgrades from 9.0 to 9.0+20241124.
• Debian 13 Trixie includes Slidge 0.2.12 and Matridge 0.2.3 for the first time! It is a gateway between XMPP and Matrix, with support for many chat features.

Not in Trixie

• Spectrum 2, a gateway from XMPP to various other messaging systems, did not make it into Debian 13, because it depends on Swift, which has release critical bugs and therefore cannot be part of a stable release.