Beyond that headline, the release also ships whisper messages, offline compose, unread badges, and a significant render-performance pass. Here is what changed and why.

End-to-End Encryption with OpenPGP

When end-to-end encryption is on, your messages are scrambled on your device before they leave it. Your XMPP server relays ciphertext, but it cannot read your conversations, even if the server is compromised or an administrator goes looking. The same applies to any relay between servers.

Fluux implements OpenPGP for XMPP (XEP-0373, also called OX) — the modern redesign of OpenPGP encryption for XMPP. If you have come across XEP-0027 (the older "Current Jabber OpenPGP Usage"), that is a different, now-deprecated approach with well-documented weaknesses: no authenticated message envelope, signed-plaintext exposure, and no multi-device story. Fluux implements XEP-0373 only. It uses a proper content-encryption layer (XEP-0420) that authenticates the full message context and hides metadata from the server. It builds on the same OpenPGP cryptography used in encrypted email for decades, adapted correctly to instant messaging.

Once you enable encryption in Settings → Encryption, your key pair is generated and your public key is published to your server. From that point, whenever a contact also has encryption enabled, Fluux automatically starts encrypting messages to them. A lock icon above the composer confirms it. Nothing to configure per conversation.

Encrypted messages cover more than just text: reactions, edits, retractions, link previews, and file attachments all ride inside the same encrypted envelope. The server cannot see which emoji you reacted with, what you edited a message to say, or which files you shared.

Why OpenPGP first?

The choice of OpenPGP as the first E2EE protocol was deliberate, and it comes down to four practical properties.

Multi-device without friction. A single OpenPGP key pair works across all your devices. You generate it once; every device you add simply loads the same key. There is no per-device key negotiation, no session bootstrapping required before encrypted history loads. This stands in contrast to ratchet-based protocols that issue a key per client installation and require all clients to exchange session state before decryption is possible.

Encrypted backup you control. When you click Back up in the encryption settings, Fluux generates a backup code — 24 upper-case characters drawn from an unambiguous alphabet (no O or 0), grouped into 4-character chunks with dashes (e.g. TWNK-KD5Y-MT3T-E1GS-DRDB-KVTW). This format follows XEP-0373 §5.4 and is accepted by other compliant clients such as Gajim. Fluux encrypts your secret key with this code and stores the encrypted blob on your own XMPP server under a private node only you can access. The code never leaves your device.

Your full history stays readable. Because every device shares the same key, messages encrypted months ago on one device remain decryptable on another. The server&aposs message archive (MAM) becomes a true history, not a graveyard of ciphertext only the originating device can open. Outgoing messages are also encrypted to your own key, so your sent history is fully accessible on every device.

Simple, comprehensible verification. Trust On First Use (TOFU) gives you safe, convenient defaults. When you want a stronger guarantee, you compare fingerprints out-of-band, i.e. in person, over a phone call, on a separate verified channel. The fingerprint lives in the tooltip on the lock icon and in Settings → Encryption. You verify once per contact, per key, and you are done.

Whisper messages — private threads inside group chats

It is now possible to reply privately to a single occupant of a room without leaving the room. These whisper messages follow XEP-0045 §7.5 and appear in a distinct private thread so it is always clear they are not visible to the room at large.

Other improvements worth knowing

Compose while offline. Messages typed before a connection is established are queued locally and sent as soon as the session comes online.

Connection status banner. A banner now appears while the app is reconnecting, so you always know when you are temporarily offline rather than wondering whether a message failed to send.

Render-performance pass. This release eliminates a class of re-render storms that affected the conversation list, command palette, room config modals, occupant panel, roster, search, and individual message rows during background sync and group-chat presence churn. The result is a noticeably smoother experience on busy accounts.

XMPP Console cleanup. Stream Management packets are now hidden by default in the developer XMPP console. The toggle remains available for when you need to trace them.

What comes next for encryption

The encryption engine is a plugin layer sitting between the XMPP client and the UI. OpenPGP is the first plugin loaded into that framework. Adding a second protocol means writing a new plugin that implements the same interface: key management, encrypt, decrypt, trust state. The rest of the app — message routing, UI indicators, backup flow — does not need to change.

This matters because no single protocol wins every use case. OpenPGP&aposs shared-key model is ideal for multi-device history access; ratchet-based protocols like OMEMO excel at forward secrecy on single-device deployments; MLS is designed for large groups where pairwise key agreement would be impractical. The plan is to support several, letting users and deployments choose.

The framework is in place; the question is which protocol to add second. OMEMO (XEP-0384) is the most widely deployed XMPP encryption protocol today. Adding it would maximise interoperability with existing XMPP clients. MLS (RFC 9420) is the newer IETF standard, designed from the ground up for multi-device and group scenarios, and is where the industry is heading long term.

We have not decided yet. If you have a strong opinion, whether you are running an ejabberd deployment or just a user who cares, we would genuinely like to hear it. Just comment under that blog post.

Release notes and download

Full changelog on GitHub. Desktop builds for macOS, Windows, and Linux — plus the web version — are available on the ProcessOne website.

Over the past few months, our team has been exploring what happens when systems come under pressure.

Through a series of webinars, we’ve looked at everything from concurrency in the BEAM to traffic spikes, real-time communication platforms, and resilient system design.

Maybe you’ve been following along, or maybe one or two of these webinars slipped past you. Either way, this is a chance to catch up on the ideas shaping how modern platforms are built and scaled.

Concurrency, Understanding the BEAM Limits

Modern systems can handle huge amounts of concurrent work. But sooner or later, every system reaches a point where performance starts to suffer.

In “Concurrency, Understanding the BEAM Limits”, Lorena Mireles Rivero explores how concurrency works inside the BEAM and where those limits begin to appear. Using examples from web applications and e-commerce platforms, she looks at how schedulers, mailboxes, CPU usage, and latency behave under load.

The session also explores common signs of system saturation and practical ways to keep applications running smoothly as demand grows.

Watch the webinar to learn more about concurrency in the BEAM and how to build systems that perform under pressure.

Keeping Real-Time Communication Platforms Online During Peak Demand

Real-time platforms don’t get a second chance. When demand spikes, messages still need to be delivered instantly and reliably.

In this webinar, Bartłomiej Górny explores what happens when systems are pushed to their limits. He looks at common bottlenecks, overloaded services, and how failures can spread across a platform when demand suddenly increases.

The session also covers practical approaches to scaling real-time systems, from service decoupling and back pressure to monitoring and load testing.

Watch the webinar to learn how real-time platforms can stay reliable during periods of peak demand.

How to Build Systems That Stay Online When Everything Spikes

Traffic doesn’t always increase gradually. Sometimes it arrives all at once.

In this session, Camjar Djoweini explores what happens when systems come under sudden pressure and why failures can quickly spread across services. He looks at where problems typically start and what makes some architectures more resilient than others.

The webinar focuses on designing systems that can absorb spikes, tolerate failures, and continue operating when conditions become unpredictable.

Explore the webinar to learn more about building resilient systems that stay online under pressure.

How to Build Platforms That Don’t Let Audiences Down

For gaming, betting, and entertainment platforms, traffic spikes are part of everyday life. The challenge is making sure users never notice them.

In this webinar, Lee Sigauke explores why systems fail during sudden surges in demand and how teams can build platforms that remain reliable under pressure. Drawing on principles from transactional systems in Erlang and Elixir, she shows how concurrency-first design helps systems cope with unpredictable workloads.

The session covers common failure patterns, resilience at scale, and practical ways to build platforms that continue performing when demand reaches its peak.

Watch the webinar to see how concurrency-first design helps platforms remain reliable when traffic surges.

To conclude

That wraps up our latest webinar round-up. We hope this guide helps you catch up on some of the ideas we’ve been exploring over the past few months.

If something here has sparked your interest, whether it’s concurrency in the BEAM, building resilient architectures, or keeping platforms reliable during periods of peak demand, we’d love to continue the conversation. So get in touch.

Here’s to building systems that stay stable, scalable, and ready for whatever comes next.

The post Erlang Solutions Webinar Round-Up appeared first on Erlang Solutions.

Here is a new version for slixmpp, the python XMPP library.

This release has one specific breaking change and two new XEP plugins. Thanks to everyone involved!

XMPP Newsletter Banner

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

The XMPP Newsletter is brought to you by the XSF Communication Team.

Just like any other product or project by the XSF, the Newsletter is the result of the voluntary work of its members and contributors. If you are happy with the services and software you may be using, please consider saying thanks or help these projects!

Interested in contributing to the XSF Communication Team? Read more at the bottom.

XSF Announcements

XMPP Summit 29

The XMPP Standards Foundation (XSF) is excited to announce the 29th XMPP Summit, the first XMPP Summit to take place fully online! The XMPP Summit will be held from Friday 4th September to Saturday 5th September 2026, both days between 13:00 - 16:00 UTC. The XSF invites everyone interested in development of XMPP technologies to attend, and discuss all things XMPP remotely!

XMPP Events

• XMPP Sprint in Berlin (DE / EN): will take place in June, from Friday 19th to Sunday 21st 2026, at the Wikimedia Deutschland e.V. offices in Berlin, Germany. If this sounds like the right event for you, come and join us! Just make sure to list yourself here, so we know how many people will attend and we can plan accordingly. If you have any questions or concerns, join us at the chatroom: sprints@muc.xmpp.org!

• XMPP at FOSSY 2026: This year’s edition of FOSSY, the fourth Free and Open Source Software Yearly conference, will take place during the month of August, from Thursday 6th to Sunday 9th 2026 at the University of British Columbia, Vancouver, Canada. As always, there will be an XMPP Track. The call for proposals is closed as of June 2nd, 2026. Once again, this year JMP is pleased to do its annual offer for funding to the potential speakers who would like to host a talk on the XMPP track.

Videos and Talks

• Independent Messaging (XMPP) unter iOS (Monal), by eversten.net for XMPP Tutorials DE. [DE] ([EN],[ES] subtitles available).
• Independent Messaging (XMPP) unter Android (Snikket), by eversten.net for XMPP Tutorials DE. [DE] ([EN],[ES] subtitles available).
• Independent Messaging (XMPP) unter Android (Conversations), by eversten.net for XMPP Tutorials DE. [DE] ([EN],[ES] subtitles available).
• Conversations (XMPP): Feature-Preview für Version 2.20.0, by eversten.net for XMPP Tutorials DE. [DE]

XMPP Articles

• EnvsBot XMPP Helper Bot for the envs pubnix - BETA,a modular XMPP bot built with Python 3 and slixmpp developed with the envs pubnix environment in mind but not limited to it, by ~dan for ~dan’s website on envs.net blog.
• Pra esse passaporte vai ter fila, by isadora for the isaCloud diario-de-bordo. [PT_BR]
• First 2026 Goal Reached! What’s Next? , by Timothée Jaussoin for the Movim Blog.
• What’s your oldest Openfire deployment?, by guus for the Ignite Realtime community.
• ¿Qué es XMPP: mensajería federada sin depender de WhatsApp?, by elenamusk for the Tuiter.Rocks blog. [ES]

XMPP Software News

