The Backbone of Real-Time Digital Services

Most platforms treat messaging as something you add. A chat module bolted on after the core product ships. A notification layer wired in once users start asking for it. A support tool that earns its place once the team has bandwidth to integrate it.

That approach made sense when digital services were simpler, but it does not hold up today.

Modern platforms depend on messaging the way infrastructure depends on foundations. Authentication flows run through it, transactions are confirmed through it, and services coordinate across distributed systems because of it. Users have live conversations on top of it, and when messaging slows or fails the whole platform feels unstable even when every other component is technically fine.

For engineering leaders responsible for systems that run continuously, that distinction matters more than most architectural decisions they will make.

Live Environments Expose Weakness Instantly

Batch-driven systems can hide problems. A delay absorbed overnight goes unnoticed, and a queue that backs up and clears before morning leaves no visible trace.

But live systems cannot afford that luxury.

Entertainment platforms, gaming ecosystems, fintech services, live commerce environments, and global support operations all run under constant visibility. Every interaction is observable in real time, and a dropped message during a live session is immediately visible to the person on the other side.

Not to mention the financial exposure is significant. Research from Gartner estimates average IT downtime costs at around $5,600 per minute, a figure that rises sharply during peak demand. The reputational cost can be harder to recover from. Research from PwC found that 32 percent of customers would stop using a brand they had actively liked after a single poor experience, and in digital services, that experience is often a delayed response, a failed notification, or a conversation that disconnects mid-session.

Live environments remove the tolerance for fragility that batch systems enjoy, and when messaging is unreliable, user trust soon follows.

Scalability Without Responsiveness Is Not Enough

Live systems expose fragility quickly, and scale is usually the next pressure that follows.

When teams talk about scalability, they’re usually talking about volume: more concurrent users, more connections, higher throughput, bigger numbers across the board. But capacity alone doesn’t guarantee a good experience.

A system can remain technically online under heavy load while the quality of the experience quietly begins to slip. Latency creeps upward, message delivery becomes less predictable, and failover processes interrupt sessions that previously felt stable. From an infrastructure perspective the system is still operating, but from a user’s perspective the experience is already degrading.

True scalability is really about maintaining responsiveness as pressure increases. That means designing architecture with those conditions in mind from the beginning: the ability to expand horizontally across distributed nodes, load balancing that distributes traffic intelligently instead of creating centralised bottlenecks, consistent state across clusters, and no single points of failure. Just as importantly, delivery guarantees still need to hold even when network conditions are less than ideal.

Resilience isn’t something you bolt on later once growth arrives. Networks partition, nodes fail, and traffic spikes appear without warning. Systems built on the assumption that conditions will remain stable tend to reveal their weaknesses at exactly the moment when the consequences are most expensive. Organisations that design their messaging architecture with those realities in mind avoid the most painful scaling problems.

Internal Communication as Operational Infrastructure

The same messaging systems that support customer interactions also coordinate how organisations operate internally.

Customer-facing communication tends to attract most of the attention, but the internal messaging infrastructure behind it is just as strategically important.

Hybrid and distributed teams rely on real-time communication to stay coordinated, while operational systems depend on alerting pipelines that surface anomalies before they escalate into incidents. Engineering teams also need observability data flowing continuously across services so they can understand what is happening inside complex systems and respond quickly when something changes.

When internal communication becomes fragmented, the effects are immediate. Decision-making slows as context becomes siloed across tools, incident response turns reactive rather than proactive, and support agents end up jumping between systems to assemble information that a unified platform could surface instantly. Engineers face a similar challenge, losing visibility into behaviour that spans multiple services and environments.

That internal alignment ultimately shapes the external customer experience. Research from Salesforce shows that 73 percent of customers expect companies to understand their specific needs, and meeting that expectation depends on systems capable of maintaining and propagating context in real time. 

In many ways, whether personalisation is practical or merely aspirational comes down to architecture.

Omnichannel Expectations Demand Unified Architecture

The pressure on messaging systems does not stop inside the organisation. Customers now expect the same continuity across every channel they use.

Customers move constantly between web platforms, mobile apps, in-app messaging, and social channels, but they don’t experience those interactions as separate systems. To them it’s all part of one ongoing relationship with a brand.

That expectation shows up clearly in the data. Zendesk reports that 70 percent of customers expect anyone they interact with to have the full context of their situation, and they have very little patience for experiences that force them to repeat themselves when they switch devices or move between platforms.

Meeting that expectation isn’t just a matter of adding more channels. What actually matters is whether the systems behind those channels share context. Without a unified messaging backbone that maintains identity, presence, and session continuity across distributed systems, every new touchpoint risks becoming another silo.

This is where architecture starts to matter. Many organisations assemble their communication stack gradually from disconnected tools, and those systems were never designed to maintain continuity across environments. By contrast, distributed platforms built around clustering, federation, and consistent state management make it possible to carry context across services and channels in a reliable way.

In other words, context persistence isn’t really a user interface feature. It’s the result of architectural decisions made much deeper in the stack.

Growth Exposes Architectural Weakness

Architectures that support seamless cross-channel experiences must also survive rapid growth.

Messaging systems often work well at moderate scale. The real pressure arrives once growth starts to change the shape of the system.

A product launch can suddenly create concurrency spikes that never appeared during development. Expanding into new regions introduces latency sensitivities that flat traffic patterns never exposed. A successful marketing campaign drives engagement surges that the original architecture was never really designed to handle.

When messaging has been treated as just another product feature, scaling usually means significant re-engineering at exactly the wrong moment. Vertical scaling starts to introduce bottlenecks, point integrations multiply as teams patch things together, and operational complexity grows with every workaround. Before long, the team that should be building new capabilities is stuck rebuilding the foundations instead.

Infrastructure-grade messaging grows in a very different way. Capacity expands horizontally as demand increases, rather than running headfirst into ceiling after ceiling. Clustered deployments distribute load while maintaining consistent state, and fault tolerance helps isolate failures instead of letting them cascade across the system. Because the platform is designed to be extensible, new services can integrate without destabilising everything that already works.

The result is that scalability stops being an emergency response and becomes a built-in property of the system.

Reliability, User Experience, and Brand Perception

As systems scale, reliability becomes visible not just to engineers but to users.

Reliability is measured inside organisations through uptime dashboards and incident reports, but outside the organisation it is measured through trust.

Research from HubSpot shows that 90 percent of customers consider an immediate response important when they have a support query. In real-time environments, immediate increasingly means seconds rather than minutes, and tolerance for anything slower continues to shrink.

When communication systems fail during periods of peak demand, users are not reading the engineering post-mortem. They are forming a perception of the platform. Notifications that arrive too late during critical moments, conversations that cut off mid-session, and responses that stall when they matter most all shape how a system is experienced. Those moments shape how a platform is understood far more powerfully than any feature release.

Engineering leaders who treat messaging as foundational infrastructure reduce that exposure. Systems designed for distribution, clustering, and fault tolerance can maintain consistency under load, preserve state during failover, and absorb traffic spikes without visible degradation.

In real-time systems, reliability ultimately shows up as user confidence, especially during the moments when attention is highest.

Infrastructure Is a Strategic Choice

Taken together, these pressures change how messaging needs to be designed inside modern platforms.

Always-on digital environments do not wait for architecture to catch up. Communication flows continuously through modern platforms, carrying transactions, context, and operational signals across distributed systems. When those flows hold steady, the platform does too.

Treating messaging as just another feature underestimates the role it plays. Treating it as infrastructure reflects how modern platforms actually operate and what it costs when communication breaks down.

Organisations that design messaging as core infrastructure give themselves something valuable: the ability to operate confidently under real conditions. They sustain responsiveness as demand grows, maintain continuity across channels, and protect user trust during the moments that matter most.

If you are assessing the resilience and scalability of your real-time messaging architecture, get in touch.

The post Messaging as Infrastructure, Not Just a Feature appeared first on Erlang Solutions.

This release brings supports for three new XEPs, fixes one specific bug that was breaking poezio, and has a lot of internal improvements including typing hings and documentation.

Thanks to everyone involved for this release!

I caught a new bug minutes after releasing, so the version to take is actually 1.14.1 and not 1.14.0!

Real-time messaging sits at the centre of many modern digital products. From live chat and streaming reactions to betting platforms and collaborative tools, users expect communication to feel immediate and consistent.

When pressure builds, the system doesn’t typically collapse. It starts to drift. Messages arrive slightly late, ordering becomes inconsistent, and the platform feels less reliable. That drift is often the first signal that chat scalability is under strain.

Imagine a live sports final going into overtime. Millions of viewers react at once. Messages stack up, connections remain open, and activity intensifies. For a moment, everything appears stable. Then delivery slows. Reactions fall slightly out of sync. Some users refresh, unsure whether the delay is on their side or yours.

Those moments reveal whether the system was designed with fault tolerance in mind. If it was, the platform degrades predictably and recovers. If it wasn’t, small issues escalate quickly.

This article explores what breaks first in real-time messaging and how early architectural decisions determine whether users experience resilience or visible strain.

Real-Time Messaging in Live Products

Live products place real-time messaging under immediate scrutiny. On sports platforms, streaming services, online games, and live commerce sites, messaging is visible while it happens. When traffic spikes, performance issues are exposed immediately.

User expectations are already set. WhatsApp reports more than 2 billion monthly active users, shaping what instant communication feels like in practice. That expectation carries into every live experience, whether it is chat, reactions, or collaborative interaction.

Source: Statista

Live environments concentrate demand rather than distribute it evenly. Traffic clusters around specific moments. Concurrency can double within minutes, and those users remain connected while message volume increases sharply. That concentration exposes limits in chat scalability far more quickly than steady growth ever would.

The operational impact tends to follow a familiar pattern:

Live scenario	System pressure	Business impact
Sports final	Sudden surge in concurrent users	Latency becomes public
Product launch	Burst of new sessions	Onboarding friction
Viral stream moment	Rapid fan-out across channels	Inconsistent experience
Regional spike	Localised traffic surge	Infrastructure imbalance

For live platforms, volatility comes with the territory.

When delivery slows or behaviour becomes inconsistent, engagement drops first. Retention follows. Users rarely blame infrastructure. They blame the platform.

Designing for unpredictable load requires architecture that assumes spikes are normal and isolates failure when it occurs. If you operate a live platform, that discipline determines whether users experience seamless interaction or visible strain.

High Concurrency and Chat Scalability

In live environments, real-time messaging operates under sustained concurrency rather than occasional bursts. Users remain connected, they interact continuously, and activity compounds when shared moments occur.

High concurrency is not simply about having many users online. It involves managing thousands, sometimes millions, of persistent connections sending and receiving messages at the same time. Every open connection consumes resources, and messages may need to be delivered to large groups of active participants without delay.

This is where chat scalability really gets tested.

In steady conditions, most systems appear stable. When demand synchronises, message fan-out increases rapidly, routing paths multiply, and coordination overhead grows. Small inefficiencies that were invisible during testing begin to surface. Response times drift. Ordering becomes inconsistent. Queues expand before alerts signal a problem.

High concurrency does not introduce entirely new issues. It reveals architectural assumptions that only become visible at scale. Concurrency increases are predictable in live systems. The risk lies in whether the messaging layer can sustain that pressure without affecting user experience.

Messaging Architecture Limits

The pressure created by high concurrency does not stay abstract for long. It shows up in the messaging architecture.

When performance degrades under load, the root cause usually sits there. At scale, every message must be routed, processed, and delivered to the correct subscribers. In distributed systems, that requires coordination across servers, and coordination carries cost. Under sustained traffic, small inefficiencies compound quickly.

Routing layers can become bottlenecks when messages must propagate across multiple nodes. Queues expand when incoming traffic outpaces processing capacity. Latency increases as backlogs grow. If state drifts between nodes, messages may arrive late or appear out of sequence.

This is where the earlier discussion of chat scalability becomes tangible. It is not only about supporting more users. It is about how efficiently the architecture distributes load and maintains consistency when concurrency remains elevated.

These limits rarely appear during controlled testing with predictable traffic. They emerge under real usage, where concurrency is sustained and message patterns are uneven.

Well-designed systems account for this from the outset. They reduce coordination overhead, isolate failure domains, and scale horizontally without introducing fragility. When they do not, performance drift becomes visible long before a full outage occurs, and users feel the impact immediately.

