The XMPP assembly for 39C3 has been confirmed!

The Chaos Communication Congress is a hacker conference that takes place every year barring specific world-ending events, and in which more than 10 000 hackers come together in Hamburg (or previously Leipzig or Berlin).

We will have a space inside the Critical Decentralization Cluster habitat this year, which will provide a friendly space for discussions and exchanges on technology and politics with other communities working towards decentralization.

I will come with a bunch of sparkly XMPP stickers that look like this:

If someone plans to stay a while at the assembly, please make sure to register with the assembly on your ticket, as described in the info pages, so that we have enough room for everyone.

On December 9th I returned to the Trolley Barn to DJ again for my friend Valerie Young. This time around my goal was to have a better mix of high energy and lower energy “groovy” tunes, and I wanted to be better prepared for tying in endings at any time, no matter how many times through the caller requested.

Prep

While I still prepped by marking each time through the dance with whether it looped cleanly or not, this time I (mostly) marked it with a cue instead of a 64 beat loop. I also named the cue based on what other cues I could jump to cleanly from it. For example, if I were on the last time through the dance I would mark if it looped cleanly itself, but also that I could jump backwards 3 times to cue 6 (or whatever the case may be). This way if I’m nearing the end of the dance but the caller is running it a bit longer I can reset without a single 32 bar phrase starting to get repetitive. I can also plan ahead by seeing that cue 6 lets me jump back to cue 8 or 9 afterwards (let’s assume these are the last two cues), which means that if the caller immediately calls 2 more times through I know that I can cleanly jump back to 2 more times without incident. I also mark a handful of things in the music such as if this time through the dance is a big recognizable build up (which I might not want to repeat even if technically it sounds okay), or if I shouldn’t jump back before a cue because the energy is significantly lower and we don’t want to kill the energy that had already been built up on the dance floor. This made it much easier to always follow the callers instructions and not have to scramble to wrap up the song or ask if we can do 4 times through the dance instead of 2 or what not.

The Set

I started out the set with a slowed down mix of “Whelan’s”, “Baghad Gus”, and “Congress Reel” all by Wild Asparagus. This was a medley that I had planned for my previous set but hadn’t managed to use, but it worked quite well to “Whoever is Right is Right” by Jim Hemphill. The only iffy moment I had in this medley was in one of the transitions where I thought I executed it perfectly, only to have the tune I was introducing jump half a beat ahead, breaking the rhythm. I had left the Quantize option on (which locks the two beat grids together even if you’re a little bit off) and unfortunately the beat grid on the song in question was about half a beat off at the point I was doing the intro.

Lesson learned: pay more attention to what options you’ve got selected (and reset them between songs, this would be a problem several times during the evening) and in a song where the beat grid can’t be right through the entire song (ie. because of tempo changes), make sure it’s correct at the point you’re going to mix in.

For the second dance Valerie picked “Made Up Tonight” by Erik Hoffman. This dance is relatively easy and in some ways similar to the previous dance so I decided the dancers could handle a little bit higher tempo and energy level. I did a mix of “Bus Stop!” by The Free Raisins and “Rec Hall” by Kingfisher. This is another mix I had prepared for my previous set and one of the ones I was most excited about performing. Unfortunately I completely broke the transition by just forgetting to bring the volume up on Rec Hall, so I ended up killing the music entirely for a few beats before I realized what was happening and brought it back in. It sounded terrible, and this one the dancers couldn’t help but notice, but Valerie kept calling so they were on beat still when I finally realized what was happening.

Lesson learned: go ahead and beat match and mix in a few bars early, then do the transition by bringing the volume up instead of just hitting play, or just remember to have the volume up first.

At this point Valerie decided to take the evening in a different direction from the modern, improper and becket contras that the Trolley Barn normally asks callers to stick to. She called “The Steps of Waterloo”, a traditional Sicilian circle, which I’ve never seen done at the Trolley Barn before. Since this one is both easy and a bit silly I used “[Flying Ice Cream]” by Giant Robot Dance which starts out very slow and groovy, then ramps up dramatically in the second half. Once the dance ramped up I mixed it with “The Randomainians” by The Great Bear Trio to make it last a little longer. This was the one mix and dance combo of the night that I was mostly extremely pleased with, when the tempo and energy ramped up half way through the song the dancers cheered and started frantically rushing to try and get to the basket swing in the limited time the (normally too fast) music allowed which was a lot of fun.

Lesson learned: prepare about twice as much music as you think you’ll need for the evening (to be fair, I already knew this, I was just struggling with the preparation for this set and didn’t end up with enough time to finish the other mixes I was considering).

Continuing Valerie’s theme of not doing modern contras she picked “The Hand Jive”, a proper ceilidh, by Colin Towns next. Because this dance is a bit more “fun” and contains some patty-cake like hand games I decided to do a simple but fun mix of “Raccoon” by Wake Up Robin and Disco Snails by Vulfmon and Zachary Barker.

Unfortunately I hadn’t considered that, easy as the hand clapping is, it required Valerie to do a significant amount more calling than she normally would do and never drop out, so picking a song with lyrics was a bad idea. A few people still got a chuckle out of the “Disco Snails” cameo though.

Lesson learned: make sure to pay attention to how much the caller will have to talk and ask if they plan on dropping out before introducing something with lyrics.

We took our mid-dance waltz break at this point for which I played “Waiting for Landfall” by Julie Vallimont, “Indifference” by the String Beings, and “Norwegian Reinlender / Schottis From Idre” by Wild Asparagus. I’d hoped that some of the dancers would know the schottische for the second part of the medley, but mostly it just confused everybody who kept trying to waltz even though it was no longer a waltz.