XMPP Clients and Applications

• aTalk has released versions 5.4.0, 5.5.0 and 6.0.0 of its encrypted instant messaging with video call and GPS features for Android. This versions bring a whole lot of ‘under the hood’ changes. Please refer to the release notes for all the details.
• Conversations has released versions 2.19.16 and 2.20.0 for Android. These releases bring some significant UI work, an improved media browser with ability to share and delete media files, store media internally by default (with setting to automatically save to gallery), send audio recordings immediately instead of attaching (plus setting to restore the old behavior), Show QR code that now includes preauth parameter on servers with easy invites, and a search bar for easier access to searches from the home screen. Make sure to take a look at the changelog for all the details!

Conversations: A prominent search bar on the main screen and a reworked media attachment flow.

• Converse.js has released versions 13.0.0 and 13.0.1 of its open-source web-based XMPP chat client, with various additions, improvements and bugfixes. These versions add support for message reactions allowing users to react to messages with emojis, message replies to specific messages, autocomplete of possible XMPP providers when registering a new account, half a dozen fixes and quite some work under the hood!. Head over to the changelog for the all the details!
• Monal has released version 6.4.21 for iOS and macOS. This version now shows last usage timestamp of OMEMO keys, improves location sharing accuracy and contact last activity timestamps, and it also fixes several bugs!
• Monocles has released versions 2.1.6, 2.2, 2.2.1, and 2.2.2 of its chat client for Android. These versions introduce a large amount of new features, implementations, and bug fixes that is way larger than we could list in here. Among the more prominent highlights you’ll find ephemeral messages, live location sharing, improved create and restore backup, use internal hidden storage by default, local database encryption, improved backup encryption & reliability, secure deletion & migration recovery, UI/UX improvements, media gallery, and a lot more! Make sure to check the links for all the details!. Note: due to some delays with the Play Store updates, these releases are only available through F-droid for the time being.

Monocles Chat: Ephemeral messages, live location sharing, and the media gallery!

• Poezio has released version 0.18 of its console client for XMPP. This new release has mostly internal improvements, with some new features like message retraction at the sending side, various improvements to the react plugin, notably a way to convert :emoji: shortcodes to real emojis, and a new way of showing or hiding groupchat presences along with a few other improvements and fixes. You can find all the details in the link to the release.
• Profanity has released version 0.18.1 of its console based XMPP client. This release brings bug fixes to connect with an empty resource, resolves issues with async editor, resolves DB migration failures, and restores message receipt requests when capabilities are unknown, among many other things. Please make sure to read the changelog for all the details!

XMPP Servers

• MongooseIM has released MongooseIM 6.7.0 with more additions, changes and fixes than what we can reasonably list in here! Make sure to read the changelog for all the details!
• The Ignite Realtime community is happy to announce the release of Openfire 5.0.5. The full changelog has more details with the highlights being bug fixes and bundled library updates whilst they continue to work on an upcoming 5.1.0 feature release.
• Prosody IM is pleased to announce version 13.0.6, a new minor release from the stable branch. This release fixes a handful of bugs which were discovered and fixed since the 13.0.5 release. Most of these are minor, but a few of them are important fixes. Make sure to read the changelog for all the details!

XMPP Libraries & Tools

• go-xmpp versions 0.3.3 and 0.3.4 have been released.
• go-sendxmpp, a tool to send messages to an XMPP contact or MUC inspired by sendxmpp, versions 0.15.6 and 0.15.8 have been released. Full details in the changelog.
• jabber.el, the XMPP client for Emacs, versions 0.10.7, 0.10.8, 0.10.9 and 0.10.10 have been released. Full details in the changelog.
• libomemo.js, a TypeScript implementation of the OMEMO Multi-End Message and Object Encryption protocol for XMPP, version 0.0.1 has been released. You can read the full changelog for all the details. Note: This version still targets XMPP OMEMO version 0.3.0. Support for the latest version of OMEMO will be added in a subsequent release.
• mellium.im has released version 0.23.0 of xmpp, an XMPP library written in Go. You can check out the changelog for all the details.
• picomemo, a compact and portable implementation of the cryptography required for XMPP’s OMEMO (E2EE), version 1.2.0 has been released. Read the details in the changelog.
• slidgnal, a feature-rich Signal to XMPP puppeteering gateway, based on slidge and signalmeow, version 0.3.0beta11 has been released. You can read the intermediate changelog from 0.3.0beta10 to 0.3.0beta11 for all the details.
• slixmpp, the MIT licensed XMPP library for Python 3.7+ version 1.15.0 has been released. You can read the official release announcement for all the details.
• xmpp-ap-bridge, a lightweight Fediverse to XMPP implementation based on client bots to enable chat-like conversations between any Fediverse application and any XMPP client from your usual client applications, versions 0.8.0 and 0.8.1 have been released. You can read about all the details on the releases page.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• TLS Channel-Binding Downgrade Protection
  • This specification provides a way to secure the SASL and SASL2 SCRAM handshakes against channel-binding downgrades through TLS version downgrades.

New

• No new XEPs this month.

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

• No XEPs deferred this month.

Updated

• Version 0.2.0 of XEP-0449 (Stickers)
  • Make pack attribute explicitly a MAY. Add more details about sending/receiving stickers without a sticker pack. (lmw)
• Version 0.2.0 of XEP-0463 (MUC Affiliations Versioning)
  • Use a dedicated child element of <x/> rather than namespaced attributes. (lmw)
• Version 0.3.0 of XEP-0503 (Server-side spaces)
  • Fix pubsub node field name in room disco info.
  • Specify how to attach images (avatar and banner) to a space. (nc)

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.

• No Last Call this month.

Stable

• No stable XEPs this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Newsletter Contributors & Translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

• Contributors:

  • To this issue: emus, cal0pteryx, Gonzalo Raúl Nemmi, Ludovic Bocquet, XSF iTeam

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • Italian: Mario Sabatino, Roberto Resoli

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF GitHub repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our XSF Communications Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

• gathering news in the XMPP universe
• short summaries of news and events
• summary of the monthly communication on extensions (XEPs)
• review of the newsletter draft
• preparation of media images
• translations
• communication via media accounts

Unsubscribe from the XMPP Newsletter

For this newsletter either log in here and unsubscribe or simply send an email to newsletter-leave@xmpp.org. (If you have not previously logged in, you may need to set up an account with the appropriate email address.)

License

This newsletter is published under CC BY-SA license.

The Ignite Realtime community is pleased to announce the release of Openfire 5.1.0, the latest version of our open-source XMPP real-time communication server!

Since the 5.0.0 release, now over 11 months ago, we’ve kept the 5.0.x branch stable and maintained, but have also been working on the next set of bigger changes. With this release, those have (finally - sorry for the wait!) been made available. If you’ve been following along in the chat or forums you might have seen pieces of it being put together: the channel binding work, the DNS improvements, the new database experiments have been in the works for quite some time, and have seen quite some discussion and collaboration. Let me give you an overview of what is included with the 5.1.0 release.

The biggest theme is security. With generous support from NLnet Foundation we’ve implemented SASL channel binding (OF-2694, OF-2879), which ties authentication to the underlying TLS connection and closes the door on a class of man-in-the-middle attack that has been observed against real XMPP servers in the wild. While we were in that part of the codebase, we also audited the encryption utilities, and found a few things worth fixing. A hardcoded AES initialisation vector (OF-3074), a single-round unsalted SHA-1 used for Blowfish key derivation (OF-3075), CBC-mode padding that was susceptible to oracle attacks (OF-3077), and timing side-channels in SCRAM-SHA-1 authentication (OF-3257, OF-3258). None of these were discovered under active exploitation, but they’re the kind of thing that shouldn’t be there, and now they’re not. We’ve also tightened up certificate identity handling (OF-3122), SASL mechanism enforcement (OF-3273), and login throttling (OF-3262), and added proper support for trusted reverse proxy configuration (OF-3260, OF-3261).

There’s also a performance fix that deserves a mention. Community members reported this issue in the PubSub functionality: after investigation, we found a method in the persistence code doing a full linear scan of every node in memory for each row it processed from the database (OF-3196). That’s O(n²), which is fine at small scale and quietly catastrophic at large scale. On a deployment with around 600,000 pubsub nodes it was causing startup times of over two hours. The fix was not much more than a one-line change. If you’ve ever accepted a very long Openfire startup as just a fact of life, this release is for you. Alongside that, blocking operations have been moved off Netty’s event loop threads (OF-3176) to improve responsiveness under load, and we’ve upgraded to Netty 4.2 (OF-2957).

5.1.0 also brings some ecosystem-related updates to Openfire. Java 25 is supported (OF-3210), and three new databases join the supported lineup:

• MariaDB (OF-3239), which many operators have been running as a MySQL stand-in for years anyway;
• Firebird (OF-3237), for the on-premise environments where it’s been quietly doing the job for a long time; and
• CockroachDB (OF-3238), for distributed and cloud-native deployments.

Support for these has not landed in most plugins yet, but we’ll work on that in the coming time. In the mean time, please try them out, and tell us what you think!

On the protocol side, Openfire now handles XEP-0398 (avatar synchronisation between XEP-0084 and vCard-based avatars, OF-2034), and provides a proper API for Service Discovery Extensions (OF-3188) so plugins no longer need to intercept IQ stanzas to enrich discovery responses. For operators, there’s a new diagnostics page for failed S2S connections (OF-3037), a UI for managing DNS overrides (OF-3244), configurable rate limiting for incoming connections (OF-3170), and a Docker healthcheck (OF-3184).

The bug fix list is long, but a few stand out: orphaned S2S routes that caused silent packet loss (OF-3193, OF-3201); encrypted properties being silently stored in plaintext after XML-to-database migration (OF-3296); plugin reload failures on Windows (OF-3208); and chatroom subjects not being delivered on join in certain conditions (OF-3131).

The full changelog lists 121 items resolved!

You can obtain Openfire 5.1.0 for your platform from its download page. The sha256sum values for the release artefacts are:

0686b30d4fb5e6f7c43bff7071ac425e45a19bbd528e301df065ef8d60355ef5  openfire-5.1.0-1.noarch.rpm
90b21993ba65d98357154183fd12e938547e68cbc59301f69b8506f483580269  openfire_5.1.0_all.deb
5fff05c4a689ae3431d5578f594e37cf7a68a2c0f36380b76d132d79217913c0  openfire_5_1_0.dmg
f72d766957eb09bedcbe8a5f64c38db85684af62bf5282534a162385f7b449ed  openfire_5_1_0.exe
0cc848b56339f07fdcbcbb92dea73a35c00661576d68f1908640ecf7c3b6febc  openfire_5_1_0.tar.gz
a830b0451770d6c8f8db81b3584299f54c48ca8c6d4bf42671325fef0b74c878  openfire_5_1_0_x64.exe
8b3f30505b3996b4b8261a99710ac2387131dac9b5a75fbbf65e9e3419aa22f5  openfire_5_1_0.zip

We’d love to hear from you! Please join our community forum or group chat and let us know what you think!

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

5 posts - 5 participants

