As the year draws to a close and the holiday season surrounds us with warmth and joy, I wanted to take a moment to look back at what an incredible journey 2025 has been for the Ignite Realtime community.
This year we’ve seen so much activity, innovation, and collective effort across our projects and forums. From major releases to exciting technical explorations, the contributions from developers, documenters, testers, and users have reminded me (time and again) what makes this community special.

Looking back through the year’s blog posts and discussions, a few moments stand out:

• Openfire 5.x Series: We welcomed multiple releases within the 5.0 line. From the early beta builds to the full releases of Openfire 5.0.0 and 5.0.1, to the stability-focused 5.0.2 and most recently 5.0.3. These milestones are the result of countless hours of debugging, testing, and refinement.
• New Features & Plugins: Several new features and plugins made their way into our ecosystem, like the Push Server plugin and advancements in XEP-0483 for HTTP Online Meetings, expanding what’s possible with our projects.
• Smack Community Progress: The continued evolution of Smack was marked by the 4.5.0 Release Candidate, giving developers an even stronger foundation for building XMPP clients.
• Broadening Perspectives: Insightful posts on interoperability, WebRTC audio/video integration, and real-world use cases highlighted the vibrant technical discourse happening here.
• Community Recognition: It was also wonderful to celebrate achievements beyond our own projects - like members being elected to roles within the broader XMPP Standards Foundation.

All these efforts show not just code being written, but ideas shared, challenges overcome, and friendships formed along the way. What’s especially meaningful to me isn’t just the software we build, but how we build it: together. Whether it’s through lively technical threads, helping a newcomer in chat, or sharing a blog post that unpacks a tricky feature, this community genuinely embodies open collaboration.

The forums, blogs, and group chats are more than repositories of knowledge - they’re where we connect, learn from one another, and celebrate each success together.

So, as we step into the holidays and prepare for the new year, I want to express my deepest gratitude:

Thank you to every contributor, big or small, for your time, passion, and patience.

Thank you to those who reported bugs, wrote documentation, asked questions, or helped others find answers.

And thank you to every user who deploys, experiments with, or builds on Ignite Realtime software: you give our work purpose.

Here’s to 2026! May the coming year bring even more collaboration, innovation, and joy. Whether you’re building a new feature, solving a tricky XMPP problem, or just dropping into the group chat to say hello. We’ll be glad to see you there!

Wishing you all a happy holiday season and a wonderful New Year!

3 posts - 3 participants

Read full topic

Hello again! We’re rounding off the year with another small release of the Snikket server software. The main purpose of this release is to fix a couple of small bugs which were discovered and reported after the previous release was announced.

Notable changes

Offline message compatibility

It was reported that Conversations 2.19.2 and later did not reliably receive offline messages after being offline for an extended period of time. This also affected the upcoming Snikket Android release (which is based on Conversations). This issue has been fixed in this server release.

Web portal debug information

The per-user debug information became inaccessible in the previous release due to a minor bug that slipped in during refactoring. It should now work.

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!

In this new series, I want to shine some light onto specific parts of Monal’s internals. It’s dedicated to programmers or people curious about how Monal works internally. If you want to give some feedback, feel free to send an email to thilo@monal-im.org

Other articles in this series:

• Monal Internals - Handlers framework
• Monal Internals - XML Query Language

Serializable Promise Framework

XMPP as a protocol is, as most protocols are, inherently asynchronous. In Monal we therefore use the popular PromiseKit library to let the UI know when a XMPP action finished or failed.

But this has a huge drawback: PromiseKit-based promises aren’t serializable, so we can’t respond to events that got handled by the Notification Service App Extension while the app was suspended. The serializable promise framework is a new framework in Monal, which exactly fills that gap.

Overall Process

For instance, imagine you want to remove the avatar of a group chat in Monal, while on a slow, unreliable network.

1. You submit the request, and the loading screen appears over the view (0:03)
2. Because the network is slow, the loading screen persists for a long time
3. You get frustrated and switch apps, sending Monal to the background (0:06)
4. After 30s in the background, Monal gets suspended (0:36)
5. The server fails to remove the avatar and sends an error to Monal
6. The response is handled by Monal’s app extension in the background (0:51)
7. You switch apps back to Monal (0:57)

Without the promise framework, the app would have continued to show the loading screen indefinitely, requiring you to fully close and open the app.