Fault Tolerance and Scaling

If you operate a live platform, this is where design choices become visible.

Once architectural limits are exposed, the question is how your system behaves as demand continues to rise.

Scaling real-time messaging is about making sure that when components falter, the impact is contained. Distributed systems are built on a simple assumption: things break. You will see restarts, reroutes and unstable network conditions. But the real test is whether your architecture absorbs the shock or amplifies it.

Systems built with fault isolation in mind tend to recover locally. Load shifts across nodes. Individual components stabilise without affecting the wider service. Systems built around central coordination points are more vulnerable to ripple effects.

In practical terms, the difference shows up as:

• Localised disruption rather than cascading instability
  
• Brief slowdown instead of prolonged degradation
  
• Controlled recovery rather than platform-wide interruption
  

These behaviours define whether users experience resilience or instability.

Fault tolerance determines how the system behaves when conditions are at their most demanding.

Real-Time Messaging in Entertainment

Entertainment platforms expose weaknesses in real-time messaging quickly because traffic converges rather than building steadily over time.

When a live event captures attention, users respond together. Demand rises sharply within a short window, and those users remain connected while interaction increases. The stress on the system comes not from gradual growth, but from concentrated activity.

Take the widespread Cloudflare outage in November 2025. As a core infrastructure provider handling a significant share of global internet traffic, its disruption affected major platforms simultaneously. The issue was due to underlying infrastructure, but the impact was immediate and highly visible because so many users were active at once.

Live gaming environments operate under comparable traffic patterns by design. During competitive matches on FACEIT, large numbers of players remain connected while scores, rankings, and in-game events update continuously. Activity intensifies around key moments, increasing message throughput while persistent connections stay open.

Across these environments, the pattern is consistent. Users connect simultaneously, interact continuously, and expect immediate feedback. When performance begins to drift, the impact is shared rather than isolated.

A Note on Architecture

This is where architectural choices begin to matter.

Platforms that manage sustained concurrency and recover predictably under pressure tend to share certain structural characteristics. In messaging environments, MongooseIM is one example of infrastructure designed around those principles.

In practical terms, that means:

• Supporting large numbers of persistent connections without central bottlenecks
• Distributing load across nodes to reduce coordination overhead
• Containing failure within defined boundaries rather than allowing it to cascade
• Maintaining message consistency even when traffic intensifies
  

These design choices do not eliminate volatility. They determine how the system behaves when it does.

In live entertainment platforms, that distinction shapes whether pressure remains internal or becomes visible to users.

Conclusion

Real-time messaging raises expectations that are easy to meet under steady conditions and far harder to sustain when attention converges.

What breaks first is rarely availability. It is timing. It is the subtle drift in delivery and consistency that users notice before any dashboard signals a failure.

Live environments make that visible because traffic arrives together and interaction compounds quickly. Concurrency is not the exception. It is the operating model. Whether the experience holds depends on how the architecture distributes load and contains failure.

Designing for that reality early makes scaling more predictable and reduces the risk of visible strain later.If you are building or modernising a platform where real-time interaction matters, assess whether your messaging architecture is prepared for sustained concurrency. Get in touch to continue the conversation.

The post What Breaks First in Real-Time Messaging? appeared first on Erlang Solutions.

Reliability is often treated as something that can be improved once a system is live. When things break, the focus shifts to monitoring, incident response, and recovery, with the belief that resilience can be strengthened over time as scale reveals weaknesses.

In reality, most of it is set much earlier.

Long before a system faces sustained demand, its underlying design has already shaped how it will respond under pressure. Choices about service boundaries, data handling, deployment models, and fault management influence whether a problem stays contained or spreads.

The conversation is gradually moving from reliability to resilience because distributed systems rarely operate without failure. The more useful question is how a platform continues running when parts of it inevitably fail. The sections that follow explore how early architectural decisions shape that outcome, why their impact becomes more visible at scale, and what it means to build resilience from the beginning rather than react to it later.

Early Decisions Create Long-Term Behaviour

Large-scale failures rarely emerge without warning. What appears sudden at scale is often the predictable outcome of structural decisions made earlier, when different commercial pressures shaped priorities. 

In the early stages of a product, the focus is understandably on delivering value quickly, reducing development friction, and validating the market. These are rational business decisions. However, architecture chosen primarily for speed can quietly define the operational ceiling of the system, setting limits that only become visible once demand increases.

Systems Behave as They Were Built to Behave

Outages are often described as “unexpected events,” but distributed systems typically respond to pressure in ways that reflect their design. How services communicate, how state is shared, where dependencies sit, and how failure is managed all influence whether disruption remains contained within a single component or spreads across the wider platform.

Research from Google’s Site Reliability Engineering work shows that around 70% of outages are caused by changes to a live system, such as configuration updates, deployments, or operational changes, rather than by hardware failures. Similarly, the Uptime Institute’s Annual Outage Analysis identifies configuration errors and dependency failures as leading causes of major disruption.

These findings are unsurprising. In distributed environments, dependencies increase and recovery paths become harder to trace, which means that architectural shortcuts that once seemed minor can have disproportionate impact under sustained load. Systems tend to fail along the structural lines already drawn into them, and those lines are shaped by early design decisions, even when those decisions were commercially sensible at the time.

Trade-offs That Compound Over Time

Architectural decisions are rarely made under ideal conditions. Early on, speed to market matters, simplicity reduces friction, and shipping is the priority. A tightly coupled service can help teams move faster, a single-region deployment keeps things straightforward, and limited observability may feel acceptable when traffic is still modest.

But overtime, these trade-offs compound.

• Limited isolation between services makes it easier for problems in one area to affect others.
• Shared infrastructure can create hidden dependencies that only become visible under heavy demand.
  Concentrated regional deployments increase the impact of a local outage or cloud disruption.
• Observability that felt sufficient at launch can fall short when trying to understand complex behaviour at scale.

At a smaller scale, these constraints can go largely unnoticed. As usage increases and demand becomes less predictable, they start to shape how the system responds under pressure. What once felt manageable begins to show its limits.

This is rarely about a lack of technical ability. It is simply what happens as complexity builds over time. Every system reflects the trade-offs made in its early stages, whether those choices were deliberate or just practical at the time.

When Architecture Becomes Business Exposure

As systems grow in scale and complexity, the way they are built starts to show up in practical ways. When services are tightly connected, recovery takes longer. When failures are not well contained, a problem in one area can disrupt others. Incidents become harder to resolve and more expensive to manage.

The cost of disruption is not abstract. ITIC’s 2023 Hourly Cost of Downtime Survey reports that more than 90% of mid-size and large enterprises estimate a single hour of downtime costs over $300,000, and roughly 41% place that figure between $1 million and $5 million per hour. At that level, even short-lived incidents carry material financial impact.

For organisations that rely on digital platforms to generate revenue, those numbers represent missed transactions, operational strain, and damage to customer trust. At that point, system design is no longer just an engineering decision. It becomes a business decision with measurable financial consequences.

When Failure Is Public

Some systems fail quietly, disrupting internal workflows or back-office processes with limited external visibility. Others operate in real time, where performance issues are experienced directly by customers, investors, and partners.

In sectors such as entertainment, demand is often synchronised and predictable. Premieres, sporting events, ticket releases, and major launches concentrate traffic into specific windows, placing simultaneous pressure on application layers, databases, and third-party services. These moments are not unusual spikes; they are built into the operating model. Platforms designed for large-scale engagement are expected to handle peak demand as part of normal business activity.

That expectation changes the stakes. When performance degrades in these environments, it is noticed immediately and often publicly. Frustration spreads quickly, confidence can shift in hours, and what might have been an operational issue becomes a visible business problem.

In this context, resilience shapes whether a high-demand event reinforces confidence in the platform or exposes its limits. When failure is experienced directly by users, it moves beyond internal metrics and becomes part of the customer experience itself.

Designing for Resilience

If failure is inevitable in distributed systems, then resilience has to be built in from the start. It cannot be something added later when the first serious incident forces the issue.

Resilient systems are structured so that problems stay contained. A fault in one component should not automatically take others down with it, and services should be able to keep operating even when parts of the system are degraded. External dependencies will fail. Traffic will spike. The design needs to account for that reality.

This way of thinking shifts the focus. Instead of trying to prevent every possible issue, teams concentrate on limiting the impact when something goes wrong. Speed still matters, but so does the ability to grow without introducing instability.

Technology choices can support that approach. Elixir programming language, running on the BEAM, was designed for environments where downtime had real consequences. Its structure reflects that:

• Applications are made up of many small, independent processes rather than large, tightly connected components.
• Failures are expected and handled locally.
• Supervision and recovery are built into the runtime so the wider system keeps running.

No language guarantees reliability, but tools built around fault tolerance make it easier to create systems that continue operating under pressure.

To conclude

By the time serious issues appear at scale, most of the important decisions have already been made.

Failure is part of running distributed systems. What matters is whether problems stay contained and whether the platform keeps operating when something goes wrong.

Thinking about resilience early makes growth easier later. It helps protect revenue, maintain trust, and avoid the instability that forces costly redesigns.If you are building distributed platforms where reliability directly affects performance and reputation, now is the time to treat resilience as a core design decision. Get in touch to discuss how to build it into your architecture from the start.

The post Reliability is a Product Decision 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 February 2026.

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 logo in Font Awesome

Just as we announced back in our Newsletter December 2025 issue, the official XMPP logo now comes bundled up in Font Awesome since version 7.2.0. And it looks Awesome!

XMPP Events

• XMPP material for DI.DAY: Four recipes to use an open chat protocol at the ‘Digital Independence Day’, the German (DI.DAY) initiative, from the XMPP community to enable people to start with independent messaging!

Four recipes for an open chat protocol at the Digital Independence Day!

• XMPP Sprint in Berlin (DE / EN): will take place from June Friday 19th to Sunday 21st 2026, at the Wikimedia Deutschland e.V. offices in Berlin, Germany. If this sounds like the right event for you, come and join us! Just make sure to list yourself here, so we know how many people will attend and we can plan accordingly. If you have any questions or concerns, join us at the chatroom: sprints@muc.xmpp.org!

Videos and Talks

• Discord Was Never the End Game by tony-btw.
• [PT-BR] XMPP #engineeringsessions #S06E16. [PT-BR]

XMPP Articles

• Upcoming changes to Let’s Encrypt and how they affect operators, by the The Prosody Team for Prosodical Thoughts.
• Apprise, Push Notifications that work with just about every platform, restored its XMPP support using Slixmpp, (after >4 years). ATM no stable release, but it’s coming …
• Bye bye Discord, hello Movim!, by Timothée Jaussoin for the Movim Blog.
• A (big) memory incoming memory optimization in Movim, by Timothée Jaussoin for the Movim Blog.
• Help Movim Reach Its Goals for 2026 by Timothée Jaussoin for the Movim Blog.
• Great Invitations, a tutorial that outlines how to create invites for the most popular clients according to XEP-0401 (Ad-hoc Account Invitation Generation), from the tutorials section at joinjabber.org.
• Visite nossa cozinha, by Isadora for the isacloud.im blog. [PT_BR]
• About Snikket and Prosody IM: relationship & goals in the XMPP ecosystem, by MattJ on Hacker News.
• Running My Own XMPP Server, by danny for the dmcc blog.
• MembeBot: ohhh I member: ¿Listo para implementar tu propio sistema de notificaciones de eventos en calendario sin depender de gigantes tecnológicos? by TheCoffeMaker for Cyberdelia. [ES]
• Introducing Wimsy: A cross-platform XMPP client built with Flutter.

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.19.10, 2.19.11 and 2.19.12 for Android. This version introduces a refactored QR code scanning and URI handling, a fix for rotation issues in tablet mode and also offers to delete messages when banning someone in a public channel among other things. You can take a look at the changelog for all the details.
• Fluux Messenger, a modern, cross-platform XMPP client for communities and organizations, versions 0.11.3, 0.12.0, 0.12.1, 0.13.0, 0.13.1 and 0.13.2 have been released, with a list of additions, new features, improvements and bugfixes that is way longer than what we could ever mention in here! Go straight for the changelog for all the details!

Fluux Messenger main window and XMPP console

• Gajim has released version 2.4.4 of its free and fully featured chat app for XMPP. This release comes with link previews, many improvements for macOS, and bugfixes. Thank you for all your contributions! You can take a look at the changelog for all the details.