Coming back we were running a bit late so I decided to drop the show-stopper for the evening, a mix of “Rainy Night” by The Dam Beavers, “Tween Spirit” by Giant Robot Dance, and “Smells Like Teen Spirit” (which, of course, the previous tune is a cover of) by Nirvana. This was paired with “Birminghams” by Gary Nelson.

I played the first two tunes as a normal medley, then when Valerie indicated that she was ready for three times left through the dance I mixed in the actual Nirvana version just for the ending. I was worried this crowd wouldn’t care for it, but when the tune first came in (as “Tween Spirit”) a lot of the dancers started singing along, and when actual Nirvana came in at the end the energy really ramped up and there was a lot of cheering and stomping, so apparently even the younger members of the crowd were still excited about 90s grunge!

The only real problem with this dance is that I had one moment where I had a clean loop that I wanted to repeat but as I did so some of the dancers, knowing what came next in the song, started singing the next verse and then had to stop when the music wasn’t what they expected.

Lesson learned: when doing a pop song don’t do transitions that would break the progression of the song that people are already used to, even if they sound okay.

At this point I realized that I hadn’t prepared enough mixes for the dance and I was more or less out of material. For the next one Valerie asked to do a very short square dance, the “Cumberland Square Eight”. Since it was going to be so short and timing didn’t matter I played “Heather’s Concussion” by The Great Bear Trio without mixing it into a medley.

This tune is itself very short (only three times through) and far too fast for a normal contra, so I slowed it down (though still keeping it too fast) and sped it up slowly through the dance to mess with the dancers. They looked like they had a good time!

This left us with just enough time for a no-walk-through contra. I had nothing else prepared but wanted to send us out on an easy-tempo dance after the various fast shenanigans from the rest of the night, but still have some good energy. I dug around in my library and ended up playing “Apple Blossom” by Great Bear. Since I didn’t have anything to mix this with I just played it through and looped once or twice near the end to keep the high-energy ending going. The dance Valerie picked was an easy ending dance that is unfortunately called “Unnamed Contra” and she didn’t know who wrote it.

We then closed down the evening (very late, much to the chagrin of the organizers) with “Mending” by “The Little Mercies”.

Stuff I Learned

A recap of the things I need to take away from the evening:

• Be thoughtful about resetting all controls, levels, mixing, effects, etc. between tunes. Possibly write down the initial state for each song so that you can re-set the board at a glance.
• Beat match early then use the volume sliders for transitions, don’t just start playing immediately at the entry point (or just remember to turn up the volume as you approach the mix point).
• Consider how much the caller will have to talk in any given dance and how soon they’re dropping out before mixing in vocals.
• For pop songs, don’t violate the order of the verses or breaks that people expect, even if the final result sounds okay. It’s jarring for the dancers who are used to it being a certain way.

And finally: relax and enjoy it! While I spend the entire evening worrying about how the sound dropped out for a moment, or my transition was a beat off and I saw the dancers stumble and catch back up, or whatever other disaster might have befallen, no one remembers any of that. I got a very nice message from the organizer the next day telling me how excited everyone was and how many conversations she’d had with people telling her how much they enjoyed the music!

Other Links

• The set list on MusicBrainz
• Recordings of the evening can be found on the Internet Archive

As we close out our “Meet the Team” series for 2025, we’re delighted to introduce Camjar Djoweini, Business Development Manager, Nordics, at Erlang Solutions. Camjar shares what drew him into his new role, the excitement of working within Trifork’s global ecosystem, and the ambitions driving him into 2026. He also reflects on his favourite winter traditions and the personal routines that help him stay energised and focused throughout the year.

Can you tell us about your new role at ESL?

I’ve joined ESL Nordics Fjällräven as Business Development Manager, Nordics, where my focus is expanding our market presence into new greenfield areas alongside Erik. The mission is clear and energising: outbound, outbound, outbound.

Which part of your new role has sparked the most curiosity or excitement so far?

It’s a mix of working with exceptionally talented and experienced people and having access to the opportunities that come with being part of Trifork globally. I love that I’m within one of 71 companies in the group yet still feel connected as if we’re operating as one large organisation. We’re agile like a startup but strong like a Fortune 500. That breadth of access and innovation keeps my curiosity alive every day.

Looking ahead to 2026, what are you most looking forward to achieving?

I’m a high pressure performer and set ambitious expectations for myself. My goal is not only to hit the targets we’ve set but to exceed them, to make the whole team proud. I want to help shape our future, open new doors within the organisation and contribute meaningfully to our long term vision.

Ahead of the holiday season, are there any traditions you’re particularly looking forward to?

This might be an unpopular opinion, but I love the darkness and the cold. There’s something beautiful about how snow lights up the darkest hours. Winter helps me focus with routines, deadlines and structure, all leading to one of the cosiest traditions of the year. Good food, warm decorations, time with friends and family and the chance to unwind for a week. Christmas is my favourite tradition and we go all in.

When you’re away from the office, what brings you the most energy and joy?

I really value being able to structure my own productivity. I can work out during lunch without feeling like I need to rush home, and if something is better done at 7 pm, I can do that and still be productive at 8 am the next morning. Having the freedom to optimise my hours while maintaining strong internal connections with colleagues is incredibly energising.

Final Thoughts

And that brings our 2025 Meet the Team series to a close. A big shoutout to Camjar for sharing his energy and perspective, and to all the fantastic colleagues who took part this year. Their stories, passions and quirks are what make our team such a great place to be.We’ve got plenty more to share in the new year, so keep an eye out for fresh profiles, behind the scenes insights and more of the people who make Erlang Solutions what it is. And if you’d like to chat with our team or get involved, please get in touch.

