Meta just closed the gates on AI chatbots. I think this is an early warning.

Starting January 15, 2026, WhatsApp will ban all third-party general-purpose AI chatbots from its platform. ChatGPT, Perplexity, Poke, they&aposll all be gone. The only general-purpose AI you&aposll find on WhatsApp? Meta AI.

Meta&aposs stated reason: these bots place a "burden on its systems and support teams." The real reason is more likely control, of course.

But here&aposs what makes this fascinating:
While Meta is locking down WhatsApp, Discord—which has no AI ambitions of its own—just raised its server capacity to 25 million users. Why? Because Midjourney, a third-party AI tool, built its entire interface on Discord and now has over 20 million members in a single server.

Discord didn&apost build the AI. They just provided the platform. And they&aposre reaping the rewards.

Two platforms, two strategies, leading to two very different futures.

Meta is betting that owning both the AI layer and the communication layer is the path to dominance.

Discord is betting that being the best platform for AI, even AI they don&apost control, creates more value.

I feel like we&aposre watching a pattern repeat itself. We already fought the battle for open communication protocols. First we won, and then, in the consumer arena at least, we lost. Today we juggle a dozen incompatible messaging apps because federation was abandoned in favor of walled gardens.

Now the same battle is starting again, but this time it&aposs about AI agent interoperability and since AI interfaces are often chat-based today, the lock-in on messaging creates an opportunity to expand that lock-in to AI agents.

It will be like a new app store monopoly all over again.

Will your company&aposs procurement agent be able to negotiate with a supplier&aposs logistics agent if they&aposre built on different platforms? Will healthcare AI be able to securely federate across hospital systems? Or will we lock ourselves into incompatible agent ecosystems controlled by whoever moves fastest?

The IETF is starting to draft standards for agent-to-agent protocols. The A2A initiative is pushing for interoperability. But the window is closing.

If we don&apost act now, while these protocols are still being designed, we&aposll spend the next 20 years trying to regulate our way out of another fragmented mess.

I&aposve been thinking about this for a while. More coming soon.

But for now, ask yourself: Do we want platforms that lock out third-party AI agents (the Meta approach) or platforms that allow them to thrive (the Discord approach)?

Here&aposs what&aposs really at stake: Today&aposs decisions aren&apost just about which apps we use. They&aposre about whether AI agents themselves will be able to work across platforms and companies, or whether we&aposll fragment into incompatible ecosystems all over again.

---

So, what do you think? Should AI agents be able to work across platforms, or is vendor lock-in really inevitable?

The Erlang Solutions team has been creating webinars that share knowledge, spark ideas, and celebrate the BEAM community. Each one offers a chance to explore new tools, hear fresh perspectives, and learn from the people building scalable and reliable systems every day.

If you haven’t tuned in yet, here’s a look at some of our recent sessions, full of practical insights and new thinking shaping the future of the BEAM.

SAFE for Elixir: Strengthening Security for Elixir and Erlang

In SAFE for Elixir, Robert Fiko and Mohamed Ali Khechine from the SAFE team talk about what it really means to build secure software. 

They introduce SAFE for Elixir, a tool created with researchers at Eötvös Loránd University, that helps developers spot and fix vulnerabilities before they cause problems. It’s an honest and practical session about weaving security into your development process and making it part of your everyday workflow.

Messaging in Regulated Markets: Compliance from Day One

Compliance isn’t the most exciting part of building software, but it’s one of the most important. It’s also easy to leave until the end, and that’s where the problems usually start.

In Messaging in Regulated Markets: Compliance from Day One, Piotr Nosek explores what happens when you treat compliance as part of the design process instead of a last-minute fix. He also looks at how MongooseIM helps teams meet tough standards like GDPR, HIPAA, and NHS, while still building modern messaging tools with encryption, notifications, and video calls.

Gleam’s Interoperability with Erlang and Elixir

Gleam’s Interoperability with Erlang and Elixir is a hands-on look at how this type-safe language fits into the BEAM family. 

Raúl Chouza uses a live Tic-Tac-Toe demo to show how Gleam works seamlessly alongside Erlang and Elixir, mixing dependencies and even pulling in modules like Phoenix LiveView. It’s a relaxed and engaging session that shows how developers can experiment across languages and still enjoy all the reliability the BEAM has to offer.

What You May Not Know About with

Every Elixir developer has come across with, but not everyone has taken the time to see what it can really do. In What You May Not Know About with, Brian Underwood and Adilet Abylov take a closer look at one of Elixir’s most overlooked features. 

They show how it can make code cleaner, easier to follow, and far more expressive when it comes to handling complex logic. The session walks through common mistakes, explores ways to manage pattern matching, and shares practical tips for better error handling, all delivered in a way that makes you want to jump back into your editor and try it out.

Women in Elixir

Women in Elixir is a celebration of the people driving change across the BEAM community. Lorena Mireles shares insights from the Women in BEAM survey and her own experience in the industry, offering a thoughtful look at progress, opportunities, and the power of representation. 

She also highlights how mentorship, community events, and visibility can help more women thrive in tech and why inclusion benefits everyone.

Learning through our webinars

These webinars show what makes the BEAM community unique: a mix of curiosity, openness, and a constant drive to improve how we build and collaborate. They reflect the depth of knowledge across Erlang, Elixir, and Gleam, and the passion that keeps this ecosystem evolving.

You can check out these sessions and more on our webinars page.

The post ​​Expert Insights from Our Latest Webinars appeared first on Erlang Solutions.

You might have seen the XMPP Standards Foundation’s open letter to NEN about NTA 7532, the Dutch effort to standardise secure healthcare chat. It’s a good read, and, as it happens, right up our street.

If you’re building a chat system that has to actually talk to someone else’s chat system (and keep doctors happy while doing it), you’ll know: writing a specification is only half the battle. The other half is making sure that everyone follow it, and that everyone follows it in the same way.

That’s where the XMPP Interop Testing Framework comes in.

So, What Do We Do Again?

In short: we make sure XMPP software behaves the way the standards say it should.

We’ve built an open-source test framework that runs a bunch of automated checks against real XMPP servers using a real XMPP client library, testing everything from the core RFCs (6120, 6121, 7622) to the popular protocol extensions for things like:

• message receipts (XEP-0184)
• group chat (XEP-0045)
• file upload (XEP-0363)
• end-to-end encryption

It’s all designed to run in CI, with containers, and produce nice, clear pass/fail results, along with machine-consumable reports and human-readbale actionable information. The kind you can wave around in a meeting and say “See? Interoperable!”

Why NTA 7532 Folks Should Care

NTA 7532 is about making sure healthcare professionals can message each other securely, even when they’re on different systems and members of different organizations. That means encryption, integrity, and actual interoperability between products from different vendors.

You could write those requirements into a 200-page document (and you probably will). But to prove it works, you need tests. Preferably ones that don’t take a week to run by hand, and that aren’t only run just prior to launch and never again.

That’s exactly what we provide.

Our framework already checks for the building blocks that NTA 7532 is likely to depend on: authentication, transport security, message delivery, receipts, and so on. And because the tests are open and automated, every vendor can run the same suite - no secret sauce or proprietary knowledge required.

From “We Think” to “We Know”

Here’s the value add:

1. Validation - The framework tells you, with logs and evidence, whether a given implementation matches the spec or standard.
2. Transparency - Everyone can see what’s tested and why and how. The same tests for everyone, with the same criteria.
3. Continuous improvement - When specs change or new features appear, we add new tests. Easy.

It turns a written standard into a living, testable thing. If you want to know whether two systems will work together before putting them in front of clinicians, this is how you find out.

The Bigger Picture

The fun part is collaboration.

The XSF writes and maintains the XMPP specs. NEN and the folks behind NTA 7532 define the national healthcare chat profile. And we, the Interop Testing Framework team, provide the bit in the middle: the place where specs meet running code.

Together, we can prove that “open standard” isn’t just a phrase, but that it’s something you can test, verify, and rely upon.

What’s Next

We’d love to:

• run pilot tests with any NTA 7532-aligned vendors
• map specific NTA 7532 requirements to existing (or new) XMPP test cases
• publish anonymised results to show real-world interoperability
• feed our findings back to both the NTA 7532 working group and to the XSF

If that sounds like something you’d like to be part of: fantastic!

Come talk to us.

Get Involved

The framework’s open-source, so dive right in:

• Website
• Code

Whether you’re writing specs, building servers, or just trying to get two chat systems to agree on a message receipt, we’re here for you.

Let’s make interoperability not just a checkbox, but a test you can actually pass ✅

Splash image courtesy of Marcus Urbenz, Unsplash

Release Highlights:

• Added more Ad-Hoc Commands from XEP-0133
• Updated support for XEP-0317 Hats

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

Other contents:

• New option archive_muc_as_mucsub in mod_mam
• Removed support for Erlang/OTP older than 25.0
• Support for the new Erlang maybe expression
• Rename New SQL schema to Multihost, and Default to Singlehost
• Improved GitHub Workflows
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.10 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

New option archive_muc_as_mucsub in mod_mam

When this option is enabled incoming groupchat messages for users that have MucSub subscription to a room from which message originated will have those messages archived after being converted to mucsub event messages.

Removed support for Erlang/OTP older than 25.0

The ejabberd 24.12 release announcement explained that support for Erlang/OTP older than 25.0 was discouraged, it would be deprecated in future releases, and completely removed sometime after ejabberd 25.01. That explanation was mentioned several times in the subsequent ejabberd releases.

The initial reason to require Erlang/OTP 25 was that this version is the lowest we can easily use nowadays for running the CI tests.

Other reasons to remove support for Erlang lower than 25 are: to support maybe expression, and to remove duplicate code.

In order to support both new and very old Erlang/OTP versions, ejabberd source code included many duplicate code. All that duplicate code that is nowadays useless will be removed in a future ejabberd release.

Support for the new Erlang &aposmaybe&apos expression

The new maybe expression is supported since Erlang/OTP 25 (requires being enabled), and it is enabled by default since 27.

Now that ejabberd requires Erlang/OTP 25, and it enables the maybe expression, this can be used freely in ejabberd source code and modules.

See:

• Erlang Documentation: maybe Expression
• EEP 49: Value-Based Error Handling Mechanisms

Rename &aposNew&apos SQL schema to &aposMultihost&apos, and &aposDefault&apos to &aposSinglehost&apos

When ejabberd first got support for SQL storage, it only supported one vhost, so it made sense to not store the host in the SQL tables. Additionally, the SQL schema in ejabberd followed that of jabberd14, which didn&apost support multiple vhosts either.

When ejabberd got support for multiple vhosts, if several of them want to use SQL storage, the solution is to configure a different SQL database for each vhost using the host_config toplevel option.

However, when there are many vhosts configured in ejabberd, all of them using SQL storage, it is preferable to setup one single SQL database, and store the vhost in the tables. When that feature was added to ejabberd, it got the name of "new SQL schema". And the previous SQL schema was called "legacy", "old", and nowadays "default".

The problem with the terms "default" and "new" is that they are circumstantial, and do not really describe the schema features or purposes.

Now those terms have been renamed:

• "default SQL schema" ⟹ "singlehost SQL schema"
• "new SQL schema" ⟹ "multihost SQL schema"

Right now all names are supported, the previous (obsolete) and the renamed (preferred). No changes are needed in your existing configuration file or building instructions, but it is preferable if you can update your setup to the new terms:

When preparing configuration, the old and new arguments are:

./configure --enable-new-sql-schema
./configure --enable-multihost-sql-schema

When configuring ejabberd, the old and new toplevel options are:

new_sql_schema: true
sql_schema_multihost: true

When developing source code, the old and new functions are:

ejabberd_sql:use_new_schema()
ejabberd_sql:use_multihost_schema()

New API Commands

Several ejabberd modules implement new API Commands, most of them inspired by XEP-0133:

• ejabberd_admin:
  • restart_kindly
• mod_admin_extra:
  • count_banned
  • list_banned
• mod_announce:
  • announce_motd_delete
  • announce_motd_get
  • announce_motd_set_online
  • announce_motd_update
  • announce_send_all
  • announce_send_online
• mod_muc_admin:
  • muc_get_registered_nick
  • muc_get_registered_nicks

Added more Ad-Hoc Commands from XEP-0133

XEP-0133 describes 31 administrative tasks that should be available as ad-hoc commands.

ejabberd already implemented many of those ad-hoc commands in mod_configure, but there were a few missing that nowadays are fairly easy to implement: this new ejabberd release supports all of them... except 5.

The five ad-hoc commands from XEP-0133 that are not supported are:

• 6. Get User Password, because it was already retracted in the XEP and should not be implemented
• 12. Edit Whitelist, because the corresponding feature is not implemented in ejabberd
• 27. Set Welcome Message, because in ejabberd this message is set in the configuration file, option welcome_message of mod_register
• 28. Delete Welcome Message, for similar reason
• 29. Edit Admin List, because in ejabberd the administrative rights to accounts are granted in the configuration file, toplevel option acl.

On the other hand, ejabberd implements more than 200 API commands in all over its source code, providing those and many other administrative tasks. And you can execute those API commands using the command line, ReST calls, XML-RPC, WebAdmin, ... and ad-hoc commands too!!! See the available API frontends.

Nowadays, all the ad-hoc commands described in XEP-0133 have a similar API command in ejabberd that you can execute using ad-hoc commands too:

Ad-hoc command in XEP-0133	Status in ejabberd 25.10	Equivalent API command
Add User	〽️ (no vCard arguments)	register
Delete User	✅	unregister
Disable User	✅	ban_account
Re-Enable User	✅	unban_account
End User Session	〽️ (argument)	kick_session
Get User Password (retracted)	▶️ (retracted)	check_password
Change User Password	✅	change_password
Get User Roster	〽️ (result syntax)	get_roster
Get User Last Login Time	✅	get_last
Get User Statistics	✅	user_sessions_info
Edit Blacklist	▶️	add_blocked_domain
Edit Whitelist	❌	-
Get Number of Registered Users	✅	stats
Get Number of Disabled Users	✅	count_banned
Get Number of Online Users	✅	stats
Get Number of Active Users	✅	status_num
Get Number of Idle Users	✅	status_num
Get List of Registered Users	✅	registered_users
Get List of Disabled Users	✅	list_banned
Get List of Online Users	✅	connected_users
Get List of Active Users	✅	status_list
Get List of Idle Users	✅	status_list
Send Announcement to Online Users	✅	announce_send_online
Set Message of the Day	✅	announce_motd_set_online
Edit Message of the Day	✅	announce_motd_update
Delete Message of the Day	✅	announce_motd_delete
Set Welcome Message	▶️	(option welcome_message in mod_register)
Delete Welcome Message	▶️	(option welcome_message in mod_register)
Edit Admin List	▶️	(option acl)
Restart Service	✅	restart_kindly
Shut Down Service	✅	stop_kindly

Status legend:

• ✅ Implemented in ejabberd exactly as XEP-0133 describes it
• 〽️ Implemented with same command name, but different arguments or results
• ▶️ Not implemented as XEP-0133 says, but we have an alternative solution
• ❌ Not implemented in ejabberd in any way

Updated support for XEP-0317 Hats

Support for XEP-0317 Hats is improved from 0.2.0 to the latest 0.3.1.

Previously, the XEP lacked some use cases, and ejabberd implemented them as custom additional features, as documented in MUC Hats. Now that the XEP includes all those additions, ejabberd strictly follows XEP-0317 version 0.3.1.

Improved GitHub Workflows

The ejabberd git repository contains several GitHub Workflows to test automatically the source code with static and dynamic tools, build installers and containers.

Those workflows recently got several improvements:

• Run agnostic-database tests only once, not for every backend
• Add local composite actions to manage ejabberd and databases
• Reorganize steps in the CI workflow to run in parallel jobs
• Use ARM runners to build ARM installers and containers, no need for cross compiling
• Use ARM runners instead of x86 when possible, as they run faster
• Cache dependencies and download from CDNs when possible

With all those improvements, the workflows complete (or give some error report) in less than 10 minutes, instead of the 30 minutes that were common before.

For details about those changes, check PR 4460

Acknowledgments

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

• Guus der Kinderen for update XMPP-Interop-Testing
• Holger Weiß for mod_push cosmetic changes
• marc0s for the new push_send_notification hook
• Pouriya Jahanbakhsh for pass HTTP headers from WS to C2S connection
• Yurt Page for updating the Russian translation

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

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition, in addition to all those improvements and bugfixes, also get the following changes:

• The bulk_roster_update API command now accept a list of groups.
• The mod_dedup module has been improved to handle received markers. This module was added in 4.2508 to prevent both delivery and storage of duplicates in archive.
• Fixed a case where a mobile client was not able to retrieve all the messages received while it was offline after a temporarily loses of its data connection.

ChangeLog

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

Ad-hoc Commands

• mod_configure: New ad-hoc commands that were missing from XEP-0133
• mod_adhoc_api: Add support for asynchronous command calling
• mod_adhoc_api: If argument is a list of jids, type is jid-multi
• mod_adhoc_api: If field has several values, type is text-multi

API Commands