Link previews in Gajim 2.4.4

• Monal has released versions 6.4.18 for iOS and macOS.
• Monocles has released versions 2.1.2 and 2.1.3 of its chat client for Android. The former release brings fixes for message retraction, images sent as link and infinite recursion in TagEditorView, adds support for links in posts, disables publish button after click to prevent double posts, refactored message correction UI and a change in the social feed pubsub access model. The latest, adds pause and resume story on delete dialog, fixes for progress bar handling and contact lookup for stories and brings fixes from Conversations, plus updated translations.
• Profanity has released version 0.16.0 of its console based XMPP client written in C. This release brings fixes for OTR detection, OMEMO startup, overwriting new accounts when running multiple instances, reconnect when no account has been set up yet, adds a new /changes command that allows the user to compare the modifications of the runtime configuration and the saved configuration among many other fixes and improvements. Make sure to read the changelog for all the details!
• xmpp-web has released version 0.11.0 of its lightweight web chat client for XMPP server.

XMPP-Web main window

XMPP Servers

• ProcessOne is pleased to announce the bugfix release of ejabberd 26.02. Make sure to read the changelog for all the details and a complete list of fixes and improvements on this release.

XMPP Libraries & Tools

• python-nbxmpp, a Python library that provides a way for Python applications to use the XMPP network, version 7.1.0 has been released. Full details on the changelog.
• QXmpp, the cross-platform C++ XMPP client and server library, versions 1.13.1, 1.14.1, 1.14.2 and 1.14.3 have been released. Full details on the changelog.
• Siltamesh, a simple bridge between Meshtastic and XMPP networks, version 0.2.0 has been released.
• Slidge versions 0.3.7 has been released. You can check the intermediate changelog from 0.3.6 to 0.3.7 for all the details.
• Slixmpp, the MIT licensed XMPP library for Python 3.7+ versions 1.13.0 and 1.13.2 have been released. You can read their respective official release announcements here and here for all the details.
• xmpppy, a Python library that is targeted to provide easy scripting with Jabber, version 0.7.3 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.

• Link Metadata
  • This specification describes how to attach metadata for links to a message.

New

• Version 0.1.0 of XEP-0510 (End-to-End Encrypted Contacts Metadata)
  • Accepted as Experimental by council vote (dg)
• Version 0.1.0 of XEP-0511 (Link Metadata)
  • 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.26.0 of XEP-0001 (XMPP Extension Protocols)
  • Surface (and correct) the source control information.
  • Surface the publication URL (although I assume anyone reading this has figured that one out by now).
  • Surface the contributor side of things.
  • Add bit about XEP authors making PRs if they don’t exist - this is “new” rather than documenting existing practice.
  • Add bit about PRs getting XEP author approval (existing practice hithertofore undocumented).
  • Add bit about Council (etc) adding authors if they drop off (existing practice hithertofore undocumented).
  • Add note to clarify that Retraction doesn’t mean Deletion (existing practice, documented, but has been misunderstood before). (dwd)
• Version 1.1.0 of XEP-0143 (Guidelines for Authors of XMPP Extension Protocols)
  • Reflect preference for GitHub pull requests for initial submission,
  • PRs to contain only one changed XEP. (dwd)
• Version 0.8.0 of XEP-0353 (Jingle Message Initiation)
  • Adapt usage of JID types to real-world usage:
    • Send JMI responses to full JID of initiator instead of bare JID
    • Send JMI <finish/> element to full JID of both parties (melvo)

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 XEPs last calls this month.

Stable

• No stable XEPs this month.

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, Ludovic Bocquet, sokai, XSF iTeam

• Translations:

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

Banner della newsletter XMPP

Benvenuti nella newsletter XMPP, è un piacere avervi di nuovo qui! Questo numero copre il mese di febbraio 2026.

La Newsletter XMPP è offerta dal Team di comunicazione XSF.

Proprio come qualsiasi altro prodotto o progetto dell’XSF, la Newsletter è il risultato del lavoro volontario dei suoi membri e collaboratori. Se siete soddisfatti dei servizi e dei software che utilizzate, vi invitiamo a ringraziare o aiutare questi progetti!

Ti interessa contribuire al Team di comunicazione XSF? Per saperne di più, leggi in fondo alla pagina.

Annunci XSF

Logo XMPP in Font Awesome

Come annunciato nella nostra Newsletter di dicembre 2025, il logo ufficiale XMPP è ora incluso in Font Awesome dalla versione 7.2.0. Ed è fantastico!

Eventi XMPP

• Materiale XMPP per DI.DAY: quattro ricette per utilizzare un protocollo di chat aperto al “Digital Independence Day”, l’iniziativa tedesca (DI.DAY) della comunità XMPP per consentire alle persone di iniziare a utilizzare la messaggistica indipendente!

Quattro ricette per un protocollo di chat aperto al Digital Independence Day!

• XMPP Sprint a Berlino (DE / EN): si terrà da venerdì 19 a domenica 21 giugno 2026, presso gli uffici di Wikimedia Deutschland e.V. a Berlino, Germania. Se pensi che questo sia l’evento giusto per te, vieni a trovarci! Assicurati solo di registrarti qui, così sapremo quante persone parteciperanno e potremo organizzarci di conseguenza. Se hai domande o dubbi, unisciti a noi nella chatroom: sprints@muc.xmpp.org!

Video e conferenze

• Discord Was Never the End Game di tony-btw.
• [PT-BR] XMPP #engineeringsessions #S06E16. [PT-BR]

Articoli XMPP

• Prossimi cambiamenti a Let’s Encrypt e come influenzano gli operatori, dal team Prosody per Prosodical Thoughts.
• Apprise, notifiche push compatibili con quasi tutte le piattaforme, ripristinato il supporto XMPP utilizzando Slixmpp, (dopo >4 anni). Al momento non esiste una versione stabile, ma è in arrivo…
• Addio Discord, benvenuto Movim!, di Timothée Jaussoin per il Movim Blog .
• Una (grande) ottimizzazione della memoria in arrivo in Movim, di Timothée Jaussoin per il Movim Blog.
• Aiuta Movim a raggiungere i suoi obiettivi per il 2026 di Timothée Jaussoin per il Movim Blog.
• Ottimi inviti, un tutorial che illustra come creare inviti per i client più popolari secondo XEP-0401 (Ad-hoc Account Invitation Generation), dalla sezione tutorials su joinjabber.org.
• Visite nossa cozinha, di Isadora per il blog isacloud.im. [PT_BR]
• Informazioni su Snikket e Prosody IM: relazione e obiettivi nell’ecosistema XMPP, di MattJ su Hacker News.
• Gestire il proprio server XMPP, di danny per il blog dmcc.
• MembeBot: ohhh I member: ¿Listo para implementar tu propio sistema de notificaciones de eventos en calendario sin depender de gigantes tecnológicos? di TheCoffeMaker per Cyberdelia. [ES]
• Presentazione di Wimsy: un client XMPP multipiattaforma realizzato con Flutter.

Notizie sul software XMPP

Client e applicazioni XMPP

• Conversations ha rilasciato le versioni 2.19.10 , 2.19.11 e 2.19.12 per Android. Questa versione introduce una scansione dei codici QR e una gestione degli URI rifattorizzate, una correzione per i problemi di rotazione in modalità tablet e offre anche la possibilità di eliminare i messaggi quando si banna qualcuno in un canale pubblico, tra le altre cose. È possibile consultare il changelog per tutti i dettagli.
• Fluux Messenger, un client XMPP moderno e multipiattaforma per comunità e organizzazioni, versioni 0.11.3, 0.12.0, 0.12.1 , 0.13.0, 0.13.1 e 0.13.2 sono state rilasciate con una lista di aggiunte, nuove funzionalità, miglioramenti e correzioni di bug che è molto più lunga di quanto potremmo mai menzionare qui! Vai direttamente al changelog per tutti i dettagli!

Finestra principale di Fluux Messenger e console XMPP

• Gajim ha rilasciato la versione 2.4.4 della sua app di chat gratuita e completa per XMPP. Questa versione include anteprime dei link, molti miglioramenti per macOS e correzioni di bug. Grazie a tutti per i vostri contributi! Potete consultare il changelog per tutti i dettagli.

Anteprime dei link in Gajim 2.4.4

• Monal ha rilasciato le versioni 6.4.18 per iOS e macOS.
• Monocles ha rilasciato le versioni 2.1.2 e 2.1.3 del suo client di chat per Android. La prima versione apporta correzioni per la revoca dei messaggi, le immagini inviate come link e la ricorsione infinita in TagEditorView, aggiunge il supporto per i link nei post, disabilita il pulsante di pubblicazione dopo il clic per impedire la doppia pubblicazione, rifattorizza l’interfaccia utente per la correzione dei messaggi e modifica il modello di accesso pubsub al feed social. L’ultima versione aggiunge la possibilità di mettere in pausa e riprendere la storia nella finestra di dialogo di eliminazione, corregge la gestione della barra di avanzamento e la ricerca dei contatti per le storie e apporta correzioni da Conversations, oltre a traduzioni aggiornate.
• Profanity ha rilasciato la versione 0.16.0 del suo client XMPP basato su console scritto in C. Questa versione apporta correzioni per il rilevamento OTR, l’avvio di OMEMO, la sovrascrittura di nuovi account durante l’esecuzione di più istanze, la riconnessione quando non è stato ancora configurato alcun account, aggiunge un nuovo comando /changes che consente all’utente di confrontare le modifiche della configurazione di runtime e della configurazione salvata, oltre a molte altre correzioni e miglioramenti. Assicuratevi di leggere il changelog per tutti i dettagli!
• xmpp-web ha rilasciato la versione 0.11.0 del suo client di chat web leggero per server XMPP.

Finestra principale di XMPP-Web

Server XMPP

• ProcessOne è lieta di annunciare il rilascio della versione bugfix di ejabberd 26.02. Assicuratevi di leggere il changelog per tutti i dettagli e un elenco completo delle correzioni e dei miglioramenti apportati in questa versione.

Librerie e strumenti XMPP

• python-nbxmpp, una libreria Python che fornisce alle applicazioni Python un modo per utilizzare la rete XMPP, è stata rilasciata la versione 7.1.0. Tutti i dettagli sono disponibili nel changelog.
• QXmpp, la libreria client e server XMPP multipiattaforma in C++, versioni 1.13.1 , 1.14.1, 1.14.2 e 1.14.3. Tutti i dettagli sono disponibili nel changelog.
• Siltamesh, un semplice ponte tra Meshtastic e le reti XMPP, versione 0.2.0 è stato rilasciato.
• Slidge versioni 0.3.7. È possibile consultare il changelog intermedio da 0.3.6 a 0.3.7 per tutti i dettagli.
• Slixmpp, la libreria XMPP con licenza MIT per Python 3.7+ versioni 1.13.0 e 1.13.2 sono state rilasciate. È possibile leggere i rispettivi annunci ufficiali di rilascio qui e qui per tutti i dettagli.
• xmpppy, una libreria Python pensata per facilitare lo scripting con Jabber, versione 0.7.3 è stata rilasciata. Tutti i dettagli sono disponibili nel changelog.

Estensioni e specifiche

La XMPP Standards Foundation sviluppa estensioni a XMPP nella sua serie XEP oltre alle XMPP RFC. Sviluppatori ed altri esperti di standard provenienti da tutto il mondo collaborano a queste estensioni, sviluppando nuove specifiche per pratiche emergenti e perfezionando i metodi esistenti. Proposte da chiunque, quelle di particolare successo finiscono per diventare definitive o attive, a seconda del loro tipo, mentre altre vengono accuratamente archiviate come differite. Questo ciclo di vita è descritto in XEP-0001, che contiene le definizioni formali e canoniche dei tipi, degli stati e dei processi. Maggiori informazioni sul processo di standardizzazione. La comunicazione relativa agli standard e alle estensioni avviene nella mailing list degli standard (archivio online).

Proposta

Il processo di sviluppo XEP inizia con la stesura di un’idea e la sua presentazione all’XMPP Editor. Entro due settimane, il Consiglio decide se accettare questa proposta come XEP sperimentale.

• Metadati dei link
• Questa specifica descrive come allegare metadati ai link in un messaggio.

Novità

