​​We are living in an economy that rarely sleeps. Payments clear late at night. Payroll runs in the background. Businesses expect every digital touchpoint to work when they need it.

Most people do not think about this shift. They assume the systems behind it will hold.

That assumption carries weight.

Fintechs, including small and mid-sized ones, now sit inside the basic infrastructure of how money moves. Their uptime affects cash flow. Their stability affects trust. When something breaks, real businesses feel it immediately.

Expectations changed faster than most systems did.This follows on from our earlier piece, From Prototype to Production, which explored how early technical shortcuts surface as systems scale. Here, we look at what happens next, when those systems become part of the infrastructure businesses rely on every day.

When “tech downtime” becomes infrastructure failure

Outages no longer feel contained. A single failure can affect services that millions of people and businesses depend on.

Large providers experience this as much as small ones. When a shared platform falters, the impact spreads quickly. More than 60 percent of outages now come from third-party providers rather than internal systems, highlighting how tightly connected the ecosystem has become.

The true cost is trust

For fintechs, the impact is immediate because money is involved.

A payment delay blocks cash flow. A failed identity check stops onboarding. A stalled platform damages credibility.

For an SME, this can play out over the course of a single day. Payroll does not process in the morning. Supplier payments stall in the afternoon. Customer support queues fill up while teams wait for systems to recover. Even short interruptions create knock-on effects that last far longer than the outage itself.

And the numbers reflect that risk:

• £25,000 is the average cost of downtime for SMEs.
• 40% of customers consider switching providers after a single outage.
• Fintech revenue losses account for approximately US$37 million of downtime-related costs each year.
  

At this level of dependency, downtime stops being a technical issue. It becomes an infrastructure failure.

Fintechs have become infrastructure whether they intended to or not

Fintech services have moved beyond convenience. They now underpin everyday economic activity for businesses that depend on constant access to money, credit, and financial data.

This shift shows up in uptime expectations. Platforms that handle financial activity are measured against standards once reserved for mission-critical systems. Even brief disruption can have outsized consequences when services are expected to remain available throughout the day..

Customers do not adjust expectations based on company size or stage. If money flows through a service, users expect it to be available around the clock. When it is not, the failure feels systemic rather than technical. What breaks is not just functionality, but confidence.

That is the environment fintech leaders are operating in now.

Where resilience typically breaks down

Most fintech systems do not fail because the idea was weak. They fail because early decisions prioritised speed over durability.

Teams optimise for launch. They prove demand. They ship quickly. That works early on, but systems designed for experimentation often struggle once demand becomes constant rather than occasional.

Shortcuts that felt harmless early on start to surface under pressure. Shared components become bottlenecks. Manual processes turn into operational risk. Integrations that worked at low volume become fragile at scale. Recent analysis shows average API uptime has fallen year over year, adding more than 18 hours of downtime annually for systems dependent on third-party APIs.
 

Common pressure points include:

• Shared components that act as single points of failure
  
• Manual operational work that cannot keep up with growth
  
• Third-party dependencies with limited visibility or control
  
• Architecture built for bursts of usage instead of continuous demand
  

These are not accidental outcomes. They are the result of trade-offs made under pressure. Funding milestones, launch timelines, and growth targets shape architecture as much as technical skill does.

When outages happen, they rarely trace back to a single bug. They trace back to earlier choices about what mattered and what could wait.

From product thinking to infrastructure grade systems

Product thinking is about features and speed. Infrastructure thinking is about continuity.

Infrastructure-grade systems assume failure will happen. They are built to contain it, recover quickly, and keep the wider platform running. The goal is not perfection. The goal is staying available.

The goal is not perfection. The goal is staying available.

Continuous availability is now expected in financial services. Systems are updated and maintained without noticeable downtime because users do not tolerate interruptions when money is involved.

This approach does not slow teams down. It reduces risk. Deployments feel routine instead of stressful. Engineering effort shifts away from incident response and toward steady improvement.

Over time, this changes how organisations operate. Teams plan differently. Roadmaps become more realistic. Reliability becomes part of delivery rather than a separate concern.

Elixir and the always-on economy

Elixir programming language is designed for systems that are expected to stay available. It runs on the BEAM virtual machine, which was built in environments where downtime carried real consequences.

That background shows up in how Elixir applications are structured. Systems are composed of many small, isolated processes rather than large, tightly coupled components. When something fails, it fails locally. Recovery is expected. The wider system continues to operate.

Elixir in Fintech