However, with the promise framework, when you switch back to the app, the loading screen disappears and correctly shows the error returned by the server:

The promise framework allows any such interaction, where the UI has to update in response from the server, to be handled in a general way.

Background

We will briefly describe the important parts below. But these links provide more detailed context and are recommended reading:

• The app decomposition slides explain the split between the main app and app extension.
• The handler framework blog post explores some of the consequences of this split.

Main app and app extension

In Monal there are two separate processes: the “main app” (MonalAppDelegate) and “app extension” (NotificationService), which is sometimes abbreviated to “appex”.

Since they do not share memory, they hand over to each other via the handler framework.

An xmpp stanza can be processed by either, depending on whether the app is running or not:

App states

Below is a slightly simplified diagram of the app’s lifecycle. A more detailed lifecycle from Apple’s perspective is available here.

• The app moves from “active” to “in background” when it is swiped away without being closed
  • It continues to run and process stanzas for ~30s in the background
• Once the 30s are complete, it moves to “suspended”
  • Apple saves the UI’s state
  • When the app is reopened, it returns to the same screen as before
  • Any stanzas that were processed in the meantime were processed by the appex

Appex states

Meanwhile, the appex has a more simple lifecycle - it is either running, or not running:

• Once the appex starts, it will connect to the server and run for 30s
• If the app is opened while the appex is running, the appex will return to “not running” state in deference to the app.

Serializable promise framework

Ok, now the background is out of the way, time to explain the promise framework!

While promises are very useful in SwiftUI, there is one problem: they only exist in that particular process, and cannot easily be passed between the app and appex.

This means that, if the promise was resolved in the appex, once the app is reopened (moves from suspended to active), it will not be consumed. This is because the appex has no way of tying the result back to the promise that updates the UI.

Since the handler framework is what allows the seamless handoff between the app and appex, we need a way to trigger consumption of a promise as a result of processing in the handler. This is precisely what the promise framework does!

High-level overview

We create a “serializable promise” class called MLPromise. This class stores a “UI promise” which is an AnyPromise from PromiseKit. Consumption of this AnyPromise is what ultimately causes the UI to update.

Whenever we want to bind a UI action to the result of a handler, we create an MLPromise and pass it as an argument to the handler. We then return the MLPromise’s AnyPromise to the UI.

Unlike the AnyPromise it contains, the MLPromise is (mostly) serializable. When the MLPromise is created, and whenever it is resolved, it persists itself to a new promises table in the database.

Meanwhile, whenever the app or appex is unfrozen, and the promise table is read into memory, the resolved arguments of any already existing promises are overwritten.

Note that this persisted version of the MLPromise is not complete - while the resolved argument can be persisted, the UI promise is not persisted at any stage.

This means that, while the resolved argument can be passed betwen the app and appex, the UI promise itself cannot. The consequence of this is that a promise cannot be consumed in the appex - it can only be resolved there, leaving consumption for when the app becomes active again:

This makes some sense, as the whole purpose of the AnyPromise is to update the UI as a result of some backend action. It only makes sense to update the UI from the process which manages the UI - the app itself.

As a result, whenever the app becomes active again, all outstanding MLPromises check the version retrieved from the DB if they have been resolved in the meantime, and if so, consume themselves. This is how the loading overlay gets removed in the above example.

Step-by-step overview

Let’s return to the initial scenario of removing the avatar of a group chat. The user chooses the new avatar and presses submit. Then, the following happens:

(1) UI code calls backend

The UI code responding to requests to remove the avatar calls the backend method to do this.

Once the backend function completes, it will return an AnyPromise, allowing the UI code to continue immediately:

showPromisingLoadingOverlay(overlay, headlineView:Text("Removing avatar..."), descriptionView:Text("carview.php?tsp=")) {
    // this returns an AnyPromise used by the loading overly to hide itself once it gets resolved
    self.account.mucProcessor.publishAvatar(nil, forMuc: contact.contactJid)
}

(2) Core code creates promise

The core code creates an MLPromise:

-(AnyPromise*) publishAvatar:(UIImage* _Nullable) image forMuc:(NSString*) room
{
    MLPromise* promise = [MLPromise new];
    // ...

(3) Core code creates handler and (4) sends IQ

The core code creates a new handler, and passes the MLPromise to it as an argument. Recall that handlers serialize their arguments - this means that, even if the app is suspended and the handler is called in the appex, the MLPromise will be available.

[_account sendIq:vcard withHandler:$newHandlerWithInvalidation(self, handleAvatarPublishResult, handleAvatarPublishResultInvalidation, $ID(room), $ID(promise))];

(5) Promise returned to UI

Internally, the MLPromise has created an AnyPromise. This is a type provided by PromiseKit that can be returned directly to the UI, and that the SwiftUI code understands. It gets returned to the UI code.

return [promise toAnyPromise];

(6) XMPP server provides response

This happens on the server side and is not relevant to Monal.

However, while waiting for the response, the user puts the app into the background, and the app gets suspended.

(7) Handler resolves promise

Now, the response from the server activates the appex, since the app was suspended.

The handler is called with the response from the server. It resolves the promise (via either reject or fulfill) - passing that response to the promise.

$$instance_handler(handleAvatarPublishResult, account.mucProcessor, $$ID(xmpp*, account), $$ID(XMPPIQ*, iqNode), $$ID(MLPromise*, promise))
    if([iqNode check:@"/<type=error>"])
    {
        // ...
        [promise reject:error];
        // ...
    }
    // ...
    [promise fulfill:nil];
$$

(8) Promise waits until app is open

If the promise had been resolved from the app, it could have been consumed immediately. However, since it was resolved from the appex, the AnyPromise was not available to call at that time.

Therefore, the promise does not consume itself yet - it instead waits for the app to return to active state.

This waiting is performed by the following observer - whenever either the app or appex is unfrozen, the deserialize method is called:

-(instancetype) init
{
    // ...
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(deserialize) name:kMonalUnfrozen object:nil];
    // ...
}

deserialize calls attemptConsume on each run. attemptConsume checks if we are inside the appex (in which case we do not consume the promise), and only if we are inside the app does it consume the promise:

-(void) attemptConsume
{
    DDLogDebug(@"Intend to consume promise %@ with uuid %@ and argument %@", self, self.uuid, self.resolvedArgument);

    if([HelperTools isAppExtension])
    {
        DDLogDebug(@"Not consuming promise %@ with uuid %@ as we are in the app extension", self, self.uuid);
        return;
    }

    // ...
}

Note that both reject and fulfill also call attemptConsume after resolving the promise. This would let the promise be consumed immediately if we are inside the app instead of the appex.

(9) Promise consumes UI promise

Once we progress past the checks in attemptConsume, we finally consume the promise by calling the resolve callback tied to the PromiseKit AnyPromise returned earlier. This in turn prompts the UI to hide the loading overlay.

-(void) attemptConsume
{
    // ...
    PMKResolver resolve = _resolvers[self.uuid];
    // ...
    resolve(self.resolvedArgument);
    // ...
}

The XMPP assembly for the Chaos Communication Congress 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 (previously Leipzig and 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.

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

Sparkly XMPP stickers

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. You can join the XMPP chatroom (web) as well as support organisation via the related XMPP Wiki page. Regarding the article contact mathieui if you have remarks or suggestions concers.

Link to Original blogpost

The IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.3 brings a number of stability improvements and bug fixes. Notably, a number of improvements were made to Multi-User Chatroom (MUC). Please refer to the full changelog for more details.

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

a08493cb19bef6dd2b51ebe88d4ffd121553e2e4473ddbecf94f5ff350e367aa  openfire-5.0.3-1.noarch.rpm
3dd1e9de84d6b177f3b890bea7d6cd88359698bd82c2e656d4b937a8ef7af96e  openfire_5.0.3_all.deb
b3674baa3ab53a1f61db8846c3cdd16ce211917c4df3cee2d4a46fbba265ea76  openfire_5_0_3.dmg
cfabc92ab9e473e71f42ec40533a5d4ae7a9c1dc5ebd060784ce434ae1ba6c12  openfire_5_0_3.exe
fb13bd4e0aff7bd6cc16d78e6f2c35d8b59a95e4f4f886d353265306f151ec45  openfire_5_0_3.tar.gz
dcad510a8a7fda677b07281d08ebb29017555944eeb41c98fb4f38c743a341c4  openfire_5_0_3_x64.exe
0ee9a0837e75b785a40653f78b94a900431067f8a9d2bac5104d2971c46a9779  openfire_5_0_3.zip

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

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

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

1 post - 1 participant

Read full topic

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 ‘https://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