• Versione 0.1.0 di XEP-0510 (Metadati dei contatti crittografati end-to-end)
• Accettato come sperimentale con voto del consiglio (dg)
• Versione 0.1.0 di XEP-0511 (Metadati dei link)
• Accettata come sperimentale con voto del consiglio (dg)

Rinviata

Se una XEP sperimentale non viene aggiornata per più di dodici mesi, verrà spostata da Sperimentale a Rinviata. Se ci sarà un altro aggiornamento, la XEP tornerà a essere Sperimentale.

• Nessuna XEP rinviata questo mese.

Aggiornato

• Versione 1.26.0 di XEP-0001 (Protocolli di estensione XMPP)

• Mostrare (e correggere) le informazioni sul controllo del codice sorgente.

• Mostrare l’URL di pubblicazione (anche se presumo che chiunque legga questo documento lo abbia già capito).

• Mostrare il lato dei contributori.

• Aggiungere un riferimento agli autori XEP che fanno PR se non esistono - questa è una “novità” piuttosto che una documentazione di una pratica esistente.

• Aggiungere un riferimento alle PR che ottengono l’approvazione dell’autore XEP (pratica esistente finora non documentata).

• Aggiungere un riferimento al Consiglio (ecc.) che aggiunge autori se questi abbandonano (pratica esistente finora non documentata).

• Aggiungere una nota per chiarire che la ritrattazione non significa cancellazione (pratica esistente, documentata, ma che in passato è stata fraintesa). (dwd)

• Versione 1.1.0 di XEP-0143 (Linee guida per gli autori dei protocolli di estensione XMPP)

• Riflettere la preferenza per le richieste pull GitHub per l’invio iniziale,

• Le PR devono contenere solo un XEP modificato. (dwd)

• Versione 0.8.0 di XEP-0353 (Avvio di messaggi Jingle)

• Adattare l’uso dei tipi JID all’uso nel mondo reale:

• Inviare le risposte JMI al JID completo dell’iniziatore invece che al JID nudo

• Inviare l’elemento JMI <finish/> al JID completo di entrambe le parti (melvo)

Ultima chiamata

Le ultime chiamate vengono emesse quando tutti sembrano soddisfatti dello stato attuale dello XEP. Dopo che il Consiglio ha deciso se lo XEP sembra pronto, l’XMPP Editor emette un’ultima chiamata per i commenti. Il feedback raccolto durante l’ultima chiamata può aiutare a migliorare lo XEP prima di restituirlo al Consiglio per il passaggio allo stato Stabile.

• Nessun ultimo appello XEP questo mese.

Stabile

• Nessun XEP stabile questo mese.

Obsoleto

• Nessun XEP obsoleto questo mese.

Rifiutato

• Nessun XEP rifiutato questo mese.

Diffondi la notizia

Condividi la notizia su altri social network:

• Mastodon
• Movim
• Bluesky
• LinkedIn
• YouTube
• Istanza Lemmy (non ufficiale)
• Reddit (non ufficiale)
• Pagina Facebook XMPP (non ufficiale)

Dai un’occhiata anche al nostro feed RSS!

Cerchi offerte di lavoro o vuoi assumere un consulente professionista per il tuo progetto XMPP? Visita la nostra bacheca dei lavori XMPP.

Collaboratori e traduttori della newsletter

Questo è un progetto comunitario e desideriamo ringraziare i traduttori per il loro contributo. Volontari e altre lingue sono i benvenuti! Le traduzioni della newsletter XMPP saranno pubblicate qui (con un certo ritardo):

• Collaboratori:

• A questo numero: emus, cal0pteryx, Gonzalo Raúl Nemmi, Ludovic Bocquet, sokai, XSF iTeam

• Traduzioni:

• Francese: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau

• Italiano: Mario Sabatino, Roberto Resoli

• Portoghese: Paulo

Aiutaci a creare la newsletter

Questa newsletter XMPP è prodotta in collaborazione dalla comunità XMPP. Ogni mese la newsletter viene redatta in questo simple pad. Alla fine di ogni mese, il contenuto del pad viene inserito nel repository GitHub XSF. Siamo sempre lieti di accogliere nuovi collaboratori. Non esitate a partecipare alla discussione nella nostra chat di gruppo Comm-Team (MUC) e ad aiutarci così a sostenere questo progetto come sforzo comunitario. Avete un progetto e volete diffondere la notizia? Considerate la possibilità di condividere qui le vostre notizie o i vostri eventi e promuoveteli a un vasto pubblico.

Attività che svolgiamo regolarmente:

• raccolta di notizie nell’universo XMPP
• brevi sintesi di notizie ed eventi
• sintesi della comunicazione mensile sulle estensioni (XEP)
• revisione della bozza della newsletter
• preparazione di immagini multimediali
• traduzioni
• comunicazione tramite account multimediali

Annullare l’iscrizione alla newsletter XMPP

Per questa newsletter, accedi qui e cancella l’iscrizione o invia semplicemente un’e-mail a newsletter-leave@xmpp.org. (Se non hai effettuato l’accesso in precedenza, potrebbe essere necessario creare un account con l’indirizzo e-mail appropriato).

Licenza

Questa newsletter è pubblicata con licenza CC BY-SA.

We&aposre excited to announce Fluux Messenger 0.13.0, featuring native TCP connections, complete European language coverage, and significant performance improvements.

Also, we recently passed the first 100 stars on GitHub. Thank you for your support and for believing in open, sovereign messaging !

What&aposs New

Native TCP Connection Support on Desktop

Desktop users can now connect directly to XMPP servers via native TCP through our WebSocket proxy implementation. This means lower latency, better reliability, and native protocol handling. No more browser limitations.

We believe that&aposs a nice milestone worth a blog post. Until now, desktop users needed their XMPP server to support WebSocket connections. With v0.13.0, you can connect to any standard XMPP server. We estimate this will enable 80% of users who couldn&apost connect before to finally use Fluux Messenger with their existing servers.

Complete European Union Language Coverage

Fluux Messenger now supports all 26 EU languages, making it truly pan-European. From Bulgarian to Swedish, Croatian to Maltese, we&aposve got you covered. Languages include:

• Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Icelandic, Irish, Italian, Latvian, Lithuanian, Maltese, Norwegian, Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish.

Dynamic locale loading means faster initial startup while maintaining comprehensive language support.

If you spot any translation issues, feel free to contribute on our GitHub repository.

Clipboard Image Paste

Paste images directly from your clipboard with Cmd+V (macOS) or Ctrl+V (Windows/Linux). Copy from anywhere, paste into Fluux. It (should) just work ;). Tested and confirmed with Safari&aposs "Copy Image" feature and system clipboard operations so far.

Clear Local Data on Logout

New privacy option to completely clear local data when logging out. Perfect for shared devices or when you need a fresh start.

Performance & Reliability Improvements

• Smarter Message History Loading - We&aposve completely redesigned our Message Archive Management (MAM) strategy. Message history now loads intelligently based on your scrolling behavior and available data, reducing unnecessary server requests.

• Better Resource Management - Fixed duplicate avatar fetches when hashes haven&apost changed, reducing bandwidth usage and improving profile picture loading times.

• Rock-Solid Scroll Behavior - Media loading no longer disrupts your scroll position. The scroll-to-bottom feature now works reliably, even when images and files are loading.

• Better Windows Tray - Improved tray behavior on Windows for a more native experience.

macOS Sleep Recovery - Fixed layout corruption that could occur after your Mac woke from sleep.

UI & UX Polish

• Consistent attachment styling across light and dark themes
• Fixed sidebar switching with Cmd+U keyboard shortcut
• Improved new message markers - position correctly maintained when switching conversations
• Better context menus - always stay within viewport bounds, no more cut-off menus
• Markdown preview accuracy - bold and strikethrough now properly shown in message previews

Linux Packaging

Improved Linux packaging using native distribution tools for better integration with your system package manager.

Developer Experience

Centralized notification state with viewport observer provides better performance and more reliable notification handling across the application.

---

Get Fluux Messenger

Download for Windows, macOS, or Linux in the latest Release page.

Source code is available at: GitHub

---

Your messages, your infrastructure : no vendor lock-in.
Sovereign by design. Built in Europe, for everyone.

Contents:

• ChangeLog
• Acknowledgments
• Improvements in ejabberd Business Edition
• ejabberd 26.02 download & feedback

ChangeLog