This matters in fintech, where failure is inevitable and interruptions are costly. External services misbehave. Load changes without warning. Elixir applications are built to absorb those conditions and recover quickly without cascading outages.

Teams working in Elixir tend to spend less time managing fragile behaviour and more time improving core functionality. Systems evolve instead of being replaced. Reliability becomes part of the foundation rather than a promise teams struggle to maintain.

For fintechs operating in an always-on economy, that approach aligns with the expectations already placed on them.

Reliability as a competitive advantage

Reliable systems can completely change how a fintech operates day to day.

For growing fintechs, uptime supports trust and regulatory confidence. Customers stay because the platform behaves predictably. Growth becomes steadier because teams are not constantly reacting to incidents. Downtime costs make this real, especially for small businesses that lose revenue when systems are unavailable.

For larger providers, reliability reduces operational strain. Fewer incidents mean fewer emergency fixes and fewer difficult conversations with partners and regulators. Teams spend more time improving core services and less time managing fallout.

Reliability also shapes perception. Platforms that stay up become easier to trust with deeper integrations and higher volumes. Over time, that trust compounds and turns stability into a real advantage, even if it is rarely visible from the outside.

To conclude

The always-on economy creates real opportunity for fintechs, but it also raises expectations that many platforms were not originally built to meet.

The question is whether your system has the resilience to operate as infrastructure day after day. If you are a fintech and want to build with reliability in mind, get in touch.

Designing for resilience early makes it far easier to scale without introducing fragility later on.

The post The Always-On Economy: Fintech as Critical Infrastructure appeared first on Erlang Solutions.

n8n is a platform for workflow automation. Let&aposs see how interface n8n workflows with an XMPP network. As an example on how to use XMPP to receive data from n8n, let&aposs build a simple workflow that publishes into a MUC room some information about each commit pushed to a GitHub repository.

Simple workflow to display Git commits in a MUC room

You can browse and download this workflow here: https://share-n8n.net/shared/l6uiZZ54bPC3

GitHub Trigger

To receive the information about each Git push, we use the GitHub Trigger node. You need to set up some GitHub credentials with access to the repository you want to monitor. Then, set the Repository Owner and Repository Name accordingly. The Events you want to receive are of type Push. At this point, you can execute the workflow (just containing this unique node), do a couple of commits on your repository, and push them to test that it&aposs received by the GitHub Trigger node. When it works, pin the output data of the node so you don&apost have to push some more commits while you test the rest of the workflow. Don&apost forget to unpin it once you want to use the workflow for real.

Information Formatting

As you can see in the output data of the GitHub Trigger node, the list of commits in the push are in body.commits. We use a Split Out node on this field to process each one of these commits.

We then use an Edit Fields (Set) node to format the information we will display about each commit in the final message posted in the MUC room, using a Manual Mapping. Just check the input data coming by the previous Split Out node to choose what data you want to send to the MUC room. We name the output field Commit (type: String). Here is an example of such a template:

"{{ $json.message.split(&apos\n&apos)[0] }}" by {{ $json.author.username }} ({{ $json.author.name }} <{{ $json.author.email }}>), {{ $json.modified.length }} modified file{{ $json.modified.length >1 ? "s" : "" }}

The split at the beginning of this example is used to only keep the first line of the commit message.

After that, an Aggregate node will combine the commits info (one per item) into a single item, with this setting:

• Aggregate: Individual Fields
• Input Field Name: Commit (as named in the previous node)

As a result, we&aposll have one item containing the list of commits into a Commit field.

ejabberd credentials

We can now send the formatted data to the XMPP server using a HTTP Request node. For that, we use the send_message command from the ejabberd API.

We use an OAuth token to securely call ejabberd API using Bearer Authentication.

Fluux

If you are using a Fluux instance, you can get an OAuth token from your Fluux console, in the API Tokens section.

Self-hosted ejabberd

To create the credentials on your own ejabberd server, you&aposll need to use the oauth_issue_token command to get an OAuth token. Be sure you have an access rule that allows you to create such a token.

For the scope parameter of oauth_issue_token command, use the one defined in your api_permissions acl (ejabberd:admin in the example below) and be sure the user you issue the token for has the right to call the send_message command.

Extract of an example of an ejabberd.yml file that allows to call send_message using OAuth:

hosts:
  - "process-one.net"

listen:
  -
    port: 5281
    ip: "::"
	tls: true
    module: ejabberd_http
    request_handlers:
      "/api": mod_http_api

acl:
  admin:
    user:
      - "admin@process-one.net"