The post Meet the Team: Camjar Djoweini 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 November 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

XMPP Summit 28 & FOSDEM 2026

The XSF is planning XMPP Summit 28, which will take place on Thursday 29th & Friday 30th, January 2026, in Brussels (Belgium, Europe). Following the Summit, the XSF is also planning to be present at FOSDEM 2026, which will take place during Saturday, January 31st & Sunday, February 1st, 2026. Find all the details in our Wiki. Please sign-up now if you are planning to attend, since this helps organizing. The event is of course open for everyone interested to participate. Spread the word within your circles!

XMPP Articles

• Europe’s Decentralized Messaging Survives “Chat Control” Threat by Mickaël Rémond for the ProcessOne Blog.
• Stop Telling Us XMPP Should Use JSON by Mickaël Rémond for the ProcessOne Blog.
• The difference between XMPP and ActivityPub, explained through the Blog feature for the Movim Blog. A detailed and accessible article that explains the differences between the XMPP network and the Fediverse and shows how blogs are handled on the XMPP network a bit more in details.

XMPP and ActivityPub: Two Different Approaches.

• Introducing Borogove, the new Snikket SDK by the Snikket Team for the Snikket blog.
• Best Python XMPP/Jabber Client Libraries: Your Experiences & Top Recommendations from PythonTutorials.net Blog.

XMPP Software News

XMPP Clients and Applications

• Dino has released version 0.5.1 of its modern open-source chat client for the desktop. It focuses on providing a clean and reliable Jabber/XMPP experience while having your privacy in mind.
• Gajim has released version 2.4.0 of its free and fully featured chat app for XMPP. This release brings read markers in group chats, improved file transfers, more details for your account, and many smaller changes and bug fixes. Thank you for all your contributions! You can take a look at the changelog for all the details.

Gajim: Your profile on the account page.

• Monal has released version 6.4.14 for iOS and macOS.
• Monocles has released version 2.0.17 of its chat client for Android. This update brings some fixes like more visible confirmation icons, update and add photo filter library, fix photo editor menu overlapping with status bar, setting to always use relays, and an improved extension deletion logic among many others. Make sure to take a look at the changelog for all the details!
• Movim has released version 0.32, code named ‘Wilk’, with version 0.32.1 immediately following it. This might be one of the biggest releases ever made on the project. It includes numerous fixes and new features in the 3 major topics Movim offers: instant messaging, social networking, and video conferencing. Head over the official release announcement and dive directly into the exciting things you can find in this release!

Movim: Share, like, and comment on articles more easily.

• Prose has released version 0.1.111 of prose-core-client, their core XMPP client manager and protocols. Full details on the changelog. The project also released version 0.13.1 and 0.14.0 of prose-app-web, their web application built in TypeScript / VueJS / WebAssembly.
• Psi+ 1.5.2128.0 installer has been released.

XMPP Servers

Snikket Server - November 2025 release: It’s time! We’ve been busy preparing a new release of the Snikket server software for you to enjoy. Although this release isn’t heavy on visible new features, a lot of internal changes and improvements have gone into this release to increase reliability and to pave the way for future plans.

XMPP Libraries & Tools

• python-nbxmpp, a Python library that provides a way for Python applications to use the XMPP network, version 6.4.0 has been released. Full details on the changelog.
• QXmpp, the cross-platform C++ XMPP client and server library, version 1.12.0 has been released. Full details on the changelog.
• slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.8 has been released.
• Smack, a modular, portable and easy to use XMPP client library for Android and Java, version 4.5.0 RC1 has been released. 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.
• xmpp.js, a JavaScript library for XMPP, version 0.14.0 has been released. This release brings faster and more reliable connection management thanks to complete implementation of Stream Management, SASL2, Bind 2 and FAST. Another important change is the removal of all third party dependencies. 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

• Version 0.1.0 of XEP-0507 (Jingle Content Category)
  • Accepted as Experimental by council vote (dg)

Deferred

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

• No XEPs deferred this month.

Updated

• Version 1.30.0 of XEP-0060 (Publish-Subscribe)
  • Describe the ‘http://jabber.org/protocol/pubsub' disco#info feature (gdk)
• Version 0.5 of XEP-0440 (SASL Channel-Binding Type)
  • Address a possible MITM attack vector by making the tls-server-end-point channel-binding mandatory to implement
  • Remove the whole ‘Interaction with SASL mechanisms’ section and replace it with ‘Business Rules’
  • Rework whole ‘Security Considerations’ section
  • Some minor editorial changes
  • Add Thilo Molitor as author (tm)
• Version 0.5.0 of XEP-0474 (SASL SCRAM Downgrade)
  • Add business rules describing client behavior
  • Make clear that PLAIN still has to be pinned away, if not disabled entirely (tm)
• Version 0.2.0 of XEP-0492 (Chat notification settings)
  • Rework the spec to use more of the Service Discovery Identities registry
  • Fix the XML schema
  • Move the <advanced/> element into the notification setting element
  • Bump the namespace (tm)

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

• Version 1.0.0 of XEP-0485 (PubSub Server Information)
  • Accept as Stable as per Council Vote from 2025-11-11 (XEP Editor(dg))

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

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

• Contributors:

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

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • 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

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

License

This newsletter is published under CC BY-SA license.

Erlang Solutions launched SAFE, a Security Audit for Erlang in the fall of 2023. We extended the analysis for Elixir in the spring of 2024 and now, SAFE officially supports Phoenix Liveview, which means a SAFE scan is now looking for vulnerabilities common in Phoenix web applications.

What is SAFE?

