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!

1 post - 1 participant

Read full topic

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.

Whelan's / Baghad Gus / Congress Reel by Wild Asparagus, DJ mix

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.

Bus Stop! / Rec Hall by The Free Raisins and Kingfisher, DJ mix

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

Flying Ice Cream / The Randomanians by Giant Robot Dance and The Great Bear Trio, DJ mix

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.

Racoon / Disco Snails by Wake Up Robin and Vulfmon and Zachary Barker, DJ mix

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.

Rainy Night / Tween Spirit / Smells Like Teen Spirit by The Dam Beavers, Giant Robot Dance, and Nirvana, DJ mix

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!

Heather's Concussion by The Great Bear Trio, DJ mix

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.

Apple Blossom by Great Bear, DJ mix

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 .

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 .

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

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

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

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

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

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

The Performance Myth

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

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

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

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

XML brings three key advantages:

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

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

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

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

Where the Real Complexity Lives

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

Consider XMPP when these factors matter to you:

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

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

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

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

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

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

Smack 4.5.0-rc1 is now available on Maven Central .

1 post - 1 participant

Read full topic