access_rules:
  muc:
    - allow: all
  muc_create:
    - allow: local
  muc_admin:
    - allow: admin
  oauth_access:
    - allow: admin

api_permissions:
  "console commands":
    from:
      - ejabberd_ctl
    who: all
    what: "*"
  "admin access":
    who:
      - oauth:
        - scope: "ejabberd:admin"
        - access:
          - allow:
            - acl: admin
    what:
      - send_message

modules:
	  mod_http_api: {}
	  mod_muc:
		  access: muc
		  access_create: muc_create
		  access_persistent: muc_create
		  access_admin: muc_admin

Example of a command to create a token with the above config:

ejabberdctl oauth_issue_token admin@process-one.net 360000 ejabberd:admin

Sending the XMPP message using send_message

Now you can create your credentials in the HTTP Request node:

• Authentication: Predefined Credential Type
• Credential Type: Bearer Auth
• Create a new Bearer Auth and put your token in the Bearer Token field.

For the other fields in the HTTP Request node:

• Method: POST
• URL: Full URL of the send_message command as defined by your ejabberd_api listener, for example https://process-one.net:5281/api/send_message. If you are using Fluux, the URL should be https://NAME.m.in-app.io:5281/api/send_message where NAME is your Fluux instance name.
• Send Body: enabled
• Body Content Type: JSON
• Specify Body: Using Fields Below
• Body Parameters: set the parameters for the send_message command:
  • type: groupchat
  • from: bare JID of the bot that will post the message in the MUC room
  • to: bare JID of the MUC room
  • subject: empty (not relevant for a MUC message)
  • body: template to format the commit information. For example, to display the name of the repository followed by the list of commits, one per line:

{{ $(&aposGithub Push&apos).item.json.body.repository.full_name }} repository:
{{ $json.Commit.join("\n") }}

The n8n workflow should now be working: it will publish all commits pushed on the repository defined in the first node into the MUC room defined in the last node (don&apost forget to unpin everything).

Same workflow with a custom stanza

You can browse and download this workflow here: https://share-n8n.net/shared/nxmUMbdNM0gH

This is a variant of the above workflow to illustrate how to create and send a custom stanza instead of the simple message that send_message API permits. This is needed for example if you want to add an element in a custom namespace into your message stanza.

The minimal stanza for a MUC message is:

<message type="groupchat">
  <body>
	List of commits
  </body>
</message>

We don&apost need to set the from, to or id attribute, it will be handled by the API call done in the last node. Let&aposs say we want to add a sub-tab containing the timestamp of the moment the message was sent by n8n. The stanza we want to create looks like this:

<message type="groupchat">
  <body>
	List of commits
  </body>
  <n8n xmlns="p1:custom:timestamp">2025-12-17T11:16:13.071-05:00</n8n>
</message>

Create a custom stanza

We want to create that stanza just before the last one, between the Aggregate node and the HTTP Request node. To ensure that all strings from the git commit are correctly encoded for XML, we use the JSON to XML node. This means we have to construct the stanza in JSON first.

This is done in the Make Stanza in JSON node of type Edit Fields (Set). We use the Manual Mapping to ensure all special characters from the git commit are correctly escaped.

• We set a $ field (which is the default Attribute Key) to set the type attribute on the root element. The name of the root element, message, will be set in the next node, JSON to XML.
• We create a body field of type String that will contain the list of commits, one per line. We can use the same template used in the last node of the previous workflow:

{{ $(&aposGithub Push&apos).item.json.body.repository.full_name }} repository:
{{ $json.Commit.join("\n") }}

• We add a n8n field for the custom tag, with type Object, to be able to set a xmlns attribute on it:

{
 "_": "{{ $now }}",
 "$": {"xmlns": "p1:custom:timestamp"}
}

Convert the stanza in XML

The stanza is converted in XML in the Convert stanza in XML, XML node:

• The Mode is JSON to XML
• Property Name is the name of the field in the output data, let&aposs name it stanza.
• We have to enable the Headless option to prevent the XML header to be added before the message.
• The Root Name is set to message (the root element of the stanza) as the JSON received from the previous node is just the content of the XML document.

Sending the XMPP message using send_stanza

The configuration of the HTTP Request node is the same than for the previous workflow, except that the URL must call send_stanza instead of send_message. The body parameter is replaced by the stanza one, in which we just have to set the stanza field from the previous node:

{{ $json.stanza }}

Be sure to adapt your ejabberd configuration accordingly, specifically to allow send_stanza to be called.

