Welcome to the latest edition of your pseudo-monthly JMP update! (it’s been 7 months since the last one 😨)
In case it’s been a while since you checked out JMP, here’s a refresher: JMP lets you send and receive text and picture messages (and calls) through a real phone number right from your computer, tablet, phone, or anything else that has a Jabber client. Among other things, JMP has these features: Your phone number on every device; Multiple phone numbers, one app; Free as in Freedom; Share one number with multiple people.
Alerts for incoming messages blocked by Original route
The partner that serves our Original route has for some time been censoring some incoming messages, meaning messages from friends and family to you might occasionally be blocked. We have finally managed to get them to tell us when this happens and so we now relay an alert to you, so you can know this has happened and ask your contact to try rewording their message. Reminder that we do offer other routes for those having issues with this. Contact support if this interests you.
(e)SIM nicknames
If you have multiple (e)SIMs through JMP, keeping track of which is which by its ICCID can be a pain. Now you can give each a nickname by opening commands with the bot, tapping 📶 (e)SIM Details or sending the sims command, then selecting Edit (e)SIM nicknames
Some updates to Cheogram Android this year
Scanning a Snikket invite works for new accounts
Search UI for emoji reactions (including custom emoji)
Display notifications for calls missed while offline
Don’t clear message field after uploading something
Allow selecting text in command UI
Initial support for community spaces
Show dot on the drawer for unseen, unread messages like chat requests
Second message edits no longer treated as separate messages1
Inherited from upstream Conversations
Conversations 2.18.0
Select backup location
Make more URIs, like mailto:, clickable
Cheogram iOS
We’ve been working on an EXPERIMENTALnative client for iOS using Borogove (previously called Snikket SDK). It’s available through Testflight for the adventurous, and push notifications require a Snikket server running the dev version for now. Contact support if you’re both interested in testing it and willing to provide feedback.
Joining conferences is one of the best perks of working as a Developer at Erlang Solutions. Despite having attended multiple Code BEAM conferences in Europe, ElixirConf US 2025 was my first. The conference had 3 tracks, filled with talks from 45+ speakers and 400+ attendees, both in-person and virtual.
ElixirConf is one of the great occasions to connect with other Elixir enthusiasts in the community and get to learn what others have been doing as well as what the Elixir core team is planning for the future of the language.
The Atmosphere
Most of the faces were unfamiliar to me, but as expected from the BEAM community, everyone was super friendly. Most were not shy about approaching others, sharing about their own or their company’s experiences. The “hallway track” was always lively during the coffee break or during the talks.
Before the conference began, I had a tough time deciding which talk to attend. At other conferences I’ve been to, most of the talks were interesting, but not all were relevant to my daily work as an Elixir developer. That made it easier to prioritise which talks to attend live and which ones I could catch up on later if they overlapped.
ElixirConf was different. Many of the talks were not only interesting but also directly relevant to my work, and several were scheduled at the same time. This made it very difficult to decide which session to attend in person and which to leave for the recordings.
Some standout talks
Chris McCord’s Keynote: Elixir’s AI Future
One of the talks I was most looking forward to was the keynote by Chris McCord. I had previously watched the recording of his ElixirConfEU keynote about phoenix.new and was eager to see what new ideas he would bring to Elixir and the Phoenix framework, especially in terms of AI.
Chris talked about AI agents, how Elixir is well-suited for building them, and what the future of Elixir and AI might look like. He emphasised that it is not about chasing hype but about staying on the bleeding edge of technology: “building the things we want to build, building the things we want to see.”
He also shared his perspective on code generation, noting that it has made it easier for newcomers to get started with Elixir and Phoenix. In his view, the community is now in a strong position to attract developers from outside the ecosystem to give it a try.
Panel: Building Careers, Balancing Life
Another talk I was eager to hear was the panel discussion hosted by my Erlang Solutions colleague Lorena, together with Allison Randal, Savannah Manning, and Anna Sherman, three women from different backgrounds and stages of their careers.
It was great hearing stories from other women in the tech community and feeling inspired. The three panellists shared the stories and challenges they had faced in their careers. They also talked about the importance of having mentors, the community, and knowing the big picture, which helped them grow. The advice they gave during the talk was both very relatable and inspiring.
Joe Harrow: Beyond Safe Migrations
I also found Beyond Safe Migrations to be great food for thought. This talk was a very practical and solid example of what could go wrong in a live database migration, and the tool Cars Commerce was using to prevent that. Over the span of my career, I have written many database migrations, from small startup projects altering a table with only a few hundred rows to large-scale projects where the tables had millions of rows.
My team sometimes discussed strategies for altering existing tables, but most of the time we would just go ahead and make the changes. Listening to Joe, I learned about things that could have gone really wrong and that there is a systematic way of mitigating those risks.
Key Takeaways
All in all, Elixir Conf US was a great conference, packed with talks about experiences and challenges, new and upcoming technologies, and also about growing the community. There was, of course, a surge in AI-related talks, both from early adopters to the future of Elixir with AI.
I found that the main theme running through the conference was the growth and sustainability of the Elixir community. ElixirConf is well worth attending, whether you are just starting out or already an experienced developer.
Welcome to the XMPP Newsletter, great to have you here again!
This issue covers the month of August 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.
ejabberd Great Invitations: One of the biggest hurdles for XMPP in terms of widespread adoption compared to single vendor solutions is a somewhat more complicated onboarding process. The goal of this project is to make this process as seamless as possible by simplifying the onboarding process - a single link is enough to guide a potential future participant - and implement it for ejabberd.
Convo XMPP client: The primary goal of this project is to develop Convo into a fully functional app that forms a viable messaging solution for KaiOS users, and publish it on the official KaiOS Store, replace the UI with a better one based on the solid-telekram project, ensure compliance with the basic XMPP Core and IM Compliance Suites (defined in XEP-0479), as well as expose end-to-end encryption (OMEMO v0.3) functionality. Visit the project page for all the details!
A Rising Tide Lifts All Boats from XMPP Providers Blog. Here the project does a review on their survey results from feedback of listed XMPP Operators and explains more about the purpose of the project.
O protocolo mais perfeito dos imperfeitos by isadora. An overview of the benefits of XMPP, including tips on how to introduce it to new people who may not be interested in the technical details. [PT_BR]
Wondering what Monocles has in store for their next version? Besides of the array of assorted enhancements and fixes that Monocles includes in every new release, the upcoming version will include support for XEP-0118 (User Tune), enabling its users to optionally share with their contacts the music they are currently listening to. This feature enhances social interaction by allowing users to discover new music, share their tastes, and connect over shared interests, fostering a more engaging and collaborative experience within the app. Check out the original announcement! A big thank you to the developer who contributed to this feature!
XMPP Software News
XMPP Clients and Applications
Cheogram has released version 2.19.0-1 for Android. Make sure to check out the changelog for all the details.
Conversations has released versions 2.19.3 and 2.19.4 for Android. This version brings improved performance for large public channels, a new ’empty chats’ page instead of redirect to ’new chat’ screen, and requires TLS 1.3 for all connections with a setting to opt out, among other fixes and improvements. You can take a look at the changelog for all the details.
Converse.js has released version 12.0.0 of its open-source web-based XMPP chat client, with various improvements and bugfixes. Several behind-the-scenes changes include OMEMO related fixes, using rspack instead of webpack, releasing an ESM build of the “headless” library version, and using an updated provider list from providers.xmpp.net for in-band registration. Head over to the release page for the full changelog!
Gajim has released version 2.3.4 of its free and fully featured chat app for XMPP. This release supports time zones in profiles, adds drag and drop improvements, enables displaying long messages inline, and fixes many smaller issues. You can take a look at the changelog for all the details. Thank you for all your contributions!
Monal has released version 6.4.13 for iOS and macOS.
Monocles has released version 2.0.13 of its chat client for Android, featuring a load of improvements like a refactored message retraction and moderation (retracted messages disappear on both sides now, the same for retracted files), a message bubble redesign, show images in full quality, a new option to import own stickers and GIFs, among many other features and a lot of fixes. Make sure to take a look at the changelog for all the details!
Profanity has released version 0.15.1 of its popular console based client for XMPP. You can read all the details about this release on the changelog.
Prose has released versions 0.12.0 and 0.12.1 of its web frontend prose-app-web! You can read all the details in the release announcement.
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.
Add hat creation and destruction flows; add hue optional parameter; add chatroom presence hats broadcast; complete disco#info; clarify how the service should broadcast updated hats; typos; standardize the form fields; (tj)
Version 1.0.4 of XEP-0388 (Extensible SASL Profile)
Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.
Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.
Newsletter Contributors & Translations
This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):
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)
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.
Last week, Spotify quietly launched direct messaging across its platform in selected areas, allowing users to share tracks and playlists through private conversations within the app. The feature was rolled out with minimal fanfare but significant media coverage, positioning itself as a complement to existing sharing mechanisms through Facebook, WhatsApp, and TikTok.
When I read this, I immediately wondered why they were bothering. We do not especially lack communication channels these days. So, Let’s take a step back and examine what Spotify is actually trying to accomplish here.
The Strange Case of Another Messaging App
We already have too many messaging apps to choose, either on mobile or mobile phones. Before I try to initiate a conversation with someone I do not often chat with, I find myself trying to remember what is her preferred messaging platform. So, adding to an app some sorts of real time messaging and live interaction features can bring value, but it has to serve a purpose and respond to some user needs.
In that context, Spotify’s decision to roll out direct messaging support feels odd. Users can already share music through established platforms where their friends actually are. They can post discoveries on social media, send links through WhatsApp, or create collaborative playlists. Why would anyone choose to message someone specifically within Spotify when they’re already connected elsewhere?
The problem is that Spotify failed to make a compelling argument for why users should discuss with friends through yet another messaging system, even if this is to talk about music. Launching a special purpose communication service is risky. When Apple Music attempted to build Ping, a social network of music fans, it failed spectacularly. Spotify’s own social experiments haven’t fared much better. Remember Greenroom, their audio-focused social platform that quietly disappeared?
This initiative becomes even more puzzling when we consider Spotify’s own history. The company built its initial viral growth through Facebook integration, leveraging social connections to drive adoption.
And now, seemingly, they are trying to reclaim that social layer for themselves?
What’s Really Happening Under the Hood
The technical implementation reveals interesting choices. According to available reports, the messaging system relies on a RESTful API over HTTPS with TLS 1.3 encryption and JSON Web Tokens for session authentication. Notably absent? End-to-end encryption.
And this absence tells us that the feature is not considered as a standard messaging service yet, but simply an alternative way to share favorite tracks and discuss them, and a possible a move to reduce the amount of data exposed to other social networks and messaging.
The Data Intelligence Play
Messaging features can provide enormous value when you have a strong daily user base, but only when they address a clear user need. Spotify’s messaging doesn’t seem designed for users. It feels designed for Spotify’s recommendation algorithms.
Every shared track, every reaction, every conversation thread becomes a new data point in Spotify’s machine learning models. Who shares what with whom? Which songs generate discussion? How do musical tastes spread through social networks? This intelligence is pure gold for a recommendation engine that already struggles to compete with YouTube Music’s discovery capabilities.
Private messaging amplifies this data collection while keeping the intelligence proprietary, unlike public social sharing, where competitors might also benefit.
Strategic Confusion or Calculated Move?
So, is this really all about data collection and control?
This is where Spotify’s European identity becomes relevant. As a Swedish company competing against American tech giants, there may be strategic value in reducing dependence on US or controlled Chinese social platforms. Every track shared through WhatsApp (Meta) or TikTok (ByteDance) represents data flowing to potential competitors or partners with their own agenda.
Building an internal messaging system allows Spotify to capture that social intelligence directly while reducing what they share with other platforms. From a data sovereignty perspective, this makes sense, especially for a European player navigating an increasingly fragmented global tech landscape.
And they may hope at some point to play a larger role in messaging platforms in general, as we deeply miss a large player in the messaging field in Europe. It may be a play to test the waters.
As we help companies reclaim their independence by building their own messaging service, this goal resonates strongly with us. However, building a successful messaging platform requires being able to create momentum around the service if it wants to attract enough users and traffic. It cannot be launched halfheartedly.
The Missing Strategic Vision
The fundamental problem isn’t technical. It’s strategic clarity. Spotify has a recommendation engine that could benefit from social signals, a creator platform focused on podcasts and videos, and a user base that already shares music socially. The ingredients for a compelling set of social features exist.
But launching messaging without addressing the basic question of “Why would I message someone here instead of where we already talk?” suggests a feature developed in isolation from user needs. It resembles the countless platform features that launch with media coverage but die quietly when adoption numbers disappoint.
What would make this feature compelling? Integration with Spotify’s creator tools, perhaps allowing artists to connect directly with fans. Or collaborative listening live sessions where messaging enhances shared musical experiences. Or leveraging Spotify’s podcast ecosystem to enable discussion around episodes.
Instead, we get generic messaging that competes with platforms where users’ friends actually are.
So, what’s Spotify’s real goal?
I see two possible options here: a pessimistic and a more optimistic one.
Perhaps the most interesting aspect of this launch is what it reveals about Spotify’s growth concerns. A mature platform doesn’t typically add generic social features unless it’s worried about engagement metrics or looking for new growth vectors.
They may want their users to spend more time in its interface, instead of most of the time, passively using that app through a player exposed as a widget in the mobile operating system.
The timing suggests Spotify sees either limited growth ahead or a competitive threat that requires better user data. Given the AI revolution in music generation and the ongoing battles over royalty structures, capturing more nuanced data about user preferences and social music behavior could be crucial for maintaining relevance.
But there’s a more optimistic reading: this could represent a European tech company trying to assert more independence from American social platforms. In a world where data is power, controlling your own social graph has strategic value.
The execution, however, suggests Spotify hasn’t quite figured out how to articulate this vision to users. Until they do, this messaging feature risks joining the graveyard of platform additions that made sense to product managers but never found their audience.
In a world already oversaturated with communication channels, every new messaging system needs to answer a simple question: Why here instead of everywhere else users are already talking? Spotify hasn’t answered that question yet.
This new version includes a few new XEP plugins as well as fixes, notably
for some leftover issues in our rust JID code, as well as one for a bug that
caused issues in Home Assistant.
Thanks to everyone who contributed with code, issues, suggestions, and reviews!
CI and build
Nicoco put in a lot of work in order to get all possible wheels built in CI. We now have manylinux and musl builds of everything doable within codeberg,
published to the codeberg pypi repo, and published on pypi.org as well.
Python version under 3.11 are no longer tested, and starting from the next version, the wheels will no longer be provided (no clue if they work, I just forgot to remove them).
Healthcare is moving quickly, and technology is playing a big part in that shift. The way information is collected, the way patients are cared for, and the way hospitals run are all changing.
Over the past year, our team has written about some of the most important trends shaping the future of healthcare. In this round-up, we bring together three of those articles: remote patient monitoring, big data, and generative AI.
Maybe you have been following along, or maybe one or two of these slipped past you. Either way, this is a chance to catch up on the ideas that are influencing healthcare right now.
What is Remote Patient Monitoring?
Remote Patient Monitoring (RPM) is already changing everyday care. With the help of connected devices, clinicians can see what’s happening with patients at home, step in earlier when something changes, and prevent unnecessary hospital stays.
“What is Remote Patient Monitoring?” sets out how RPM works, the devices that make it possible (from blood pressure monitors to smart inhalers), and why it is now a priority for healthcare leaders. The article shows how RPM is transforming chronic disease management, post-operative recovery, elderly care, and clinical trials, while driving down system costs by up to 40 per cent.
Digital care models like virtual wards are no longer experiments. They are reshaping the NHS and health systems worldwide, and this guide explains why.
Understanding Big Data in Healthcare
Healthcare produces enormous amounts of information every day. Patient records, medical scans, wearables, and research all add to the mix, and the real challenge is turning it into something useful. Done well, big data can improve care, reduce costs, and even speed up medical breakthroughs.
“Understanding Big Data in Healthcare” breaks down the fundamentals, including the three V’s that define it: volume, velocity, and variety. You’ll see how providers are already using data to personalise treatments, predict health trends, and cut readmissions by up to 20 per cent. The article also shows how it can shorten clinical trial times by 30 per cent and reduce costs by as much as 50 per cent.
But with opportunity comes risk. The average cost of a healthcare data breach now stands at $9.77 million, making security a top priority for every provider. The article looks at the biggest threats, the regulations shaping data use, and how technologies like Erlang, Elixir, and SAFE can help keep information secure and systems reliable.
How Generative AI is Transforming Healthcare
With adoption already valued at more than $1.6 billion, generative AI is fast becoming one of the biggest drivers of change in healthcare. The global AI in healthcare market is projected to hit $45.2 billion by 2026, reflecting the scale of its potential to improve patient outcomes, support clinicians, and make systems more efficient.
In “How Generative AI is Transforming Healthcare”, we look at how it differs from traditional AI and why its flexibility makes it such a powerful tool for the industry. The article explores real-world applications such as personalised treatment plans, predictive analytics, enhanced diagnostics, virtual health assistants, and even accelerating drug discovery.
It also considers the future of AI in healthcare, including the need to address challenges around privacy, regulation, and patient trust. With the right planning and technologies like Elixir supporting scalable and reliable systems, generative AI could help shape a new era of patient-centred care.
To conclude
That wraps up our latest healthcare round-up. We hope this guide helps you cut through the noise and get a clear picture of the trends that matter most right now.
If something here has sparked your interest, whether it’s the possibilities of remote monitoring, the power of data, or the promise of generative AI, we would love to keep the conversation going. So get in touch.
Here’s to smarter systems, healthier outcomes, and more confident decision-making in healthcare.
A double percent (%%) 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.
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:
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:
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 keywordHOST_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.
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:
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.
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
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)
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.
XMPP Interface
Purpose
Connection type
Reworked in version
C2S (client-to-server)
Accept connections from XMPP clients
inbound
6.1.0 – 6.4.0
S2S (server-to-server)
Federate with other XMPP servers
inbound/outbound
6.4.0
Component
Accept connections from external components
inbound
6.4.0
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-exporterchannel 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.
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:
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:
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-exporterchannel 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
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.
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.
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. ;)
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!
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!
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.
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.
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.
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):
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)
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.
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.
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.
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 bySAFE (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.
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, visitour community hub.
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:
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!
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).
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:
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.
Device Type
Primary Function
Blood pressure monitors
Measure systolic/diastolic pressure for hypertension monitoring
Glucometers
Track blood glucose levels for diabetes management
Pulse oximeters
Monitor oxygen saturation (SpO2) and heart rate
ECG monitors
Detect heart rhythm abnormalities such as arrhythmias
Smart inhalers
Track usage and technique for asthma or COPD
Wearable sensors
Monitor movement, sleep, temperature and heart rate
Smart scales
Measure weight trends, often linked to fluid retention or post-op care
Sleep apnoea monitors
Detect interrupted breathing patterns during sleep
Maternity tracking devices
Monitor fetal heart rate, maternal blood pressure, or contractions
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:
Data collection from connected medical devices
Secure transmission to a clinical platform
Integration with existing systems
Analysis and alerting via algorithms or clinician review
Intervention where thresholds are breached
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 Researchstudy 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.
Real-time data visibility, increased capacity, and better focus on complex cases
Carers
Peace of mind, early alerts, and less reliance on manual checks
ICBs & Providers
Lower readmissions, improved resource use, and more coordinated care
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.
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).
The ejabberd installers and the ejabberdcontainer image already use a patched version Erlang/OTP 27.3.4.1, but the ecscontainer 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.
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)
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
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:
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.
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:
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
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.
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).
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]
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.
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.
The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).
Proposed
The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.
This specification defines 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.
Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.
Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.
Newsletter Contributors & Translations
This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):
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)
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.
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
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
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).
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.
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)
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.
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:
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.
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.
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.
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.
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
Come join the celebrations in 
