We hear this too often: “XMPP uses XML. It should use JSON—it’s more modern.”

The logic seems straightforward: JSON came later, so it must be better. But better for what, exactly?

JSON became successful because it’s the standard serialization format for JavaScript. That made it convenient for browser-based applications.

Does that make it the universal format for every protocol? Of course not.

Consider this: browsers still use HTML to organize web pages, not JSON. Same with CSS. Why? Because using JSON for everything would be a nightmare.

XML remains the best format for representing trees—deep hierarchies of nested data. JSON handles flatter structures well, but good messaging protocols are extensible: extensions can be embedded at different levels and composed together, like Lego bricks. That’s where XML shines.

The Performance Myth

Another common claim: XMPP’s XML is more complex than JSON, so it must be much slower.

In practice, XMPP chat platforms are snappier, with remarkably low message latency. How?

XMPP clients don’t parse XML the way most people assume. They’re not building massive DOM trees in memory, like a browser loading a page. Instead, they use stream-based parsing—XML arrives, gets parsed incrementally, and converts directly into native data structures.

This is especially true in browser environments, where XMPP streams run over WebSockets, which naturally frames the XMPP protocol. That’s why you are never actually working with XML trees consuming large chunks of memory. Modern implementations like XMPP.js go further and use LTX—a lightweight parser built specifically for XMPP’s streaming model—rather than the browser’s DOM parser. The result: developers work with JSON-like objects anyway. The wire format becomes invisible to your application code.

XML brings three key advantages:

• Built-in extensibility with validation via XML Schemas
• Clean namespace management for XEPs: when the protocol needs to evolve, you can change the namespace of an extension, making versioning explicit and backward compatibility manageable
• 25+ years of mature tooling and battle-tested parsers

These matter when you’re building federated systems that need to evolve over time and need to stay compliant over time. The XMPP federation is a huge ecosystem of servers that can talk to each other, relying on different server implementations and are not always up to date. Still, the federation works, and we too often forget that this is a great achievement in itself.

Real performance bottlenecks in XMPP deployments come from elsewhere entirely: network latency, database optimization for roster and message storage, custom module performance, external components, or clustering and routing logic.

The myth persists because XML looks verbose when you read it. But visual verbosity has almost no correlation with parsing performance. Modern CPUs parse XML and JSON at nearly identical speeds for typical XMPP message sizes. Any difference vanishes in a real-world client.

Where the Real Complexity Lives

XMPP does have genuine complexity—but it’s not the wire format. It’s the protocol depth and the extensive XEP ecosystem with hundreds of extensions. That’s a real learning curve.

Consider XMPP when these factors matter to you:

• Federation across organizational boundaries
• Open standards and avoiding vendor lock-in
• Protocol stability that won’t break in three years
• Extensibility without forking the protocol

If those resonate, the wire format should be the least of your concerns.

We’ve been building XMPP systems for over 25 years. The XML performance question comes up often in early conversations. Every single time, we end up optimizing ejabberd configuration, clustering, architecture, client protocol usage, and databases instead.

Thinking about XMPP for your next project? Reach out during the design phase. We’ll help you avoid the actual bottlenecks.

The Smack developers are happy to announce the availability the first release candidate (RC) of Smack 4.5.0.

The upcoming Smack 4.5 release contains many bug fixes and improvements. Please consider testing this release candidate in your integration stages and report back any issues you may found. The more people are actively testing release candidates, the less issues will remain in the actual release.

Smack 4.5.0-rc1 is now available on Maven Central .

1 post - 1 participant

Read full topic

Signal improved its protocol to prepare encrypted messaging for the quantum era.

They call the improvement “Triple Ratchet” (or SPQR = Signal Post-Quantum Ratchet).

If history repeats itself, this could become the next open standard for secure messaging.

Signal (formerly Open Whisper Systems) created the Double Ratchet protocol in 2013–2014, introduced in TextSecure v2 in February 2014. They packaged it into the open source Signal Protocol. It became the mainstream standard for end-to-end encrypted messaging. XMPP adopted it (OMEMO, developed in 2015). Matrix adopted it (Olm/Megolm implements Double Ratchet concepts).

The problem is that current encryption methods could break when quantum computers get powerful enough, so Signal built Triple Ratchet to protect against that.

Most messaging companies are preparing for this but I noticed that WhatsApp has no public roadmap for the adoption of quantum resistance protocols. They use the Signal Protocol for encryption, so they may simply wait for the result of Signal’s work to adopt the new approach.

It is much heavier to implement, so I am wondering if Triple Ratchet follows the same path as Double Ratchet and gets widespread adoption.

If open protocols like XMPP and Matrix adopt it, it may be huge for European messaging independence.

What’s your take? Do you think quantum resistance will become a mandatory feature for end-to-end encrypted messaging platforms in the next couple of years?

Good news for anyone building messaging infrastructure in Europe: Denmark&aposs Council presidency is abandoning mandatory detection orders in the Child Sexual Abuse Material (CSAM) proposal for now. The proposal was nicknamed "Chat Control" because it was invasive, requiring platforms to scan all message content. To do that, it would have required bypassing end-to-end encryption, practically creating a surveillance infrastructure.

They gave up after Germany and other EU countries blocked the message scanning obligation. They abandoned plans to put the text to a vote in the Council of the European Union in October as they had hoped. Now, they propose to return to the previous status quo .

It&aposs a relief for companies working on open and standards-based infrastructure. As I&aposve already explained, mandatory scanning is technically impossible to enforce for federated protocols like XMPP and Matrix . Europe&aposs decentralized messaging ecosystem would have been threatened, and the law would have been ineffective at preventing illegal data exchange, as encryption can always be applied outside of the chat application.

I know this is the type of fight that is never really over, but still, it is nice to see that sometimes sanity can prevail.

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

1 post - 1 participant

Read full topic

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.