I had the pleasure of giving a talk on "XMPP and Metadata" during the last Chaos Communication Congress, in the Critical Decentralization Cluster area. It was my first public presentation in a very long while (also in english), so the talk went okay-ish at best. The end of the year was also hectic and I did not manage to prepare or rehearse as much as I would have liked to.

This blog post will be a longer, more complete version of the talk. You can nonetheless find the talk slides on the CDC pretalx. Thanks a lot to the people who proofread the blog post to fix stuff or suggest additional content.

This was about metadata, but also generally data retention and what the server sees in general.

As we previously described here, your Fluux.io service can send push notifications to your xmpp user&aposs browsers when they are offline. It includes Safari on iOS devices. But before enabling it your users need to add your Progressive Web App (PWA) on their home screen.

You can test the whole process with our "Test Client" from your fluux.io console. First, sign in fluux.io console and go to WebPush App list. Like in previous blog post open test client.

This page has a link tag :

<link rel="manifest" href="/manifest.json">

linking to a WebApp manifest file such this one https://fluux.io/manifest.json

We reproduced here main fields :

{
  "name": "FluuxIO",
  "icons": [
    {
      "src": "/logo.png",
      "type": "image/png",
      "sizes": "200x200"
    }
  ],
  "display": "standalone"
}

This file provides a name, an icon and so on to the PWA. It also fixes display mode to "standalone" which is required to enable push notification on a Progressive Web App on iOS.

With such configuration, end-user has to tap on "share button" :

Then iOS user has to scroll and tap on "Add to Home Screen".

It will open a form prefilled with data from manifest.json

Once registration form submitted, a new icon will appear on iOS device home screen and will act as a new app.

Launch it, sign in your fluux console, and move back to test client and connect using a test user. You can now tap on "Enable webpush"

You will be prompted to allow your device to receive push notification from your fluux platform (through safari/apple server).

Like other push worflows a notification for new message will be sent to xmpp user&aposs device when offline :

We are pleased to announce a new minor release from our stable branch.

Happy new year! Our first release of 2026 is a minor release for our stable branch, with a range of tweaks, bug fixes and minor improvements for you.

A summary of changes in this release:

Fixes and improvements

• mod_storage_sql: Set configurable wait time for locked SQLite3 database
• net.server_event: Port TLS 1.3 channel binding method to libevent backend
• mod_roster: Add command for cleaning out invalid contact JIDs
• migrator: Allow migrating between different configs of the same driver
• mod_admin_shell: Allow pinging any JID with xmpp:ping()
• mod_invites: Accept –admin flag as shortcut for –role prosody:admin
• mod_mam: Add send_legacy_offline_messages_to_mam_clients config option
• mod_limits: Allow configuration of general ‘s2s’ limit, and have s2sout inherit from s2sin
• mod_storage_internal: Return item-not-found for unknown before/after ids
• MUC: Fixes for room avatar caching

Minor changes