Read full topic

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

This release fixes a handful of bugs which were discovered and fixed since the 13.0.5 release. Most of these are minor, but a few of them are important fixes.

A summary of changes in this release:

Fixes and improvements

• mod_cloud_notify: Use correct stanza id when clearing table entries (mem leak)
• mod_admin_shell: Don’t echo new password back to the client
• util.pubsub: Remove JIDs not permitted to be subscribed on affiliation change (fixes #1709)

Minor changes

• mod_account_activity: Don’t traceback when called without options
• util.jsonschema: Always accept 0 for multipleOf properties
• util.paths: Fix check for adding installer path to package.cpath
• util.datamanager: Fix listing of host stores
• util.crypto: Use post-Lua 5.1 buffer API for improved memory safety
• util.dataforms: Don’t treat invalid jid-multi fields as missing
• util.crypto: Ensure signing parameter is a string
• util.poll: Reject unsupported file descriptors when using select() backend
• util.pubsub: Ensure deleted node stays in memory store deletion failed
• util.ringbuffer: Fix incorrect returned position from :find() for #needle~=1
• util.pposix: Fix incorrect syslog facility mapping
• util.ringbuffer: find(): Fix find logic bugs
• util.signal: Fix signalfd closure on non-Linux systems
• net.websocket: Fix traceback in client if server doesn’t respond with Connection header
• net.server_event: Fix incorrect flag logic for watchfd handles
• mod_debug_stanzas: Only clear active_filters when there are no subscribers
• mod_carbons: Fix ‘to’ attribute of stanzas to own account
• net.stun: Fix parsing of STUN packets with 0-length attributes
• mod_storage_memory: Fix assignment to ‘with’ when calling archive:set()
• net.http.parser: Include final component in path normalization check
• mod_register_ibr: Use set_password() instead of create_user() for resets
• mod_vcard: Ignore invalid photo data
• util.timer: Fix incorrect rescheduling of some kinds of timers

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

Poezio is a terminal-based XMPP client which aims to replicate the feeling of terminal-based IRC clients such as irssi or weechat; to this end, poezio originally only supported multi-user chats and anonymous authentication.

This new release has mostly internal improvements, but a few improvements and fixes as well.

Thanks to all contributors and users!

% git diff --stat v0.17...v0.18
…
157 files changed, 5366 insertions(+), 3158 deletions(-)

The XMPP Standards Foundation (XSF) is excited to announce the 29th XMPP Summit, the first XMPP Summit to take place fully online! The XMPP Summit will be held from Friday 4th September to Saturday 5th September 2026, both days between 13:00 - 16:00 UTC. The XSF invites everyone interested in development of XMPP technologies to attend, and discuss all things XMPP remotely!

The online XMPP Summit

The XMPP Summit is where the XMPP community comes together to discuss protocol development (such as XMPP extensions (XEPs)), implementation experience, and the future of the ecosystem.

As this is the first online XMPP Summit, it’s intentionally kept lightweight. The goal is not to replicate the in-person XMPP Summit experience, but to provide value that complements our existing asynchronous communication channels.

Favored topics will likely be follow-ups to topics discussed during Summit 28, advance current work on extensions (XEPs), discuss implementation pain points, and improvement of collaboration between projects. In general, the intention is to make it easier for more XMPP community members to participate, too.

Info, Date & Time

Date: Friday 4th - Saturday 5th, September 2026

Time: 13:00 - 16:00 UTC (both days)

Session link: TBA

Cost: Free (registration and topic proposals appreciated)

Who participates at the Summit?

Similar to an unconference at the beginning all interested participants can suggest topics and others can indicate via votes whether or not they are interested in these topics. Afterwards a rough order of topics is established that will be followed in moderation with the participants.

How does the Summit work?

If you have ever followed a thread on the Standards Mailing List or taken part in a discussion on the public XSF channel you should be familiar with this. The different topics are broken up by short breaks that are great for networking and getting to know other XMPP developers.

Agreeing on a common strategy or even establishing a rough priority for certain features in our decentralized and interoperable technology and protocol can be challenging. To get the most out of the Summit, you should have a background in reading (and maybe even writing) XEPs. If you are simply an enthusiastic user or admin, we regularly have booths at various conferences (e.g. FOSDEM, CLT, FrOSCon) that are a great opportunity to meet with us, too. Either way, everyone is welcome to participate!

If we’ve caught your attention, we will then hopefully see you at the XMPP Summit 29. Read on!

Participation

If you’re interested in attending, please help us by filling out your details on the XMPP wiki page for Summit 29. To edit the page, reach out to an XSF member to enter and update your details or you’ll need a wiki account, which we’ll happily provide for you. To obtain an account on the XMPP wiki, please contact the Sysops who will be glad to create it for you (to avoid the spaming). Contact us using the communication channels listed below. If your plans change, please remove your name from the list.

Please also consider listing your agenda proposals and if you want to have a short talk: Topic proposals

Conduct and policies

We expect all participants to respect our Community Code of Conduct.

Please be respectful of others’ time, perspectives, and personal circumstances. Online participation can be demanding; we encourage everyone to help keep discussions constructive and focused.

Communication

To ensure you receive all relevant information, updates and announcements about the event, make sure that you’re signed up to the Summit mailing list and joined the Summit chatroom (Webview).

Spread the word! Feel free to use our communication channels (see page footer).

We are really excited to already see people signing up. Looking forward to meeting all of you online this time!

The XMPP Standards Foundation Board

As we’re preparing the upcoming Openfire 5.1.0 release, I’ve been spending a lot of time looking at parts of the codebase that have been around for a long time.

Some of them date back to assumptions that were perfectly reasonable when Java 5 was current, IPv6 was still considered “future tech”, Docker didn’t exist yet, and “cloud-native” wasn’t a phrase anyone but meteorologists used.

Yet somehow, Openfire deployments that started in those days are still running today.

That got me wondering:

What’s the oldest Openfire deployment that you still run?

Not necessarily the oldest version (although I’d love to hear that too), but the oldest continuously running installation, the oldest surviving user database, or perhaps the weirdest setup that somehow still works despite years of upgrades, migrations and changing infrastructure.

I suspect there are Openfire instances out there that have survived datacenter migrations, moved from physical hardware to virtual machines to containers, switched databases more than once, and outlived several generations of administrators. Some probably still contain configuration decisions that nobody fully understands anymore. Is anyone still running Wildfire? Jive Messenger?

Honestly, I love those stories from the trenches. The odd workarounds, the “temporary” fixes that became permanent infrastructure, the upgrade that everyone expected to fail but somehow didn’t, or the deployment that quietly kept running for a decade without anyone thinking much about it.

One of the things I appreciate most about infrastructure software is that success often becomes invisible. If a messaging server quietly keeps working for ten years, nobody talks about it. But that kind of stability is actually a huge achievement (both for the software and for the people operating it). I think that’s something we, as a community, can be genuinely proud of.

For Openfire 5.1.0, we’ve been modernizing quite a few internals:

• support for Java 25
• upgrades to Netty 4.2 and various database drivers
• improvements around reverse proxies and DNS handling
• clustering improvements
• security hardening
• performance fixes for larger deployments.

While doing that work, we constantly try to balance modernization with compatibility for long-running installations. That balancing act becomes much easier when we understand how people actually deploy and operate Openfire in the real world, which, apart from simply wanting to hear your stories, is another reason for me to ask this question.

So: I’d love to hear your stories! How old is your deployment? What version did you start with? What infrastructure changes has it survived over the years? Are there plugins or integrations you absolutely depend on? What operational lessons have you learned?

And perhaps most importantly: what surprised you most about running Openfire long-term?

I’m hoping this thread becomes a collection of deployment stories, operational lessons, and perhaps a bit of Openfire history.

Looking forward to hearing your stories!

We’d love to hear from you! Please join our community forum or group chat and let us know what you think!

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

7 posts - 6 participants

Read full topic

The Ignite Realtime community is pleased to announce a new release of Openfire, version 5.0.5. The full changelog has more details with the highlights being bug fixes and bundled library updates whilst we continue to work on an upcoming 5.1.0 feature release.

You can obtain the new version of Openfire for your platform from its download page. The sha256sum values for the release artifacts are:

4ba9b6476efefc54378c0fd4a2a402177fd94bc11512354db887eb446f37f211  openfire-5.0.5-1.noarch.rpm
3a870ef09415f3bf2eac315ac826b59997eba6bcc38a1eb3740856ff16ffc11c  openfire_5.0.5_all.deb
94d3a8a159a68fdff17394c415d3ce1feb557fb8ef0618a883180f668a359cc2  openfire_5_0_5.dmg
bbc4c1147ff1a4d8740a5e12929e650dc04e3c7a6c765ff13855da48c16f980a  openfire_5_0_5.exe
50028a20587ea9d6b5bcc8260ca626e022d223b39748ffe7b9851d9b344dba6b  openfire_5_0_5.tar.gz
649f3b14a5403275780a2344b2d575f163a2e182eefa9c4978bd325cbf7486d5  openfire_5_0_5_x64.exe
49edd9873a84d2f6b19c24d360ac964ea9180753f6dff4355d75be3943e20817  openfire_5_0_5.zip

For those of you that enjoy metrics, here’s an accounting of 5.0.4 release artifact downloads.

We’d love to hear from you! Please join our community forum or group chat and let us know what you think!

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

1 post - 1 participant

Read full topic

XMPP Newsletter Banner

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

The XMPP Newsletter is brought to you by the XSF Communication Team.

Just like any other product or project by the XSF, the Newsletter is the result of the voluntary work of its members and contributors. If you are happy with the services and software you may be using, please consider saying thanks or help these projects!

Interested in contributing to the XSF Communication Team? Read more at the bottom.

XSF Announcements

XSF Membership

Being an elected member of the XMPP Standards Foundation signals a commitment to open standards and professional engagement in / with the XMPP community. Here, your membership helps position the XSF as a healthy organization, which in itself is valuable. It also grants voting rights on technical and administrative matters within the XSF. The application is a light-weight and free of cost process and you can use your membership to get more involved more easily, too. If you are interested in joining the XMPP Standards Foundation as a member, please apply to our 2nd quarterly call for members admissions before May 17th, 2026, 00:00 UTC.

XMPP Events

• XMPP Sprint in Berlin (DE / EN): will take place in June, from Friday 19th to Sunday 21st 2026, at the Wikimedia Deutschland e.V. offices in Berlin, Germany. If this sounds like the right event for you, come and join us! Just make sure to list yourself here, so we know how many people will attend and we can plan accordingly. If you have any questions or concerns, join us at the chatroom: sprints@muc.xmpp.org!
• XMPP at FOSSY 2026: This year’s edition of FOSSY, the fourth Free and Open Source Software Yearly conference, will take place during the month of August, from Thursday 6th to Sunday 9th 2026 at the University of British Columbia, Vancouver, Canada. As always, there will be an XMPP Track. The call for proposals remains open until May 22, 2026. Once again, this year JMP is pleased to announce its annual offer for funding to the potential speakers who would like to host a talk on the XMPP track. Please, join them at discuss@conference.soprani.ca, and don’t hesitate to ask for more information!

Videos and Talks

• Mensajería instantánea: por qué recomiendo XMPP, a podcast by Damián Muraña for Cosas de Damián. [ES]
• Conversations (XMPP): Feature-Preview, by eversten.net for XMPP Tutorials DE. [DE] [EN]
• Monal (XMPP): Feature-Preview für Version 7, by eversten.net for XMPP Tutorials DE. [DE]
• Deutschlandfunk Nova: Interview über EU-Regulierung von Instant-Messengern, a radio interview with Daniel Gultsch. [DE]
• XMPP: Instant Messaging that works like email by Polarian and Chewie at oggcamp 2026.

XMPP Articles

• NLnet: 57 Projects Receive NGI Zero Grants to Fix the Internet
  • OpenPGP refresh for Conversations: This project aims to modernize PGP encryption within Conversations, a Jabber/XMPP client, by integrating cryptographic operations and adopting updated messaging standards. Furthermore, the project will implement and update the modern OpenPGP standards for XMPP (XEP-0373 and XEP-0374) by making use of Stanza Content Encryption (SCE). This transition not only benefits users who prefer PGP-based encryption but also serves as a critical building block for the development of OMEMOv2.
  • Matridge spaces: Matridge is a gateway for XMPP users to transparently chat in Matrix rooms. It is an XMPP server-side component that acts as a Matrix client and makes it possible to pilot a Matrix client from any XMPP client. It implements modern instant messaging features such as rich replies, spaces, attachments, emoji reactions and threads. It is self-hosting friendly, community-lead, written in python and based on slidge, an XMPP gateway library.
    • Matridge spaces with NLNet, from the slidge.im blog.
• Experimenting with MariaDB, Firebird and CockroachDB Support in Openfire, by guus for the Ignite Realtime community.
• Bringing jabber.el Back From the Dead, by Thanos Apollo from the thanosapollo posts.
• Fluux Messenger 0.15: Search, Themes, Polls, and a Whole Lot More, by Mickaël Rémond for the ProcessOne blog.
• Full Text Search with IndexedDB, by singpolyma for the JMP blog.
• Fluux Messenger 0.15.2: RTL Support, Faster Reconnection, and a Pile of Reliability Fixes by Mickaël Rémond for the ProcessOne blog.
• Libervia progress note 2026-W16: a complete and comprehensive blog post about the Audio/Video implementation, email gateway, work on installation/configuration simplification and the new forge, focus on web frontend and redesign and work done with current metadata reduction and serverless XMPP (Tor, contacts e2ee, new pubsub implementation) by Goffi.
• Movim 0.33 “Halley” is out!, by Timothée Jaussoin for the Movim Blog.
• XMPP – The Middle Ground Of Instant Messaging: XMPP or Extensible Messaging and Presence Protocol is an open communication protocol. In this article you will learn to install a private, non-federated XMPP server. By Tom’s IT Cafe for the Tom’s IT Cafe blog.
• XMPP como alternativa a Whatsapp, by Runforrest for Runforrest World blog. [ES]
• XMPP: mensajería instantánea libre y federada, by Damián Muraña for Damián Muraña blog. [ES]

XMPP Software News

XMPP Clients and Applications

• aTalk has released versions 5.2.2 and 5.3.0 of its encrypted instant messaging with video call and GPS features for Android. Both versions bring a lot of ‘under the hood’ changes. Please refer to the release notes or check out the intermediate changelog from 5.2.1 to 5.3.0 for all the details.
• Fluux Messenger, has released versions 0.15.0, 0.15.1 and 0.15.2, of its modern, cross-platform XMPP client for communities and organizations. These versions introduce a large list of additions and new features like 12 built-in themes, reaction-based polls for MUC rooms with deadlines, full-text message search across all conversations and rooms, font size adjustment buttons, activity log events are clickable and allow you to navigate to the relevant conversation and message, and the ability to disable push notifications just to name a few of them! The list also expands to improvements, bugfixes and it’s way longer than what we can mention in here! Please, go straight to the fulll changelog for all the details, because there are a lot of them!

Fluux Messenger Rose Pine theme.

• Gajim has released version 2.4.6 of its free and fully featured chat app for XMPP. This release can now give you a clue if it’s night for your contacts and comes with improvements for the activity feed, better display of mentions, fixed message scrolling, and many bugfixes. Thank you for all your contributions! You can take a look at the changelog for all the details.

Gajim: A message mentioning you

• Monal has released version 6.4.20 for iOS and macOS with a rather large list of fixes.
• Monocles has released version 2.1.5 of its chat client for Android. This release brings fixes on import settings and hide offline. It implements swipe to previous or next media in preview, clear push notification configuration values, and work on UnifiedPush to add support for link activity among other niceties!
• Movim has released version 0.33, code named Halley! After months of work and hundreds of commits, this is the biggest Movim release ever made. This release massively scales up Movim’s architecture while introducing long-awaited, and exclusive, new features like spaces, shortcuts, hats, swipe to reply, videoconference, audio and screen sharing, categorizing content during calls, refactored notifications, new administration tools and accessibility improvements, a big Funding Campaign for 2026, and even two new mascots: Miho and Stash! A lot of work was also done to improve accessibility thanks to NLnet funding. Head over the official release announcement and dive directly into the exciting things you can find in this release!

Movim: Spaces; already compatible with ejabberd. Prosody support coming very soon!

• Poezio has released versions 0.16.1 and 0.17 of its console XMPP client. The former is a bugfix release that brings mostly fixes and internal stuff, but also adds the ability to see redacted/moderated messages if you wish so, particularly useful if you are the one moderating. The latter is a small release focused on receiving and sending message reactions! You can find all the details in their respective links.

Poezio: receiving message reactions

Poezio: sending message reactions

• Profanity has released version 0.18.0 of its console based XMPP client written in C. This release adds spellcheck highlighting support and implements asynchronous external editor support while introducing quite a few bugfixes. Please make sure to read the changelog for all the details!

XMPP Servers

• ProcessOne has released ejabberd 26.04. This security release includes options to limit XML parser, and other minor bugfixes. It is strongly encouraged that you update ejabberd as soon as possible. Make sure to read the changelog for all the details and a complete list of fixes and improvements on this release.
• Prosody IM is pleased to announce versions 13.0.5 and 0.12.6. These are security releases for the Prosody 13.0.x stable series and for the old Prosody 0.12.x old stable series respectively. They fix multiple security issues, some memory leaks, some smaller bugs and changes which have been implemented since the previous releases. Full details about the security vulnerabilities can be found in the security advisory. All Prosody operators on 13.0.4 or earlier, or on 0.12.5 or earlier, are encouraged to upgrade to 13.0.5 and/or 0.12.6 as soon as possible, or to review the advisory and implement appropriate mitigations. Read changelog for all the details, and as always, detailed download and install instructions are available on the download page for your convenience. Note: Support for the 0.12.x series ends in June 2026. This means it will no longer receive any fixes or updates, even for security issues. It is likely that 0.12.6 will be the last release from this series. Check out the guide on upgrading Prosody and the release notes for 13.0.0 before you upgrade to the 13.0.x series.

XMPP Libraries & Tools

• jabber.el, the XMPP client for Emacs, versions 0.10.0 to 0.10.6 have been released. Full details on all the releases in the changelog.
• librssguard-xmpp, a plugin for the RSS Guard desktop feed reader that offers basic XMPP support to fetch real-time (push) ATOM/PubSub entries and single/multi user chat messages.
• python-nbxmpp, a Python library that provides a way for Python applications to use the XMPP network, version 7.2.0 has been released. Full details on the changelog.
• QXmpp, the cross-platform C++ XMPP client and server library, versions 1.14.6, 1.14.7, 1.15.0 and 1.15.1 have been released. Full details on the changelog.
• Slidge versions 0.3.8 and 0.3.9 have been released. The former comes with the usual bug fixes and introduces image link previews and contact- and room-specific commands along with a lot of internal changes to improve the code maintainability. The latter is a bugfix release, notably for a crash triggered by using chat commands introduced by a refactor of the commands system in the previous release. You can check the intermediate changelog from 0.3.7 to 0.3.9 for all the details.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• Message Archive Management: Trim Command
  • This specification describes how a client can request “trimming” of an archive.
• Group Chat Reporting
  • This specification describes how a client can report abuse and spam in a MUC or other group chat context.
• Occupant Mute Synchronization
  • Allows synchronizing a list of muted group chat participants between multiple clients.
• New MUC
  • This document specifies an enhanced Multi-User Chat protocol that is broadly backwards compatible with that of XEP-0045(Multi-User Chat), but adds a number of key improvements.
• Payment Required
  • This specification defines an XMPP protocol extension that enables services to require payment before granting access to a resource. It provides a payment-system neutral invoice format supporting multiple concurrent payment options, including bank transfers (SEPA, IBAN, UPI) and instant-settlement networks (Lightning Network), and integrates with the existing CAPTCHA challenge mechanism defined in XEP-0158 (CAPTCHA Forms).
• Emoji Markup
  • This specification leverages Message Markup and Stateless file sharing or Stateless Inline Media Sharing (SIMS) to send custom emojis.

New

• Version 5.6.7.8 of XEP-0512 (XMPP as Interpretive Dance)
  • Initial published version. (gdk)
• Version 0.1.0 of XEP-0513 (Explicit Mentions)
  • Accepted as Experimental by council vote on 2026-03-31 (dg)

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

• No XEPs deferred this month.

Updated

• Version 1.35.4 of XEP-0045 (Multi-User Chat)
  • Add clarification how to unset a reserved nickname when modifying the member list.
  • Split passage which defines how to modify the member list into multiple sentences to improve readability. (ph)
• Version 1.1.0 of XEP-0345 (Form of Membership Applications)
  • Apply policy changes after Board vote on 2026-04-16.
  • Allow Legal Name to be provided privately to the Secretary instead of published.
  • Add support for alternative public identifiers.
  • Clarify handling of private information and alignment with XSF disclosure policy. (gdk)
• Version 0.9.1 of XEP-0384 (OMEMO Encryption)
  • Fix using id=0 in examples. Spec requires positive numbers. (XEP Editor: dg)
• Version 0.2.1 of XEP-0413 (Order-By)
  • Replace old namespace use in examples. (jp)
• Version 0.2.0 of XEP-0509 (Initial Authentication Pipelining)
  • Updates based on implementation. (dwd)

Last Call

Last calls are issued once everyone seems satisfied with the current XEP status. After the Council decides whether the XEP seems ready, the XMPP Editor issues a Last Call for comments. The feedback gathered during the Last Call can help improve the XEP before returning it to the Council for advancement to Stable.

• No Last Call this month.

Stable

• No stable XEPs this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Newsletter Contributors & Translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

• Contributors:

  • To this issue: emus, cal0pteryx, Gonzalo Raúl Nemmi, Ludovic Bocquet, XSF iTeam

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • Italian: Mario Sabatino, Roberto Resoli
  • Portuguese: Paulo

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF GitHub repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our XSF Communications Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

• gathering news in the XMPP universe
• short summaries of news and events
• summary of the monthly communication on extensions (XEPs)
• review of the newsletter draft
• preparation of media images
• translations
• communication via media accounts

Unsubscribe from the XMPP Newsletter

For this newsletter either log in here and unsubscribe or simply send an email to newsletter-leave@xmpp.org. (If you have not previously logged in, you may need to set up an account with the appropriate email address.)

License

This newsletter is published under CC BY-SA license.

Here is a new version for slixmpp, the python XMPP library.

Thanks to everyone involved for this release!

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

This is a security release for the Prosody 0.12.x old stable series. It addresses multiple security issues, some memory leaks and some smaller bugs which have been fixed since the previous release.

Full details about the security vulnerabilities can be found in our security advisory. We encourage all Prosody operators on 0.12.5 or earlier to upgrade to 0.12.6 or 13.0.5 as soon as possible, or to review the advisory and implement appropriate mitigations.

Note: Support for the 0.12.x series ends in June 2026. This means it will no longer receive any fixes or updates, even for security issues. It is likely that 0.12.6 will be the last release from this series. Check our guide on upgrading Prosody and the release notes for 13.0.0 before you upgrade to the 13.0.x series.

A summary of changes in this release:

Security

• mod_proxy65: Consistently apply authorization checks
• mod_proxy65: Don’t proxy data until after bytestream activation
• mod_c2s, mod_s2s: Introduce new pre-authentication stanza size limit
• Add limit for stanza max child elements
• mod_c2s: Remove timers immediately on disconnection
• net.server_epoll: Clean up timers after disconnection

Fixes and improvements

• Fix memory leak in module API

Minor changes

• util.prosodyctl.check: Improve error handling of UDP socket setup (for #1803)

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

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

This is a security release for the Prosody 13.0.x stable series. It fixes multiple security issues, some memory leaks and some smaller bugs and changes which have been implemented since the previous release.

Full details about the security vulnerabilities can be found in our security advisory. We encourage all Prosody operators on 13.0.4 or earlier to upgrade to 13.0.5 as soon as possible, or to review the advisory and implement appropriate mitigations.

A summary of changes in this release:

Security

• mod_proxy65: Consistently apply authorization checks
• mod_proxy65: Don’t proxy data until after bytestream activation
• mod_c2s, mod_s2s: Introduce new pre-authentication stanza size limit
• Add limit for stanza max child elements
• mod_c2s: Remove timers immediately on disconnection
• net.server_epoll: Clean up timers after disconnection

Fixes and improvements

• net.http.parser: Fix handling of chunked request
• MUC: Advertise hats feature on room JID (thanks Daniel)
• moduleapi: Use multitable add/remove instead of set (fixes memory leak)
• mod_cloud_notify: Fix leaking iq response handlers by using send_iq()
• Improve federation with servers using only IP addresses
• prosody: Prevent loading local code when installed system-wide
• mod_http_file_share: Improve handling of Range requests
• mod_carbons: Fix some carbons decision-making bugs (fixes #1861: mod_carbons does not forward “sent” MUC PMs to other clients)

Minor changes

• net.resolvers: Fix to avoid SRV lookups for IP addresses
• prosody: Abort earlier on incompatible Lua version
• mod_turn_external: hand out credentials for type == turns too
• mod_s2s: Fully validate stream addressing
• prosodyctl check features: Warn if http file sharing enabled on both host and component
• util.prosodyctl: Don’t check for mod_posix being disabled, it’s deprecated
• util.startup: Improve error message when failing to load config file
• util.x509: Add support for iPAddress certs
• prosodyctl: Trim any trailing newline from password entry
• mod_admin_shell: Make cert index search path relative to config file
• mod_admin_shell: Improve multi-host command handling
• mod_admin_shell: Show help listing when specifying only a section name
• mod_admin_shell: Ensure password validity when setting passwords for new/existing users
• mod_account_activity: Handle authentication provider returning no user info
• config: Use default value when enum option has incorrect value
• mod_http: “Handle” streaming requests to avoid invoking redirect handler

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

This is a maintenance release with a few notable additions: RTL language support, faster reconnection after stream-management resume, and a handful of reliability fixes scattered across reconnect edge cases.

RTL layout support (Arabic and Hebrew) and User interface tweaks

Fluux Messenger now renders correctly in right-to-left languages. Arabic and Hebrew translations are included in this release. Both are beta quality, so if you spot translation errors or layout glitches, please open an issue. Getting community feedback early is the fastest way to improve coverage.

On the UI side, blockquotes now use decorative quotation marks, a small polish detail that also helps in RTL contexts where quote direction matters.

Reconnection: faster and far more reliable

A significant chunk of this release is dedicated to making reconnects work the way they should. If you&aposve seen Fluux Messenger freeze after waking your laptop, or loop on reconnect attempts, most of those scenarios are addressed here.

Faster resume: When stream management successfully resumes a session, the client now skips redundant MAM queries. If the stream was cleanly resumed, there&aposs no need to re-fetch history, so reconnection feels almost instant in good network conditions.

Sleep/wake handling: Two separate bugs could cause the app to stall after a system sleep. One was a Tauri-specific reconnect stall, now recovered via native keepalive with a proxy fallback. The other was a post-wake auto-connect stall that happened after SASL negotiation completed but before the session was fully established. Both are fixed.

Loop prevention:

 The reconnect attempt counter was incorrectly capped at the backoff ceiling, meaning it would stop growing and could trigger premature reconnect loops. That&aposs fixed, and superseded connection attempts now get a dedicated error class so they&aposre handled cleanly rather than causing UI freezes.

MUC room state: Room state is now properly preserved across stream-management resume and interrupted fresh sessions. Previously, a reconnect could wipe stored room messages or fail to restore saved rooms, leaving history empty after resume. Both are fixed: live room messages are written directly to IndexedDB, and rooms are restored through the connect call so history loads correctly after SM resume.

SASL2 and FAST token improvements

Several fixes land around SASL2 and FAST token handling:

• The websocket stream from attribute is now correctly set, which is required for SASL2 to be accepted on compliant servers.
• FAST token rotation now works correctly across page-reload reconnects.
• Token authentication is retried when the server field was initially empty on login.
• A spurious "FAST token deleted" log message that appeared on first login (when no token existed yet) is suppressed.
• The SASL2 user-agent identifier is updated, and server-side FAST token invalidation is triggered on logout.
• The outbound stream-management state is now hydrated on resume, preventing an ackQueue crash that could occur in certain reconnect scenarios.

Performance: per-conversation subscriptions

Typing indicators and draft state now use per-conversation subscriptions rather than a single global subscription. This reduces re-renders in the conversation list during background sync, which was noticeable when many conversations were active simultaneously. The list stays responsive while the client is catching up on missed messages.

Other fixes worth noting

• Notifications: On web, notifications now use ServiceWorker.showNotification() for reliable delivery, replacing the previous approach that could silently fail.
• Image lightbox: The lightbox no longer upscales images past their natural resolution, displaying the full-resolution original at actual size.
• Web image cache: If the cache fetch fails, the client now falls back to loading directly from the URL instead of showing nothing.
• Upload errors: HTTP upload errors are now displayed in the UI rather than failing silently. HTTP upload URLs are also now allowed.
• Dynamic import failures: On failure, the client probes the runtime before reloading, and auto-reloads if the probe succeeds, skipping unnecessary hard reloads.
• Discovery calls: Service discovery calls now run before the serial session-setup chain, which can shave time off the initial connection in some server configurations.
• Accessibility: The scroll-to-bottom FAB now uses inert instead of aria-hidden, and the message toolbar "more" menu button vertical alignment is fixed.

Getting 0.15.2

The latest release is available on our website. The full changelog is in CHANGELOG.md on Github.

If you run into issues, especially around the new RTL translations or any of the reconnect scenarios, please open an issue. This release fixes a lot of edge cases and we want to make sure nothing slipped through.

Here is yet another poezio release focused on message reactions!

Poezio is a terminal-based XMPP client which aims to replicate the feeling of terminal-based IRC clients such as irssi or weechat; to this end, poezio originally only supported multi-user chats and anonymous authentication.

Contents:

• New limits options for XML parser
• ChangeLog
• Acknowledgments
• ejabberd 26.04 download & feedback

New limits options for XML parser

This release adds new options that limit max memory used by XML parser used to process XMPP payloads, to prevent potential Denial of Service attack. The default values for pre-auth provide sufficient protection for ejabberd against non-authenticated users on c2s and s2s, so there is no need to change your configuration.

The option max_stanza_elements sets a limit on the maximum number of XML elements that an individual stanza can contain. By default, this option is set to infinity.

The pair of options pre_auth_max_stanza_elements and pre_auth_max_stanza_size define separate limits for sessions that haven&apost authenticated yet. The session will switch to the limits defined by the options max_stanza_elements and max_stanza_size after the client has successfully authenticated. The default values for these options are: 32 for pre_auth_max_stanza_elements and 8192 for pre_auth_max_stanza_size.

All those options are recognized inside listener sections, and can be applied to ejabberd_c2s and ejabberd_s2s_in listeners.

ChangeLog

Core

• Add new listener options to limit xml parser accepted input
• Improve leave_cluster command to work even in own node
• New predefined keyword DATABASE_PATH that points to the Mnesia spool dir
• Support HOST keyword in sql_database toplevel option, set nice default value
• Provide more details in log messages when using SQLite
• Update documentation of jwt_key to match the Docs site
• ejabberd_config: New default_ram_db/3 clause that checks module support
• ejabberd_sm: Remove session_counter, used for get_vh_session_number now removed

Modules

• mod_http_fileserver: Use integer in ejabberd_hooks:add as expected by "make hooks"
• mod_invites: Add --enable-bootstrap=no to configure options to bypass download (#4558)
• mod_invites: don&apost crash in get_invite_by_invitee_t for sql backend (#4566)
• mod_invites: quick howto for creating integrity check checksums
• mod_invites: remove dependency on jquery
• mod_mqtt: Define RAM callbacks as optional
• mod_mqtt: Use default_ram_db only if it really supports RAM storage
• mod_roster: Fix bug introduced in 26.03 in commit d5c1440 (#4564)
• mod_roster_sql: Cast approved integer as boolean when exporting Mnesia to SQL
• mod_shared_roster_sql: Fix typo introduced 10 years ago in commit 0ea0ba30

Container and Installers

• Bump Erlang/OTP 28.4.2
• make-binaries: Bump OpenSSL to 3.5.6

Full Changelog

https://github.com/processone/ejabberd/compare/26.03...26.04

Acknowledgments

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

• Stefan Strigler for the improvements in mod_invites

And also to all the people contributing in the ejabberd chatroom, issue tracker...

ejabberd 26.04 download & feedback

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

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

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

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

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

In recent years, software security has become a hot topic due to regulatory pressure (NIS2, EU Cyber Resilience Act, etc.). Beyond regulations, software communities and open source maintainers have also put security into focus, because open source libraries are often part of commercial software supply chains. This has reached the Erlang/Elixir ecosystem as well, and that is a good thing.

In this post, the SAFE team takes us through SAFE, Erlang Solutions’ security analysis tool for the BEAM, covering what it does, how it works, and what makes it effective in practice.

The BEAM is secure by default (Up to a point)

The BEAM’s architecture eliminates entire classes of bugs for free. Isolated process memory means processes can’t manipulate each other’s state, they only communicate through messages. Immutable data structures rule out a whole category of aliasing bugs. These are real wins, and they come without any effort from the developer.

But “secure by default” only goes so far. Application-level vulnerabilities, e.g., XSS, SQL injection, CSRF, unsafe deserialization, atom exhaustion, are just as possible in Erlang and Elixir as anywhere else. That’s the gap SAFE exists to cover.

What is SAFE?

SAFE (Security Analysis for Erlang/Elixir) is Erlang Solutions’ static analysis tool for the BEAM. It analyses compiled BEAM files rather than source code, so it works consistently across Erlang, Elixir, and Phoenix, including mixed-language codebases. SAFE is free for open source projects (subject to approval) and commercially available for other use cases.

It is developed in collaboration with academic research on static analysis from Eötvös Loránd University , and are aligned with the security recommendations of the Erlang Ecosystem Foundation (EEF).

SAFE detects a broad range of vulnerabilities, including:

• Cross-Site Scripting (XSS)
• SQL injection
• Command injection
• Remote Code Execution
• Denial of Service (e.g. atom exhaustion)
• Unsafe serialisation
• Cross-Site Request Forgery (CSRF)
• Session hijacking, fixation, and information leakage
• Content Security Policy (CSP) misconfigurations

Data-flow analysis: the core of what makes SAFE different

The central feature that sets SAFE apart is data-flow analysis. Most static analysis tools work by pattern matching, they look for known dangerous function calls and flag them. The problem is that not every call to a dangerous function is actually dangerous. Without understanding the possible values flowing through the code, a tool has no way to tell the difference, and the result is a high rate of false positives.

SAFE takes a different approach. Data-flow analysis tracks what values variables can hold at each point in the program. This information is then used to filter the initial list of vulnerability candidates, eliminating findings where the data can be proven safe, and surfacing only the ones that represent real risk.

The practical impact of this is significant. In our tests across 7 popular open source BEAM projects (~70,000 lines of code), SAFE produced a false positive rate of 7.78% and that number continues to improve as we refine our analysis. We also manually review findings during development to further sharpen the filtering.

How data-flow analysis eliminates false positives

Example 1 — guarded atom creation

A common pattern in Elixir is to convert a binary to an atom only after validating it against an allowlist:

     
    def safe_to_atom(binary, allowed) do    
      if Enum.member?(allowed, binary), do: String.to_atom(binary)    
    end    

A pattern-matching tool sees String.to_atom/1 and flags it. SAFE’s data-flow analysis traces the possible values of binary at the point of the call and determines that it is always a member of a finite, controlled list so it eliminates the finding entirely.

Example 2 — finite compile-time atom generation

Metaprogramming is common in Elixir. Consider this pattern where atoms are generated at compile time:

 @variants [:case_a, :case_b, :case_c]    
    #    
    # ...    
    #    
    for var <- @variants do    
      defp unquote(var)() do    
        env = Application.get_env(:my_app, :environment)    
        if env == "test" do    
          unquote(Macro.escape(Module.get_attribute(__MODULE__, :"test_#{var}")))    
        else    
          unquote(Macro.escape(Module.get_attribute(__MODULE__, var)))    
        end    
      end    
    end    
         

The number of atoms created here is strictly bounded by the length of @variants, a compile-time constant. SAFE calculates this and correctly determines the atom count is finite hence no vulnerability. A tool without data-flow analysis cannot make this determination.

What SAFE catches in practice

Session management vulnerabilities

Session management vulnerabilities allow attackers to gain unauthorised access to user sessions, which can lead to data theft, unauthorised actions, and account takeover. SAFE detects session hijacking, session fixation, and session information leakage. Session hijacking occurs when an attacker gains access to cookie contents. To prevent this, thehttp_only and secure attributes should both be set to true when setting a cookie. Below is a vulnerable example:

 @spec set_cookie(Plug.Conn.t()) :: Plug.Conn.t()    
    def set_cookie(conn) do    
      Plug.Conn.put_resp_cookie(conn, "my_cookie", "true",    
        http_only: false,    
        max_age: @max_age # an integer    
      )    
    end    
         

Session fixation is an attack where a malicious user plants a session ID for a victim to use, then hijacks their account after login. The Plug.Session API provides the configure_session/2 function for renewing the session ID. When this function is misconfigured by setting the renew option to false, session fixation can occur.

Session information leakage can be prevented by encrypting cookie contents. Encryption can be enabled by setting the encryption_salt in Plug.Session. For non-session cookies, encryption can be enabled via the encrypt option in Plug.Conn.put_resp_cookie/4.

Content Security Policy misconfigurations

When it comes to Content Security Policy (CSP), any policy is better than none. Using :put_secure_browser_headers without a custom policy won’t be enough on its own:

   plug :put_secure_browser_headers, %{    
      "content-security-policy": "[Your Policy]"    
    }    
         

There are also dedicated plugs for this, such as PlugContentSecurityPolicy:

   plug PlugContentSecurityPolicy,    

SAFE inspects the policy content itself and will flag an overly permissive default. You should define your own policy, keeping it as restrictive as possible to avoid unintentionally whitelisting too much. Beyond that, SAFE checks that all pipelines accepting HTML have CSP protection at all, a gap that is easy to miss during development.

Results from the field

The top three vulnerability types are XSS, DoS, and CSP. Notably, a large share of DoS findings trace back to unguarded String.to_atom/1 calls, a known footgun that is consistently flagged in Erlang/Elixir documentation, yet still appears frequently in practice.

SAFE found a total of 90 vulnerabilities, of which 7 were false positives after manual investigation, a false positive ratio of 7.78%, and an area of active improvement.

The projects tested are anonymized to avoid identification, since the disclosed vulnerabilities may still be present in production systems. While this limits full reproducibility, responsible disclosure takes priority. Contact us at safe@erlang-solutions.com to discuss the methodology in detail.

Closing notes

Security analysis on the BEAM is a genuinely hard problem. The same flexibility that makes Erlang and Elixir so expressive also makes it easy to introduce subtle vulnerabilities without realising it. SAFE is built specifically for this environment, grounded in academic research, and designed to give you signals you can act on rather than noise you have to filter.

If you maintain an open-source project, SAFE is free: reach out to us at safe@erlang-solutions.com and after a short approval process you’ll receive a licence at no cost. For commercial use or a third-party security review of your system, get in touch with the team.

The post SAFE: Bringing Real Static Analysis to the BEAM appeared first on Erlang Solutions.

Here is 0.16.1, a bugfix and cleanup release for poezio, with exactly one new feature as an improvement over an existing plugin.

Poezio is a terminal-based XMPP client which aims to replicate the feeling of terminal-based IRC clients such as irssi or weechat; to this end, poezio originally only supported multi-user chats and anonymous authentication.

Real-time messaging sits at the centre of many modern digital products. From live chat and streaming reactions to betting platforms and collaborative tools, users expect communication to feel immediate and consistent.

When pressure builds, the system doesn’t typically collapse. It starts to drift. Messages arrive slightly late, ordering becomes inconsistent, and the platform feels less reliable. That drift is often the first signal that chat scalability is under strain.

Imagine a live sports final going into overtime. Millions of viewers react at once. Messages stack up, connections remain open, and activity intensifies. For a moment, everything appears stable. Then delivery slows. Reactions fall slightly out of sync. Some users refresh, unsure whether the delay is on their side or yours.

Those moments reveal whether the system was designed with fault tolerance in mind. If it was, the platform degrades predictably and recovers. If it wasn’t, small issues escalate quickly.

This article explores what breaks first in real-time messaging and how early architectural decisions determine whether users experience resilience or visible strain.

Real-Time Messaging in Live Products

Live products place real-time messaging under immediate scrutiny. On sports platforms, streaming services, online games, and live commerce sites, messaging is visible while it happens. When traffic spikes, performance issues are exposed immediately.

User expectations are already set. WhatsApp reports more than 2 billion monthly active users, shaping what instant communication feels like in practice. That expectation carries into every live experience, whether it is chat, reactions, or collaborative interaction.

Source: Statista

Live environments concentrate demand rather than distribute it evenly. Traffic clusters around specific moments. Concurrency can double within minutes, and those users remain connected while message volume increases sharply. That concentration exposes limits in chat scalability far more quickly than steady growth ever would.

The operational impact tends to follow a familiar pattern:

For live platforms, volatility comes with the territory.

When delivery slows or behaviour becomes inconsistent, engagement drops first. Retention follows. Users rarely blame infrastructure. They blame the platform.

Designing for unpredictable load requires architecture that assumes spikes are normal and isolates failure when it occurs. If you operate a live platform, that discipline determines whether users experience seamless interaction or visible strain.

High Concurrency and Chat Scalability

In live environments, real-time messaging operates under sustained concurrency rather than occasional bursts. Users remain connected, they interact continuously, and activity compounds when shared moments occur.

High concurrency is not simply about having many users online. It involves managing thousands, sometimes millions, of persistent connections sending and receiving messages at the same time. Every open connection consumes resources, and messages may need to be delivered to large groups of active participants without delay.

This is where chat scalability really gets tested.

In steady conditions, most systems appear stable. When demand synchronises, message fan-out increases rapidly, routing paths multiply, and coordination overhead grows. Small inefficiencies that were invisible during testing begin to surface. Response times drift. Ordering becomes inconsistent. Queues expand before alerts signal a problem.

High concurrency does not introduce entirely new issues. It reveals architectural assumptions that only become visible at scale. Concurrency increases are predictable in live systems. The risk lies in whether the messaging layer can sustain that pressure without affecting user experience.

Messaging Architecture Limits

The pressure created by high concurrency does not stay abstract for long. It shows up in the messaging architecture.

When performance degrades under load, the root cause usually sits there. At scale, every message must be routed, processed, and delivered to the correct subscribers. In distributed systems, that requires coordination across servers, and coordination carries cost. Under sustained traffic, small inefficiencies compound quickly.

Routing layers can become bottlenecks when messages must propagate across multiple nodes. Queues expand when incoming traffic outpaces processing capacity. Latency increases as backlogs grow. If state drifts between nodes, messages may arrive late or appear out of sequence.

This is where the earlier discussion of chat scalability becomes tangible. It is not only about supporting more users. It is about how efficiently the architecture distributes load and maintains consistency when concurrency remains elevated.

These limits rarely appear during controlled testing with predictable traffic. They emerge under real usage, where concurrency is sustained and message patterns are uneven.

Well-designed systems account for this from the outset. They reduce coordination overhead, isolate failure domains, and scale horizontally without introducing fragility. When they do not, performance drift becomes visible long before a full outage occurs, and users feel the impact immediately.

Fault Tolerance and Scaling

If you operate a live platform, this is where design choices become visible.

Once architectural limits are exposed, the question is how your system behaves as demand continues to rise.

Scaling real-time messaging is about making sure that when components falter, the impact is contained. Distributed systems are built on a simple assumption: things break. You will see restarts, reroutes and unstable network conditions. But the real test is whether your architecture absorbs the shock or amplifies it.

Systems built with fault isolation in mind tend to recover locally. Load shifts across nodes. Individual components stabilise without affecting the wider service. Systems built around central coordination points are more vulnerable to ripple effects.

In practical terms, the difference shows up as:

• Localised disruption rather than cascading instability
  
• Brief slowdown instead of prolonged degradation
  
• Controlled recovery rather than platform-wide interruption
  

These behaviours define whether users experience resilience or instability.

Fault tolerance determines how the system behaves when conditions are at their most demanding.

Real-Time Messaging in Entertainment

Entertainment platforms expose weaknesses in real-time messaging quickly because traffic converges rather than building steadily over time.

When a live event captures attention, users respond together. Demand rises sharply within a short window, and those users remain connected while interaction increases. The stress on the system comes not from gradual growth, but from concentrated activity.

Take the widespread Cloudflare outage in November 2025. As a core infrastructure provider handling a significant share of global internet traffic, its disruption affected major platforms simultaneously. The issue was due to underlying infrastructure, but the impact was immediate and highly visible because so many users were active at once.

Live gaming environments operate under comparable traffic patterns by design. During competitive matches on FACEIT, large numbers of players remain connected while scores, rankings, and in-game events update continuously. Activity intensifies around key moments, increasing message throughput while persistent connections stay open.

Across these environments, the pattern is consistent. Users connect simultaneously, interact continuously, and expect immediate feedback. When performance begins to drift, the impact is shared rather than isolated.

A Note on Architecture

This is where architectural choices begin to matter.

Platforms that manage sustained concurrency and recover predictably under pressure tend to share certain structural characteristics. In messaging environments, MongooseIM is one example of infrastructure designed around those principles.

In practical terms, that means:

• Supporting large numbers of persistent connections without central bottlenecks
• Distributing load across nodes to reduce coordination overhead
• Containing failure within defined boundaries rather than allowing it to cascade
• Maintaining message consistency even when traffic intensifies
  

These design choices do not eliminate volatility. They determine how the system behaves when it does.

In live entertainment platforms, that distinction shapes whether pressure remains internal or becomes visible to users.

Conclusion

Real-time messaging raises expectations that are easy to meet under steady conditions and far harder to sustain when attention converges.

What breaks first is rarely availability. It is timing. It is the subtle drift in delivery and consistency that users notice before any dashboard signals a failure.

Live environments make that visible because traffic arrives together and interaction compounds quickly. Concurrency is not the exception. It is the operating model. Whether the experience holds depends on how the architecture distributes load and contains failure.

Designing for that reality early makes scaling more predictable and reduces the risk of visible strain later.If you are building or modernising a platform where real-time interaction matters, assess whether your messaging architecture is prepared for sustained concurrency. Get in touch to continue the conversation.

The post What Breaks First in Real-Time Messaging? appeared first on Erlang Solutions.

We have shipped Fluux Messenger 0.15, and it is packed with major advancements. After the excitement of the FOSDEM launch, the team put their heads down on three things users were asking for most: the ability to find past messages, a messenger that looks and feels different from Discord, and richer collaboration tools for group rooms.

Find anything, instantly

Full-text search is now built into Fluux Messenger, every conversation, every room, searchable, locally and instantly.

The search engine runs entirely on your device using an IndexedDB inverted index with prefix matching and highlighted result snippets. No messages leave your machine to power this. For rooms with deep history on the server, results are supplemented with MAM (Message Archive Management) server-side queries, giving you the best of both worlds: speed from local cache, completeness from the archive.

A find-in-page mode (Cmd+F) lets you scan within any conversation, mirroring the browser experience developers expect.

Make it yours: a full theme system

Fluux Messenger now ships with a proper design token system, three-tier (Foundation → Semantic → Component), and a theme picker bundled in the Appearance settings.

Twelve themes are available out of the box: Fluux, Dracula, Nord, Gruvbox, Catppuccin Mocha, Solarized, One Dark, Tokyo Night, Monokai, Rosé Pine, Kanagawa, and GitHub. If none of them are quite right, you can import your own theme or inject CSS snippets directly. A global accent color picker with theme-specific presets lets you go further without writing a single line of code.

Font size adjustment is now in Appearance settings as well.

Polls in group rooms

Reaction-based polls are now a first-class feature in MUC rooms. Create a poll with custom emojis, set a deadline, and let participants vote. The room enforces voting rules server-side, so results are trustworthy. Polls can be closed and reopened, and an "unanswered" banner nudges participants who haven&apost voted yet. Results are visualized inline and captured in the activity log.

Faster connections with FAST authentication

Fluux Messenger now supports XEP-0484: FAST (Fast Authentication Streamlining Tokens) alongside SASL2. Reconnection after a network interruption or wake from sleep is now possible in the web version.

Media cache

Downloaded images are now cached to the filesystem, so they load instantly on revisit and don&apost count against your bandwidth twice. A new storage management screen in settings lets you see and clear the cache.

Polish and fixes worth noting

• Emoji picker (emoji-mart) with dynamic viewport positioning, so it never clips off-screen
• Last Activity (XEP-0012) — offline contacts now show how long ago they were last seen
• Syntax highlighting for code blocks, lazily loaded per language, with theme integration and a fullscreen modal for long snippets
• IRC-style mention detection with consistent per-user colors (XEP-0392)
• VCard popovers on occupant and member list nicks
• Scroll-to-bottom button now shows an unread badge and implements two-step scroll: first click jumps to the new message marker, second click goes to the very bottom
• Particle burst animation when adding a reaction, and a message send slide-up animation
• Upgraded to React 19 with the React Compiler for automatic memoization, and Vite 8 with lazy-loaded views for a faster startup

A note on Windows signing

Starting with 0.15, the Windows binary is no longer signed. This is a temporary decision while we work through the signing infrastructure — full details are in issue #290. On install, Windows will prompt you to manually trust the application. We know this isn&apost ideal and are working to restore signed builds.

Get it

Fluux Messenger 0.15 is available now. Download it here or check the full changelog on GitHub for every detail.

As always, feedback and bug reports are welcome. The community is the best part of building open-standard messaging software.

I have recently started experimenting with adding support for three additional databases in Openfire: MariaDB, Firebird and CockroachDB.

This work is still exploratory. Before committing to this direction, I would like to get a better understanding of whether this is actually valuable to the Openfire community.

I have prepared initial pull requests for each database:

• MariaDB: https://github.com/igniterealtime/Openfire/pull/3240 (OF-3239 in our issue tracker)
• Firebird: https://github.com/igniterealtime/Openfire/pull/3241 (OF-3237 in our issue tracker)
• CockroachDB: https://github.com/igniterealtime/Openfire/pull/3243 (OF-3238 in our issue tracker)

These are not production-ready, but intended to validate feasibility and surface any obvious issues.

Why these databases?

MariaDB is widely used as a drop-in replacement for MySQL. Although Openfire supports MySQL, MariaDB is not explicitly treated as a first-class option. Given how often it is used in practice, formal support could provide more confidence for administrators.

Firebird represents a more niche but still relevant ecosystem. It is commonly found in long-lived, on-premise systems where changing the database is not realistic. Supporting it could make Openfire easier to adopt in those environments.

CockroachDB targets modern, distributed deployments. With its PostgreSQL compatibility and focus on resilience and scalability, it could make Openfire more attractive for cloud-native and multi-region setups.

Trade-offs

Supporting additional databases comes with a cost: more code paths, more testing, and more long-term maintenance. The key question is whether the added flexibility justifies that complexity.

Feedback wanted

Before taking this further, I would really appreciate feedback from the community:

Are you using (or considering) MariaDB, Firebird or CockroachDB with Openfire? Would official support influence your deployment decisions? Do you see this as valuable, or as unnecessary complexity?

Please share your thoughts on the pull requests or through the usual community channels!

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

4 posts - 4 participants

Read full topic

XMPP Newsletter Banner

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

The XMPP Newsletter is brought to you by the XSF Communication Team. Just like any other product or project by the XSF, the Newsletter is the result of the voluntary work of its members and contributors. If you are happy with the services and software you may be using, please consider saying thanks or help these projects!

Interested in contributing to the XSF Communication Team? Read more at the bottom.

XSF Announcements

XSF Membership

Being an elected member of the XMPP Standards Foundation signals a commitment to open standards and professional engagement in / with the XMPP community. Here, your membership helps position the XSF as a healthy organization, which in itself is valuable. It also grants voting rights on technical and administrative matters within the XSF. The application is a light-weight and free of cost process and you can use your membership to get more involved more easily, too. If you are interested in joining the XMPP Standards Foundation as a member, please apply to our 2nd quarterly call for members admissions before May 17th, 2026, 00:00 UTC.

XMPP Events

• XMPP Sprint in Berlin (DE / EN): will take place in June, from Friday 19th to Sunday 21st 2026, at the Wikimedia Deutschland e.V. offices in Berlin, Germany. If this sounds like the right event for you, come and join us! Just make sure to list yourself here, so we know how many people will attend and we can plan accordingly. If you have any questions or concerns, join us at the chatroom: sprints@muc.xmpp.org!
• XMPP at FOSSY 2026: This year’s edition of FOSSY, the fourth Free and Open Source Software Yearly conference, will take place during the month of August, from Thursday 6th to Sunday 9th 2026 at the University of British Columbia, Vancouver, Canada. As always, there will be an XMPP Track and the call for proposals is open until May 22, 2026. Once again, this year JMP is pleased to announce its annual offer for funding to the potential speakers who would like to host a talk on the XMPP track. Please, join them at discuss@conference.soprani.ca, and don’t hesitate to ask for more information!

Videos and Talks

• IETF125 Hackathon: XEP-0202 Entity Time, by Daniel Gultsch.

XMPP Articles

• Let’s Talk About Spaces in XMPP, by Timothée Jaussoin for the Movim Blog.
• Our new XMPP MUC BanBot, by ~dan for ~dan’s website on envs.net.
• Sending Jabber/XMPP Messages via HTTP, by Daniel Gultsch.
• Self-hosting UnifiedPush with Conversations as Distributor, by Daniel Gultsch.
• Installing ejabberd, by eltheanine for the The Teabag Ninja.
• Fluux Messenger 0.14.0 - Full Room Control & Richer Contact Profiles, by Mickaël Rémond for the ProcessOne Blog.
• My Prosody setup with Docker Compose, by gsvd.dev for the gsvd.dev blog.
• The Slidge family is growing, from the slidge.im blog/.
• JoinJabber: thanks to the excellent work done by one of the community members, the whole site is now fully available in Portuguese (BR)! You can check the translation status on their web translation status page and help out with other translations!
• Introducing CLabber: A terminal UI (TUI) XMPP (Jabber) client written in Common Lisp.
• Upgrade ejabberd on Debian NOW: Chances might be that you are running a Debian based ejabberd server. Unfortunately push for all your Monal users on that server will break in less than 2 months. And chances are that some of your S2S connections are already failing today. By Thilo Molitor for the monal-im blog.

XMPP Software News

XMPP Clients and Applications

• aTalk has released versions 5.2.0 and 5.2.1 of its encrypted instant messaging with video call and GPS features for Android. The former version implements XEP-0384 (OMEMO Encryption), decryption of OMEMO messages, upgrades smack to support XEP-0420 (Stanza Content Encryption) and other relevant updates and fixes, while the latter introduces a fix for an incorrect fetching. You can check the intermediate changelog from 5.1.0 to 5.2.0 and 5.2.0 to 5.2.1 for all the details.
• Conversations has released versions 2.19.13, 2.19.14 and 2.9.15 for Android. These releases bring fixes for a crash when changing OMEMO bundle access model, a crash when sharing Quicksy XMPP addresses and a fix for Quicksy registration on older devices, shows hats in public conferences where available, shows a warning in the chat if a contact is in different time zone and it is night time for them, a refactored automatic DND handling (based on system DND), and a warning in the chat window if contact is in DND mode. You can take a look at the changelog for all the details or check the intermediate changelogs from 2.19.12 to 2.19.13, 2.19.13 to 2.19.14 and/or 2.19.14 to 2.19.15.

Conversations showing contact’s local time in the chat window

• Cheogram has released version 2.19.0-5 for Android. A bugfix release that addresses many crash fixes, never use iterative DNS for DNSSEC, fallback public server is now jabber.fr, merge security fixes from upstream, allow emoji search by emoji (eg for reactions), better isApp logic to default to commands list or not, and fix for channel avatars on some older servers. Make sure to check out the changelog for all the details.
• Fluux Messenger has released versions 0.13.3 and 0.14.0, of its modern, cross-platform XMPP client for communities and organizations, with a list of additions, new features, improvements and bugfixes that is way longer than what we could ever mention in here! You can go straight to the full changelog or check the intermediate changelogs from 0.13.2 to 0.13.3 and/or 0.13.3 to 0.14.0 for all the details!

Fluux Messenger team chat

• Gajim has released version 2.4.5 of its free and fully featured chat app for XMPP. This release lets you know when somebody reacted to one of your messages. It also comes with automatic timezone updates and improvements for macOS, and bugfixes. Thank you for all your contributions! You can take a look at the changelog for all the details.

Gajim automatic timezone updates

• Monal has released version 6.4.19 for iOS and macOS with a rather large list of fixes.
• Monocles has released version 2.1.4 of its chat client for Android. This release brings fixes for message moderation, truncated text, link click handling, disappearing reactions popup, MUC destruction, a crash when message body not spannable, allow camera/mic in command UI webview and pick channel binding fallback when server has no XEP-0440 (SASL Channel-Binding Type Capability) support.
• Poezio has released version 0.16 of its console XMPP client. This release implements XEP-0425 (Moderated Message Retraction) a receiving side of moderation, XEP-0424 (Message Retraction) retraction events, XEP-0377 (Blocking Command Reports) a new /report plugin to report spam, a new /tcp-reconnect to kill TCP connections on faulty networks, a tls_verify_cert option that can be set to false if the user wishes so, and several fixes. You can find all the details in the release announcement.

Moderated message retraction testing in Poezio

• Profanity has released version 0.17.0 of its console based XMPP client written in C. The release announcement for this version is so long that it spans over 200 lines worth of information, which is a lot more than what we could ever list in here, so please make sure to read the changelog for all the details!
• Psi+ has released version 1.5.2132.0 installer of its development branch of the Psi XMPP client.
• Wimsy has released version 0.0.5 of it cross-platform XMPP client built with Flutter.
• xmpp-web has released version 0.12.0 of its lightweight web chat client for XMPP server. You can read the intermediate changelog from 0.11.0 to 0.12.0 for all the details.

XMPP Servers

• The Ignite Realtime community is happy to announce the release of Openfire 5.0.4. This release continues the efforts to provide a stable 5.0.x series releases whilst they finalize work on the upcoming 5.1.0 release. Please refer to the full changelog for all the details or to the intermediate changelog for versions 0.5.3 to 0.5.4.
• MongooseIM has released MongooseIM 6.6.0 with more additions, changes and fixes than what we can reasonably list in here! Make sure to read the changelog for all the details!
• ProcessOne is pleased to announce another bugfix release: ejabberd 26.03. This brings support for roster pre-approval, and more than 100 commits with bugfixes all around, many of them dedicated to the new mod_invites, including also many security fixes. Make sure to read the changelog for all the details and a complete list of fixes and improvements on this release.

XMPP Libraries & Tools

• matridge, the Matrix to XMPP gateway based on Slidge and nio, versions 0.3.3 has been released. You can read the intermediate changelog from 0.3.2 to 0.3.3 for all the details.
• QXmpp, the cross-platform C++ XMPP client and server library, versions 1.14.4 and 1.14.5 have been released. Full details on the changelog.
• Rusty-Filer, an external XMPP file server for HTTP uploads. An alternative to the internal HTTP file servers of Ejabberd and Prosody, written in Rust, version 1.0.0 has been released.
• Siltamesh, a simple bridge between Meshtastic and XMPP networks, version 0.2.0 has been released.
• slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.11beta1 has been released. You can read the intermediate changelog from 0.3.10 to 0.3.11beta1 for all the details.
• slidgnal, a feature-rich Signal to XMPP puppeteering gateway, based on slidge and signalmeow, version 0.3.0beta10 has been released. You can read the intermediate changelog from 0.3.0beta9 to 0.3.0beta10 for all the details.
• Slixmpp, the MIT licensed XMPP library for Python 3.7+ version 1.14.1 has been released. You can read the official release announcement for all the details.
• Xepher, a plugin written in C++23 that adds full XMPP support to WeeChat. It targets XEP-0459 (XMPP Compliance Suite 2022) and implements a broad set of modern XEPs — including XEP-0384 (OMEMO encryption), XEP-0313 (Message Archive Management), XEP-0363 (HTTP file upload), XEP-0472 (Pubsub Social Feed) microblogging via PubSub, and more.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• Explicit Mentions
  • This specification defines a way to explicitly mention a person or groups of people.

New

• No new XEPs this month.

Deferred

If an experimental XEP is not updated for more than twelve months, it will be moved off Experimental to Deferred. If there is another update, it will put the XEP back onto Experimental.

• No XEPs deferred this month.

Updated

• Version 0.2.1 of XEP-0461 (Message Replies)
  • Update the example to use the correct fallback namespace. (mye)
• Version 0.1.1 of XEP-0473 (OpenPGP for XMPP Pubsub)
  • Fix inconsistency between text and example; it’s the key attribute that carries the shared secret ID (formerly it was secret). (jp)
• Version 0.1.1 of XEP-0493 (OAuth Client Login)
  • Fix reference to RFC 7628 for SASL OAUTHBEARER (XEP Editor: dg)
• Version 0.1.1 of XEP-0511 (Link Metadata)
  • Added security consideration. Added alt text to example. (spw)

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.

• Last Call for comments on XEP-0377 (Blocking Command Reports)
  • This Last Call begins on 2026-03-31 and shall end at the close of business on 2026-04-14.

Stable

• No stable XEPs this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

Looking for job offers or want to hire a professional consultant for your XMPP project? Visit our XMPP job board.

Newsletter Contributors & Translations

This is a community effort, and we would like to thank translators for their contributions. Volunteers and more languages are welcome! Translations of the XMPP Newsletter will be released here (with some delay):

• Contributors:

  • To this issue: emus, cal0pteryx, Gonzalo Raúl Nemmi, Ludovic Bocquet, Sairam Bisoyi, XSF iTeam

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • Italian: Mario Sabatino, Roberto Resoli
  • Portuguese: Paulo

Help us to build the newsletter

This XMPP Newsletter is produced collaboratively by the XMPP community. Each month’s newsletter issue is drafted in this simple pad. At the end of each month, the pad’s content is merged into the XSF GitHub repository. We are always happy to welcome contributors. Do not hesitate to join the discussion in our Comm-Team group chat (MUC) and thereby help us sustain this as a community effort. You have a project and want to spread the news? Please consider sharing your news or events here, and promote it to a large audience.

Tasks we do on a regular basis:

• gathering news in the XMPP universe
• short summaries of news and events
• summary of the monthly communication on extensions (XEPs)
• review of the newsletter draft
• preparation of media images
• translations
• communication via media accounts

Unsubscribe from the XMPP Newsletter

For this newsletter either log in here and unsubscribe or simply send an email to newsletter-leave@xmpp.org. (If you have not previously logged in, you may need to set up an account with the appropriate email address.)

License

This newsletter is published under CC BY-SA license.

Chances might be that you are running a Debian based ejabberd server. Unfortunately push for all your Monal users on that server will break in less than 2 month. And chances are that some of your S2S connections are already failing today.

Some background

The Web-PKI is moving away from certificates having bot, the TLS Web Server Authentication and the TLS Web Client Authentication extended key usage enabled. Most CAs already stopped issuing certificates with the TLS Web Client Authentication EKU set or will stop doing so in a few month.

Traditionally both servers of an S2S connections in XMPP authenticate to each other. One is the server part of a TLS handshake (and needs the server EKU), the other one is the client part of the TLS handshake (and needs the client EKU). Which one is which, solely depends upon which server starts the underlying TCP connection (that one becomes the client in this connection).

The underlying problem

This mutual authentication breaks, once the client part can’t present a certificate having the client EKU. All TLS libraries fail the authentification in this case.

The solution

Fortunately almost all TLS libraries allow users to customize the certificate validation process and ejabberd was updated in version 25.08 (August 2025) to do exactly this: ignore the EKU when validating the certificate. But unfortunately it was too late to go into Debian Trixie, the current stable Debian version.

Debian

This is where the real problem starts. Many server operators use Debian because it is so extremely stable and well maintained. Of course Debian provides point releases to upgrade packages if they have some severe bug (like not being able to properly participate in S2S connections). The next point release will contain a fix for the problem, but that will still take more than a month to reach servers.

How to fix the situation

I urge all ejabberd server operators to take one of the following steps as soon as possible:

• Add trixie-proposed-updates to your sources.list file and update ejabberd to version 24.12-3+deb13u2
• Install these two packages kindly built by Holger (an ejabberd developer): https://ejabberd.messaging.one/download/s2s-fix/
• Install the official packages by ProcessOne from here: https://repo.process-one.net/ (caution: these packages use /opt/ejabberd, so you’ll need to copy your config from /etc/ejabberd over!)
• Switch to Prosody (Prosody’s fix for the S2S client EKU problem made it into Debian Trixie)
• Switch to some other distribution
• If you absolutely don’t want to take any action, please enable at least dialback by adding mod_s2s_dialback: {} to the modules section of your ejabberd config. But be aware: while this will fix the S2S connection to Monal’s push servers, other servers might not have turned it on (both parts must turn it on to be effective). The security of the connection will also be degraded when using dialback rather than properly verifying certificates.

Last words

Many thanks to Holger Weiß and Philipp Huebner for fixing this bug in Debian!