SAFE is a security scanning tool for Erlang, Elixir and Phoenix (LiveView) codebases. It works by loading and analysing your code, without running it. SAFE conducts an in-depth analysis of codebases, which can help you and your company to elevate your cybersecurity.

Supporting Phoenix LiveView

Now, as of the 1.3.0 release of SAFE, we support Phoenix LiveView, which means we can check for the following vulnerabilities:

• Cross Site Scripting (XSS)
• Cross Site Request Forgery (CSRF)
• Cross-Site WebSocket Hijacking (CSWSH)
• SQL Injection (with Ecto support)
• Denial of Services (DoS)
• Session leakage (unprotected session information)
• Session fixation (session ID renewal issues)
• Session hijacking
• Content Security Policy (CSP)

On-Prem report visualisation

With the release of the new SAFE version, a new SAFE product flavour was also launched, called SAFE OnPrem. This solution allows companies to host a centralised security report viewer that engineers and security specialists can access via the web interface.

Overview page of an example report:

User management:

Running SAFE

If you are interested in running SAFE on your code base, please check out our Quick Start Guide and contact the SAFE team. You can also drop us a message if you maintain an open source project, as you may be eligible for a free SAFE license. 

More information about Open Source licensing can be found in our announcement blog post.

The post SAFE for Elixir: Phoenix LiveView appeared first on Erlang Solutions.

The moment a fintech product shifts from prototype to production is often when the cracks appear. Tiny shortcuts. Half-formed assumptions. Decisions made because “we’ll fix it later.” They all return, and they return quickly.

At first, everything looks fine. The demo works. Early users onboard without trouble. In turn, confidence builds. Then real volume arrives with real expectations, and the product that once felt promising starts to resist growth.

The (Minimum Viable Product) MVP phase should have revealed the weak points. It should have been the place to break things safely. But often it becomes a race to launch without learning much at all. Speed gets mistaken for insight, and the cost shows up when the stakes are highest.

For teams serving SMEs, the risk is even greater.

The Scaling Problem: When “go fast” Stops Working

Fintechs focused on small businesses usually start strong. They prove demand, attract their first cohorts and show early traction.

Then comes the real hurdle: scale.

Small and medium-sized businesses don’t want flash. They want reliability, simplicity and absolute confidence that their money, payments, payroll and data won’t break at the wrong moment. According to The Payment Association, with 5.51 million SMEs representing 99% of UK businesses alone, that demand is huge.

Picture thousands of businesses depending on your platform every minute. If your stack can’t handle load variations, regulatory nuances across regions or the complexity of business onboarding, growth becomes dangerous. 

And the consequences aren’t theoretical. One industry review found that hidden infrastructure issues in fintech quietly drain 10–20% of capital and create terrifying downtime costs.

When an SME loses access to its financial tools, even for an hour, it can feel like a lost lifeline.

Scenario in action

Let’s imagine a fintech that nails product-market fit in one region. SMEs love it. Growth follows. Then expansion begins, and strain appears immediately.

The original build never accounted for multi-region onboarding, regulatory differences, load variation or different payment rails. The product did not fail. Success exposed everything the MVP never tested.

This often happens when early architecture is not prepared for real-world complexity. As usage expands, the gaps surface quickly.

Why MVP habits collapse at SME scale

In the rush to market, fintechs often use the MVP mindset (launch early, iterate fast). That works for consumer apps but is riskier for platforms serving SMEs, where downtime, data inconsistency and compliance are costly.

Research shows only around 43% of UK SMEs accessed external finance in Q2 2024, and just 44% of applications were successful. Given this tight margin of trust and reliability, the fintech solving SME problems must get the architecture right from early on.

SMEs often adopt fintech solutions fast: one study found that 65% of UK SME decision-makers believe they need the agility of fintech to enable their growth plans. The opportunity is there; what is less guaranteed is the product foundation. When the MVP is built purely for launch speed, the next stage of growth can expose fragilities.

Common challenges for SME-serving fintechs:

• Lack of monitoring for thousands of SME users rather than hundreds
  
• Compliance demands when onboarding business accounts vs consumer
  
• Manual operational workarounds that don’t scale
  
• Infrastructure built for single region, not multi-market
  

These issues rarely show up in a prototype. They surface the moment production load, regulation and real SME behaviour collide.

Building for production: What matters most

Turning a prototype into a platform that serves millions of SMEs requires architectural discipline. It starts with asking a simple question: what happens when this grows?

Technology choices matter. Systems built on concurrency, resilience and fault tolerance give fintechs room to scale without rebuilding from scratch.

Platforms using the BEAM virtual machine and languages like Elixir rely on lightweight processes and supervision strategies that keep systems stable under heavy load. Adopting these foundations early means your prototype does not have to be replaced. It evolves.

And SMEs feel that difference.

What this means for fintech SMEs (and their customers)

When a fintech platform is designed with SMEs in mind, the impact is felt inside the company and in the daily routines of customers.

Reduced downtime and more stability

SMEs cannot pause operations because a platform is struggling. Payroll, payments and transactions move continuously. Downtime is costly and trust disappears quickly. A system designed to scale helps avoid those fragile moments and reduces the need for constant emergency fixes.

Lower cost of change

When the architecture anticipates growth, teams spend less time rebuilding and more time improving the product. Smoother onboarding, integrated payments and better analytics become easier to deliver. Languages like Elixir support this quietly, allowing teams to make changes without breaking the foundations.

Simpler compliance and clearer audit-ability

Serving SMEs means navigating business account requirements, lending oversight and payment regulations. Systems built to production standards make compliance part of the design rather than a collection of manual steps.

Faster deployment and steady iteration