• Add commands argument type binary_or_list
• mod_http_api: Format sub elements for tuples from maps
• mod_admin_extra: Improve roster API commands documentation
• mod_announce: New API commands, reusing existing ad-hoc functions
• ejabberd_admin: New API command restart_kindly, improve stop_kindly
• mod_admin_extra: New API commands list_banned and count_banned
• mod_admin_extra: Improve API command status_list: support for status to be a list
• mod_muc_admin: New API commands muc_get_registered_nick and nicks (#4468)
• Use mod_private:del_data in unban_account API command

Configuration

• Rename New SQL schema to Multihost, and Default to Singlehost (#4456)
• Add config transformer from use_new_schema -> sql_multihost_schema
• mod_sip: Fix problem parsing via in yconf library (#4444)

Erlang/OTP support

• Enable feature maybe_expr in the compiler for Erlang/OTP 26 (#4459)
• Enable feature maybe_expr also in the runtime for Erlang/OTP 25
• Runtime: Remove Erlang 24 which won&apost work anymore with maybe_expr
• Remove EX_RULE and EX_STACK macros only used with ancient erlang

GitHub Workflows

• CI: Bump XMPP-Interop-Testing/xmpp-interop-tests-action (#4469)
• CI: Don&apost care to include commit details in the CT logs HTML page
• CI and Runtime: Reorganize steps to run in parallel, and ARM runner (#4460)
• Add local composite actions to manage ejabberd and databases
• Container: Build ARM in native runner instead of QEMU, merge and clean
• Installers: Generate ARM installers in native runner
• Tests: Run agnostic-database tests only once, not for every backend
• Tests: The odbc backend is not actually used in Commont Tests
• Weekly: New workflow that condenses CI, test all erlang without caching

Installers and Containers

• Bump Erlang/OTP version to 27.3.4.3 in installers and container
• Bump Expat 2.7.3, OpenSSL 3.5.4, unixODBC 2.3.14 in installers

MUC

• mod_mam: New option archive_muc_as_mucsub
• mod_muc: Check if room is hibernated before calling mod_muc process
• mod_muc: Update implementation of XEP-0317 Hats to version 0.3.1 (#4380)
• mod_muc: Make mod_muc_sql properly handle new hats data (#4380)
• mod_muc_room: Don&apost require password if user is owner of room
• mod_muc_admin: Use in WebAdmin the new API commands that get nick registers

Core and Modules

• ejabberd_http_ws: Pass HTTP headers from WS to C2S connection (#4471)
• ejabberd_listener: Properly pass send_timeout option to listener sockets
• ejabberdctl: When ping returns pang, return also status code 1 (#4327)
• ext_mod: Print module status message after installation
• misc: json_encode should always call json with our filter
• mod_admin_update_sql: Use same index name than when creating database
• mod_block_strangers: Clarify access and captcha documentation (#4221)
• mod_http_upload: Encode URL before parsing, as done before bba1a1e3c (#4450)
• mod_private: Add del_data/3, get_users_with_data/2, count_users_with_data/2
• mod_pubsub: Don&apost catch exit:{aborted, _} inside mnesia transactions
• mod_push: Run new hook push_send_notification (#4383)
• WebAdmin: Respect newline and whitespace characters in results

Full Changelog

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

ejabberd 25.10 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.

Helping Dutch Healthcare Speak the Same Language with XMPP

The XMPP Standards Foundation (XSF) has put out a call to action: it’s time for the community to help make secure, interoperable chat a reality - especially in healthcare. Here at Ignite Realtime, we’re excited to support this effort. Our projects, such as Openfire and Smack, provide powerful building blocks to explore what’s possible for Dutch healthcare communication.

Building Blocks for Dutch Healthcare Messaging

Many of the features mentioned in the XSF’s call to action (such as attachments, group chat, and read receipts) are already available in our projects, providing a strong foundation for exploring messaging workflows. Openfire offers a scalable XMPP server with a flexible plugin system, while Smack, a modular Java library for building clients on Android, desktop, or other platforms, makes it possible to experiment with custom client-side solutions. Together, these tools allow developers and organizations to prototype, test, and explore how messaging could work in Dutch healthcare contexts.

How Our Community Can Contribute

Even though the Dutch healthcare chat standard is still being finalized, there are ways to explore and prepare for it using projects such as Openfire and Smack:

1. Develop Proof-of-Concepts (PoCs): It’s possible to build early prototypes of messaging solutions to explore how the new standard might work in practice. Many core specifications are already implemented in our products, so prototypes can focus on workflow and interoperability rather than reinventing basic features.
2. Experiment with Custom Functionality: The modular architectures of projects like Openfire and Smack make it possible to create custom plugins, extensions, or client features to test new communication ideas. Resources and examples from the project repositories can help get started.
3. Explore Security and Privacy Configurations: By building prototypes, setting up test environments, or simulating messaging workflows, the community can experiment with authentication, encryption, and access control setups to see how patient data could be protected under the new standard.

Let’s Build a Connected Dutch Healthcare Community

Projects such as Openfire and Smack give us the building blocks to explore messaging that’s secure, reliable, and ready for the future. By experimenting, prototyping, and sharing insights, the community can help ensure the new Dutch healthcare chat standard meets real-world needs from day one.

And since the Ignite Realtime Foundation is a Dutch stichting with local contributors and partners, we like to think of this as more than just coding - let’s discuss the possibilities over a stroopwafel sometime!

For more information and to join the conversation, visit Ignite Realtime and introduce yourself in our community at disource.igniterealtime.org. Together, we can help Dutch healthcare teams communicate better and build a strong, collaborative XMPP ecosystem in the Netherlands.

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

4 posts - 3 participants

Read full topic

Supporting the development of the Dutch NTA 7532 standard with lessons from international practice

Who We Are and Why This Matters

The XMPP Standards Foundation (XSF) is an independent, non-profit organization that promotes and advances open standards for real-time communication and collaboration. The XSF oversees the development of extensions to the Extensible Messaging and Presence Protocol (XMPP) and fosters an open, secure, and decentralized ecosystem for messaging technologies across the Internet.

In healthcare, chat and messaging have become essential for coordination between doctors, nurses, general practitioners, and patients. Yet many existing tools are consumer-grade, not designed to meet healthcare’s strict requirements for privacy, auditability, and compliance.

The Netherlands is taking major steps to address this gap through the upcoming NTA 7532 technical specification for healthcare chat, part of the broader NEN 7516 framework on secure communication. This initiative has strong potential to align national practice with international standards - if built on proven, open technologies.

What Is XMPP - in Simple Terms

XMPP (Extensible Messaging and Presence Protocol) is an open standard for secure messaging that allows different chat systems to talk to each other. You can think of it as email for chat: anyone can host their own service, and as long as both sides follow the same rules, messages flow securely and reliably between organizations.

Because XMPP is built on core Internet Engineering Task Force (IETF) standards, it works hand-in-hand with the technologies that power the Internet itself: like TLS for encryption, SASL for authentication, and DNS for service discovery. This means XMPP isn’t just compatible - it’s part of the Internet’s DNA.

XMPP is already used by government, defense, and healthcare networks in several countries, proving that open protocols can deliver high-assurance, privacy-compliant communication at scale.

A Quick Example from Healthcare

Imagine a nurse in a hospital who needs to consult a specialist in another organization about a patient’s medication plan. With a secure XMPP-based chat system following the NTA 7532 standard:

1. The nurse can send a message from her hospital’s system.
2. The specialist receives it instantly on their organization’s system.
3. Both systems verify each other’s identity, encrypt the message, and log it for audit purposes.
4. No one needs to use consumer apps or insecure messaging.

This is the type of trusted, interoperable communication the Dutch healthcare system aims to achieve, and where XMPP offers a proven foundation.

Security and Interoperability in Healthcare Messaging, A Context for XMPP

Instant messaging has become an essential tool in healthcare, supporting communication among professionals and between care providers and patients. However, clear and consistent security and interoperability standards are still lacking. Without these, users often rely on generic consumer platforms that do not meet healthcare’s privacy, compliance, and auditability requirements.

The Netherlands is taking important steps to address this challenge. A security framework for healthcare messaging already exists in the form of NTA 7516, which is now being revised and elevated to NEN 7516. This will serve as the overarching functional standard, supported by two technical specifications: one for email (NTA 7531) and one for chat (NTA 7532).

NTA 7532 will define essential areas such as encryption, authentication, user transparency, archiving, and audit logging. These standards are being developed collaboratively by healthcare organizations, IT vendors, and the Ministry of Health, with a public consultation and pilot implementations to follow.

XMPP as a Foundation for Secure and Interoperable Chat

Many of the goals described in the Dutch NTA 7532 standard align closely with what the Extensible Messaging and Presence Protocol (XMPP) already provides.

From its very beginning, XMPP was designed for federation, meaning that independent systems (for example, different hospitals or care providers) can exchange messages securely, just like email servers do today. This makes XMPP a natural fit for a national healthcare messaging standard that needs security, interoperability, and local control.

How XMPP Supports NTA 7532 Objectives

XMPP offers a modular, standards-based foundation where essential capabilities such as authentication, encryption, message delivery, and federation are already well-defined. This allows healthcare chat systems to meet functional and security requirements without reinventing the underlying technology.

Purpose	What It Means in Practice	XMPP / Internet Standard
Base protocol	All message exchange between chat service providers uses the XMPP protocol to ensure interoperability.	RFC 6120, RFC 6121, RFC 7590, RFC 7622
Addressing and federation	Users and organizations are identified in a globally unique format (user@organization.tld), supporting secure cross-domain communication.	RFC 7622
Server discovery	Systems automatically locate other trusted servers using DNS SRV records.	RFC 2782, RFC 6120
Sender verification	The authenticity of servers is validated through DNSSEC and DANE, combined with TLS certificates.	RFC 4033 (DNSSEC), RFC 6698 (DANE)
Transport encryption	All traffic between servers and clients is encrypted with modern TLS (1.2 or 1.3).	RFC 5246, RFC 8446, RFC 7590
Data-at-rest encryption	Stored messages are encrypted using AES with a 256-bit key to protect message history and attachments.	AES-256
Delivery confirmation	Servers confirm successful receipt of each message, ensuring reliability and auditability.	XEP-0184 (Message Delivery Receipts)
Attachments	Files or images are exchanged through secure HTTPS links protected by TLS.	XEP-0363 (HTTP File Upload), RFC 2818 (HTTPS)
Digital signatures	Messages or metadata can be digitally signed to verify integrity and origin.	ETSI TS 101 903 (XAdES)
Group chat	Multi-user conversations across organizations, with invitation and moderation capabilities.	XEP-0045, XEP-0249, XEP-0410
Message correction / retraction	Users can edit or withdraw sent messages where supported.	XEP-0308, XEP-0424, XEP-0425
Read receipts	Participants can indicate that a message has been read.	XEP-0085 (Chat State Notifications)
Publishing contact info and avatars	Professionals can share verified contact details and profile images.	XEP-0054 (vCard-temp), XEP-0084 (User Avatar)
Interoperability and registry model	Each organization can operate its own trusted service provider, discoverable through DNS, enabling secure federation between systems.	Core XMPP federation and DNS-based trust mechanisms
Confidentiality and access labeling	Messages can carry structured confidentiality labels (as recommended by FHIR) to indicate sensitivity levels, access restrictions, or handling rules.	XEP-0258 (Security Labels in XMPP)

Note: End-to-end encryption (e.g., OMEMO or OpenPGP) is possible within XMPP but may be applied selectively, as healthcare messaging often requires auditable storage and controlled access for compliance.

This mapping illustrates how an open, extensible protocol can meet functional and security goals while allowing national specifications such as NTA 7532 to define which features and policies are mandatory for certified systems.

Why This Matters for Healthcare

Using XMPP doesn’t mean reinventing the wheel. Instead, NTA 7532 can build on mature, international standards, simply defining which XMPP features and policies are required for certified systems.

This approach ensures:

• Predictable interoperability: Different vendors’ systems can communicate reliably.
• Security by design: Proven encryption and authentication methods are reused, not re-created.
• Vendor independence: Hospitals and care providers can choose any compliant system without losing connectivity.

In short, XMPP already provides the technical foundation. NTA 7532 defines the rules of engagement for Dutch healthcare, ensuring all participants use it safely and consistently.

Interoperability and Vendor Independence

One of the biggest strengths of XMPP is its federated and open architecture. In simple terms, this means every healthcare organization, whether a hospital, general practice, or mental health provider, can run its own chat system, while still communicating securely with others. Messages flow across organizational boundaries just as emails do, but with modern security controls and fine-grained authentication.

How This Helps Healthcare Providers

In practice, this means:

• A hospital’s internal chat server can communicate securely with a general practitioner’s system, even if each uses a different vendor.
• Authentication can rely on digital certificates or other trusted credentials, so both sides know who they’re talking to.
• Each organization keeps control over its own infrastructure and data, meeting national privacy requirements.

This design directly supports the core goals of NTA 7532 (interoperability, traceability, and security) without forcing all parties onto one platform or vendor.

The Role of a Shared Profile

To make interoperability truly seamless, participating systems must agree on how they use XMPP’s many features. That’s where NTA 7532 comes in: it can define a shared national profile, specifying which XMPP extensions and settings are mandatory, recommended, or optional.

Such a profile ensures:

• Predictable behavior between implementations
• Reliable message delivery across systems
• Verified compliance through testing and certification

Vendor Independence and Open Innovation

Because XMPP is open, royalty-free, and supported by dozens of implementations, no single company controls it. Any vendor can build or extend XMPP-based products, whether open-source or commercial, while still remaining compatible with others. This enables true vendor independence: healthcare organizations can switch suppliers or integrate new tools without losing interoperability.

Existing compliance and interoperability test suites for XMPP further support this independence, helping vendors validate that their systems behave consistently and securely.

In short, XMPP provides not just a technical foundation but also a healthy market ecosystem: one that fosters collaboration, innovation, and long-term sustainability in healthcare communication.

Alignment with International and European Practice

Across the world, governments and public institutions are choosing open, standards-based messaging protocols to support secure, interoperable communication, especially in sectors where trust and reliability are critical.

The Extensible Messaging and Presence Protocol (XMPP) has already proven itself in these environments. It underpins communication systems for organizations such as the U.S. Department of Defense, NATO, and several European government and public-safety networks. Within the UK, the National Health Service (NHS) employs XMPP-compatible systems for messaging and notifications.

These real-world deployments demonstrate that XMPP can deliver:

• High assurance - meeting strict security and auditability requirements
• Operational resilience - functioning across multiple infrastructures and jurisdictions
• Scalability - supporting large networks with millions of users

A Natural Fit with European Priorities

The open nature of XMPP aligns closely with European digital policy objectives, particularly around:

• Digital sovereignty - reducing dependency on proprietary or non-European technology providers.
• Open standards and interoperability - ensuring systems from different vendors or sectors can work together.
• Transparency and trust - through openly developed, publicly available specifications.

By basing healthcare chat interoperability on XMPP, the Netherlands not only meets its national goals for security and compliance, but also contributes to Europe’s broader vision of an open and connected digital ecosystem.

Learning from International Practice

Adopting and aligning with internationally proven standards like XMPP offers clear advantages:

• Dutch implementers can reuse tested building blocks instead of designing everything from scratch.
• The national profile defined in NTA 7532 can stay compatible with international healthcare or government messaging systems.
• Future collaboration, whether with European neighbors or global health initiatives, becomes far simpler.

In short, the Netherlands has the opportunity to lead by example, demonstrating how open standards can support secure, sovereign, and future-proof communication in healthcare.

Collaboration Opportunities

The development of NTA 7532 is more than a technical exercise: it’s a chance to shape the future of secure, interoperable communication in Dutch healthcare.

To make this a lasting success, collaboration between the Dutch standards community and the XMPP Standards Foundation (XSF) will be essential. The XSF works transparently and welcomes cooperation with all. By engaging directly with the XSF, Dutch experts and healthcare stakeholders can ensure that NTA 7532 remains aligned with international best practice while addressing national needs.

We invite the NTA 7532 working group and stakeholders to engage directly with the us!

Areas for Collaboration

Here are some concrete ways to work together:

• Share healthcare use cases and requirements with XSF technical groups, ensuring that future protocol extensions reflect real-world healthcare needs.
• Participate in joint workshops or liaison roles, creating a two-way channel between the Dutch NEN/NTA community and XSF developers.
• Run pilot implementations that test interoperability between systems, contributing results back to both Dutch and international standardization efforts.
• Collaborate on testing and certification, leveraging existing XMPP validation tools to support NTA 7532 compliance.

Such collaboration would ensure that the technical realization of NTA 7532 remains future-proof, internationally aligned, and interoperable by design.

How to Get Involved

The XSF welcomes contributions from anyone interested in secure, standards-based communication. There are several easy ways to engage:

• Visit our website: https://xmpp.org
• Join our discussion list: https://mail.jabber.org/mailman/listinfo/standards
• Chat with us: https://xmpp.org/community/chat/
• Contact us directly: https://xmpp.org/contact/

Participation is open, free, and designed to lower barriers for new contributors.

Together, we can ensure that Dutch healthcare messaging (and by extension, European healthcare communication) is secure, interoperable, and sustainable for years to come.

Conclusion

The Dutch NTA 7532 initiative marks a pivotal step toward trusted, interoperable digital communication in healthcare. By defining a clear, open, and verifiable framework for secure chat, the Netherlands is setting a benchmark for how national standards can align with international innovation.

The Extensible Messaging and Presence Protocol (XMPP) provides a ready-made foundation for this effort:

• It is mature and battle-tested in demanding environments.
• It is open and royalty-free, fostering vendor independence and innovation.
• It is flexible and extensible, ready to adapt to evolving clinical and regulatory needs.

By working closely with the XMPP Standards Foundation and the wider international community, the NTA 7532 working group can ensure that its standard remains technically sound, future-proof, and globally compatible.

In short: XMPP supports the secure, interoperable communication that Dutch healthcare needs today, and lays the groundwork for the trusted systems of tomorrow.

Nicolas Vial will host the Quale sistema alternativo per il vostro cellulare? talk with a workshop that will demonstrate how to install and use XMPP for free from F-DROID, but will also give away free QR codes for Monocles Chat from Google Play. The talk will center around LineageOS, with a strong focus on XMPP as an IM solution.

Linux Day Torino 2025 will take place this next Saturday, October 25th, at the Arsenale della Pace, Piazza Borgo Dora, Torino, Italia. The event will be free, open to everyone and no prior registration will be required.

Linux Day Torino would like to invite you, your friends, colleagues and families to join the event and hopes to see you there!

• Date: Saturday, October 25th, 2025
• Location: Arsenale della Pace, Piazza Borgo Dora, Torino, Italia.
• Time: 2 p.m. at MISC CLASSROOM

This version is out mostly to provide a stable version with compatibility with the newly released Python 3.14, there are nonetheless a few new things on top.

Thanks to all contributors for this release!

Esports has outgrown local tournaments and now runs on global platforms linking millions of players and fans, powered by immersive esports technology. Communities form around games, teams, and streamers, blending competition, entertainment, and social connection. At this scale, reliability and low latency are non-negotiable to keep matches fair and audiences engaged during spikes.

High-speed networks, cloud rendering, modern graphics, and streaming make worldwide play possible, while data and AI sharpen strategy. Crucially, infrastructure must scale horizontally across regions, cache at the edge, and expand automatically under load so performance stays consistent.

This article maps the technologies behind modern esports and the design choices that keep them resilient at scale, so the experience feels instant from first click to final play.

The Global Picture

Let’s start with the big picture and why esports now feels like a shared live moment wherever you are.

You may have watched a finals stream with friends or shared a highlight in chat. That everyday moment sits on top of a vast market and audience. The market has expanded at a 20.9% rate in recent years.

Source: Scoop Market

The global esports audience surpassed 500 million viewers in 2020. Industry revenue reached around USD 2.0 billion in 2023 and is projected to grow to USD 5.5 billion by 2029. Longer-term forecasts suggest a compound annual growth rate of nearly 21%, with revenues expected to reach USD 10.9 billion by 2032. 

Esports is digital-first, so fans join live from different regions at the same time. That reach shapes every technical choice.

Platforms and Real-Time Infrastructure

Fans expect more than a broadcast. They want to react, interact, and feel part of the match. Meeting that expectation means processing actions and reflecting results in milliseconds: bets settle as they happen, moves register for every client at once, and streams stay in step with in-game events.

Behind the scenes, persistent connections keep two-way communication open. Load balancers and game servers handle traffic and core logic. Event-driven patterns broadcast only what each user needs. Caching and in-memory stores such as Redis answer hot reads quickly. Content delivery networks ( CDNs) and edge locations reduce round-trip time for global audiences. These are the building blocks of immersive esports technology, and they exist to keep the experience responsive when traffic surges.

Speed protects immersion and trust. A delay during a clutch play or a live bet breaks both. Real-time platforms enable instant feedback, live chat, synced multiplayer, and up-to-the-second odds. Operators benefit as well: live data supports fraud checks, personalised offers, dynamic pricing, and timely promotions. The result is higher retention and fairer play.

AI and Data: From Play to Shared Insight

This is where raw play turns into insight that helps players, teams, and viewers get smarter together.

Artificial intelligence (AI) now supports training, planning, and engagement across the community. Teams review footage with machine learning, spot errors, and test scenarios before match day. Virtual assistants help track progress and suggest adjustments.

Matchmaking pairs players of similar skill so every game feels balanced, while anti-cheat tools monitor play in real time and respond within seconds. For viewers, AI compiles highlights, personalises feeds, and surfaces stats that spark discussion. AI does not replace the human side of esports. It amplifies it by making fair play easier to maintain and shared learning easier to access.

The Future of Immersive Esports: AR, VR, and Cloud Integration

Next, we look at how new realities and cloud power will make watching and playing feel more present.

Esports is moving toward presence, not just pixels. The next wave blends virtual reality (VR), augmented reality (AR), and cloud, so players and fans feel inside the match while platforms hold steady under load.

At a basic level, cloud rendering sends high-quality visuals from powerful servers straight to headsets and phones, so devices do less work and the action feels smooth. Nearby servers cut the time between your input and what you see, which means steadier aim, smoother movement and viewers who stay in sync with the match.

On the viewing side, augmented reality (AR) adds simple overlays like live stats, heatmaps and quick point-of-view switches for watch parties. Fans can pin tactics on screen and share clips that include useful context, not just the video. For collaboration, social virtual reality (VR) creates shared rooms where teams review rounds together, coaches sketch ideas in space, and gentle haptic cues help with timing. Early brain-computer interface (BCI) research is already improving training and accessibility, with competitive use further out.

Operationally, security and identity are handled in the cloud. Anti-cheat updates roll out quickly, and your profile and items travel with you across devices. Better compatibility between platforms helps communities stay together wherever they log in.

Cloud rendering, AR, and VR stitched to edge-first delivery keep the play responsive and viewing in sync at any scale. The technology fades into the background, matches feel immediate, spectators feel present, and communities stay connected long after the final round.

Scalability in Esports Platforms

All of this only works at scale, so these are the principles that keep things smooth when the crowd shows up.

Immersive features raise the bar. AR, VR, and cloud expand access, lengthen sessions, and multiply real-time events. To keep the experience smooth, platforms must scale from the first click to the final play.

Design principles

Scale out horizontally rather than relying on larger single servers. Hold latency steady as traffic rises. Use distributed services that add capacity on demand. Place compute at the edge to shorten round-trip times for inputs, tracking, and streams. Move events through queues and pub/sub so spikes do not reach clients. Share hot data. Cache reads close to players. Isolate failure with circuit breakers and graceful fallbacks.

Consistent experience under load

Keep match starts fast, frame timing stable, chat responsive, and spectating in sync during peak traffic. Run multi-region deployments with smart routing so performance feels similar across continents. Maintain identities, inventories, and anti-cheat on the server and keep them in sync across devices.

Operate by signals

Define SLOs for latency and availability. Instrument everything. Auto-scale from real usage, not guesses. Use rolling updates, redundancy, and automatic failover to stay always on. Control cost with elastic capacity that expands for events and contracts afterwards. This is where immersive esports technology proves its value, turning peak moments into reliable moments.

Proof in production

Scalability is the test that decides whether real-time features, AI-driven insights, and AR/VR hold up. Peak moments create sudden spikes in concurrent users, messages, and state updates. A scalable platform keeps latency steady, expands capacity on signal, and degrades gracefully if a region falters.

FACEIT shows what this looks like in practice. Working with Erlang Solutions, the team upgraded MongooseIM and Erlang, redesigned presence at scale, and tightened deploys. The result was a two-times speed increase and stable support for up to 250,000 users with lower maintenance. Crucially, presence and chat stayed responsive during surges, which is the hallmark of a platform built to scale rather than cope.

In the end, scaling well turns pressure into proof. When capacity grows on signal and services degrade gracefully, peak moments feel natural, competition stays fair, and communities keep turning up. That is how the tech steps back and the match takes centre stage.

To conclude

Esports thrives when technology fades into the background and the community takes centre stage. Real-time services keep playing responsively. AI and analytics turn activity into shared insight. AR, VR, and cloud widen access. Scalability makes peak moments feel natural. If you are building or scaling an esports platform, design for low latency and resilience from day one. We design real-time systems that keep matches responsive and communities connected, so get in touch.

The post Immersive Esports: The Technology Behind Competitive Gaming appeared first on Erlang Solutions.

This year I haven’t blogged much at all, but it’s time for the 15th annual Coffeeneuring and who-knows-how-many-annual Biketober challenges so here we go! This post will be updated with each of my Coffeeneuring rides as the month goes on, and may (or may not) contain a few fun C+1 rides that count towards Biketober, but not for Coffeeneuring.

Week One (Oct 13–19)

Oct 13

I missed the first few days this year and wasn’t able to take advantage of Rule 2: “Early Bird Friday”, so I decided to start my week on Monday and biked over to a new coffee shop in Smyrna, GA: Lume Coffee Co. Unfortunately, it’s just an empty store at the moment with a sign that says that the actual coffee is “coming soon”, so per Rule 3 “Coffee Shop Without Walls” I had my own coffee nearby. Hopefully the actual coffee shop is open before the season is over and I can report back (but given that the shop is an empty shell at the moment, I doubt it).

Oct 19

To close the week out I rode back over to more or less the same area where Lume was (the Smyrna Village Green) to go to the Farmers Market! No coffee today, but one vendor was selling very spicy Ginger Lemonade. While I think the introduction of the ginger changes Lemonade form a summer drink to a fall drink, in the spirit of Rule 6, “Controversial Beverage Rule,” I’ve opened a poll over on fedi to seek adjudication for whether this ride counts!

Poll: https://social.coop/@sam/115406548366036109

Week Two (Oct 20-26)

Oct 26

Rode to Rev Coffee in Smyrna, GA today. This is one of my favorite coffee shops and, best of all, I managed to drag a friend along (they were not happy that the only bike of mine that fit them was a single-speed and there were several hills along the way)! A plain-old-drip-coffee was acquired to make it a Coffeeneuring ride..

October 14th was supposed to be the day the European Council voted to mandate scanning of all private communications, encrypted or not.

The vote was pulled at the last minute.

Germany withdrew support, creating a blocking minority that blocked the Danish Presidency&aposs hope to get the text approved. Denmark still hopes to push this through by the end of its EU presidency in December. I personally would like to be optimistic and think that the tech community managed to raise enough concerns with EU policymakers.

Hundreds of European companies such as Proton, NordVPN, Tuta, Murena, Element, ProcessOne voiced their concerns about Chat Control. These companies are building the European alternatives we need for digital sovereignty. They offer what the EuroStack coalition is demanding: local infrastructure, values-driven technology, independence from US hyperscalers.

And EU policy trying to force them to break the very protocols that make sovereignty possible does not seem like the wisest strategic move.

What policymakers are missing is that encryption is a built-in foundation of most communication protocols. You cannot turn it on or off depending on what is considered right in a given place at a given moment. You either have secure end-to-end encryption or you don&apost. There is no "just this once" exception that doesn&apost become an exploitable technical or administrative vulnerability.

When Denmark&aposs Justice Minister suggested that the "completely misguided perception" is that everyone has a right to secure communication, he revealed the fundamental gap: policymakers who don&apost understand that secure infrastructure is the core of today&aposs Internet backbone, not just for the pure sake of democracy (I swear it hurts to have to explain this), but also for the existential security of European countries.

Today, European countries are prioritizing defense spending while missing that digital infrastructure is the battlefield. Networks allow us to control drones, spread misinformation, they are vectors of attacks on critical infrastructure.

It is time for Europe to develop a coherent tech strategy. Can we build digital sovereignty while simultaneously undermining the protocols that enable it? Can we demand independence from US tech giants while forcing European alternatives to adopt vulnerabilities that US companies will try to avoid through commercial pressure?

The October postponement is an opportunity. Two months for actual infrastructure builders and engineers to inform policy. Two months to bridge the gap between Brussels&apos political vision and the technical reality of how secure systems actually work.

This is exactly the gap I work to bridge: between policymakers who understand the geopolitical stakes and engineers who understand protocol layers. Europe&aposs path to digital sovereignty requires both.

Denmark&aposs December push will show us whether Europe is serious about learning from its own technical community, or whether we&aposre condemned to keep making policy that contradicts our stated goals.

The European way should be: tech with purpose, built on sound engineering, serving democratic values. Not tech policy that undermines the very infrastructure we need to achieve independence.

The first time I DJed for a Contra Dance¹ was at Inman Park’s famous Trolley Barn. At the time I was DJing in the way other social dances are normally DJed: I had a laptop, I played a song, everyone danced. No fancy mixing, or effects: the most technical thing I did was loop 32 bar sections of music to stretch it out until the caller was ready to end the dance.

This time around, returning to the Trolley Barn, I wanted to see if my DJ skills had improved and try live mixing for the first time. Since I’ve never heard of anyone else DJing a traditional contra dance² I didn’t have a good idea of what I was doing but I worked with the caller, my friend Valerie Young, to plan a set that I thought the dancers would like. The set comprised mostly high energy contra dance bands who play traditional songs in less traditional ways: think the Gaslight Tinkers, Great Bear, and ContraForce. My goal is to be able to tell the caller, “just treat me like a band” so that I can play a medley of two or more songs (as the band would traditionally do), they can request a tempo, energy level or vibe, and signal me when they’d like to end the dance and I’ll get ready to wrap up the mix with a nice ending. I don’t think I quite achieved that goal with this set, but it was close and the dancers had a blast either way, even if occasionally some of them ended up out on the ends when the dance wrapped up due to me not being able to give the caller as many times through as she wanted and still make the ending sound clean.

Prep

I prepped the individual music in this set basically the same way I did last time: in Mixxx I marked each time through the dance (contra has a very specific form) with color-coded loops or hot cues depending on if they looped cleanly or not, and named the mix-in and mix-out points when I decided what song to pair them with.

I try to come up with enough mixes to fill the night, plus a few more that are both high and low energy to have in my back pocket in case the caller is just feeling a certain way that night. This way I hopefully always have something that I’ve practiced which works well for each dance in terms of where bouncy or smooth sections of the song fall. That said, I didn’t do a good job of matching songs to dances in every case this night (I would have liked songs with a harder hit on a few of the petronellas), but overall it worked well.

The Set

The night started out with the dance “Jefferson’s Sixpence” by Ann Fallon to which I played a mix of Gaslight Avenue and Reel du Nord, both by The Gaslight Tinkers. This went okay except that I let the track run a bit far before the caller was ready to stop and had to loop the same section a couple of times to make the mix keep working smoothly, which I felt got a bit boring after a handful of times through the dance. The dancers didn’t seem to notice or mind though and were enthusiastic about the start to the evening.

Please excuse the clipping on the recordings, one of the unfortunate problems with the evening (that we’ll come to later) is that the gain on the main board was up way too high and I didn’t have control over that, so it was clipping most of the night. More on that in the retrospective at the end of this post.

Gaslight Avenue / Reel du Nord by the Gaslight Tinkers, DJ mix

The second song was a more traditional contra song, a mix of Highland by Wake Up Robin and Fleur de Mandragore by the Free Raisins to the dance “Made Up Tonight” by Erik Hoffman. Due to some technical difficulties with the sound pulled from the main board I didn’t wind up with a recording of this one (or most of the following songs), so let’s just pretend the mix went perfectly and everyone had a good time.

Next the caller picked “Trip to Elsan” by Joe Surdyk and Eric Schreiber. For this I branched out a bit, mixing the (more or less) traditional contra song, Basketball by Countercurrent with FIDDLE DISCO! by Elias Alexander. I had one minor issue with the mix towards the end of FIDDLE DISCO!, a loop that wasn’t really clean but was necessary for the number of times through the dance the caller wanted, but the dancers didn’t seem to notice and they went wild for the modern beats that the tune introduces! This was also the first time I had to re-mix a tune a bit on the fly besides just transitioning between two tunes since FIDDLE DISCO! is crooked and won’t work for contra dancing without (minor) adjustments.

Basketball / FIDDLE DISCO! by Countercurrent and Elias Alexander, DJ Mix

The Tuesday night Trolley Barn dance is rather short, so we took a waltz break at this point. I played Here Comes Sunshine by George Paul at the callers request, and Les Yeux Noirs by Burçin since I knew that a number of people from the local Lindy Hop scene were in the crowd. The switch to swing made those dancers happy, even if it confused the waltzers.

Back in the main dance I did a mix of Lafferty’s and Camel Hump by Wild Asparagus to one of my personal favorite contra dances: Tika Tika Timing by Dean Snipes.

Afterwards came what I thought was going to be the second to last song of the evening (we’d been running dances a bit long and were short on time) so I pulled out the show stopper: a medley of Griffin Road and Trip to Moscow, both by Kingfisher, but I added a little contra joke by mixing Rasputin by Boney M in with Trip to Moscow, purely based on the name (but the combo also just worked really well). This one really brought the house down!

I didn’t get a recording of this one, sadly with all the times through, but here was the backup recording I made in advance in case my laptop died during the show or something. The transition sounds like I had a buffer underflow (or just bad timing) on this one, and the mixing is a bit iffy in places, but trust me, it was better live!

Griffin Road / Trip to Moscow / Rasputin by Kingfisher and Boney M, DJ mix

At this point one of the organizers said she was having such a good enough time that she offered to let us run a bit over so we added “Vivian’s Catwalk” by Valerie herself to a mix of Muscles / Ride the Wheel by Buddy System and Garbage in A by Great Bear. This went well, except that I had layered the percussion from Garbage in A into Ride the Wheel so that when the transition happened it would have some continuity. Except that I somehow wound up off the beat and had to absolutely scramble to beat match; it sounded terrible, but somehow it didn’t throw Valerie off and once I finally got it beat matched we were still right on time.

For the final tune of the evening Valerie picked “Frock’s Rockin Frolick” by Will Mentor which works great as either a high or low energy dance depending on the caller. To compliment this I brought the energy down a bit with a mix of Brand by Potent Brew and El Bourbon Grande by ContraForce which brought the energy right back up to the high point by its rather loud ending!

Finally we closed the evening down with Ootpik Waltz by Wild Asparagus.

Stuff I Learned

• Either ask to do sound yourself, or don’t be afraid to ask the sound person if something sounds wrong (I didn’t want to be rude, so I didn’t ask, but they didn’t realize it was clipping all night and I’m sure they would have fixed it had I mentioned it!),
• I meant to both record my set on my laptop (no caller) but also record the main outputs from the board with a portable recorder (with caller), and ended up with only a few of the songs actually recorded. You have to actually remember to start recording…
• Prep endings better, if there are no clean loops near the end of the song, prepare a different ending or get better at covering the bad loop with effects or something. I had a few times where the caller asked for “3 more times” or “2 more times” and I had to say “uhhh, how does 1 or 3 sound?” or something along those lines. This was fine with my friend Valerie, but isn’t going to make you any other callers favorite band to work with.
• The jog wheels on the Traktor Kontrol S4 MK3 aren’t big enough. Do I do anything that technically means I need bigger jog wheels? No. Would I feel better about having them? Yes. Unfortunately the only controller that meets all my requirements and has bigger job wheels is the Rane Performer, and that’s way out of my price range (and will likely remain so forever), so maybe this is a “learn to get over it” type situation.
• Don’t just assume the waltz breaks don’t matter, they’re still part of your set and should be selected with care (the tempo was way too fast too, gotta pay more attention to the waltzes in general).

Other Links

• The event on MusicBrainz
• Some (non-live) practice recordings are available on Balfolk.social
• The few live recordings that we got can be found on the Internet Archive

Adoption of XMPP Providers

We are very pleased to see that the XMPP web client Converse 12.0.0 refers to XMPP Providers’ service. If users of Converse are looking for a way to register a new account, they are guided to providers.xmpp.net. Even if this is not a fully integrated solution as other apps provide, we are happy to see more general adoption of the XMPP Providers project.

Furthermore, the XMPP server software ejabberd has added a module for XMPP provider files in version 25.08. We were neither involved in its development nor reached out to its author in this regard, so this is great news and a helpful addition.

This circumstance, but also the level of acceptance and adoption motivates us even more to realize a long-standing thought: Publishing a new XEP to improve formalizing and accessing public XMPP server information.

XMPP Providers Server Update

To keep up with the latest changes, we updated the XMPP Providers Server to Debian Trixie (13) and ejabberd 24.12. Furthermore, a number of smaller improvements have been made to allow updating all software packages and to upgrade the system to new releases.

The XMPP Providers Server is the automated server setup used by XMPP Providers. It makes use of Ansible to set up a Debian-based server and contains playbooks for a simple all-in-one setup with a fully-featured XMPP server.

Help the Project, Improve XMPP

For a good user experience, apps integrating XMPP Providers are as important as the providers themselves. If you are an XMPP developer, please consider adding XMPP Providers support to your app. If you are an operator of a public XMPP service, provide the information XMPP Providers needs and add your service to the list. You can also consider to run our (automated) XMPP Providers Server setup yourself. It is easily configurable to be used as a public or private XMPP server.

Feel free to reach out to us if you have any questions! If you like to support XMPP Providers, please consider making a donation. Follow us and spread the word!

XMPP Providers Logo

Adoption of XMPP Providers

We are very pleased to see that the XMPP web client Converse 12.0.0 refers to XMPP Providers’ service. If users of Converse are looking for a way to register a new account, they are guided to providers.xmpp.net. Even if this is not a fully integrated solution as other apps provide, we are happy to see more general adoption of the XMPP Providers project.

Furthermore, the XMPP server software ejabberd has added a module for XMPP provider files in version 25.08. We were neither involved in its development nor reached out to its author in this regard, so this is great news and a helpful addition.

This circumstance, but also the level of acceptance and adoption motivates us even more to realize a long-standing thought: Publishing a new XEP to improve formalizing and accessing public XMPP server information.

XMPP Providers Server Update

To keep up with the latest changes, we updated the XMPP Providers Server to Debian Trixie (13) and ejabberd 24.12. Furthermore, a number of smaller improvements have been made to allow updating all software packages and to upgrade the system to new releases.

The XMPP Providers Server is the automated server setup used by XMPP Providers. It makes use of Ansible to set up a Debian-based server and contains playbooks for a simple all-in-one setup with a fully-featured XMPP server.

Help the Project, Improve XMPP

For a good user experience, apps integrating XMPP Providers are as important as the providers themselves. If you are an XMPP developer, please consider adding XMPP Providers support to your app. If you are an operator of a public XMPP service, provide the information XMPP Providers needs and add your service to the list. You can also consider to run our (automated) XMPP Providers Server setup yourself. It is easily configurable to be used as a public or private XMPP server.

Feel free to reach out to us if you have any questions! If you like to support XMPP Providers, please consider making a donation. Follow us and spread the word!

XMPP Providers Logo

XMPP Newsletter Banner

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

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

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

XSF Board and Council Elections 2025

The XMPP Standards Foundation is calling for individuals to compose the Board of Directors and members to serve on the XMPP Council for the 2025/2026 period. If you are interested in running for the Board of Directors or the XMPP Council, please add a wiki page about your candidacy to one or both of the aforementioned sections before November 2nd, 2025, 00:00 UTC.

Get involved in the XMPP Standards Foundation organization decisions and with the specifications we publish!

Note: XMPP Council members must be elected members of the XSF; however, there is no such restriction for the Board of Directors.

Videos and Talks

• XMPP Tutorials DE by eversten.net.
  • Conversations (XMPP) - Verbindungsproblem nach Update beheben. [DE]
  • Quicksy - Der einfachste Einstieg in XMPP (iOS-Version). [DE]
• UnifiedPush: a lecture by Daniel Gultsch at the Datenspuren 2025. [DE]

XMPP Articles

• ProcessOne
  • Why Europe’s ‘Chat Control’ Proposal Will Cripple European Communication Industry While Failing to Protect Children by Mickaël Rémond for the ProcessOne Blog.
• XMPP Interop Testing
  • Lots More Options!: A slew of new CI systems have been added. This time the target was freedom-respecting, open source CI systems for your open source projects ( including Jenkins, Drone, Harness and Woodpecker ). This brings the total number of CI systems in which you can run XMPP interop tests up to a whopping ELEVEN, plus anywhere else you can run containers. If there’s a CI system that you’re using and you’d like to see supported, or if it’s already supported but you’re struggling, please join their MUC, or open an issue on GitHub. By Dan Caseley for the XMPP Interop Testing Blog.
  • Two New Features for Clearer Testing: Has released version 1.7.1 of all of its test runners. This release adds two improvements to make interop testing both stricter and easier to set up! Now you can configure the suite to treat impossible tests as failures, ensuring that a green run really means every configured test executed and passed. You can now choose from three provisioning methods:
    • Admin Account using XEP-0133 (Service Administration) to create test accounts.
    • Explicit Test Accounts you configure up front.
    • In-Band Registration via XEP-0077 (In-Band Registration). Pick the approach that fits your setup best. There is documentation available for you to review the finer details!
• Libervia CLI tips: Did you know that Liverbia has a CLI that you can use to do nearly everything with? Well, that’s right, and Goffi, its author, has been steadily publishing a series of Mastodon toots to help you make the most out of it! Share files, publish blog posts, send encrypted messages, make audio/video calls, encrypt a pubsub node, automate tasks with ad-hoc commands, etc; everything from the comfort of your terminal!
• FastCGI Authorizer implementing XEP-0070 (Verifying HTTP Requests via XMPP) XMPP confirmation by PulkoMandy for pulkomandy.tk Git repositories. [FR]
• Montando un WhatsApp gateway desde XMPP con Slidge by z3r0 via SMOLNET PORTAL. [ES]
• Modern messaging: Running your own XMPP server by Holger for codedge.
• Install Slidgram in NetBSD by Eugene for Dragon’s notes.
• XMPP Brasil celebrates its first anniversary providing free accounts for the Brasilian community and its new status as a Category Provider A by XMPP Providers. [PT]

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.19.0-2 for Android. A bugfix release that addresses issues with registration and discovery (fixes options to block) on Snikket instances, fix more insets on latest Android, and scrolling ‘Manage Accounts’ with many accounts, among other things. Make sure to check out the changelog for all the details.
• Conversations has released version 2.19.5 for Android, with improved error message for servers that do not support TLS 1.3 and fixed issues with device rotation among many other fixes and improvements. You can take a look at the changelog for all the details.
• Convo XMPP client for KaiOS has released version 0.2.0 codenamed “Eyes Only” with support for OMEMO powered end-to-end encryption! This is the first time XMPP with OMEMO is available on a button phone. You can find all the announcements on the release page.

Convo 0.2.0: Support for end-to-end encryption with OMEMO.

• Gajim has released versions 2.3.5 and 2.3.6 of its free and fully featured chat app for XMPP. This release brings reorganized account settings, a brand new shortcuts manager, more contact info, video previews, performance improvements, and many bugfixes. The latest update fixes some issues with video previews and preview generation as well as some issues around loading icons. You can take a look at the changelog for all the details. Thank you for all your contributions!

Gajim 2.3.5 bundles preferences and account settings!

• Kaidan has released version 0.13.0 of its user-friendly and modern chat app for XMPP. This new release brings support for using multiple accounts simultaneously, enable/disable accounts, message forwarding, apply consistent criteria for all message correction, secure passwords storage, try all providers on connection error during automatic registration and many other new features and bugfixes! You can find a detailed list of new features, bugfixes and notes in the changelog.

Kaidan 0.13.0: Multi-Account support with enable/disable toggle switch.

• Monocles has released versions 2.0.14 and 2.0.15 of its chat client for Android. This updates bring in the ability to pin images and files to the top of the chat window, support for geo URI in pinned messages and reply previews, enable video preview for pinned messages and show audio file icon for pinned audio messages among other ‘pinning related’ improvements. They also allow replies to yourself, sending replies with OMEMO and jump to message on tap on reply with new scroll to reply, among many other features and a lot of fixes. Make sure to take a look at the changelog for all the details!
• Psi+ has released version 1.5.2117 portable of its development branch of the Psi, the cross-platform XMPP client designed for experienced users.
• Renga XMPP client for Haiku has released version 1.28, with some improvements to MUC support, and an implementation of XEP-0070 (Verifying HTTP Requests via XMPP) for HTTP authentication using XMPP. You can read all the details about this release on the latest news about it.
• xmpp-web has released version 0.10.7 of its lightweight web chat client for XMPP server.
• XOWS has released version 0.9.9c of its XMPP Over WebSocket web client, with refactored avatar fetch routines, some browser DOM refresh optimizations, fixes to account registration process crash and MUC occupant that may be duplicated.

XMPP Servers

• The Ignite Realtime community is happy to announce the release of Openfire 5.0.2! This release addresses a recently identified security vulnerability (CVE-2025-59154). The issue allowed for potential identity spoofing via unsafe Common Name attribute parsing. Please read the full security advisory for more information. This release also improves the SystemD-based scripts, removing a few annoyances introduced in Openfire 5.0.1. Please refer to the full changelog for more details.

XMPP Libraries & Tools

• python-nbxmpp version 6.3.1 has been released. Full details on the changelog.
• QXmpp version 1.11.2 has been released. Full the details on the changelog.
• Slidge versions 0.3.0 and 0.3.1 have been released. Migration from the 0.2 series is not supported, the slidge home dir has to be deleted and users have to register again. New features and improvements were introduced, mainly: support for (optional) reaction fallbacks (for older XMPP clients not supporting reactions), a lot of gateway-wide settings have been moved to user-specific settings, check the “preferences” command (adhoc or chatbot-style) and support for pronouns in VCards. You can check the intermediate changelogs from 0.2.12 to 0.3.0 for the full list of changes.
  • slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, versions 0.3.0beta and 0.3.0 have been released.
  • sleamdge, the Steam to XMPP gateway based on Slidge and steamio, version 0.3.0 has been released.
  • matteridge, the Mattermost to XMPP gateway based on Slidge and mattermost-api-reference-client, version 0.3.0 has been released.
  • slidcord, the Discord to XMPP gateway based on Slidge and discord.py-self, version 0.3.0, has been released.
  • matridge, the Matrix to XMPP gateway based on Slidge and nio, versions 0.3.0 and 0.3.1 have been released.
  • slidgram, the Telegram to XMPP gateway based on Slidge and Pyrofork, version 0.3.0, has been released.
• Slixmpp version 1.11.0 has been released. You can read the official release announcement for all the details.
• xmpp-dns versions 0.5.2 and 0.5.3 have been released. Full details on the changelog.
• xmpp-fastcgi-authorizer, a FastCGI Authorizer implementing XEP-0070 (Verifying HTTP Requests via XMPP) to allow logging in to websites using an XMPP account, versions 0.1 and 0.2 have been released.

Extensions and specifications

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

Proposed

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

• Pubsub Node Bookmark
  • This specification defines a bookmark element pointing to a Pubsub node.

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.3.1 of XEP-0317 (Hats)
  • Typos, completed some examples and paragraph clarifications thanks to badlop feedback. (tj)
• Version 0.2.0 of XEP-0503 (Server-side spaces)
  • Rewrite using pubsub semantics. (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 XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

XMPP Public channels

New rooms and public channels are created on a daily basis on the XMPP network. So, if you are on the look out for new and exciting public channels to join, make sure to check out the Public Channel Search Engine to find out groups or communities that share your interests!

• If you want to list all the channels, you can find them here.
• If you are interested on something in particular, look by tag!
• If you only want to list rooms in a particular language just add lang:xx in the search box, like in this example for the Spanish language. Just make sure to replace es for your desired language (like lang:fr, lang:de, lang:pt and so on).

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

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

Newsletter Contributors this month: emus, Badri Sunderarajan, cal0pteryx, Gonzalo Raúl Nemmi, Kris “poVoq”, Ludovic Bocquet, XSF iTeam

Translation Contributors:

• French: Adrien Bourmault (neox), anubis, Benoît Sibaud, Julien Jorge seveso, Pierre Jarillon
• German: Millesimus
• Italian: nicola
• 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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

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

License

This newsletter is published under CC BY-SA license.

We’ve just released version 1.7.1 of all of our test runners. This release adds two improvements to make interop testing both stricter and easier to set up!

Impossible Tests Can Fail Runs

Some tests can’t be executed if the server lacks required features. Previously, these “impossible” tests were skipped, which could make a run look fully successful when it wasn’t. Now you can configure the suite to treat impossible tests as failures, ensuring that a green run really means every configured test executed and passed.

Flexible Account Provisioning

Our tests act like clients, so they need accounts to log in. You can now choose from three provisioning methods:

• Admin Account using XEP-0133 to create test accounts.
• Explicit Test Accounts you configure up front.
• In-Band Registration via XEP-0077.

Pick the approach that fits your setup best. There is documentation available for you to review the finer details!

Together, these features give you more reliable results and more flexibility in how you run tests!

Splash image courtesy of Mohamed Nohassi, Unsplash

Meet Adam Rack, our new Business Development Manager.

Adam is all about building high-performing teams, driving innovation, and delivering solutions that make a difference.

In our latest chat, he talks about what excites him in this new chapter, his vision for growing our DACH presence, and why sustainability and community matter to him.

A big welcome to the team! Could you share more about your new role at Erlang Solutions?

For me, joining Erlang Solutions as a Business Development Manager means being part of change. What excites me most is that this is not a company standing still. As the market evolves, we are evolving too, moving towards being more solution- and product-driven.

I’m glad to contribute to this journey, learning from experienced leaders while sharing my own perspective. I want to support the team and help make Erlang Solutions a key player in the DACH region.

It has also felt like joining a big family: I was welcomed openly and immediately felt part of a supportive, knowledgeable community. Another aspect that matters to me is sustainability. I believe technology can play a big role here, using efficient architectures that need fewer servers, consume less energy, and still deliver world-class performance.

It’s motivating to know the systems we build aren’t just reliable but also lighter on resources, which I think will be essential in the years ahead.

Have you had any highlights from the job so far?

A highlight was attending ElixirConf US and seeing how central BEAM values are to the global community. Fault tolerance, scalability, concurrency, resilience: these aren’t just abstract concepts; they’re lived experiences for the people building with them. The community reflects those values too: highly collaborative, generous with knowledge, and positive.

What struck me most is how these values translate into mission-critical solutions that keep running for years without intervention. I even heard of a client returning after a decade because their system, untouched for ten years, was only now ready for an update. That kind of longevity proves both the robustness and efficiency of the technology: less waste, fewer rebuilds, and more sustainable impact.

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

I’m looking forward to being part of the company’s ongoing transformation together with Trifork, building solutions, products, and community in equal measure. It’s inspiring that technology created decades ago is still future-proof and highly relevant in solving today’s challenges. Erlang and Elixir’s ability to deliver resilient, scalable systems with lower infrastructure requirements fits perfectly with the growing importance of sustainability in tech.

That vision, combined with a culture of innovation, makes me confident we’ll continue to play a critical role for our clients. My goal is to help establish Erlang Solutions as a defining player in the DACH region, shaping not just projects but the ecosystem around us.

Outside of work, how do you like to spend your time?

In my free time, I keep things down to earth. Sailing is one of the activities that truly switches me off, even if I didn’t manage to do it as often as I’d like this year. Being out on the water, away from screens, reminds me what balance feels like.

I also enjoy simple routines: cooking at home, walking my dog, or short trips exploring new corners of cities. The more green areas, forests, valleys, and mountains I can discover, the better. I’m not chasing extraordinary hobbies; everyday activities bring the most energy for the challenges at work.

Final thoughts

Catching up with Adam left us inspired about what’s ahead for the DACH region. His focus on innovation, teamwork, and sustainability sets the tone for exciting things to come.

We will be sharing more stories like Adam’s soon, so keep an eye out. And if you want to swap ideas or connect with him or the ESL team directly, feel free to drop a message.

The post Meet the Team: Adam Rack appeared first on Erlang Solutions.

On October 14th, the European Concil will vote on a regulation that could effectively dismantle Europe&aposs emerging decentralized messaging ecosystem, and shake the broader European communication industry while failing to protect the children it claims to defend. Driven by Denmark&aposs fierce advocacy during its EU presidency, proposal 11596/25 – labeled &aposChat Control&apos by privacy advocates – finally faces a decisive moment after years of debate.

The proposal seems straightforward: require platforms to scan for child sexual abuse material. But the technical reality reveals a devastating contradiction: it demands the impossible from open, federated European alternatives while handing structural advantages to the very US tech giants Europe claims to want to regulate.

What the proposal actually requires

Proposal 11596/25 targets child sexual abuse material across a large range of services operating in the European Union: hosting services, interpersonal communications services, software application stores, internet access services, and online search engines. Under this regulation, these providers would be required to detect illegal content (images, URLs, text), report it to authorities, and remove it.

The scope goes far beyond what the European Parliament previously considered acceptable. In its balanced approach to child protection, Parliament explicitly rejected "widespread web scanning, blanket monitoring of private communications or the creation of backdoors in apps to weaken encryption." See: How the EU is fighting child abuse online.

This proposal abandons that restraint. It creates an obligation for service providers to scan all user traffic – encrypted or not – in search of illegal materials. More critically, it requires scanning private chat conversations before content is encrypted, not just publicly available content.

The risk of surveillance overreach

While child protection is undeniably crucial, the surveillance mechanisms described in this regulation create infrastructure that could threaten fundamental civil liberties. Once governments possess the technical capability to scan all private communications before encryption, the temptation to expand its use becomes overwhelming.

The concern isn&apost about protecting illegal content, it&aposs about protecting democratic discourse. Private conversations could become subject to monitoring based on shifting political definitions of harmful speech. What begins as child protection infrastructure could evolve into a tool for suppressing political opposition or monitoring dissenting opinions in private communications.

The infrastructure created for child protection becomes the foundation that future governments — potentially less democratic ones — could leverage to monitor any communications they consider threatening to their power.

This is what privacy advocates primarily focus on, and their concerns are valid. However, as operators of messaging infrastructure, we face more immediate technical realities that make this regulation unworkable regardless of its civil liberties implications.

Why the technical requirements are impossible to implement

As operators of XMPP messaging infrastructure in sensitive industries, like for example the medical sector, we face the practical reality of what this regulation would require. The technical demands in Articles 7 and 10 reveal fundamental misunderstandings about how modern communication systems actually work.

The architectural reality: In-band vs. out-of-band content

Modern messaging platforms fundamentally separate data types. Messages and protocol data transfer "in-band" through the messaging protocol, while binary content like images and documents transfers "out-of-band" because files are too large for messaging channels.

This creates an immediate problem for the regulation&aposs scanning requirements. When doctors share diagnostic images through our XMPP platform, the system works like this:

• Clients negotiate the exchange via XMPP (metadata visible to server)
• The medical file transfers peer-to-peer or via HTTPS upload with a unique, secure link
• The messaging server never sees the actual content – only the negotiation

The regulation can only scan in-band messaging content and metadata, not the out-of-band transfers where sensitive material could actually reside. It will break confidentiality of legitimate medical discussions without accessing the data it claims to monitor.

The open protocols impossibility

Article 10.1&aposs requirement to scan "prior to transmission" in end-to-end encrypted services assumes complete client control -- something impossible with open protocols like XMPP.

The regulation demands that service providers guarantee scanning occurs before encryption on every client. But XMPP is a standardized, open protocol where anyone can develop compatible clients. On an average XMPP server, more than 30 different clients coexist. How can we guarantee that each client respects scanning obligations when we cannot control their code?

The problem deepens with federation. XMPP servers interconnect, allowing users on different servers to exchange messages. When a message arrives from another server, it&aposs already been end-to-end encrypted by a client we have no control over. There&aposs no technical mechanism for the receiving server operator to enforce scanning requirements on clients that are not directly connected on its platform.

This creates an absurd regulatory requirement: we would need to either abandon open standards entirely or somehow police every piece of software that implements XMPP, including modified open-source clients that users could easily deploy to bypass scanning.

The circumvention reality

Real criminals can easily bypass these measures through three complementary approaches that the regulation fails to address:

Distributed architecture: Store content on external servers and share only URLs through chat, exactly what legitimate services like our XMPP platform already do naturally for file transfers.

External encryption: Encrypt content with PGP, GnuPG, or OpenSSL before uploading it anywhere, making scanning meaningless regardless of the platform&aposs capabilities.

Modified clients: Use altered XMPP or Matrix clients that automatically implement these behaviors, exploiting the same open-source flexibility that makes compliance impossible.

The result is predictable: the regulation will only catch criminals amateur enough to send illegal content directly as unencrypted attachments through unmodified clients. Meanwhile, it subjects all legitimate communications of European citizens to mass surveillance.

This isn&apost theoretical speculation. These methods are already standard practice across European messaging infrastructure, used by both legitimate services and bad actors alike.

The programmed death of European alternatives

This regulation creates a structural disadvantage for European communication services trying to build alternatives to US tech giants.

Complexity favors incumbents

Annex XIV reveals a scoring system of Kafkaesque complexity, requiring considerable resources for compliance. This complexity structurally favors large platforms, usually Americans, that can:

• Deploy massive financial resources to adapt their systems
• Control their closed ecosystems completely
• Distribute compliance costs across billions of users

The decentralized ecosystem under threat

Meanwhile, Europe&aposs emerging decentralized alternatives face impossible technical requirements. There are currently tens of thousands of independent XMPP servers, federated Matrix deployments, and GDPR-compliant solutions that represent Europe&aposs best chance for digital messaging independence. Can they comply with obligations designed around centralized architectures?

We operate several messaging servers on behalf of customers. Under this regulation, we face a stark choice: shut down services we cannot control completely, from clients to servers, or force our European clients to migrate for example to Microsoft Teams to avoid regulatory complications.

Conclusion

This technical analysis reveals a regulation that fails on multiple levels. It demands technical impossibilities from European service providers while offering trivial workarounds for actual criminals. It structurally advantages US tech giants over European alternatives at precisely the moment Europe seeks digital independence.

For communication service operators, this regulation creates an impossible choice: abandon open protocols and federated architectures that represent Europe&aposs best path to messaging independence, or face legal risks with high mitigation costs even in lawful, legitimate use cases.

The October 14th vote represents more than a policy choice about child protection. It&aposs a decision about whether Europe will cripple its own communication infrastructure in pursuit of surveillance capabilities that won&apost work as promised.

The current compromise proposal has been shared here: Proposal for a Regulation of the European Parliament and of the Council laying down rules to prevent and combat child sexual abuse - Presidency compromise texts. This seems is the most up to date version of the text I could find. Read the text and make your own assessment of whether Europe can afford to implement technical requirements that its own industry cannot comply with.

Kaidan 0.13.0 is out now! And it comes with a bunch of shiny new features.

Most of the work has been funded by NLnet via NGI Zero Entrust with public money provided by the European Commission.

Multi-Account Support

Kaidan supports the simultaneous usage of multiple accounts now. Imagine you could use the same chat app at work and with your friends. All your favorite and accustomed features would always be accessible without switching apps. It is possible with XMPP and finally with Kaidan too!

In order to quickly distinguish the account a chat belongs to, there is a small avatar of the corresponding account in the corner of a chat’s avatar. Furthermore, Kaidan makes sure that you do not accidentally add a new contact to the wrong account. That is achieved by selecting the account before you enter the contact’s chat address or scan their QR code. The same applies to the group chat actions.

Secure Password Storage

The account passwords are stored in the device’s password manager. You do not need to keep passwords in your mind. Instead, you can use random ones. They are securely stored in a central place.

Mark Messages

If you already read the latest messages from a contact but do not have time now to respond, you can simply mark them. A separate counter is shown for the marked messages. Take your time and come back to those messages later. You will not forget to reply anymore!

Forward Messages

You can forward messages from one chat to another. After clicking the corresponding context menu button, you can choose a chat to forward the message to. By default, only the chats of the current account are listed to make it as simple as possible for you. But you are able to list chats of other accounts as well.

Once you selected a chat, the message is added to its input field. You can directly send it or adjust it beforehand.

Changelog

There are several other improvements. Have a look at the following changelog for more details.

Features:

• Add support for using multiple accounts simultaneously (melvo)
• List accounts and show button to add new accounts (melvo)
• Show dialog to select account for global action such as adding a contact (melvo)
• Allow to enable/disable accounts instead of connecting/disconnecting them manually (melvo)
• Update nicknames of own accounts once connected (melvo)
• Show small account avatars next to regular avatars if multiple accounts are used (melvo)
• Hide global drawer handle on chat if window is narrow (melvo)
• Use PNG/.png instead of JPEG/.jpg for thumbnails to allow transparency (melvo)
• Use AAC/.m4a instead of MP3/.mp3 for voice messages to improve compatibility (melvo)
• Provide size of sent images to recipients allowing receiving client to scale thumbnails to size of original image (melvo)
• Provide size of generated thumbnails to recipients (melvo)
• Increase size of generated thumbnails (melvo)
• Show circle instead of bar for upload/download progress (melvo)
• Try all providers on connection error during automatic registration (melvo)
• Add message forwarding (melvo)
• Enable voice message recording via Flatpak (melvo)
• Store account passwords encrypted if password manager is available (fazevedo)
• Apply consistent criteria for all message corrections (melvo)
• Add support to mark messages locally in order to reply to them later or to quickly find important messages (melvo)
• Reuse SASL 2 user agent and FAST token on every restart for faster connection establishment (melvo)

Bugfixes:

• Fix selecting media via long press in media overview (melvo)
• Fix OMEMO initialization (melvo)
• Fix displaying geo location map (melvo)
• Fix showing hints on invalid input of various input fields (melvo)
• Fix name/date of chat list item moving if counter for unread messages dis-/appears (melvo)
• Fix counter for unread messages (melvo)
• Fix handling removed message reactions (melvo)
• Fix canceling personal data sharing via contact details (melvo)
• Fix finding existing notifications for personal data sharing requests (melvo)
• Fix cursor behavior in message input field by allowing vertical cursor movements while participant picker is closed and prohibiting horizontal cursor movements while participant picker is open (melvo)

Notes:

• Kaidan requires QtKeychain 0.15 now
• Kaidan requires QXmpp 1.11 now

Download

• Source code (.tar.xz) (sig signed with 04EFAD0F7A4D9724)
• Linux (Flatpak on Flathub)

Or install Kaidan for your distribution:

The IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.2 brings a number of stability improvements and bug fixes.

Notably, it addresses a recently identified security vulnerability, identifies as CVE-2025-59154. The issue allows for potential identity spoofing via unsafe Common Name attribute parsing. It is mostly applicable to what we perceive to be niche use-cases of Openfire. Please read the full security advisory for more information.

Openfire 5.0.2 is a bugfix release, with various bugfixes and improvements. Of particular interest to some will be the improvements made to the SystemD-based scripts (used in many Linux environments), which remove a few annoyances that were introduced in Openfire 5.0.1. Please refer to the full changelog for more details.

You can obtain the new version of Openfire for your platform from its download page. The checksums for the binaries are:

4e907c615b3a19af0a1b5ab68ae24825b737496f9cf1715c9feafe8f909086da  openfire-5.0.2-1.noarch.rpm
21271a6f22895852e50712236c45c7d213430171d5a3178474b8398f036ac07a  openfire_5.0.2_all.deb
06794a12acdd8f23ca3c40fcd7af1677d8108b4b23bb72424c2751b30cfb3d14  openfire_5_0_2.dmg
c1e830b5e016d0bcff40005cc7bb14c846fe0ec26fc5a3fc967c30e5b6d2e356  openfire_5_0_2.exe
c84ca15cd470d3233add97c852c738eb373859dc9968ad34ec581725164c8114  openfire_5_0_2.tar.gz
98b5cf96326c668efb18cd9347b808a5ef85162b4a0b703aaf8e29d82cc6c727  openfire_5_0_2_x64.exe
8e09ca3dc7fb84b116ce95d10bfa3ff045708cdac4b23bd3d78ccf318e8742d8  openfire_5_0_2.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

2 posts - 2 participants

Read full topic

Since the last update, we’ve added a lot more options on how to run your tests. We’ve added a slew of new CI systems, this time focussing on freedom-respecting, open source CI systems for your open source projects.

Recent additions include Jenkins, Drone, Harness and Woodpecker.

This brings our total number of CI systems in which you can run XMPP interop tests up to a whopping ELEVEN, plus anywhere else you can run containers!

Whether you’re building in GitHub, GitLab, CircleCI, Jenkins, Forgejo, Woodpecker, Drone, Hardness or Bamboo, we’ve got you covered. If you build locally, you can run the JAR, and if you build anywhere that has a Docker or OCI image container runtime, you’re sorted.

We’ve done our absolute best to preserve every option in every runner, but not all CI systems are created equal, and there might be some discrepancies. If there’s a feature you’re missing that you need, do let us know.

Similarly, If there’s a CI system that you’re using that you’d like us to support, or if we do support it but you’re struggling, come find us in our MUC, or open an issue on GitHub.

Test all the things!!!1!

Splash image courtesy of Clay Banks, Unsplash

Joining conferences is one of the best perks of working as a Developer at Erlang Solutions. Despite having attended multiple Code BEAM conferences in Europe, ElixirConf US 2025 was my first. The conference had 3 tracks, filled with talks from 45+ speakers and 400+ attendees, both in-person and virtual. 

ElixirConf is one of the great occasions to connect with other Elixir enthusiasts in the community and get to learn what others have been doing as well as what the Elixir core team is planning for the future of the language.

The Atmosphere

Most of the faces were unfamiliar to me, but as expected from the BEAM community, everyone was super friendly. Most were not shy about approaching others, sharing about their own or their company’s experiences. The “hallway track” was always lively during the coffee break or during the talks.

Before the conference began, I had a tough time deciding which talk to attend. At other conferences I’ve been to, most of the talks were interesting, but not all were relevant to my daily work as an Elixir developer. That made it easier to prioritise which talks to attend live and which ones I could catch up on later if they overlapped.

ElixirConf was different. Many of the talks were not only interesting but also directly relevant to my work, and several were scheduled at the same time. This made it very difficult to decide which session to attend in person and which to leave for the recordings.

Some standout talks

Chris McCord’s Keynote: Elixir’s AI Future

One of the talks I was most looking forward to was the keynote by Chris McCord. I had previously watched the recording of his ElixirConfEU keynote about phoenix.new and was eager to see what new ideas he would bring to Elixir and the Phoenix framework, especially in terms of AI.

Chris talked about AI agents, how Elixir is well-suited for building them, and what the future of Elixir and AI might look like. He emphasised that it is not about chasing hype but about staying on the bleeding edge of technology: “building the things we want to build, building the things we want to see.”

He also shared his perspective on code generation, noting that it has made it easier for newcomers to get started with Elixir and Phoenix. In his view, the community is now in a strong position to attract developers from outside the ecosystem to give it a try.

Panel: Building Careers, Balancing Life

Another talk I was eager to hear was the panel discussion hosted by my Erlang Solutions colleague Lorena, together with Allison Randal, Savannah Manning, and Anna Sherman, three women from different backgrounds and stages of their careers.

It was great hearing stories from other women in the tech community and feeling inspired. The three panellists shared the stories and challenges they had faced in their careers. They also talked about the importance of having mentors, the community, and knowing the big picture, which helped them grow. The advice they gave during the talk was both very relatable and inspiring.

Joe Harrow: Beyond Safe Migrations

I also found Beyond Safe Migrations to be great food for thought. This talk was a very practical and solid example of what could go wrong in a live database migration, and the tool Cars Commerce was using to prevent that. Over the span of my career, I have written many database migrations, from small startup projects altering a table with only a few hundred rows to large-scale projects where the tables had millions of rows.

My team sometimes discussed strategies for altering existing tables, but most of the time we would just go ahead and make the changes. Listening to Joe, I learned about things that could have gone really wrong and that there is a systematic way of mitigating those risks.

Key Takeaways

All in all, Elixir Conf US was a great conference, packed with talks about experiences and challenges, new and upcoming technologies, and also about growing the community. There was, of course, a surge in AI-related talks, both from early adopters to the future of Elixir with AI. 

I found that the main theme running through the conference was the growth and sustainability of the Elixir community. ElixirConf is well worth attending, whether you are just starting out or already an experienced developer.

The post ElixirConf US 2025: Highlights from My First ElixirConf appeared first on Erlang Solutions.

XMPP Newsletter Banner

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

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

Videos

• XMPP Tutorials DE by eversten.net.
  • Conversations (XMPP): Permanente Benachrichtigung deaktivieren. [DE]
  • Conversations (XMPP): Sprachnachrichten pausieren und probehören. [DE]
  • Conversations (XMPP): Schnellzugriff auf wichtige Kontakte. [DE]
  • Conversations (XMPP): Möglichkeit eines Passwort-Resets schaffen (bei conversations.im) Passwort. [DE]
  • Conversations (XMPP): Kontakte schöner benennen. [DE]
  • Conversations (XMPP): Eigenen Anzeigenamen setzen. [DE]
  • Conversations (XMPP): Schnelltaste definieren. [DE]
  • Conversations (XMPP): Einstellungen der Anhänge optimieren. [DE]
  • Conversations / Quicksy (XMPP): Zuletzt verwendet. [DE]
  • Messaging mit XMPP - Wie finde ich die passende App? [DE]
  • Quicksy - Der einfachste Einstieg in XMPP (Android-Version). [DE]

XMPP Articles

• NLnet: New wave of projects to create digital commons
  • ejabberd Great Invitations: One of the biggest hurdles for XMPP in terms of widespread adoption compared to single vendor solutions is a somewhat more complicated onboarding process. The goal of this project is to make this process as seamless as possible by simplifying the onboarding process - a single link is enough to guide a potential future participant - and implement it for ejabberd.
  • Convo XMPP client: The primary goal of this project is to develop Convo into a fully functional app that forms a viable messaging solution for KaiOS users, and publish it on the official KaiOS Store, replace the UI with a better one based on the solid-telekram project, ensure compliance with the basic XMPP Core and IM Compliance Suites (defined in XEP-0479), as well as expose end-to-end encryption (OMEMO v0.3) functionality. Visit the project page for all the details!
• A Rising Tide Lifts All Boats from XMPP Providers Blog. Here the project does a review on their survey results from feedback of listed XMPP Operators and explains more about the purpose of the project.
• Wait, did Movim just unlock the global search feature in its chat messages? from the official Movim blog.
• XMPP/Jabber Debian 13 Trixie News. Take a look at some of the features, that Debian 13 Trixie will bring on packages related to XMPP, a.k.a. Jabber.
• Jabbers.one The server has been migrated to the hosting provider Netcup. A public monitoring status page is now available at: https://xmpp-status.fluxxer.de. Also a Grafana statistic site is now available at https://stats.jabbers.one.
• jabjab.de XMPP server celebrates 20 years of existence! [DE]
• MongooseIM 6.4: Simplified and Unified by Pawel Chrzaszcz for Erlang Solutions.
• O protocolo mais perfeito dos imperfeitos by isadora. An overview of the benefits of XMPP, including tips on how to introduce it to new people who may not be interested in the technical details. [PT_BR]
• Cambios en mi red de la mano de XMPP by Gabriel Viso Carrera for gvisoc.com. [EN]
• Wondering what Monocles has in store for their next version? Besides of the array of assorted enhancements and fixes that Monocles includes in every new release, the upcoming version will include support for XEP-0118 (User Tune), enabling its users to optionally share with their contacts the music they are currently listening to. This feature enhances social interaction by allowing users to discover new music, share their tastes, and connect over shared interests, fostering a more engaging and collaborative experience within the app. Check out the original announcement! A big thank you to the developer who contributed to this feature!

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.19.0-1 for Android. Make sure to check out the changelog for all the details.
• Conversations has released versions 2.19.3 and 2.19.4 for Android. This version brings improved performance for large public channels, a new ’empty chats’ page instead of redirect to ’new chat’ screen, and requires TLS 1.3 for all connections with a setting to opt out, among other fixes and improvements. You can take a look at the changelog for all the details.
• Converse.js has released version 12.0.0 of its open-source web-based XMPP chat client, with various improvements and bugfixes. Several behind-the-scenes changes include OMEMO related fixes, using rspack instead of webpack, releasing an ESM build of the “headless” library version, and using an updated provider list from providers.xmpp.net for in-band registration. Head over to the release page for the full changelog!
• Gajim has released version 2.3.4 of its free and fully featured chat app for XMPP. This release supports time zones in profiles, adds drag and drop improvements, enables displaying long messages inline, and fixes many smaller issues. You can take a look at the changelog for all the details. Thank you for all your contributions!
• Monal has released version 6.4.13 for iOS and macOS.
• Monocles has released version 2.0.13 of its chat client for Android, featuring a load of improvements like a refactored message retraction and moderation (retracted messages disappear on both sides now, the same for retracted files), a message bubble redesign, show images in full quality, a new option to import own stickers and GIFs, among many other features and a lot of fixes. Make sure to take a look at the changelog for all the details!
• Profanity has released version 0.15.1 of its popular console based client for XMPP. You can read all the details about this release on the changelog.
• Prose has released versions 0.12.0 and 0.12.1 of its web frontend prose-app-web! You can read all the details in the release announcement.
• Psi+ has released version 1.5.2109 to 1.5.2114 installer of its development branch of the Psi XMPP client.
• XOWS has released versions 0.9.9 and 0.9.9b of its XMPP Over WebSocket web client, with numerous bug fixes and some new features.

XOWS 0.9.9.b: Automatic embedding of images, video and audio.

XMPP Servers

• ProcessOne is pleased to announce the release of ejabberd 25.08. This release includes the support for Hydra rooms in the Matrix gateway, which fixes high severity protocol vulnerabilities, a fixed and tested to work ACME in Erlang/OTP 28.0.2, and brings in a new mod_providers to serve XMPP Providers file among many other features and improvements! Make sure to read the changelog for all the details and a complete list of changes, new features, fixes and improvements!

XMPP Libraries & Tools

• go-xmpp version 0.2.17 has been released.
• go-sendxmpp version 0.15.0 has been released. Full details on the changelog.
• python-nbxmpp version 6.3.0 has been released. Full details on the changelog.
• QXmpp versions 1.11.0 and 1.11.1 have been released. Full the details on the changelog.
• xmpppy version 0.7.2 has been released. Full details on the changelog.
• xmpp-dns version 0.5.1 has been released. Full details on the changelog.

Extensions and specifications

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

Proposed

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

• No XEPs proposed this month.

New

• No New XEPs this month.

Deferred

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

• No XEPs deferred this month.

Updated

• Version 1.2.3 of XEP-0167 (Jingle RTP Sessions)
  • Make ‘ssrc’ attribute ‘xs:unsignedInt’ (32-bit) instead of ‘xs:string’ to match RFC3550. (lnj)
• Version 1.6.3 of XEP-0198 (Stream Management)
  • Remove leftover <optional/> and <required/> children in <sm/> element. (egp)
• Version 0.3.0 of XEP-0317 (Hats)
  • Add hat creation and destruction flows; add hue optional parameter; add chatroom presence hats broadcast; complete disco#info; clarify how the service should broadcast updated hats; typos; standardize the form fields; (tj)
• Version 1.0.4 of XEP-0388 (Extensible SASL Profile)
  • Schema should use all instead of sequence (dg)
• Version 0.4.0 of XEP-0455 (Service Outage Status)
  • Remove leftover pubsub references, add accessibility considerations. (mp)

Last Call

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

• No Last Call this month.

Stable

• No XEPs moved to Stable this month.

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

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

Newsletter Contributors & Translations

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

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

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

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

License

This newsletter is published under CC BY-SA license.

Last week, Spotify quietly launched direct messaging across its platform in selected areas, allowing users to share tracks and playlists through private conversations within the app. The feature was rolled out with minimal fanfare but significant media coverage, positioning itself as a complement to existing sharing mechanisms through Facebook, WhatsApp, and TikTok.

When I read this, I immediately wondered why they were bothering. We do not especially lack communication channels these days. So, Let’s take a step back and examine what Spotify is actually trying to accomplish here.

The Strange Case of Another Messaging App

We already have too many messaging apps to choose, either on mobile or mobile phones. Before I try to initiate a conversation with someone I do not often chat with, I find myself trying to remember what is her preferred messaging platform. So, adding to an app some sorts of real time messaging and live interaction features can bring value, but it has to serve a purpose and respond to some user needs.

In that context, Spotify’s decision to roll out direct messaging support feels odd. Users can already share music through established platforms where their friends actually are. They can post discoveries on social media, send links through WhatsApp, or create collaborative playlists. Why would anyone choose to message someone specifically within Spotify when they’re already connected elsewhere?

The problem is that Spotify failed to make a compelling argument for why users should discuss with friends through yet another messaging system, even if this is to talk about music. Launching a special purpose communication service is risky. When Apple Music attempted to build Ping, a social network of music fans, it failed spectacularly. Spotify’s own social experiments haven’t fared much better. Remember Greenroom, their audio-focused social platform that quietly disappeared?

This initiative becomes even more puzzling when we consider Spotify’s own history. The company built its initial viral growth through Facebook integration, leveraging social connections to drive adoption.

And now, seemingly, they are trying to reclaim that social layer for themselves?

What’s Really Happening Under the Hood

The technical implementation reveals interesting choices. According to available reports, the messaging system relies on a RESTful API over HTTPS with TLS 1.3 encryption and JSON Web Tokens for session authentication. Notably absent? End-to-end encryption.

And this absence tells us that the feature is not considered as a standard messaging service yet, but simply an alternative way to share favorite tracks and discuss them, and a possible a move to reduce the amount of data exposed to other social networks and messaging.

The Data Intelligence Play

Messaging features can provide enormous value when you have a strong daily user base, but only when they address a clear user need. Spotify’s messaging doesn’t seem designed for users. It feels designed for Spotify’s recommendation algorithms.

Every shared track, every reaction, every conversation thread becomes a new data point in Spotify’s machine learning models. Who shares what with whom? Which songs generate discussion? How do musical tastes spread through social networks? This intelligence is pure gold for a recommendation engine that already struggles to compete with YouTube Music’s discovery capabilities.

Private messaging amplifies this data collection while keeping the intelligence proprietary, unlike public social sharing, where competitors might also benefit.

Strategic Confusion or Calculated Move?

So, is this really all about data collection and control?

This is where Spotify’s European identity becomes relevant. As a Swedish company competing against American tech giants, there may be strategic value in reducing dependence on US or controlled Chinese social platforms. Every track shared through WhatsApp (Meta) or TikTok (ByteDance) represents data flowing to potential competitors or partners with their own agenda.

Building an internal messaging system allows Spotify to capture that social intelligence directly while reducing what they share with other platforms. From a data sovereignty perspective, this makes sense, especially for a European player navigating an increasingly fragmented global tech landscape.

And they may hope at some point to play a larger role in messaging platforms in general, as we deeply miss a large player in the messaging field in Europe. It may be a play to test the waters.

As we help companies reclaim their independence by building their own messaging service, this goal resonates strongly with us. However, building a successful messaging platform requires being able to create momentum around the service if it wants to attract enough users and traffic. It cannot be launched halfheartedly.

The Missing Strategic Vision

The fundamental problem isn’t technical. It’s strategic clarity. Spotify has a recommendation engine that could benefit from social signals, a creator platform focused on podcasts and videos, and a user base that already shares music socially. The ingredients for a compelling set of social features exist.

But launching messaging without addressing the basic question of “Why would I message someone here instead of where we already talk?” suggests a feature developed in isolation from user needs. It resembles the countless platform features that launch with media coverage but die quietly when adoption numbers disappoint.

What would make this feature compelling? Integration with Spotify’s creator tools, perhaps allowing artists to connect directly with fans. Or collaborative listening live sessions where messaging enhances shared musical experiences. Or leveraging Spotify’s podcast ecosystem to enable discussion around episodes.

Instead, we get generic messaging that competes with platforms where users’ friends actually are.

So, what’s Spotify’s real goal?

I see two possible options here: a pessimistic and a more optimistic one.

Perhaps the most interesting aspect of this launch is what it reveals about Spotify’s growth concerns. A mature platform doesn’t typically add generic social features unless it’s worried about engagement metrics or looking for new growth vectors.

They may want their users to spend more time in its interface, instead of most of the time, passively using that app through a player exposed as a widget in the mobile operating system.

The timing suggests Spotify sees either limited growth ahead or a competitive threat that requires better user data. Given the AI revolution in music generation and the ongoing battles over royalty structures, capturing more nuanced data about user preferences and social music behavior could be crucial for maintaining relevance.

But there’s a more optimistic reading: this could represent a European tech company trying to assert more independence from American social platforms. In a world where data is power, controlling your own social graph has strategic value.

The execution, however, suggests Spotify hasn’t quite figured out how to articulate this vision to users. Until they do, this messaging feature risks joining the graveyard of platform additions that made sense to product managers but never found their audience.

In a world already oversaturated with communication channels, every new messaging system needs to answer a simple question: Why here instead of everywhere else users are already talking? Spotify hasn’t answered that question yet.