• core.configmanager: Fix referencing previous config options #1950
• MUC: Ensure allow MUC PM setting has valid value (fixes #1933: PM does not work on new MUCs)
• mod_storage_sql: Assert that serialization of archive:set() payload succeeds
• mod_smacks: Remove extra optional from sm element
• mod_s2s_auth_dane_in: Fix caching SHA2-512 hash
• MUC: Fix muc_room_default_presence_broadcast option not working
• util.sslconfig: Fix error when applying ssl={[port]=…}
• net.server_epoll: Restore idle checks after pause (e.g. rate limits)
• util.jid: Validate domainparts using IDNA or as IP literals (fixes #1903: Invalid JID in Roster)
• util.datamanager: Fix detection of index files created on different architectures
• util.startup: Inform process manager about failure to reload config
• mod_muc: Revert f4e16e6265e6 and invalidate avatar cache only on vcard change
• mod_http_file_share: Improve debug logging around unexpected file sizes
• mod_admin_shell: Ensure JIDs are normalized in xmpp:ping()
• mod_invites: Return error when generating password reset for non-existent account
• util.uuid: Update UUIDv7 to match RFC 9562

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

Chat of Future Initiative Banner.png

Dear all,

the XSF Communication Team is pleased to announce a new initiative to help evolving the XMPP ecosystem in a broader and aligned perspective. This should cover discussions, development but also extended public communication and presence. As this initiative is being setup in an iterative way, participants will be able to form and steer its direction over time.

Why the Chat of the Future Initiative?

XMPP exists for more than 25 years now, with world-wide implementations across various applications and more than 500 published and public specifications. At xmpp.org, software of more than 35 clients, 20 libraries and 8 servers are listed. This rich history is only possible through the federation endorsed since 1999.

Although this is an advantage, maintaining a federated and decentralised network also requires significantly higher efforts for cross-network alignment, adoption and also quality of the XMPP technology. This initiative intends to support such activities along different actors.

What is the Chat of the Future Initiative about?

Participants will try to identify, collect, and formulate activities that apply to the XMPP ecosystem that needs efforts around today’s status quo. This new collaboration space is considered to formulate along user and developer needs. From the discussions common ground on where we can act should be found.

Far thinking, this could lead to community vision and strategic thinking that every actor can decide to contribute individually. In the past, possible topics named have been for example an interoperability session, to work on encryption or having a landing page for developers.** Of course, the scope should be limited to the actors capabilities.

How will the Chat of the Future Initiative work?

The Chat of the Future initiative will begin with a series of open-ended and interactive collaboration sessions and open up for discussion, alignment and collecting of thoughts and ideas. This can happend across multiple session and is always a quarterly activity. It’s for example planned to ask you about your perspective on the status quo of the XMPP ecosystem. What are we getting right, what are we not? Where is it that we see room for improvement? Can we formulate any activities out of this?

The participants will have the chance to contribute with their perspective, feedback and discussion topics via a BigBlueBotton session, both in spoken and written form. For notetaking a HedgeDoc pad will be used. If other organisation spaces - such as a group chat - be necessary, the development of the initiative will show. At its best, this interactions are integrated in what is available in the existing XMPP channels.

Who can participate the Chat of the Future Initiative?

Anyone interested and willing to contribute to the XMPP ecosystem of any level of experience can join with their perspective. This also involves newcomers and bare users as well as professionals of the XMPP technology. If you cannot participate, consider to provide your thoughts in a written statement to the organiser. There are multiple sessions and more planned, so one can join at another time or phase.

When & Where will the Chat of the Future Initiative take place?

Currently a first set of sessions is planned and listed below with more sessions to work on actual topics to come. This can be matter of change based on feedback.

The session link can be found here: BigBlueBotton. Access code: 932872

The password code and the pad will posted on the day in the XSF Chat (see below).

Meeting netiquette: Please keep a respectful, constructive and positive tone and statements.

If you have further questions, please join the XSF chat.

We hope this will positively contribute to the community and technology as a whole. See you soon,

— The XSF Communication Team

Note: In a previous statement another tool and setup has been named. Through dicussions this has been changed.

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of December 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 the XMPP Summit 28, which will take place during 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!

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before February 15th, 2026, 00:00 UTC.

XMPP logo and Font Awesome

The XSF is proud to announce that the official XMPP logo has been accepted into Font Awesome and will be bundled up in their source tarball starting from their next release!

XMPP Events

• XMPP at FOSDEM26: These are the XMPP related talks that will take place on the Decentralised Communication track. This talks will take place in room AW1.126 on Sunday, January 31st, 2026. You can also join the conversation or watch the live videos at aw1126.
  • Engineering XMPP Federation: Building Messaging, Voice & Social Features Across Independent Projects: The XSF is a standards body that sits at the core of a development ecosystem of independent implementations by different individuals and organizations that actually work together, all highly interoperable, shipping new features at a high pace. This talk, by Jérôme Sautret will share how things work at this scale and will be co-presented by a server and client developer, showing how they work together to fine-tune their implementations. This talk starts at 13:15 and ends at 13:45 hs.(UTC+1:00)
  • Movim: Building a Decentralized Social Network on XMPP: In this talk, Timothée Jaussoin will present how Movim leverages the XMPP standard and its extensions to deliver features users expect from modern social platforms (communities, IM, group chats, video calls, blogging and a complete publishing platform into a unified experience), without giving up your data to a centralized platform, while remaining fully federated, interoperable with other XMPP clients like Conversations and Dino, and capable of bridging to centralized platforms like Discord, Telegram, and WhatsApp!. This talk starts at 13:45 and ends at 14:15 hs. (UTC+1:00)
  • What are you listening to now?: Implementing “Now Playing” feature in modern XMPP: In this talk, Özcan Oğuz will share the journey on his research on implementing this feature in modern XMPP clients, the protocols of certain operating systems to read the currently playing media, the current status of the support of XEP-0118 (User Tune) and the PoC of a modern “Now Playing” feature. This talk starts at 14:15 and ends at 14:45 hs. (UTC+1:00)
• XMPP at RHL26: this french-speaking event for software freedom will take place during January 23-27 in Switzerland and will welcome two conferences about XMPP. Codimp will host the ‘XMPP ou comment ne pas réinventer la roue : messagerie fédérée et sécurisée en 2026’ presentation about the improvements to the protocol, servers and clients in last five years, while neox will host the ‘L’hébergement éthique comme Commun’ presentation about how the Libre en Communs non-profit built its own infrastructure as a common around fully free software and compatible hardware in order to hosts projects and in particular a public XMPP service, being the communication core to manage this together.
• XMPP at 39C3 CCC: the Critical Decentralisation Cluster (CDC) returned to the 39th Chaos Communication Congress in Hamburg (Germany) during this last December 27-30 2025. The CDC provided a friendly space for discussions and exchanges on technology and politics with other communities working towards decentralization. The XMPP assembly was part of it thanks to neox and mathieui active involvement, with the latter being responsible for the sparkly XMPP stickers!!

Left: the highly coveted XMPP sparkly stickers! Right: XMPP assembly at the 39C3 Critical Decentralisation Cluster!

Videos and Talks

• Devuan 6 Excalibur instalamos el cliente xmpp Gajim by gnuxero. [ES]

XMPP Articles

• Explorando XMPP e Ejabberd: Um Estudo Profundo by Eduardo Marques for DMarkInfo Blog. [PT_BR]
• Monal Internals - Serializable Promise framework by Matthew Fennell for the Monal IM Blog.
• Movim: Some of you might have experienced difficulties to open Movim as a Progressive Web App on your Android device. There is a known issue on Chrome related to that. A workaround has been pushed to master, please clear your application cache to deploy it!
• Reflecting on 2025: A Year of Growth, Collaboration & Community by guus for the Ignite Realtime Community.
• JMP newsletter - More Cheogram Apps: this latest edition of your pseudo-monthly JMP update brings you news about port-out PIN self-service, data-only registration, a collection of selected recent Cheogram Android changes, a word of advise about some changes to the official distribution mechanism for Cheogram apps and all you need to know about the highly anticipated Borogove based Cheogram WWW and Cheogram iOS clients!
• The XMPP newsgroup on Usenet: The NNTP protocol is still in use, and there is an active Usenet group about the XMPP/Jabber topic at alt.chat-programs.jabber. NNTP is a standard application-level protocol that enables the exchange of messages in distributed systems such as Usenet — a protocol worth revisiting. Some free public servers are available; one of them is Eternal September, which has open free registration. You may use Thunderbird, PAN or TIN as a client.

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.19.0-4 for Android. A bugfix release that introduces fixes to tablet view, account filters for starting new chat, some crashing bugs, WASM in WebXDC, show an extra piece of context on call status/failure, align message text size with upcoming Snikket release, among many others! Make sure to check out the list of changes for all the details across releases.
• Conversations has released versions 2.19.6 and 2.19.7 for Android. This version introduces a setting to always use relays, sends delivery receipts by default and turn setting into “Read receipts” and fixes avatar caching issue and DNS occasionally not resolving when Private DNS is enabled. You can take a look at the changelog for all the details.
• Gajim has released version 2.4.1 of its free and fully featured chat app for XMPP. This release brings previews for GIFs and similar animation file formats, 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.

Animated previews in Gajim.

• Kaidan has released version 0.14.0 and it includes some great new features and fixes! Advanced media sharing, filtering XMPP providers for account creation, highlighted messages, XMPP URIs, and many other new features and bugfixes! You can find a detailed list of new features, bugfixes and notes in the changelog.
• Monal has released versions 6.4.15 and 6.4.16 for iOS and macOS.
• Monocles has released version 2.0.18 of its chat client for Android. And it comes loaded! It introduces a VCard4 profile editor, a VCard QR code generator to account editor, a drag and drop account reordering, improves input field text color visibility, an option to save media to downloads folder in media viewer, introduces chat history calendar, updates TLSv1.3 setting (Default on), adds wasm extension and application/wasm MIME and more!. Make sure to take a look at the changelog for all the details!
• Quicksy has released versions 1.17.0 and 1.21.0 for iOS.
• Initial development of MankalaNextGen, a graphical user interface to play Mancala games was done during Google Summer of Code 2025 by Srisharan VS. The application uses QXMPP to enable remote play.

XMPP Servers

• MongooseIM has released version 6.5.0 of its Enterprise Instant Messaging Solution. This release brings new features, changes, various fixes and improvements. For more information, make sure to check out the changelog and the documentation.
• The Ignite Realtime community is happy to announce the release of Openfire 5.0.3! This release 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.
• Snikket Server - December 2025 release: Snikket is rounding off the year with another small release of its 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. Some notable changes include offline message compatibility and web portal debug information.

XMPP Libraries & Tools

• go-xmpp versions 0.3.0, 0.3.1 and 0.3.2 have been released.
• go-sendxmpp, a tool to send messages to an XMPP contact or MUC inspired by sendxmpp, versions 0.15.2, 0.15.3 0.15.4 and 0.15.5 have been released. Full details on the changelog.
• nbxmpp-client, a small GTK test client to test various ways to connect to a server, version 2.0.1 has been released. Full details on the changelog.
• peertube-plugin-livechat, a plugin meant to provide a chat system for Peertube videos, version 14.0.2 has been released.
• python-nbxmpp, a Python library that provides a way for Python applications to use the XMPP network, version 7.0.0 has been released. Full details on the changelog.
• QXmpp, the cross-platform C++ XMPP client and server library, version 1.13.0 has been released. Full details on the changelog.
• Slidge versions 0.3.4 ‘Christmas special’ and 0.3.5 have been released. This releases incorporates conversion of vector animated stickers in the lottie format to webp. Slidgram and slidcord already did such conversion, but now it’s done via an optional (“extra”) dependency of slidge: rlottie-python, which makes packaging/distribution easier. And many other features, improvements and bugfixes! You can check the release changelog or the intermediate changelogs from 0.3.3 to 0.3.5 for the full list of changes.
  • matridge, the Matrix to XMPP gateway based on Slidge and nio, versions 0.3.2 has been released.
  • matteridge, the Mattermost to XMPP gateway based on Slidge and mattermost-api-reference-client, version 0.3.2 has been released.
  • slidcord, the Discord to XMPP gateway based on Slidge and discord.py-self, version 0.3.1, has been released.
  • slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.9 has been released.
  • slidgram, the Telegram to XMPP gateway based on Slidge and Pyrofork, version 0.3.1, has been released.
• xmpp-ap-bridge, a lightweight Fediverse to XMPP implementation based on client bots to enable chat-like conversations between any Fediverse application and any XMPP client, from your usual client applications, versions 0.7.3 and 0.7.4 have been released.
• xmpp-dns, a CLI tool to check XMPP SRV records, version 0.5.5 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.

• Initial Authentication Pipelining
  • This specification defines a protocol for discovering if the SASL2 <authenticate> can be pipelined safely along with the stream open, and if so allows the client to perform this pipelining safely.

New

• Version 0.1.0 of XEP-0508 (Forums)
  • Accepted as Experimental by council vote (dg)
• Version 0.1.0 of XEP-0509 (Initial Authentication Pipelining)
  • 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.3 of XEP-0045 (Multi-User Chat)
  • muc#roomconfig_allowinvites doesn’t restrict owners but enables additional permissions for members. (spw)
• Version 0.7.0 of XEP-0353 (Jingle Message Initiation)
  • Remove local redefinition of jingle <reason/> element in XML schema and reference existing.
  • Make usage of <reason/> element optional in schema, as specified in the text.
  • Add missing definition of ’empty’ type in XML schema. (lnj)

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-0377 (Spam Reporting)
  • This Last Call begins on 2025-12-12 and shall end at the close of business on 2026-01-05.

Stable

• Version 1.0.0 of XEP-0440 (SASL Channel-Binding Type Capability)
  • Accept as Stable as per Council Vote from 2025-11-18 (XEP Editor (dg))

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

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

Newsletter Contributors & Translations

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

• Contributors:

  • To this issue: emus, cal0pteryx, Gonzalo Raúl Nemmi, Adrien ’neox’ Bourmault, Ludovic Bocquet, Benson Muite, Mario Sabatino, XSF iTeam

• Translations:

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

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.

Here comes Kaidan 0.14.0! It includes some great new features and fixes!

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

Advanced Media Sharing

It is now possible to select media to be shared while being offline. Once you are connected, all media is automatically uploaded. Even downloads can be enqueued to be started as soon as you are online. In addition, ongoing transfers are canceled on disconnecting and automatically restarted once connected again. Up- and downloads can be manually canceled and restarted as well.

Filtering XMPP Providers for Account Creation

Kaidan’s manual registration now allows to filter all XMPP providers by various properties. For example, you can choose whether only providers are shown that store their data in a specific country or whose service runs on renewable energy. That is possible because Kaidan uses the data from XMPP Providers.

Highlighted Messages

Messages are now precisely highlighted on various actions. A border is displayed around a message if you open its context menu, search it, or jump to if from a reply. That makes it possible to quickly see the relevant message.

XMPP URIs

If you received an XMPP URI such as xmpp:alice@example.org, you can paste it directly into the field for adding a new contact. There is no need to remove any characters that are required to be machine-readable. The same applies to XMPP group chat URIs.

Changelog

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

Features:

• Keep draft messages on top of pinned/unpinned chat list items (pehg)
• Optimize thumbnail creation (fazevedo)
• Display border around searched/referenced message instead of bar (melvo)
• Display border around message if its context menu is shown (melvo)
• Highlight message’s avatar if hovered (melvo)
• Display provider chat (used for welcome messages and service announcements) as such (melvo)
• Always display same name and proper avatar initials for notes chats (melvo)
• Allow to cancel downloads/uploads (fazevedo)
• Allow to restart canceled uploads (fazevedo)
• Allow to resend failed message via context menu (melvo)
• Retrieve support addresses from server instead of provider list (XEP-0157: Contact Addresses for XMPP Services, XEP-0128: Service Discovery Extensions) (melvo)
• Allow adding contact by entering XMPP URI (including authentication of OMEMO 2 keys) (melvo)
• Allow joining group chat by entering XMPP URI (melvo)
• Add option for allowing SASL PLAIN (needed for servers using LDAP) to custom connection settings (melvo)
• Add filtering options to choose provider for registration (melvo)
• Cancel file transfers on disconnecting from server (fazevedo)
• Add support for offline media sharing queue (fazevedo)
• Restart downloads canceled on logout once logged in (melvo)
• Remove all related data on message removal (such as reactions and media) (melvo)

Bugfixes:

• Fix displaying message reaction details (melvo)
• Fix adding unneeded separator on mention after new line (melvo)
• Wrap hint for actions needing user to be connected to server (melvo)
• Fix displaying icons on Windows (pehg)
• Fix adding new line at cursor position (melvo)
• Ensure that own encryption devices are not removed if notes chat is removed (melvo)

Notes:

• Kaidan requires KIconThemes (for Windows) now
• Kaidan requires Qt6GuiPrivate (for Qt 6.10 or above) now
• Kaidan requires Qt 6.7 now
• Kaidan requires QXmpp 1.13 now

Download

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

Or install Kaidan for your distribution:

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!

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

Last Call

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

• No Last Call this month.

Stable

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

Deprecated

• No XEPs deprecated this month.

Rejected

• No XEPs rejected this month.

XMPP Public channels

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

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

Spread the news

Please share the news on other networks:

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

Also check out our RSS Feed!

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

Newsletter Contributors & Translations

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

• Contributors:

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

• Translations:

  • French: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
  • German: Millesimus
  • Italian: nicola
  • Portuguese: Paulo

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

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

License

This newsletter is published under CC BY-SA license.

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

What is SAFE?

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

Supporting Phoenix LiveView

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

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

On-Prem report visualisation

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

Overview page of an example report:

User management:

Running SAFE

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

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

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

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

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

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

For teams serving SMEs, the risk is even greater.

The Scaling Problem: When “go fast” Stops Working

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

Then comes the real hurdle: scale.

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

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

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

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

Scenario in action

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

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

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

Why MVP habits collapse at SME scale

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

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

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

Common challenges for SME-serving fintechs:

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

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

Building for production: What matters most

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

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

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

And SMEs feel that difference.

What this means for fintech SMEs (and their customers)

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

Reduced downtime and more stability

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

Lower cost of change

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

Simpler compliance and clearer audit-ability

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

Faster deployment and steady iteration

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

A better experience for SME customers

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

To conclude 

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

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

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

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

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

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

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

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

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

• XMPP Council:

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

• Board of Directors:

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

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

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

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

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

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

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

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

The Performance Myth

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

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

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

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

XML brings three key advantages:

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

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

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

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

Where the Real Complexity Lives

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

Consider XMPP when these factors matter to you:

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

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

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

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

The XMPP Community is very excited to announce its presence at the coming FOSDEM 2026!

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

Realtime Lounge

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

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

Map of the K building level 2

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

Decentralised Communication Devroom & Talks

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

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

Info & Dates

XMPP Summit 28 prio to FOSDEM 2026

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

Looking forward to see you there!

Spread the word 📢

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

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

Smack 4.5.0-rc1 is now available on Maven Central.

1 post - 1 participant

Read full topic

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

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

Signal Protocol and Post-Quantum Ratchets

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

Signal Messenger

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

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

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

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

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

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

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