Fintechs must keep innovating without sacrificing stability. Lightweight processes and strong supervision make frequent, safe deployments possible. Stability and progress can coexist.

A better experience for SME customers

When the platform works reliably, teams can focus on problems that matter: cash-flow visibility, credit access, smoother invoicing and efficient banking. SMEs notice. 85 percent of UK SMEs would consider choosing a fintech over a traditional bank because the digital tools are stronger.

To conclude 

Fintechs serving SMEs rarely struggle because the idea is weak. They struggle when the technology behind that idea cannot keep up with real businesses. The prototype is only the starting point. Production is where reliability becomes a promise you must keep.

SMEs run on trust, cash flow and predictable systems. When a platform fails, it affects salaries and core operations.

This is why resilient foundations matter. Using a programming language like Elixir, built on BEAM’s concurrency and fault-tolerance strengths, helps teams create systems that stay steady even as demand rises. It gives product teams room to improve instead of constantly patching.

The SME opportunity is significant. The question is whether your platform has the strength to grow with it. If you’re a fintech and would like to build with resilience in mind, let’s talk. 

Turning fast- moving prototypes into stable, scalable solutions is far easier when you make the right choices early.

The post From Prototype to Production: Scaling Fintech for SMEs appeared first on Erlang Solutions.

Every year the members of the XSF get together to vote on the current quarter’s new and renewing members. Additionally, elections for both XMPP Council and Board of Directors have been held.

This year’s election meeting was held on November 20th, 2025 and the voting results can be found in the XSF Wiki.

The 2025/2026 term will be formed by the following members:

• XMPP Council:

  • Dan Caseley
  • Daniel Gultsch
  • Jérôme Poisson
  • Marvin Wißfeld
  • Stephen Paul Weber

• Board of Directors:

  • Arne-Bruen Vogelsang
  • Florian Schmaus
  • Guus der Kinderen
  • Mickaël Rémond
  • Ralph Meijer

Please congratulate them if you run across any of them, but also please help us make this another great year for the XSF.

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 XMPP Community is very excited to announce its presence at the coming FOSDEM 2026!

Once again, many members of the XMPP community will be attending, and will happily welcome you!

Realtime Lounge

The XMPP community invites you to the Realtime Lounge, where you can come and meet community members, project developers, see demos and ask all the questions.

This year you can find the lounge at the regular place on the K building’s 2nd floor.

Map of the K building level 2

For XMPP Community members and interested individuals: Please share any promotion materials, ideas, or planned activities for the Realtime Lounge, and your thoughts will help us prepare a welcoming space. Click here to contribute.

Decentralised Communication Devroom & Talks

Be invited to the technical talks around decentralised communication. There will also be talks on various messaging and Real-time communication (RTC) projects such as ActivityPub, ATProto, Automerge, DeltaChat, Matrix and of course XMPP in the Decentralised Communication developer room.

To become a speaker please submit your talk through the FOSDEM’s conference management system. You can read more here: Call for Participation to the FOSDEM 2026 Decentralised Communications Devroom. Submission deadline is 30th November 2025. Attendees, speakers, and volunteers are expected to follow the FOSDEM Code of Conduct at all times.

Info & Dates

XMPP Summit 28 prio to FOSDEM 2026

Prior to FOSDEM, the XSF will also traditionally hold its 28th XMPP summit. This is where community members gather to discuss protocol changes and the XMPP roadmap. Everyone is welcome to join, just kindly list yourself free of cost as there is only limited space. Check the official online presence and communication, too (see the media links in the footer).

Looking forward to see you there!

Spread the word 📢

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

Signal Protocol and Post-Quantum Ratchets

We are excited to announce a significant advancement in the security of the Signal Protocol: the introduction of the Sparse Post Quantum Ratchet (SPQR). This new ratchet enhances the Signal Protocol’s resilience against future quantum computing threats while maintaining our existing security guar…

Signal Messenger

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

Signal (formerly Open Whisper Systems) created the Double Ratchet algorithm 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, first drafted 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?

It’s time! We’ve been busy preparing a new release of the Snikket server software for you to enjoy. Although this release isn’t heavy on visible new features, a lot of internal changes and improvements have gone into this release to increase reliability and to pave the way for future plans.

Notable changes

Changes to limited user accounts

Snikket allows you to configure chosen accounts as “limited”. These limited accounts can only communicate with other people on the same instance of Snikket. They are commonly used for children, guests, and similar purposes.

Until this version, it was documented that limited accounts prevented outbound messages, but inbound messages (if someone knows the address) were still accepted. While this provided a certain level of protection, inbound messages will now also be blocked. This ensures that even if a limited user’s address becomes somehow known, it will still be impossible to send them messages.

We believe that the new behaviour aligns with what the vast majority of people expect and want from the limited accounts feature.

Docker health checks

Some of our containers provided health checks. In practice these were noisy, causing excessive log entries. They checked various things, but were never a full guarantee that Snikket is working successfully.

These built-in health checks have been removed from this release. We recommend external monitoring if you want to make sure your Snikket instance is up and running. The docker health checks were never able to fully provide this.

Compatibility with SDK-based apps

We have been working on an SDK which makes it easier to develop cross-platform apps for Snikket and other modern XMPP services. You can read the latest SDK news in this blog post.

The first new apps using the SDK will be a dedicated Snikket web app (so you will finally be able to chat using your Snikket account in a web browser) and we are also working towards a future update to our iOS app based on the SDK.

This Snikket server release adds certain protocol features, such as upgraded push notification APIs, which are used by the SDK-based apps. This makes it easier for developers and early adopters to test the new apps and iron out any issues before they reach general availability.