• Fixes issue with adding hats data in presences send by group chats (#4516)
• Removes mod_muc_occupantid modules, and integrates its functionality directly into mod_muc (#4521)
• Fixes issue with reset occupant-id values after restart of ejabberd (#4521)
• Improves handling of mediated group chat invitations in mod_block_stranger (#4523)
• Properly install mod_invites templates in make install call (#4514)
• Better errors in mod_invites (#4515)
• Accessibility improvements in mod_invites (#4524)
• Improves handling of request with invalid url encoded values in request handled by ejabberd_http
• Improves handling of invalid responses to disco queries in mod_pubsub_serverinfo
• Fixes conversion of MUC room configs from ejabberd older than 21.12
• Fixes to autologin in WebAdmin

If you are upgrading from a previous version, there are no changes in SQL schemas, configuration, API commands or hooks.

Notice that mod_muc now incorporates the feature from mod_muc_occupantid, and that module has been removed. You can remove mod_muc_occupantid in your configuration file as it is unnecessary now, and ejabberd simply ignores it.

Check also the commit log: https://github.com/processone/ejabberd/compare/26.01...26.02

Acknowledgments

We would like to thank the contributions to the source code and translations provided by:

• Stefan Strigler for the improvements in mod_invites
• Mr. EddX for updating the Bulgarian translation
• Sketch6580 for updating the Chinese (Simplified) translation
• ffunk for updating the Czech translation
• Stefan Strigler for updating the German translation

And also to all the people contributing in the ejabberd chatroom, issue tracker...

Improvements in ejabberd Business Edition

Customers of the ejabberd Business Edition, in addition to all those improvements and bugfixes, also get the following change:

• Change default_ram_db from mnesia to p1db when using p1db cluster_backend

ejabberd 26.02 download & feedback

As usual, the release is tagged in the Git source code repository on GitHub.

The source package and installers are available in ejabberd Downloads page. To check the *.asc signature files, see How to verify ProcessOne downloads integrity.

For convenience, there are alternative download locations like the ejabberd DEB/RPM Packages Repository and the GitHub Release / Tags.

The ecs container image is available in docker.io/ejabberd/ecs and ghcr.io/processone/ecs. The alternative ejabberd container image is available in ghcr.io/processone/ejabberd.

If you consider that you&aposve found a bug, please search or fill a bug report on GitHub Issues.

Version 1.13.0 has shipped with a packaging bug that affects people trying to build wheels using setuptools. 1.13.1 is an attempt to fix that (made packaging from git work somehow), and 1.13.2 is the correct fix thanks to one single additional character.

There are no other changes, and pypi wheels are not affected because they are built in CI with uv.

Last month a friend invited me to trade songs with him DJing at an Atlanta Lindy Hop social dance. This was my first time DJing for a social dance other than Contra, and I was surprised by what a different experience it was. To that end, this post will be a mix of post-mortem as I’ve done for contra dances, but also a reflection on the differences between DJing for called and non-called social dances.

Prep

Preparation was the first, and perhaps most obvious, place where the two types of DJing vastly differed.

Preparing for Contra requires hours of sorting new tracks, creating mixes, adding hot cues, fixing beat grids, and analyzing song structure. Once the tracks are all analyzed and annotated, I can then create a playlist of mixes and start practicing them.

For Lindy, on the other hand, I can sit down and prepare a basic set in a few hours right before the dance. Sorting any new tracks still needs to be done, but otherwise I mostly don’t have to do any work other than possibly adding a cue point to let me know where to start a track on the rare version where the beginning doesn’t work (ie. live recordings with lots of chatter or applause before and after), and even that isn’t really necessary.

For Contra I normally make a play list with all my mixes in an order that I think will work well, then shuffle that around on the day of the event depending on the dance picked by the caller. For Lindy I chose to make a crate (which differs from a playlist in that there can’t be duplicate tracks and there is no order to the tracks) instead, pull in about 50 tracks (far more than I’d need, especially when trading songs with another DJ) and largely pull from those just to make selection quicker, while still dipping into the rest of my library on occasion when nothing I’d pre-selected fits the current vibe.

Nerves

When a dancer asks if I get nervous before DJing for contra I confidently say “no”. Not out of some toxic sense of bravado or machismo (I hope), or because I think I’m particularly good at it and don’t need to worry (I’m not, and I do), but because I know I’m going to make mistakes and I’m okay with that.

Instead of being nervous I tend to go into problem solving mode:

• “How did I get the dancers 8 beats off the phrase?”
• “Can I jump back to an earlier point in the song to give us more time without it sounding bad?”
• “I haven’t practiced this mix enough, focus on the cue out point coming up.”
• etc.

This apparently isn’t the case when I DJ Lindy. The first time, I was immediately a nervous wreck. This is likely particular to me, of course, but it was still an interesting difference that I wasn’t expecting given how much more technically difficult Contra DJing is. I knew intellectually that the technical side of doing a mix (ie. beat matching, harmonic mixing, transitioning between tunes, etc.) isn’t the important part of DJing, the finesse of picking tracks that the crowd will like is what matters. A DJ who just plays a few contra songs, but chooses them well is a much better crowd pleaser than one who does impressive mixing but picks bad songs. However, when it came right down to it I was still surprised by how much more nerve wracking it was when that’s the only thing you’re being judged on.

At some point I remembered that it’s just a dance and if one of them is bad or doesn’t work, we’ll move on and play another song. If I can’t find something, playing something at random is fine too (not ideal, but fine). Once I accepted this I almost immediately started picking songs quicker and not having to rely on picking something random at the last minute after all. It’s much easier to focus on what will be good when you’re not worried about whether it will be perfect. After that we were able to cover for each other and play off each other, and it made the evening much more enjoyable. If one of us killed the floor, the other would try a different style and bring it back. Doug covered for me, and I was even able to cover for Doug once or twice and revive a somewhat empty floor! None of this is something I’d have to deal with in Contra where my mixes are pre-selected, practiced, and where I’m picking from a much smaller selection of tunes.

Playing to the Dancers

While Lindy may not require the technical skills used when mixing tunes in the same way that Contra does, the dancers also aren’t pre-lined-up as they would be with a Contra or Square dance. If you play a tune no one likes at Contra most everyone is stuck with it for 7 minutes or so until the caller wraps up the dance. The dance may fall a part entirely if the tune is too fast or doesn’t have clear enough phrasing for the dancers or caller to follow along, but generally speaking as long as the track sort of works the dancers will dance to it—and they’ll probably enjoy themselves. There are also fewer dances in an evening, so I suspect dancers feel more compelled to dance every single dance.

With Lindy that’s not the case. Many dancers will wait to hear if your track selection is one that they like before venturing out onto the dance floor, and even those that aren’t deliberately checking the music may not be as inclined to break off their conversations with a friend to go ask someone to dance if the track doesn’t immediately catch their interest.

There is also a several minute break between each tune in a contra dance where the caller teaches the next pre-choreographed dance. This means that if two back-to-back mixes have nothing to do with each other, or sound completely different, no one notices as long as you’ve picked a mix that goes well with the dance. Whereas with Lindy only a few seconds elapse between songs, just enough time for someone to thank their partner and go ask the next person to dance. This means that you have to consider the previous track when selecting the next one: a leap from fast balboa to slow blues is going to be jarring for the dancers and they may choose not to dance. Changing the style requires either gradually shifting between the two over several tracks, or maybe giving a slightly longer pause between songs to let the dancers get the previous style out of their ears and bodies.

Similarly there is a big difference in what music really gets the dancers blood pumping, though I suspect this is specific to these two venues and not to the type of social dancing as a whole.

With the contra venue I DJ for it’s mostly a younger crowd and they’re mostly used to hearing a hand full of local old-time string bands and the occasional high energy (but still traditional) New England style dance band. The contra chestnuts are an important part of the dances history, and sometimes you play them, but they don’t get many people excited.

This means that I can do two things if the energy is feeling low: I can play a track by a band they normally wouldn’t be able to hear that’s a bit more modern sounding, or otherwise has something different and interesting about it, or I can mix in a pop tune they’re familiar with. This is almost like a cheat code: if the energy is low, play a song they know and they’ll get excited and raise the energy of the floor.

With Lindy it’s not quite as simple as that. The reliable floor savers for Lindy are mostly old chestnuts by some of the jazz greats. Modern swing is sometimes played, but sparingly, and pop songs are a definite “no”. People come to the dance expecting a certain style, and they’re unhappy if you don’t stick to it. You have to work within the constraints of the genre, and picking floor savers is much more subtle work that requires carefully watching the dancers and seeing what will make them take to the dance floor on any particular night.

The act of watching the floor and adjusting the set as necessary may be obvious to club DJs and other social dance DJs, but to me it was a new experience, and one that I initially found somewhat paralyzing. For the first few tracks, my friend Doug had to cover for me and play as if he were the solo DJ while I flailed trying to find a track that I thought would work. I hadn’t fully internalized until that moment that in a Contra dance the DJ is picking the music to match the dance, but in Lindy Hop the dancers are picking the dance to match the music, and this may include not dancing entirely! I let the perfect become the enemy of the good and Doug had to pick several tracks in a row even though in theory we were trading songs 1 for 1.

Genre and Form

Sometime after the half I had mostly gotten over my nerves, and most of the newbies had drifted off home. I felt more comfortable trying a few experimental tracks that targeted primarily the more experienced late-night crowd: one a fast blues dance recorded at a legendary local Blues club, and the other two folksy tracks by bands that mostly play contra dances.

I was a bit nervous about these tracks as I didn’t know how they’d be received at this particular dance where the DJs play almost exclusively 30s and 40s jazz and the most modern bands that get any air time tend to be emulating the style of the jazz greats. Luckily they all went over well and filled the dance floor! A few people switched to blues dancing for “Sweet Betty”, while others continued with Lindy. Even better, for “Rhinoceros for Sue” the head DJ for the organization (who schedules everyone else, and therefore was the person to try and impress during the evening) went out on the floor to do some Balboa and came over afterwards and asked me what the track was!

I mention this because this is both a similarity and a difference from Contra. Techno-contra¹ excluded, I largely can’t play anything for a contra dance that’s not in strict 32-bar “AABB” form. I can layer a modern beat or a pop song over a traditional contra tune, or maybe even find pop tunes that more or less stick to contra form and play it alone, but the form has to be there for the dancers (and some callers) to be comfortable.

With Lindy the freedom to play tracks with a wider variety of forms, so long as they respect the history of the dance, was a nice change of pace. That said, mostly it still needs to have a swung beat and I’m more at the mercy of what the dancers like (which is a narrower subset of music in the Lindy scene in my experience, as previously mentioned), so maybe this is more of a similarity than a difference.

Conclusion

Like learning to dance both lead and follow roles (in Lindy), or from either side of the minor set (in Contra): having done two different forms of DJing will, I suspect, make me a better DJ for either type of dance. I really enjoyed DJing for Lindy and was delighted when the head DJ asked if I’d like to start doing it regularly, hopefully I’ll be able to do it more often going forward!

If you’re curious about the set Doug and I ended up playing, the final set list for the evening can be found on Musicbrainz.

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of January 2026.

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

Call for XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before February 15th, 2026, 00:00 UTC. Being a member signals a commitment to open standards and professional engagement in / with the XMPP community. Here, your membership helps position the XSF as a healthy organization, which in itself is valuable. It also grants voting rights on technical and administrative matters within the XSF. The application is a light-weight and free of cost process and you can use membership to get more involved more easily, too.

XMPP Summit 28

The XSF held its 28th XMPP Summit during January 29th and 30th 2026 in Brussels (Belgium, Europe). During this two-day gathering, we discussed XMPP protocol development topics and kept making progress on current issues within the protocol and ecosystem. We would like to thank everyone that took part in the Summit for their continuous commitment and contribution to the XSF and all the XMPP related projects!

The XSF would like to extend a special thank you to those who made this XMPP Summit possible:

• Edward Maurer from the XSF Communication Team as well as Daniel Gultsch and Guus der Kinderen from the XSF Summits, Conferences, and Meetups Team for their time, resources, strong commitment, thorough contribution and attention to detail in the organization and moderation of the event.
• Ralph Meijer, Dan Caseley and Edwin Mons for their time and dedicated work on streaming the Summit.
• Ralph Meijer for organising the XSF dinner and Alexander Gnauck’s noted sponsor contribution.
• Additional thanks to mathieui, Rémi and other unknown people helping to keep track of the notes during the event.

Welcome to the 28th XMPP Summit!

A summary of the main topics discussed is planned to be published soon at xmpp.org.

XMPP at FOSDEM 2026

During January 31st and February 1st, the XSF was present at FOSDEM 26 in Brussels, Belgium. The XMPP community took part in the Realtime Lounge, a room located in Level 1, AW building, together with the Prosody IM and the Snikket projects, where several open source projects around the Decentralised Communication Devroom can present themselves.

We are pleased to say that there was a lot of interaction at the XMPP booth! A rather large number of FOSDEM visitors had the opportunity to come say “Hi!”, meet, interact, talk and have interesting conversations with many of the developers of the most popular clients, servers, tools and libraries that power the whole XMPP ecosystem and bring it to life.

In addition to the activities that took place on the XMPP booth, Daniel Gultsch and S1m, Jérôme Sautret, Timothée Jaussoin, and Özcan Oğuz hosted four different XMPP related presentations from the Decentralised Communication Developer Room and the FOSS on Mobile track.

You can watch the presentations from the following list of links:

• UnifiedPush - Push notifications. Decentralized and Open Source by Daniel Gultsch and S1m at FOSDEM 2026
• Engineering XMPP Federation: Building Messaging, Voice & Social Features Across Independent Projects by Jérôme Sautret and Timothée Jaussoin at FOSDEM 2026
• Movim: Building a Decentralized Social Network on XMPP by Timothée Jaussoin at FOSDEM 2026
• What are you listening to now?: Implementing “Now Playing” feature in modern XMPP by Özcan Oğuz at FOSDEM 2026

And, of course .. we had plenty of leaflets, informational material, and as always: the coolest stickers! ;)

We found Wally. Now, can you find the XMPP booth in the picture?

XSF Bluesky account is verified now (New handle!)

The XSF Bluesky account is verified now. This means that the profile handle is different now (@xmpp.org) You can find the profile with its new handle via https://bsky.app/profile/xmpp.org. Many thanks to cal0pteryx from the XSF Communication Team as well as singpolyma and Zash from Infrastructure Team.

Events

XMPP listed as Alternative Chat at DI.DAY Initiative

The German initiative ‘Digital Independence Day’ (DI.DAY) has been kicked off this year to enable users to migrate to open-source software alternatives in various contexts. Besides other services, XMPP is listed as an alternative chat option and XMPP Community members have created so-called switch recipes: Digital Independence Day. Find the related blogpost at xmpp.org

There are more related activities and resources available from the XMPP Community:

• Wechselrezept zu Quicksy (XMPP) and Wechselrezept zu XMPP by Axel Reimer for the eversten.net blog. [DE]
• Independent Messaging Day: A recipe for digital freedom and sovereignty, a complete and easy guide to digital freedom and sovereignty recipe inspired by the DI.DAY, by Axel Reimer. [DE]

XMPP Articles

• XMPP and Metadata by mathieui for the mathieui blog.
• XMPP integration with n8n by Jérôme Sautret for the ProcessOne Blog.
• NLnet: Grants for 45 Projects Working on Shared Digital Infrastructure
  • Converse XMPP Chat on Mobile
  • Support for Microblogging and Social Feeds to Converse
  • Macaw Instant Messenger Web/Desktop: The intention for this grant is to port the current Macaw web client to Tauri, which enables the client logic to run natively within a desktop application, as well as to implement new features such as group chats and sticker/emoji packs to improve usability. Further, to lay the groundwork for later development of features such as group video calls and end-to-end message encryption, as well as ports to other platforms.
• Vou sempre lutar pelo xmpp by Isadora for the isacloud.im blog. [PT_BR]
• IgniteRealtime Heads to Brussels: XSF Summit & FOSDEM 2026 by guus for the Ignite Realtime Community.
• A new look for Snikket Android by The Snikket Team for the Snikket Blog.
• Your European Union XMPP Chat Provider! by the XMPP Providers Team for the XMPP Providers blog.
• Introducing Fluux Messenger: A Modern XMPP Client Born from a Holiday Coding Session by Mickaël Rémond for the ProcessOne Blog.
• Notificaciones XMPP con un minimo esfuerzo by TheCoffeMaker for Cyberdelia. [ES]

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.19.8 and 2.19.9 for Android. These versions introduce a fix for calls getting stuck at connecting when ‘Use Relays’ is enabled but server doesn’t have any. They also come with bandwidth optimizations and they combine QR code related actions (show, scan, invite) into one central menu. You can take a look at the changelog for all the details.
• Gajim has released versions 2.4.2 and 2.4.3 of its free and fully featured chat app for XMPP. Installing Gajim on macOS is now only a single click away. Gajim 2.4.2 release brings a simplified macOS setup, easier sharing for files and support for link previews, along many other improvements, changes and some important bug fixes. You can take a look at the changelog for all the details.
• Kaidan has released versions 0.14.0 and 0.15.0 of its user-friendly and modern chat app for XMPP. The former release brings support for advanced media sharing and registration provider filtering, while the latter implements an integrated search field and experimental support for Audio/Video Calls (with most of the work being funded by NLnet via NGI Zero Entrust and NGI Zero Commons Fund with public money provided by the European Commission) in addition to some very useful improvements and lots of fixes! You can find a detailed list of new features, bugfixes and notes in their respective release announcements, or the changelog.

Kaidan 0.15.0: Experimental Audio/Video support on Linux.

• Monal has released versions 6.4.17 for iOS and macOS.
• Monocles has released version 2.1 of its chat app for Android. This a huge update with three fundamental new features: Stories, Feeds, and Phone log. In addition to many other improvements and features such as account sorting and improved message deletion, this update also brings new support for multiple XEPs. Thanks to the standardization of XMPP, it is now possible to have social interaction across different XMPP platforms and messengers. These new features bring more functions that are fully compatible with the XMPP web platform Movim.

Create your stories today and make a post for your contacts in Monocles Chat or Movim!

• Prose has released version 0.14.1 of prose-app-web, their web application built in TypeScript / VueJS / WebAssembly.

XMPP Servers

• Prosody IM is pleased to announce versions 13.0.3 and 13.0.4, both minor releases of the stable branch. The former comes with a range of tweaks, bug fixes and minor improvements, and the latter being the encouraged upgrade, partly due to a bug that was introduced into UUID generation in the previous release. Although not strictly bug fixes, some configuration-related improvements that help make configuring Prosody a little easier and more reliable also made their way into the latest release. Read all the details on the changelog, and as always, detailed download and install instructions are available on the download page for your convenience.
• MongooseIM has released MongooseIM 6.5: Open for Integration. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server. The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself.
• ProcessOne is pleased to announce the release of ejabberd 26.01. This release addresses real operational pain points: export your data from one database backend and import it into another, and roster invites and invite-based account registration to let your users invite others without opening the gates to spam! Make sure to read the changelog for all the details and a complete list of changes, new features, fixes and improvements on this release.

XMPP Libraries & Tools

• QXmpp, the cross-platform C++ XMPP client and server library, version 1.14.0 has been released. Full details on the changelog.
• Slidge version 0.3.6 has been released. You can check the intermediate changelog from 0.3.5 to 0.3.6 for all the details.
• slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.10 has been released.
• xmpp-dns, a CLI tool to check XMPP SRV records, version 0.5.6, 0.6.0, 0.6.1 and 0.6.2 have 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.

• End-to-End Encrypted Contacts Metadata
  • This specification describes how to encrypt contacts metadata to minimize server exposure.

New

• No new XEPs this month.

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.1.0 of XEP-0386 (Bind 2)
  • It’s authorization-identifier not authorization-identity (dg)

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 XEPs last calls this month.

Stable

• No stable XEPs this month.

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, Ludovic Bocquet, XSF iTeam

• Translations:

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

XMPP Newsletter Banner

Welcome to the XMPP Newsletter, great to have you here again! This issue covers the month of January 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

Call for XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, please apply before February 15th, 2026, 00:00 UTC. Being a member signals a commitment to open standards and professional engagement in / with the XMPP community. Here, your membership helps position the XSF as a healthy organization, which in itself is valuable. It also grants voting rights on technical and administrative matters within the XSF. The application is a light-weight and free of cost process and you can use membership to get more involved more easily, too.

XMPP Summit 28

The XSF held its 28th XMPP Summit during January 29th and 30th 2026 in Brussels (Belgium, Europe). During this two-day gathering, we discussed XMPP protocol development topics and kept making progress on current issues within the protocol and ecosystem. We would like to thank everyone that took part in the Summit for their continuous commitment and contribution to the XSF and all the XMPP related projects!

The XSF would like to extend a special thank you to those who made this XMPP Summit possible:

• Edward Maurer from the XSF Communication Team as well as Daniel Gultsch and Guus der Kinderen from the XSF Summits, Conferences, and Meetups Team for their time, resources, strong commitment, thorough contribution and attention to detail in the organization and moderation of the event.
• Ralph Meijer, Dan Caseley and Edwin Mons for their time and dedicated work on streaming the Summit.
• Ralph Meijer for organising the XSF dinner and Alexander Gnauck’s noted sponsor contribution.
• Additional thanks to mathieui, Rémi and other unknown people helping to keep track of the notes during the event.

Welcome to the 28th XMPP Summit!

A summary of the main topics discussed is planned to be published soon at xmpp.org.

XMPP at FOSDEM 2026

During January 31st and February 1st, the XSF was present at FOSDEM 26 in Brussels, Belgium. The XMPP community took part in the Realtime Lounge, a room located in Level 1, AW building, together with the Prosody IM and the Snikket projects, where several open source projects around the Decentralised Communication Devroom can present themselves.

We are pleased to say that there was a lot of interaction at the XMPP booth! A rather large number of FOSDEM visitors had the opportunity to come say “Hi!”, meet, interact, talk and have interesting conversations with many of the developers of the most popular clients, servers, tools and libraries that power the whole XMPP ecosystem and bring it to life.

In addition to the activities that took place on the XMPP booth, Daniel Gultsch and S1m, Jérôme Sautret, Timothée Jaussoin, and Özcan Oğuz hosted four different XMPP related presentations from the Decentralised Communication Developer Room and the FOSS on Mobile track.

You can watch the presentations from the following list of links:

• UnifiedPush - Push notifications. Decentralized and Open Source by Daniel Gultsch and S1m at FOSDEM 2026
• Engineering XMPP Federation: Building Messaging, Voice & Social Features Across Independent Projects by Jérôme Sautret and Timothée Jaussoin at FOSDEM 2026
• Movim: Building a Decentralized Social Network on XMPP by Timothée Jaussoin at FOSDEM 2026
• What are you listening to now?: Implementing “Now Playing” feature in modern XMPP by Özcan Oğuz at FOSDEM 2026

And, of course .. we had plenty of leaflets, informational material, and as always: the coolest stickers! ;)

We found Wally. Now, can you find the XMPP booth in the picture?

XSF Bluesky account is verified now (New handle!)

The XSF Bluesky account is verified now. This means that the profile handle is different now (@xmpp.org) You can find the profile with its new handle via https://bsky.app/profile/xmpp.org. Many thanks to cal0pteryx from the XSF Communication Team as well as singpolyma and Zash from Infrastructure Team.

Events

XMPP listed as Alternative Chat at DI.DAY Initiative

The German initiative ‘Digital Independence Day’ (DI.DAY) has been kicked off this year to enable users to migrate to open-source software alternatives in various contexts. Besides other services, XMPP is listed as an alternative chat option and XMPP Community members have created so-called switch recipes: Digital Independence Day. Find the related blogpost at xmpp.org

There are more related activities and resources available from the XMPP Community:

• Wechselrezept zu Quicksy (XMPP) and Wechselrezept zu XMPP by Axel Reimer for the eversten.net blog. [DE]
• Independent Messaging Day: A recipe for digital freedom and sovereignty, a complete and easy guide to digital freedom and sovereignty recipe inspired by the DI.DAY, by Axel Reimer. [DE]

XMPP Articles

• XMPP and Metadata by mathieui for the mathieui blog.
• XMPP integration with n8n by Jérôme Sautret for the ProcessOne Blog.
• NLnet: Grants for 45 Projects Working on Shared Digital Infrastructure
  • Converse XMPP Chat on Mobile
  • Support for Microblogging and Social Feeds to Converse
  • Macaw Instant Messenger Web/Desktop: The intention for this grant is to port the current Macaw web client to Tauri, which enables the client logic to run natively within a desktop application, as well as to implement new features such as group chats and sticker/emoji packs to improve usability. Further, to lay the groundwork for later development of features such as group video calls and end-to-end message encryption, as well as ports to other platforms.
• Vou sempre lutar pelo xmpp by Isadora for the isacloud.im blog. [PT_BR]
• IgniteRealtime Heads to Brussels: XSF Summit & FOSDEM 2026 by guus for the Ignite Realtime Community.
• A new look for Snikket Android by The Snikket Team for the Snikket Blog.
• Your European Union XMPP Chat Provider! by the XMPP Providers Team for the XMPP Providers blog.
• Introducing Fluux Messenger: A Modern XMPP Client Born from a Holiday Coding Session by Mickaël Rémond for the ProcessOne Blog.
• Notificaciones XMPP con un minimo esfuerzo by TheCoffeMaker for Cyberdelia. [ES]

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.19.8 and 2.19.9 for Android. These versions introduce a fix for calls getting stuck at connecting when ‘Use Relays’ is enabled but server doesn’t have any. They also come with bandwidth optimizations and they combine QR code related actions (show, scan, invite) into one central menu. You can take a look at the changelog for all the details.
• Gajim has released versions 2.4.2 and 2.4.3 of its free and fully featured chat app for XMPP. Installing Gajim on macOS is now only a single click away. Gajim 2.4.2 release brings a simplified macOS setup, easier sharing for files and support for link previews, along many other improvements, changes and some important bug fixes. You can take a look at the changelog for all the details.
• Kaidan has released versions 0.14.0 and 0.15.0 of its user-friendly and modern chat app for XMPP. The former release brings support for advanced media sharing and registration provider filtering, while the latter implements an integrated search field and experimental support for Audio/Video Calls (with most of the work being funded by NLnet via NGI Zero Entrust and NGI Zero Commons Fund with public money provided by the European Commission) in addition to some very useful improvements and lots of fixes! You can find a detailed list of new features, bugfixes and notes in their respective release announcements, or the changelog.

Kaidan 0.15.0: Experimental Audio/Video support on Linux.

• Monal has released versions 6.4.17 for iOS and macOS.
• Monocles has released version 2.1 of its chat app for Android. This a huge update with three fundamental new features: Stories, Feeds, and Phone log. In addition to many other improvements and features such as account sorting and improved message deletion, this update also brings new support for multiple XEPs. Thanks to the standardization of XMPP, it is now possible to have social interaction across different XMPP platforms and messengers. These new features bring more functions that are fully compatible with the XMPP web platform Movim.

Create your stories today and make a post for your contacts in Monocles Chat or Movim!

• Prose has released version 0.14.1 of prose-app-web, their web application built in TypeScript / VueJS / WebAssembly.

XMPP Servers

• Prosody IM is pleased to announce versions 13.0.3 and 13.0.4, both minor releases of the stable branch. The former comes with a range of tweaks, bug fixes and minor improvements, and the latter being the encouraged upgrade, partly due to a bug that was introduced into UUID generation in the previous release. Although not strictly bug fixes, some configuration-related improvements that help make configuring Prosody a little easier and more reliable also made their way into the latest release. Read all the details on the changelog, and as always, detailed download and install instructions are available on the download page for your convenience.
• MongooseIM has released MongooseIM 6.5: Open for Integration. This release focuses on easier integration with your applications while continuing to deliver a scalable and reliable XMPP-based messaging server. The most important improvement in MongooseIM 6.5.0 is the production-ready integration with RabbitMQ, allowing external services to process the events from the server. It is worth noting that the mechanism is highly extensible – you can craft such extensions yourself.
• ProcessOne is pleased to announce the release of ejabberd 26.01. This release addresses real operational pain points: export your data from one database backend and import it into another, and roster invites and invite-based account registration to let your users invite others without opening the gates to spam! Make sure to read the changelog for all the details and a complete list of changes, new features, fixes and improvements on this release.

XMPP Libraries & Tools

• QXmpp, the cross-platform C++ XMPP client and server library, version 1.14.0 has been released. Full details on the changelog.
• Slidge version 0.3.6 has been released. You can check the intermediate changelog from 0.3.5 to 0.3.6 for all the details.
• slidge-whatsapp, the WhatsApp to XMPP gateway based on Slidge and whatsmeow, version 0.3.10 has been released.
• xmpp-dns, a CLI tool to check XMPP SRV records, version 0.5.6, 0.6.0, 0.6.1 and 0.6.2 have 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.

• End-to-End Encrypted Contacts Metadata
  • This specification describes how to encrypt contacts metadata to minimize server exposure.

New

• No new XEPs this month.

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.1.0 of XEP-0386 (Bind 2)
  • It’s authorization-identifier not authorization-identity (dg)

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 XEPs last calls this month.

Stable

• No stable XEPs this month.

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, XSF iTeam

• Translations:

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

This version fixes a regression in the previous release regarding joining rooms, improves compatibility with the new aiodns releases, and brings a number of other features and fixes.

Thanks to everyone involved (with new contributors) for this release!

On 11th February, Let’s Encrypt will be rolling out a change to the certificates they issue to servers by default. Although there is generally nothing that Prosody operators need to do, servers using the new certificates may experience problems connecting to some other XMPP servers on the network.

Certificate basics

First, a tiny bit of background on certificates. Certificate Authorities (CAs) such as Let’s Encrypt work by verifying that you own or control a domain, and then they issue you with a certificate that you can present to others as proof of this verification. Obtaining a certificate can be done using the ‘certbot’ tool or any one of the large number of tools compatible with the ACME protocol.

When an XMPP client connects to a server, it will expect the server to present a certificate which is valid for the domain the client is logging in to.

Likewise, certificates are also used when servers connect to other servers (server-to-server connections are often called “s2s” or generally “federation”). This prevents various attacks, including spoofing - because when your server receives a message claiming to be from “user@example.com”, it can ensure that the server it came from presented a valid certificate for “example.com” and has been verified.

Certificates can specify usage

Most people know that certificates contain the domain name that has been verified. However they contain other data too, including the details of the CA that signed and issued the certificate, validity period, and various metadata.

Another part of the certificate can specify limitations on what the certificate can be used for. For example, a CA’s own certificate will specify that they are allowed to use their certificate to sign other certificates. Similar restrictions can be used to permit whether it can be used for signing and/or encryption.

One such extension, called “Extended Key Usage” can be used to restrict whether the certificate is used for “server authentication” or “client authentication”.

What’s changing?

Let’s Encrypt currently issue certificates which specify they may be used for both “server authentication” and “client authentication”. However they have announced that they will be issuing certificates for only “server authentication” by default from 11th February 2026. In the rest of this post we’ll refer to these as “server-only” certificates.

Traditional interpretation of the relevant specifications would forbid use of those certificates by a client which is connecting to a server. Unfortunately, XMPP makes heavy use of connections between servers, and in the context of such server-to-server connections the TLS specifications actually consider the server that initiated the connection to be a “client” (not an XMPP client, but a TLS client).

Common TLS libraries and APIs such as OpenSSL will automatically verify the certificate’s key usage fields, and fail certificate validation if an incoming connection is received that uses a certificate without the “client authentication” purpose. This has the potential to break server-to-server connection authentication in XMPP (and also other protocols that make connections between servers).

Does this affect Prosody?

Not directly. Let’s Encrypt is not the first CA to issue server-only certificates. Many years ago, we incorporated changes into Prosody which allow server-only certificates to be used for server-to-server connections, regardless of which server started the connection. We believe that this is the correct approach for XMPP.

This means that Prosody will accept connections from servers that are using the new server-only certificates from Let’s Encrypt.

Unfortunately this behaviour is not standardized, partly due to controversy outside the XMPP community about this approach. The current CA ecosystem is heavily driven by web browser vendors (i.e. Google, Apple, Microsoft and Mozilla), and they are increasingly hostile towards non-browser applications using certificates from CAs that they say only provide certificates for consumption by web browsers.

An attempt at updating the specifications to clarify the expected roles of servers and clients failed to gain consensus at the IETF.

Does this affect the XMPP network?

Although Prosody will accept server-only certificates, some other server implementations do not have the alternative certificate usage validation that Prosody has, or they added it only recently.

Compatible servers:

• ejabberd (requires 25.08 or later)
• Openfire

Operators of incompatible server versions should upgrade to a version that is compatible with server-only certificates as soon as possible to prevent problems with federation.

Server software not listed above has not been tested, and may not accept connections from servers using server-only certificates.

What will happen with other servers?

If a server does not use the alternative validation (because the software doesn’t implement it, or it has not been updated) then it will treat the certificates of all other servers as invalid for initiating s2s connections.

Many servers still have the dialback protocol enabled, which will act as a fallback authentication mechanism (using DNS), and in this case the connections may still succeed.

However if dialback is disabled on either server, or if the target server strictly requires valid certificates, server-to-server connections will always fail entirely.

You may see errors in your Prosody log file such as:

Server-to-server connection failed: Could not authenticate to remote server

In such a case, the remote server operator usually needs to update their software.

How can I test my server?

Send an XMPP ping (XEP-0199) to le-tlsserver.badxmpp.eu - if you get a successful iq response, this means your server accepts server-only certificates. If you don’t get a response, check your server’s log file for any incoming s2s failures.

Introduction

This document defines common Vorbis comments related to Contra, Square and other traditional called folk dances. Their use is also recommended (and identical) in other specifications that re-use Vorbis comments such as OGG/Opus Tag Definitions, and FLAC tags. The same names may be used in other metadata containers such as APE or ID3 but their use in these systems is not defined in this document.

Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

Namespace

Each tag defined in this document will use the CONTRA: namespace to differentiate it from similar tags that may already exist. This is true regardless of the dance form being used (ie. if the recording is of a square dance, the CONTRA: namespace is still used).

Tags

CONTRA:CALLER

The name of the caller heard in the track for recordings that include calls.

CONTRA:TITLE

The name of the dance in recordings that include calls. For example, “Scrubbies”.

CONTRA:CHOREOGRAPHER

The name of the dance author in recordings that include calls. For example, “David Smukler”. The special value “[traditional]” SHOULD be used for traditional dances where no known choreographer exists. For dances that are a variation on a previous dance the choreographers SHOULD be listed in reverse chronological order, with the author of the variant as the first author.

CONTRA:UNSYNCEDDANCE

The moves of the dance, a single time through, in a plain text format. No exact style is specified but the dance author, choreographer, difficulty, or any callers notes SHOULD NOT be included and should instead be read from the appropriate tags.

CONTRA:NOTES

Any caller or listener provided notes (ie. “Beginner friendly dance” or “When teaching the A1 part, have the Larks cross over first…”, etc.)

CONTRA:ROLES

The role terms used in the dance for recordings that include calls. For example: “Larks/Robins” or “Positional”. No specific format is defined.

CONTRA:LICENSE

Like the LICENSE field defined in vorbis/v-comment, but for the license of the dance instead of the recording.

CONTRA:POTATOES

The number of beats (not bars) of introduction before the first time through the dance begins (whether they are traditional bluegrass-style potatoes or an introductory phrase). This MAY be used in conjunction with CONTRA:START.

CONTRA:START

The start time (in milliseconds) of the first time through the dance (where the dancers would start moving, not where the caller would start calling). This MAY be used in conjunction with CONTRA:POTATOES.

CONTRA:TIMES

The number of complete times through the dance excluding any intros, potatoes, or outros. The exact definition will depend on the type of dance, for contras it should be complete 64 beat (32 bar) phrases.

CONTRA:CROOKED

Whether the dance is crooked (ie. not in perfect dance form) or not. This key MUST always be the value “TRUE” or “FALSE”.

The German initiative ‘Digital Independence Day’ (DI.DAY) has been kicked off this year to enable users to migrate to open-source software alternatives in various contexts. Besides other services, XMPP is listed as an alternative chat option and XMPP Community members have created so-called switch recipes: Digital Independence Day.

The DI.DAY is not a single event, it takes place every first sunday of the month so interested users can switch one service at a time. This initiative shares many values of the XMPP community, such as digital sovereignty and digital privacy. Still, we believe XMPP as standardised technology for realtime communication serves these values best.

Many thanks to the XMPP Community members and beyond for investing their time and efforts to provide all material, namely Axel, Daniel, emus, Ge0rG, padeluun and especially IM from freie-messenger.de! Additional thanks to Digitalcourage and Save Social for sponsoring the handouts for FOSDEM!

Find many other chat apps at xmpp.org!

See you online via XMPP and open-source software!

The XMPP switch recipie handouts infront of the XMPP booth at FOSDEM.

Welcome Kaidan 0.15.0! This release adds experimental support for calls. In addition, it contains some very useful improvements and lots of 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.

Audio/Video Calls

Kaidan has supported voice and video messages for a long time. Starting with this release, you can even have an audio or video call with a contact! An incoming call is indicated via a notification and you can either accept or reject it.

Please note that there are still some features missing and some setups may not work properly. Especially, calls are only supposed to work on Linux at the moment. But wee wanted to share the current achievements with you to get some feedback! Our goal is to extend the A/V calls functionality and make it available on other operating systems in the future.

Notifications for Group Chat Replies

Formerly, you got a notification if someone mentioned you in a group chat while the corresponding setting was enabled. But you could miss replies to your messages. Kaidan notifies you now on receiving replies as well.

Message Input Field Focusing

In contrast to the soft keyboard on a mobile device, which needs to be opened each time you want to enter something, your keyboard is always reachable on a desktop device. Why not make use of that circumstance? Kaidan ensures that the most relevant message input field stays focused to allow entering text without an additional click into the corresponding field. That way, you can interact smoothly with the user interface and be more productive.

Advanced Message Highlighting

Kaidan 0.14 introduced highlighted messages if you opened their context menu. Messages are now also highlighted while they are being corrected or while you are choosing emojis to react to them. If another message was already highlighted before, that message is highlighted again once you sent the correction/reaction.

Integrated Search Field

With Kaidan, you can quickly search for chats and messages. But while searching for messages, the opened search bar reduced the space for messages. On mobile devices, the search bar even consumed unnecessary space within the chat list. Both problems are solved now! The search field is integrated into the main toolbar above the messages resp. the chat list. You can even focus each search field via an own keyboard shortcut to directly search without moving the cursor.

Password Manager Fallback

Since Kaidan’s last version, passwords are stored in a password manager if the system provides one. But there was no fallback yet. It is now possible to use Kaidan even if no password manager is available. In that case, the passwords are stored in an unencrypted file. Once Kaidan detects a password manager on start, the unencrypted passwords are automatically migrated to the password manager.

Changelog

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

Features:

• Add support for audio/video calls (XEP-0166: Jingle, XEP-0167: Jingle RTP Sessions, XEP-0176: Jingle ICE-UDP Transport Method, XEP-0215: External Service Discovery, XEP-0320: Use of DTLS-SRTP in Jingle Sessions, XEP-0353: Jingle Message Initiation) (@melvo)
• Show busy indicator while saving captured image/video data (@melvo)
• Notify on receiving reply to own group chat message if ‘On mention’ notification setting is enabled (@melvo)
• Select file after opening in folder on Linux if supported (@melvo)
• Improve media capturing look/behavior (including preview after capturing image until image is saved) (@melvo)
• Restore focusing of last focused user interface elements (especially message input field) for various use cases (@melvo)
• Keep message bubble highlighted on reacting/correcting (@melvo)
• Allow to select message for correction via Ctrl+Up/Ctrl+Down (@melvo)
• Integrate search field into main toolbar increasing space for messages and, on mobile devices, even for chats in chat list (@melvo)
• Show message search field via Ctrl+Shift+F (@melvo)
• Display toolbar buttons on mobile devices exactly as on desktop devices (@melvo)
• Hide horizontal separator above top-most chat unless chat list is scrolled (@melvo)
• Store passwords in unencrypted file if no password manager is available or corresponding command-line option provided (@fazevedo)
• Migrate unencrypted passwords to password manager if available on start (@fazevedo)

Bugfixes:

• Fix overlapping message bubble tail (@melvo)
• Fix medium preview hovering if hidden drop area info is hovered (@melvo)
• Fix updating OMEMO 2 keys for all use cases (@melvo)
• Fix deadlock on logout during upload of multiple files (@melvo)
• Fix creating additional database connection on wrong thread (@melvo)
• Fix sending/resetting whether message is being composed for various corner cases (switching chat, logging out, disabling corresponding setting) (@melvo)
• Fix updating last message on receiving initial message after setting up existing account in Kaidan for first time (@melvo)
• Fix resetting draft message after canceling message correction (@melvo)
• Fix resending failed message reaction (@melvo)
• Fix selecting previously selected message after changing reactions (@melvo)
• Fix restoring message highlighting and cancel ongoing correction/reply on removing corresponding message (@melvo)
• Fix displaying last message sender in chat list after draft message removal (@melvo)

Notes:

• Kaidan requires Kirigami Addons 1.8 now
• Kaidan requires QXmpp 1.14 now

Download

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

Or install Kaidan for your distribution:

It was mid-December 2025, just before the Christmas break. My favorite XMPP client had broken on the main branch I was using. Frustrated, rather than waiting for a fix, I decided I wanted to give another try at working on a client. This time, I would be using the opportunity to explore a new set of tools I was curious about: TypeScript, React, and Tauri.

What started as a weekend experiment quickly turned into something more. Using AI tools to accelerate the initial setup, I found myself totally absorbed in the work. Days blurred together as features took shape. By early January, what had been a personal scratch project had become a surprisingly capable desktop client.

When I demonstrated it to my coworkers at ProcessOne, their reaction was unanimous: this was worth pursuing seriously. We decided to put the entire company behind the effort. Today, we&aposre sharing the first public release of Fluux Messenger.

More Than Just Another Chat Client

At ProcessOne, we&aposve spent over two decades building messaging infrastructure. Our XMPP server, ejabberd, has powered some of the world&aposs largest messaging deployments. But we&aposve always approached messaging from the server side. Fluux Messenger represents something new for us, bringing that same engineering philosophy to the client.

The key innovation isn&apost in the UI (though we&aposre proud of it). It&aposs in what lies beneath: the Fluux SDK.

The Fluux SDK: Bridging Two Worlds

Anyone who has built an XMPP client knows the challenge. XMPP is event-driven, signal-based, asynchronous. Modern UI frameworks expect reactive state, typed data, and predictable updates. There&aposs an impedance mismatch between these two worlds.

The Fluux SDK is our answer. It provides a high-level TypeScript API that handles all XMPP complexity internally. Developers work with clean types and reactive state, not XML stanzas. The SDK maintains local cache, manages reconnection, and handles synchronization intelligently. It&aposs not a passive pipe between server and UI; it&aposs an active participant that makes the client easier to develop and more resilient.

As an example, the client is not telling the SDK which presence it wants to publish when stepping away from the computer, but it will signal to the SDK that it is inactive. The SDK is responsible for doing the right thing.

This three-tiered architecture, Server -> Headless client (SDK) -> UI, lets us apply the same design principles that made ejabberd scalable to the client side. Distributed logic, local-first responsiveness, server-side efficiency.

What Fluux Messenger Offers Today

The current release (v0.11.1) already includes substantial functionality:

• Reliable connection and message management
• Cross-platform desktop app for Windows, macOS, and Linux, built on Tauri for a lightweight native experience
• Web version: It works great on the Web as well.
• 40+ XMPP extensions (XEPs) implemented, including message archive management, multi-user chat, HTTP file upload, message carbons, and reactions
• MUC support with @mentions notification and bookmarks
• Local message cache storage using IndexedDB with automatic sync on reconnect
• Built-in XMPP console for developers and power users who want to see what&aposs happening under the hood
• Preliminary admin capabilities letting you manage your ejabberd server directly from the client (But this is still mostly a work in progress).
• 8 languages supported out of the box
• Light and dark modes with theme system to come

What I envision for Fluux Messenger is to follow the steps of major projects like Obsidian or VSCode. In my wildest dreams, I expect Fluux Messenger to become as configurable and versatile as those tools.

The Road Ahead

This is an ambitious project. The roadmap stretches far into the future, and we&aposre just getting started. Our plans include mobile support through PWA and eventually native apps, expansion to other frameworks (Vue, Svelte), and Kotlin Multiplatform for Android and iOS.

But ambitious doesn&apost mean closed. Fluux Messenger is open source under AGPL-3.0. We believe that modern, privacy-respecting messaging shouldn&apost require vendor lock-in. Connect to any XMPP server. Host it yourself.

I used AI to bootstrap this project and accelerate my learning phase. Many developers do now. But we are crafters at ProcessOne, and we want to own the responsibility for great code. Those who know me will tell you I&aposll be relentless until I master React and TypeScript, and they know I will. Fast.

A Continuation of ejabberd&aposs Vision

Fluux Messenger represents the client-side continuation of what we started with ejabberd over twenty years ago. The same principles, scalability, reliability, clean architecture, now flow from server to client. If you&aposve trusted ejabberd to power your messaging infrastructure, we hope you&aposll trust Fluux Messenger to be the interface your users deserve.

This is the beginning of an exciting journey. We hope you&aposll join us.

---

Get started

• Download from GitHub Releases
• Join the conversation: fluux-messenger@conference.process-one.net
• Report issues and suggest features on GitHub

If you share our vision for clean, reactive messaging APIs, we&aposd love to collaborate. Reach out and let&aposs grow the Fluux community together.

We’re looking forward to meeting new and familiar faces at FOSDEM in Brussels this weekend!

Every February, thousands of developers (and users) of open-source and free (as in freedom) software gather in Brussels to discuss and celebrate our communities, and collaborate and share ideas and projects.

If you are attending, come and find us in the AW building, Level 1. We’ll be sharing the stand with other projects in the XMPP ecosystem and adjacent to other communication projects such as Linphone, Delta Chat and Matrix.

You can bring us questions about Snikket or XMPP, receive help with your own Snikket deployment, or just stop by and say hi!

We’re looking forward to meeting new and familiar faces at FOSDEM in Brussels this weekend!

Every February, thousands of developers (and users) of open-source and free (as in freedom) software gather in Brussels to discuss and celebrate our communities, and collaborate and share ideas and projects.

If you are attending, come and find us in the AW building, Level 1. We’ll be sharing the stand with other projects in the XMPP ecosystem and adjacent to other communication projects such as Linphone, Delta Chat and Matrix.

You can bring us questions about Prosody or XMPP, receive help with your own Prosody deployment, or just stop by and say hi!

You can now easily find an XMPP provider based in the European Union (EU)! We have updated our filter options. Previously, you could filter for the server location of an XMPP provider. That filter now allows to select EU-only hosted services.

Try it out! Click the Filter list drop-down menu on the main page.

The location-based filter allows to select the server location.

There are many other properties you can filter for, too. In addition, there is an overview table of providers with column filters and sorting options.

Looking forward to more European Union XMPP chat providers and beyond!

Info: Meet us this week at FOSDEM!

Improve the XMPP experience

For a good user experience, apps integrating XMPP Providers are as important as the providers themselves. If you are an XMPP developer, please consider adding XMPP Providers support to your app. If you are an operator of a public XMPP service, add your service to the list.

You can also consider to run your own XMPP server and become a public provider. With our automated XMPP server setup, you can operate a fully-featured XMPP server with minimal effort.

Feel free to reach out to us if you have any questions! If you like to support XMPP Providers, please consider making a donation. Follow us and spread the word!

XMPP Providers Logo

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

Welcome to another minor release from our stable branch!

We encourage any deployments using 13.0.3 to upgrade, partly due to a bug that was introduced into UUID generation in that release. We’re not aware of any direct consequences of this bug, but it may cause compatibility problems with other software.

Although not strictly bug fixes, we sneaked in some configuration-related improvements to this release which help make configuring Prosody a little easier and more reliable. We’re highlighting them because these changes have a chance to impact some rare configurations.

The first change is to prevent mod_pubsub from being loaded on a VirtualHost (easily done if you accidentally add it to your global modules_enabled list). Loading mod_pubsub on a normal user host can lead to unexpected behaviour. Now it will log an error and refuse to load if you do that.

The second change is to simplify configuration of archiving in MUCs. Practically all modern clients now use XEP-0313 to synchronize message history. For VirtualHosts this is implemented in mod_mam, and for MUC components it is implemented in mod_muc_mam. From this release, things get much simpler: loading mod_mam (globally or directly on a MUC component) will automatically load mod_muc_mam on the MUC component. This means most people (e.g. who have mod_mam loaded globally on their server) can now remove “muc_mam” from modules_enabled in their MUC component configuration. It will be loaded automatically.

This last point does mean that if you have mod_mam enabled globally, but do not want it enabled on your MUCs, you now have to state that explicitly by adding “mam” to modules_disabled under the MUC’s Component. Be aware that such a configuration may lead to missing messages in group chats.

A summary of changes in this release:

Fixes and improvements

• mod_s2s: Fix traceback when outgoing s2s queue is full
• util.uuid: Fix padding of group 2 of UUIDv7 to use zeroes

Minor changes

• core.modulemanager: Fix shell commands on components
• mod_s2s: Explicitly prevent sending recursive error replies when queue is full
• modulemanager: Allow component modules to specify additional inherited modules
• prosodyctl check features: Use modulemanager to calculate modules that will actually be loaded
• prosodyctl check features: change recommendation from mod_muc_mam to mod_mam
• prosodyctl check config: Fix traceback when zero modules are enabled
• mod_pubsub: Fail early if loaded outside of a component to prevent misconfiguration
• doap: Add XEP-0486
• mod_pubsub/commands: Fix listing item numbers along with item names
• mod_account_activity: Handle authentication provider returning no user info
• mod_mam: Automatically load mod_muc_mam if loaded on a MUC component
• mod_muc: Inherit mod_mam if globally loaded

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!

We’re sharing a sneak peek at the visual design of the upcoming release of Snikket’s Android app - what we’ve changed, why, and how we got here. The new app will be released on 25th January 2026. To learn more about using Snikket for your communication, check our homepage.

---

The foundational principles of good user interface design never really change. People should be able to easily find common actions, text should be clear and legible, buttons should be large enough to press, to name a few. But around these pillars, aesthetic conventions are always shifting and evolving.

Years ago, square corners used to be lauded as “crisp”. Today, rounded edges are marvellously “smooth”. Where shadows used to add a three-dimensional realism to our interfaces, flat designs are now the norm in most apps.

One of Snikket’s goals is to be approachable and familiar to people who are used to other popular messaging ecosystems. It should be a welcoming gateway to the world of decentralized messaging. This means, where reasonable, keeping up with the conventions established by other widespread communication apps. We can’t stand still.

Snikket’s Android app has been looking increasingly out of place in recent years, compared to the rest of the apps on a typical Android phone. A large reason for this is the shift towards Google’s Material design - the latest design framework that Android uses, and provides to developers, to help with the design, colours, typography and user interface controls in applications.

For the next release, the Snikket app has been updated to Material 3. This is largely thanks to the work done by Daniel on the upstream Conversations app which underlies the Snikket Android app. On top of the work in Conversations, we have put a Snikket spin on the new interface, aligning it with our colours, and making adjustments to various elements to ensure the design feels familiar, friendly and accessible.

A sample of our updated colour palette

While our brand colour remains our iconic yellow, we have designed a new colour palette for this release. This is derived from Material 3 guidelines, with assistance from the ever-helpful folk at Superbloom, plus a custom-built utility to ensure excellent colour contrast across all our new colours and ensure sufficient legibility.

Speaking of colours, the app now also supports “Material You”, which is a feature of modern Android that allows apps to adapt to a user-chosen colour scheme or wallpaper image without sacrificing usability. If enabled in the settings, Snikket will automatically follow your system’s dynamic colour scheme.

Chat bubbles have been given additional space to more clearly separate individual messages, and default font sizes have been slightly increased. These changes were made after carefully reviewing the interfaces of other similar messaging apps. The goal is to allow anyone to feel as “at home” when using Snikket as they would any other app on their device.

Snikket continues to follow the system font preferences as in the past, but during our research we found our default font size was slightly smaller than other messaging apps we compared with. Our default size now matches what other similar apps use, and an in-app setting allows you to further boost the font size of messages in case you just need that little bit of extra clarity in your chats.

Old font size, new size, and optional extra large size

We hope that each aspect of the new design helps people feel even more at home when using Snikket. The new release will be available on the 25th January!