Upgrading

Upgrading an existing installation is super simple and takes less than a minute! You can find instructions in the ‘Upgrading’ section of the release notes.

If you have any questions or feedback about the new release, come and join the discussion in our community chat.

We hope you enjoy Snikket. Happy chatting!

Some time ago, we teased you with our plans for a cross-platform “Snikket SDK” (Software Development Kit) which would be used to build a new generation of Snikket apps. Particularly a much-requested web app for Snikket, so folks can chat directly in the web browser without installing anything. We also intend to replace our current iOS app with an SDK-based app when that becomes feasible.

The SDK is not aimed directly at Snikket users (but if you have development skills, why not?!). It is primarily for the people developing Snikket apps, though it will bring with it many benefits for the project and its users.

Why an SDK?

We currently have two official apps, for Android and iOS. Both of these are entirely separate codebases, which means that, while we have tried to align them as much as we can, there are still significant disparities between the two platforms, in terms of features, bugs and the general user experience. Snikket has consistency as one of its main goals, so this is something we consider important to improve.

On top of this situation, people frequently request the ability to chat using their Snikket account via their web browser. However, this would add a third codebase for us to maintain, and the existing problems would be amplified. And we haven’t even talked about a desktop app yet!

It’s not sustainable to maintain so many completely independent apps of the quality and consistency the project is aiming for. With currently only one person working full-time directly on Snikket, simplification would be especially beneficial.

Developer experience

One of the reasons that Snikket only has one developer is that it’s hard to find developers! The majority of developers we have worked with are familiar with front-end work, and often have experience with integrating with basic HTTP APIs. But it’s much harder to find generalists who are also willing to work with other technologies that Snikket uses, such as XMPP. Similarly, it’s rare to find developers interested in chat protocols who are also front-end user interface developers.

While it’s undoubtedly not hard to build an XMPP-based chat app in a weekend, building a comprehensive modern chat app using any protocol and any language with all the modern features, security, and reliability that people expect is understandably a daunting task.

With the SDK, we aim to “divide and conquer” - enclose all the protocol parts in the SDK, and leave the least amount of complexity possible so that front-end developers can do their thing with the UI without unnecessary friction.

XMPP libraries are already available for most platforms to perform a lot of the work for developers. However, they generally still assume and require a level of familiarity with XMPP, and require the developer to make certain higher-level architectural decisions when building an app. This includes things like message synchronization strategies, processing push notifications, audio/video calls, and so on.

Our SDK is not yet another XMPP library. In fact, it actually uses existing XMPP libraries itself. What the SDK provides is the middle “glue” layer between the user interface and the messaging protocol layer. The SDK itself hides every detail of XMPP from the app developer.

While most XMPP libraries try to remain flexible, to allow developers to build and design their apps however they want, the goal of our SDK is to make all the choices for them. Provide just one obvious way to do things - the Snikket way.

This works for us precisely because of Snikket’s goal for one consistent user experience across all platforms. It wouldn’t necessarily be a good idea to use the SDK to build an IoT app, or any of the other use cases XMPP can be applied to (though this hasn’t stopped people building cool things with the SDK already!).

Developer efficiency

While we knew that writing this SDK from scratch would be a significant effort, much of it is effort that we would have had to spend anyway on writing a new Snikket app for, say, the web. All we had to do was make sure that the work we did for that app could be re-used across multiple platforms.

For this we adopted a relatively niche but well-established language called Haxe.

Fairly well-known in certain domains, such as multi-platform mobile game development, Haxe is a neat little language with built-in capabilities for cross-compiling to multiple output languages. This means that we can write our SDK code once in Haxe, and then compile it to Javascript for the web, but also to native libraries for practically any platform. In line with our goals to build a web app and iOS app for Snikket, we currently build JS and Swift versions of the SDK.

Now, when adding a new feature, the bulk of our work will be in the SDK, followed by the supporting UI code for each of our apps (which can be undertaken by anyone familiar with those platforms - no special XMPP expertise needed).

Current status

The SDK project already covers most important features, from messaging to audio/video calls. Although we aren’t ready to announce any new Snikket apps yet, we’re getting closer with every commit. There are several projects already based on the SDK:

• Cheogram WWW alpha
• Cheogram iOS alpha
• Cheogram CLI dialer
• Honeybee

The Cheogram apps were developed by singpolyma who has also been the driving force behind getting the SDK towards stability and feature completion.

There are a few things we’re still working on in the SDK. The big one for Snikket is OMEMO. We have 1-to-1 just working (not yet included in any of the above apps). OMEMO in group chats is next, and top of the priority list.

Finally, in recognition that the SDK is already growing beyond powering just Snikket apps, we have spun it off as a semi-independent project with its own website and project name - Borogove SDK!

Next steps

Once the SDK has feature parity with the current apps, we’ll be working on the user interface, starting with the web app. Keep an eye out for preview builds of Snikket apps in the new year!

If you’re a developer and any of this sounds like stuff you would be keen to help out with, get in touch!

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of October 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 voluntary work of its members and contributors. If you are happy with the services and software you may be using, please consider saying thanks or help these projects!

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

XSF Announcements

XMPP and Dutch Healthcare Chat

Healthcare messaging must be secure, interoperable, and compliant, yet too often relies on closed consumer platforms. In the Netherlands, the forthcoming NTA 7532 specification aims to provide a national framework for secure, auditable communication between healthcare professionals.

To this effect, the XMPP Standards Foundation published the ‘Towards Secure and Interoperable Healthcare Chat’ open letter, in order to explain how the XMPP standard offers a proven foundation for NTA 7532, supporting vendor-independent and interoperable messaging. By engaging with initiatives like NTA 7532, the XSF promotes open, privacy-respecting communication technologies and invites collaboration with Dutch healthcare stakeholders and the global XMPP community.

XSF Membership

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

Events

The 28th XMPP Summit has been announced. It will be held Thursday 29th - Friday 30th January 2026 in Brussels, Belgium. These are the two days preceding FOSDEM.

XMPP at Hack or Di(y|e) 2025

Vril will host the XMPP - Iniziamo ad usare sistemi compagni di chat (se chattiamo talk and workshop at the Hack or Di(y|e) 2025 in Bologna, Italy, on this next November 7th and 8th, 2025.

The talk will be as accessible as possible in terms of vocabulary. Aiming to give an overview of the XMPP protocol and what are the methodologies to start using it immediately through applications installed on your smartphone or PC. Immediately after the talk, the workshop will move to a corner of the VAG61 to help each other install applications and create accounts on companion servers to immediately start chatting via XMPP and 1000 different accounts! + chaos!!. P.S. if you already want to get informed, here is a nice guide: XMPP Guide. [IT]

• Date: November 7th and 8th, 2025.
• Location: Via Paolo Fabbri 110, rione Cirenaica, Bologna, Italy.

Videos and Talks

• Selfhosting I2P XMPP Server by RightToPrivacy & Tech Tips.
• Messaging mit XMPP - Wie finde ich den passenden Anbieter? by eversten.net for XMPP Tutorials DE. [DE]
• Quale sistema alternativo per il vostro cellulare? by Nicolas Vial for the XMPP related workshop at the Linux Day Torino 2025. [IT]

XMPP Articles

• The XMPP Standards Foundation has put out a call to action: it’s time for the community to help make secure, interoperable chat a reality - especially in healthcare. 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. Let’s Build a Connected Dutch Healthcare Community! [NL]
• XMPP Interop Testing: Putting NTA 7532 to the Test (literally): 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. By Dan Caseley for the XMPP Interop Testing Blog.
• Europe’s Digital Sovereignty Paradox - “Chat Control” update: Can you build tech independence while breaking encryption? by Mickaël Rémond for the ProcessOne Blog.
• NLnet: 29 Free and Open Source Projects Receive Grants to Build Digital Commons. One project brings the latest OMEMO support for Converse.js with libomemo.js: This project will finalise support for the latest version of the OMEMO protocol in Converse.js, bringing both state-of-the-art security based on the Noise protocol in private messaging, as well as standards-based interoperability between several messaging applications and services.
• More Adoption of XMPP Providers in the XMPP Ecosystem & XMPP Providers Server Update by the XMPP Providers Team for the XMPP Providers blog. The Overview page received new functions. Now you can see all the available information across the operators in a tabular view. Thanks to the work of the XMPP Providers Team, you can search each column for specific information. If you are actively looking for custom properties, easily start breaking down the table to your needs!
• Un nuovo server di chat per la libertà di comunicare: la nostra risposta a ChatControl by Fabio Lovato for ILS Este. [IT]
• End-to-End Encrypted Chat that YOU Control: Hosting XMPP (Jabber) with Prosody by starkzarn for the RogueSecurity blog.
• New home for the slidge room(s!), from the Slidge.im blog.
• Libervia CLI tips: Goffi keeps adding them and the list keeps growing with more and more CLI tips to make it easier for you to use and do nearly everything you need with Libervia from the comfort of your terminal!

XMPP Software News

XMPP Clients and Applications

• Monocles has released version 2.0.16 of its chat client for Android. This update comes loaded with features and improvements; way too many to list in here! Make sure to take a look at the changelog for all the details!
• Prose has released versions 0.13.0 of its web frontend prose-app-web and muliple versions of its prose-core-client: 0.1.107, 0.1.108, 0.1.109 and 0.1.110. You can read all the details on their changelog.

XMPP Servers

• ProcessOne is pleased to announce the release of ejabberd 25.10 only two months after the previous one. This release brings updated support for XEP-0317 Hats, adds more Ad-Hoc Commands from XEP-0133, and includes several bugfixes and many improvements for administrators and developers! 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.18 has been released.
• go-sendxmpp, a tool to send messages to an XMPP contact or MUC inspired by sendxmpp, version 0.15.1 has been released. Full details on the changelog.
• QXmpp, the cross-platform C++ XMPP client and server library, version 1.11.3 has been released. Full the details on the changelog.
• Slidge versions 0.3.2 and 0.3.3 have been released with many improvements and bugfixes. You can check the intermediate changelog from 0.3.1 to 0.3.3 for the full list of changes.
  • slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6 and 0.3.7 have been released.
  • matteridge, the Mattermost to XMPP gateway based on Slidge and the mattermost-api-reference-client, version 0.3.1 has been released.
• Slixmpp version 1.12.0 has been released. You can read the official release announcement for all the details.
• talk_xmpp_bridge, a new bridge between Nextcloud Talk and the XMPP protocol, is now available for download.
• xmpp-dns, a CLI tool to check XMPP SRV records, version 0.5.4 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-reply JIDs
  • This specification defines a way for JIDs to advertise that they don’t accept incoming chat messages.
• Forums
  • This specification describes how to implement XMPP-based discussion forums.
• Jingle Content Category
  • This specification defines an XMPP extension to negotiate the use of Session Description Protocol (SDP) media- level attribute content as defined by RFC 4796 with Jingle RTP sessions.

New

• Version 0.1.0 of XEP-0506 (No-reply JIDs) has been released.
  • Accepted as Experimental by council vote (dg)

Deferred

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

• No XEPs deferred this month.

Updated

• Version 1.35.2 of XEP-0045 (Multi-User Chat)
  • Fix inconsistency in roomconfig_roomsecret data form field definition. (gk)
• Version 1.28.0 of XEP-0060 (Publish-Subscribe)
  • (gdk)
• Version 1.0.2 of XEP-0070 (Verifying HTTP Requests via XMPP)
  • See in-document revision history
• Version 0.5.0 of XEP-0248 (PubSub Collection Nodes)
  • Enhance ‘Discover Nodes’ section with hierarchy / Collection Nodes description and examples
  • Move the Service Discovery Identity type collection from XEP-0060 to XEP-0248
  • Move collection-specific Service Discovery Features from XEP-0060 to XEP-0248
  • Move process for changing node of type leaf to collection from XEP-0060 to XEP-0248
  • Move requirement to support pubsub#notify_config for collection nodes from XEP-0060 to XEP-0248 (gdk)
• Version 1.0.1 of XEP-0392 (Consistent Color Generation)
  • Add missing saturation and lightness information to compute the test vectors. (egp)
• Version 0.2.0 of XEP-0471 (Calendar Events)
  • Modified title for “Calendar Events”. Updated short-name and namespaces accordingly. (jp)
• Version 0.2.1 of XEP-0472 (Pubsub Social Feed)
  • Clarify text in Reply-To section to show that the XMPP link is mandatory and that the HTTP link is optional. (jp)
• Version 0.1.1 of XEP-0505 (Data Forms File Input Element)
  • Replaced XEP-0446 (File metadata element) with XEP-0447 (Stateless file sharing), which is necessary to have file sources.
  • Fixed the incorrectly‑named <file> element (now <file-input>).
  • Add tags.
  • Various minor fixes. (jp)

Last Call

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

• Last Call for comments on XEP-0424 (Message Retraction)
  • This Last Call begins on 2025-10-14 and shall end at the close of business on 2025-10-28.
• Last Call for comments on XEP-0440 (SASL Channel-Binding Type Capability)
  • This Last Call begins on 2025-10-14 and shall end at the close of business on 2025-10-28.
• Last Call for comments on XEP-0485 (PubSub Server Information)
  • This Last Call begins on 2025-10-20 and shall end at the close of business on 2025-11-03.

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 lookout 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 by 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

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

• Contributors:

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

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • 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.

The XMPP Standards Foundation (XSF) is exited to announce the 28th XMPP Summit taking place in Brussels, Belgium next year - just before FOSDEM 2026. The XSF invites everyone interested in development of the XMPP protocol to attend, and discuss all things XMPP - both in person and remotely!

The XMPP Summit

The XMPP Summit is a two-day event for the people who write and implement XMPP extensions (XEPs). The event is not a typical conference - aside from small and short lightning talks, there are no long presentations.

Who participates at the Summit?

The participants, where everyone is welcome, are sitting at a round table to discuss and active participation is encouraged. Similar to an unconference at the beginning all participants can suggest topics and others can indicate via votes whether or not they are interested in that topic.

Afterwards a rough order of topics is established that will be followed in moderation with the participants.

How does the Summit work?

If you have ever followed a thread on the standards mailing list or taken part in a discussion on the public XSF channel you should be familiar with this - just in person. The different topics are broken up by short breaks that are great for networking and getting to know other XMPP developers. Still, if you cannot participate, we will also provide an online way of joining the discussion.

Agreeing on a common strategy or even establishing a rough priority for certain features in our decentral and interoperable technology and protocol can be hard. In-person events do a lot in getting us on the same page and as an XMPP developer (e.g. client, server, gateway) we strongly encourage you to come to the summit. (In short: To get the most out of the summit you should have a background in reading (and maybe even writing) XEPs).

If you are simply an enthusiastic user or admin we regularly have booths at various conferences (FOSDEM, CLT, FrOSCon, …) that are a great opportunity to meet us, too. Either way, everyone is welcome to participate!

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

Info, Time & Address

The event will take place at the Huis van het Nederlands Brussel. There will be a coffee break (from 09:00 o’clock) and lunch (13:00 to 14:00 o’clock). Coffee, tea and water will be served.

Date: Thursday 29th - Friday 30th, January 2026
Time: 09:00 - 17:00 o’clock (CET) (both days)
Venue: Huis van het Nederlands Brussel
Address: Philippe de Champagnestraat 23, 1000 Brussels
Cost: Free (registration required)
Capacity: 25 participants
Hybrid participation: Yes
Map: Openstreetmap

Furthermore, the XSF will have its Summit Dinner on Thursday night, which is paid for all participating XSF members. Non-members are warmly invited to join, however at their own expense.

Participation

We are limited to 25 places, so please register by Wednesday, 14th January 2026!

Please note that, although we welcome everyone to join (free of cost), you must announce your attendance beforehand. If you’re interested in attending, please make yourself known by filling out your details on the wiki page for Summit 28. To edit the page, reach out to an XSF member to enter and update your details or you’ll need a wiki account, which we’ll happily provide for you. Contact us using the communication channels listed below. If you sign-up, don’t forget accomodation and your travel bookings. If your plans change, please remove your name from the list.

Please also consider signing up if you plan to:

• present in the Lightning talks or Show-and-Tell
• participate remotely

Communication

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

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

Sponsors

The XSF would like to express its sincere gratitude to its general sponsors and acknowledges that their sponsoring allows us to keep events like this an annunal highlight. We also appreciate support via direct sponsoring of the event or even XSF sponsorship, so that we can keep the event open and accessible for everyone. If you are interested, please contact the XSF Board.

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

The XMPP Standards Foundation Board

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.

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:

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.

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.