XMPP Newsletter Banner

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

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or helping these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

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

XMPP at FrOSCon 20

On August 16th & 17th, 2025, the FrOSCon will hold its 20th anniversary edition™. It will take place at the Hochschule Bonn-Rhein-Sieg in Sankt Augustin, Germany, and the XMPP community will be part of it!

While you are there, you may be interested in what is going on at the Devrooms.

The Gemeinsamer DevRoom von Gentoo e.V. und TroLUG will take place at Room C125, where Gentoo e.V. and TroLUG will offer a rich and varied 2-day program on various topics, including the Gentoo and Debian distributions and free software for smartphones. XMPP will play a special role. Short presentations, demos and workshops will encourage visitors to join in. There will also be plenty of time for spontaneous topics and social interaction. (Shh! Don’t tell anyone! … but you can take a look at all the nitty gritty details in here)

And, of course: make sure to come by the XMPP booth and say hi!. We promise there will be stickers. ;)

Videos

• Federated instant messaging, 100% debianized by Elena “of Valhalla” Grandi at the DebConf25.
• Why Aren’t You Using XMPP?
• FOSSY 2025: XMPP track at Room 327.
  • Setting Up A Simple XMPP Server by Root.
  • Telecomms for Preppers by Phillip.
  • Messaging interoperability with MLS, MIMI and XMPP by Marvin W..
  • Adventures in Onboarding: Helping New Users Navigate Federated Services by Gideon Mayhak.
  • How do you solve a problem like iOS? by Stephen Paul Weber.

XMPP Articles

• Empowering Digita:l Sovereignty with Openfire: A Secure and Customizable Communication Platform by guus.
• ProcessOne
  • XMPP: When a 25-Year-Old Protocol Becomes Strategic Again by Mickaël Rémond .
• XMPP Interop Testing
  • MOAR TESTS!: Ever heard of XMPP Interop Testing? It’s this cool project that helps make sure different XMPP servers can all work together smoothly. They have just released version 1.6.0 of all their test runners! The biggest chunk of work has gone into tests that verify parts of the basic XMPP protocol, notably for testing functionality that involves roster management (as specified in section 2 of RFC 6121) and for server rules for processing XML stanzas (section 8 of RFC 6121). Please get in touch if you have any ideas for improvement, or other feedback. They’d love to hear from you!
• JoinJabber now has a Governance document based on the Cooperative Development Guidelines governance template. It aims to be the authoritative document on what JoinJabber wants to do, how they are doing it, an overview of their structure (in few words; there is going to be a separate document to define it fully), and the RFC process for changes.
• Configure the Prosody XMPP-server for free communication on the network from exception.net.ua. [UA]
• Launch of the XMPP / Fediverse Bridge! by BarbaPulpe. [DE] [ES] [FR] [IT] [NL] [PT]
• Federated instant messaging, 100% debianized, a short and concise summary of the speak hosted by Elena “of Valhalla” Grandi at the DebConf25 for people who prefer reading text. [IT] [ES]
• XMPP Home Automation Demonstration Machine from Rainer’s Hilfeseiten [DE].
• Guia rápido e fácil para novos usuários de XMPP, a Brazilian Portuguese translation and adaptation of contrapunctus’ ‘The Quick and Easy Guide to Jabber/XMPP’, by Isadora Ribeiro for the DEV Community. [PT_BR]
• Introducing XOWS: a Javascript XMPP web client that makes use of the WebSocket protocol. A first Beta release, which is more or less an advanced Alpha, is already available for download.
• Join the XMPP-IT Community: Your Help Matters!. The XMPP-IT community is launching a call for active collaboration — no need to be an expert, and it’s not paid work, just shared participation. From translations to testing software, writing wiki content or contributing code, there’s room for everyone. [IT]

XMPP Software News

XMPP Clients and Applications

• Conversations has released versions 2.19.0, 2.19.1 and 2.19.2 for Android, adding support for moderated message retraction in public channels (XEP-0425), showing ‘Last seen’ prominently in chat title (when enabled), and various bug fixes. You can take a look at the changelog for all the details.
• Gajim has released version 2.3.3 of its free and fully featured chat app for XMPP. This release comes with many fixes for Windows and it brings some styling improvements, better performance and bugfixes. You can take a look at the changelog for all the details. Thank you for all your contributions!
• Monal has released version 6.4.12 for iOS and macOS.
• Monocles has released version 2.0.12 of its chat client for Android, featuring improvements and fixes. Take a look at the changelog for all the details.
• Movim has released version 0.31 (code named “Kameny”). This release comes loaded with new features ranging from the NLNet funded simultaneous webcam and screen sharing (and the first steps to SFU integration) to global chatroom search (XEP-0433), URL resolver worker, pronouns support in the profile (in compliance with RFC vCard4), quick switch between 1:1 chats and chatrooms and the ability to move the actions list in the ‘Contact’ or ‘Chatroom’ panel, among many other news!

Movim 0.31 (Kameny): Simultaneous webcam and screen sharing!

• XOWS 0.9.8, a lightweight and modern XMPP over WebSocket Web client, has been released.

XMPP Servers

• ProcessOne is pleased to announce the release of ejabberd 25.07. This release focuses on integration in a wider federated network, with support for spam fighting features, improved Matrix gateway, native support for PubSub Server Information to have your server count as part of the wider XMPP network (e.g. register your server on XMPP Network Graph), new modules, features, improvements and bugfixes. Make sure to read the changelog for all the details and a complete list of changes!
• Prosodical Thoughts: Debian repository key change. The Prosody Team has been working on some changes on the Debian/Ubuntu package repository. If you use this repository to keep up to date with new Prosody packages, you need to take action before 4th August 2025 to continue receiving updates smoothly. Please follow the instructions described in the article. If you have any questions about this change, the Prosody Team is always happy to help and answer them on their community chat!
• WebRTC based audio and video in Openfire 2025 by Dele_Olajide1.

XMPP Libraries & Tools

• slidge-whatsapp, the XMPP-to-WhatsApp gateway based on Slidge, version 0.2.7 has been released.
• peertube-plugin-livechat version 14.0.1 has been released.
• xmpp-ap-bridge versions 0.7.0, 0.7.1 and 0.7.2 have been released.
• xmpp-dns version 0.5.0 Beta 1 has been released.
• go-sendxmpp version 0.15.0 Beta 1 has been released.
• ignite realtime community: XEP-0483: HTTP Online Meetings by Dele_Olajide1.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• No XEPs proposed this month.

New

• Version 0.1.0 of XEP-0504 (Data Policy)
  • Accepted as Experimental by Council vote on 2025-06-08 (XEP Editor: dg)
• Version 0.1.0 of XEP-0505 (Data Forms File Input Element)
  • Accepted as Experimental by Council vote on 2025-07-08 (XEP Editor: 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.10.0 of XEP-0080 (User Location)
  • Added <regioncode/> element. (jp)
• Version 1.2.0 of XEP-0363 (HTTP File Upload)
  • Add optional upload purpose when requesting slots (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 Last Call this month.

Stable

• No XEPs moved to Stable 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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• German: xmpp.org
  • Translators: Millesimus
• Italian: notes.nicfab.eu
  • Translators: nicola
• Portuguese: xmpp.org
  • Translators: Paulo
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

Providers Survey

In May 2025, we ran a small survey to gather feedback from XMPP server operators. Our main concerns were XMPP Provider’s service and the project itself. First of all, we would like to thank almost 60 people who participated in this survey. While the XMPP Providers project currently lists a little more than 70 providers, this is a good turnout. At this point we can already tell that the general feedback is very positive!

Although we had quite a few participants, only about one third were actual server operators. Most of the responders were listed in category A or B or they were not listed yet.

Survey category result

Since we are curious about the general satisfaction with XMPP Provider’s service, we made these four aspects part of the survey: Service listing and its processes, transparency, documentation and communication. Across all these aspects, we see mostly satisfied to very satisfied participants. For the occasional question about project documentation, we recommend the FAQ as a starting point.

Survey general experience result

Since being listed as a provider may come with increased public visibility, we are interested in potential changes in registration count, usage activity, maintenance efforts or spam incidents. The results suggest that spam incidents, maintenance efforts and usage activity didn’t change much. However, registration count increased, which supports federation in the XMPP ecosystem.

Survey listing experience result

In addition to these survey results, we received a lot of written feedback. A good share of this feedback praises the project for empowering people to make a good and informed choice about their XMPP provider. We would like to address some of the points raised in the feedback separately:

• Which kind of providers do we list? Our goal is to list all publicly visible XMPP providers. XMPP Providers gathers information about all listed providers automatically, which may be helpful for registration purposes, for getting an overview about providers, or for looking up information about a specific provider, even if registration is closed.
• Why do you make in-band registration a requirement for a category A or B listing? XMPP Providers is a project made to simplify the users’ onboardings. Therefore, the criteria we use for the categorization are from a user’s perspective. This means users should be able to register directly from their XMPP client. Spam may be the most prominent reason to disable in-band registration, but that creates a barrier for newcomers.
• Why do I need to provide an extra file for XMPP Providers? We try to gather data automatically, but not all data is available in a machine-readable format. To reduce manual efforts until more data is available for automatic processing, we opted for a provider file containing additional information, which is hosted by individual providers. In the meantime, we continue to work on automating as much as possible.
• Why can I only get into category B and not into category A if my service is not free? We made this distinction to allow a completely automated registration without any user input. In the future, we would like to add payment and donation information.

Perspective

A year after introducing the provider file, more than 60% of the currently listed XMPP providers host such a file to offer additional information. We see this as a great success, since it helps to improve both transparency and quality of XMPP providers.

At the time of writing, about 60% of the 74 XMPP providers listed are category D providers. This is either due to closed registration, missing information, or both. We encourage all providers to offer a provider file to fill the missing information gap.

Furthermore, with the client monocles chat, now three active apps have integrated information from the XMPP Providers project.

Why Provider Categories?

The decentralized nature of the XMPP network allows for a wide variety of clients and servers. While the basic features might work in many cases, more advanced features might fail to work if a client or a server does not support the necessary feature set. On top of that, there can be servers configured with outdated settings or insufficient storage options, which may further degrade the experience.

Take for example file transfers: A provider offers file transfers via HTTP File Upload with up to 10 MB per file. Now there is a user trying to send a 12 MB file, but their client does not support alternative file transfer methods. In this case, the user cannot send their file via XMPP. While registering with their provider, the user might not be aware of potential limits or issues, which could be avoided otherwise.

To give newcomers the best possible experience, the XMPP Providers project groups providers into simple categories. Each category is based on a set of criteria a provider has to meet, and thus generalizes technical details into categories. This is the easiest way to offer newcomers a list of providers with little potential for frustration. Frustration during the first steps with a new service may turn users away from XMPP. That’s why frictionless onboarding and initial experience for first-time users is so important. But users don’t have to rely on categories alone. XMPP Providers offers plenty of details for tech-savvy users, which can be used to filter the list by further criteria.

Putting providers into categories may lead to conflicts, that’s true. Oftentimes providers can reach better categories by fixing configuration issues, and we are always glad to help where we can. There is an extensive FAQ with the most frequent configuration issues, and we offer a support chat for help with technical issues or related questions. Last but not least, categories give providers an incentive to improve their service for better first-time user experience.

Why Another Providers List?

There are many websites listing XMPP providers, ranging from wikis to user guides and personal websites. Many of them have a common problem: Information becomes stale. In order to have up-to-date information, they need a lot of manual maintenance. To avoid having to maintain a list manually, XMPP Providers builds on automation. As much of the data gathering and processing as possible has been automated. For data which cannot be gathered automatically, we are actively working on solutions.

Automating data processing and categorization needs transparency, accessibility, and good documentation to be sustainable. To reach these goals, and to improve the XMPP onboarding experience, we built the service around XMPP Providers with the following features in mind:

• an open-source interface which can be hosted by every interested party
• extensive service documentation
• offering automated and up-to-date information for listed providers, including categorization with soft and hard quality criteria
• helping to retrieve service information and support information beyond the registration process
• giving opportunities for providers to check and improve their service quality
• providing an API to include the list of providers in XMPP clients

While this project certainly leaves room for improvement, it’s a first step to make the registration process smoother and less error-prone. Providing a public service comes with great responsibility, and we would like to support service providers in that.

Remember: A rising tide lifts all boats!

The survey has been created with Formbricks.

Help the Project, Improve XMPP

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, provide the information we need and add it to the list.

If you like to support XMPP Providers, please consider making a donation.

Feel free to reach out to us if you have any questions!

Spread the Word

The XMPP Providers project lives from the community and we are happy to hear your feedback. Follow us and spread the word!

XMPP Providers Logo

At Erlang Solutions, our support for the BEAM community is long-standing and built into everything we do. From contributing to open-source tools and sponsoring events to improving security and shaping ecosystem standards, we’re proud to play an active role in helping the BEAM ecosystem grow and thrive.

One way we’re putting that support into action is by offering free CI/CD-based security audits for open-source Erlang and Elixir projects. These audits help maintainers identify and fix vulnerabilities early, integrated directly into modern development workflows.

What the Free CI/CD Audits Offer

Our free CI/CD security audits for open source projects are powered by SAFE (Security Audit for Erlang/Elixir), a dedicated solution built to detect vulnerabilities in Erlang and Elixir code that could leave systems exposed to cyber attacks.

The CI/CD version of SAFE integrates directly into your development pipeline (e.g. GitHub Actions, CircleCI, Jenkins), enabling you to scan for vulnerabilities automatically every time code is committed or updated. This helps projects:

• Detect issues early, before they reach production
  
• Maintain a more secure and resilient codebase
  
• Improve visibility of risks within day-to-day workflows
  

Results are delivered quickly– typically within a few minutes. For larger codebases, it may take up to 20–30 minutes. The feedback is designed to be clear, actionable, and minimally disruptive.

Open source maintainers can request a free license by emailing safe@erlang-solutions.com and including a link to their repository. Once approved, we provide a SAFE license for one month or up to a year, depending on the project’s needs, at no cost.

For more information, read our full terms and conditions.

Expert-Led Audits for Production BEAM Systems

SAFE is just one way we help teams build secure, resilient systems. We also offer hands-on audit services for production systems, including:

• Code reviews focused on clarity, maintainability, and best practices
  
• Architecture assessments to help ensure systems are scalable and fault-tolerant
  
• Performance audits to identify bottlenecks and optimise how systems behave under load

These services are delivered by our in-house experts and are a great fit for teams working on complex or business-critical systems. They also pair well with SAFE for a full picture of how systems are running and how they could be even better.

Of course, supporting the BEAM community goes beyond security and audits. Our involvement spans education, events, and long-term ecosystem development.

“We’re proud to support the BEAM ecosystem not just with code, but with the infrastructure and insights that help it grow stronger,” says Zoltan Literati, Business Unit Leader at Erlang Solutions Hungary.

“Our free audits offer real, practical value to maintainers working in open source. It’s one of the ways we’re giving back to the community.”

A Broader Commitment to the BEAM Community

The BEAM ecosystem continues to grow across languages like Erlang, Elixir and Gleam, driven by a global community of developers, maintainers, educators and advocates. Erlang Solutions is proud to contribute across multiple fronts, including:

• Sponsoring various conferences, including Code Sync
• Supporting the Erlang Ecosystem Foundation (EEF), including participation in working groups focused on security, documentation, interoperability, and tooling
• Backing inclusion-focused initiatives such as Women in BEAM
• Sharing learning resources, contributing to open source libraries, and facilitating knowledge exchange through meetups, blogs and webinars
  

Our role is to support the ecosystem not only through expertise, but through action, and to help ensure that BEAM-based systems are not only scalable and reliable, but secure.

To learn more about our free CI/CD security audits or how we support the BEAM community, visit our community hub.

The post Supporting the BEAM Community with Free CI/CD Security Audits appeared first on Erlang Solutions.

Ever heard of XMPP Interop Testing? It’s this cool project that helps make sure different XMPP servers can all work together smoothly. Our XMPP Interop Testing project provides a suite of automated tests that can be integrated into CI/CD pipelines to verify the compliance and interoperability of XMPP server implementations.

Late last year, we reported that we had secured funding graciously provided by NLnet that allowed us to massively build out this project. This blog has been a bit quiet since then, but work has progressed. Significantly.

We have just released version 1.6.0 of all our test runners. With this release, we (again) more than doubled the total number of XMPP interop tests! By my count, our project now lets loose 933 tests on your XMPP server implementation!

The biggest chunk of work has gone into tests that verify parts of the basic XMPP protocol, notably for testing functionality that involves roster management (as specified in section 2 of RFC 6121) and for server rules for processing XML stanzas (section 8 of RFC 6121).

Additionally, a couple of new specifications are now being tested by our framework! Tests have been added for:

• XEP-0133: Service Administration
• XEP-0410: MUC Self-Ping (Schrödinger’s Chat)
• XEP-0421: Occupant identifiers for semi-anonymous MUCs
• XEP-0433: Extended Channel Search

This table gives a complete comparison of test coverage between versions 1.5.0 and 1.6.0.

Specification	v1.5.0	v1.6.0	Difference
unknown	13	13	0
RFC 6120	1	1	0
RFC 6121	11	402	391
XEP-0030	19	19	0
XEP-0045	252	252	0
XEP-0048	1	1	0
XEP-0050	4	4	0
XEP-0054	10	10	0
XEP-0060	24	24	0
XEP-0080	2	2	0
XEP-0085	1	1	0
XEP-0092	1	1	0
XEP-0096	2	2	0
XEP-0107	2	2	0
XEP-0115	12	12	0
XEP-0118	2	2	0
XEP-0133	0	44	44
XEP-0198	10	10	0
XEP-0199	2	2	0
XEP-0215	6	6	0
XEP-0232	1	1	0
XEP-0313	2	2	0
XEP-0347	3	3	0
XEP-0352	6	6	0
XEP-0363	12	12	0
XEP-0374	2	2	0
XEP-0384	4	4	0
XEP-0410	0	3	3
XEP-0421	0	67	67
XEP-0433	0	19	19
XEP-0486	4	4	0

To be clear: the work doesn’t end here. There is still significant improvement to be made (and we’ve not yet used up all of the grant either!) - we just liked to give you all an update. In the works are additional test implementations, and a couple of new test runners. That should both increase coverage, but also allow our tests to be executed on even more CI/CD platforms!

Please get in touch if you have any ideas for improvement, or other feedback. We’d love to hear from you!

• Splash image courtesy of Imagine Buddy, Unsplash

We have been working on some changes to our Debian/Ubuntu package repository. If you use our repository to keep up to date with new Prosody packages, you need to take action before 4th August 2025 to continue receiving updates smoothly.

New repository instructions

The ‘apt’ utility has been moving towards a new format for specifying package repositories. If you are familiar with putting deb lines in a sources.list file, that method is changing.

The new preferred format for package repository configuration, known as “deb822”, has a number of advantages. One of them is simplified configuration of additional package repositories such as ours.

The new configuration format is already supported in Debian 12 (bookworm) and Ubuntu 22.04 LTS (jammy), which means you can use it right now.

If you already have our package repository configured, simply remove it and use the new instructions to add our updated configuration.

Signing key update

The reason existing deployments should do this before the 4th August is because from that day, we will be rolling our repository signing key to a new key. The old key is being retired because it is using older and weaker algorithms which are being phased out.

If you do not update the repository configuration on your system, apt will complain that our repository is not signed by a trusted key (typically a NO_PUBKEY error).

Old key fingerprint:

107D65A0A148C237FDF00AB47393D7E674D9DBB5 (short version: 7393D7E674D9DBB5)

New key fingerprint:

AD3B912769C5F962DCBA7956F7A37EB33D0B25D7 (short version: F7A37EB33D0B25D7)

To ensure you are ready for the new key, remove the existing configuration for our repository from your system, and follow the new instructions to configure our repository.

Support and questions

If you have any questions about this change, we’re always happy to help answer them in our community chat. Come and join us!

After twenty-five years, XMPP (Extensible Messaging and Presence Protocol) is still here. Mature, proven, modular, and standardized, it may well be the most solid foundation available today to build the future of messaging.

And now, XMPP is more relevant than ever: its resurgence is driven by European digital sovereignty efforts, renewed focus on interoperability, and the growing need for long-term, vendor-independent infrastructure.

Against this backdrop, the recent funding round around XMTP (Extensible Message Transport Protocol), a newly launched blockchain-based protocol marketed as a universal messaging layer, raises questions. The name clearly evokes XMPP, yet there is no technological or community connection. And while XMPP could easily serve as a transport layer for blockchain-integrated messaging, XMTP chooses to ignore this legacy and start anew.

So the real question is:
Why rebuild from scratch when a solid, extensible foundation already exists?

A Protocol That Never Went Away

XMPP is an open protocol for real-time messaging, designed from the start for federation and decentralization. Standardized by the IETF (RFC 6120, 6121, 7622…), it has powered mission-critical systems for decades: enterprise communication, mobile apps at scale, online games, IoT control platforms.

What makes XMPP especially powerful is not just its architectural simplicity, but its modular extensibility. The protocol evolves through an ecosystem of open specifications (XEPs), covering:

• End-to-end encryption (OMEMO, OTR)
• Multi-device synchronization (Message Archive Management)
• Group chat with subscriptions (MUC and MUCSub)
• PubSub (XEP-0060) for real-time data and events
• Interoperability bridges (SIP, MQTT, Matrix)
• And more…

XMPP has never stopped evolving. Dozens of new extensions are proposed every year. It remains one of the most adaptable foundations for building secure, federated, and future-ready messaging systems.

XMTP: A New Protocol with a Familiar Name, but a Different Approach

XMTP is a blockchain-native messaging protocol developed by Ephemera. It aims to connect wallets and dApps, leveraging decentralized infrastructure (libp2p, IPFS-style storage) and cryptographic identities.

The ambition is clear: to build a censorship-resistant, peer-to-peer messaging layer for Web3, rooted in crypto-native identity and cryptography.

However, the naming is misleading. In an older interview, XMTP co-founder Matt Galligan said the name is a blend of SMTP and XMPP. It was chosen to evoke familiarity, perhaps even as a tribute. But the result is confusing: XMTP is not an extension, evolution, or even distant cousin of XMPP. There is no shared architecture, no interoperability, no community overlap.

Why This Matters Right Now

This naming issue would be minor if it weren’t happening at a critical time for protocol design. Governments, especially in Europe, are actively exploring how to regain control over digital infrastructure. Messaging is central to this effort, especially with upcoming interoperability mandates, data sovereignty requirements, and the need for long-term maintainability.

XMPP is uniquely well-positioned to meet these needs. It is mature, open, extensible, and governed through transparent standards. It has a community of engineers, operators, and developers actively maintaining and evolving it.

Instead of inventing closed messaging stacks around new ecosystems, the more pragmatic move would be to build on robust, extensible layers like XMPP:

• Need to integrate blockchain identities? XMPP can map public keys or wallet identifiers through custom namespaces or JIDs.
• Need cryptographic message-level guarantees? XMPP already supports message metadata, signatures, and encryption.
• Need better privacy ? XMPP can be run over privacy-preserving transports like Tor.

In short: XMPP can serve as a transport layer for Web3 communication without discarding two decades of protocol maturity.

I understand that the main focus of XMTP is to prevent censorship, but this really a situation that can be mitigated efficiently with XMPP. You can for example run your own server or develop a fully decentralized approach that you can leverage as needed (e.g. xmpp-overlay).

Yes, there is still work to be done. For example, integrating MLS (Messaging Layer Security) into XMPP would provide a strong foundation for interoperable, end-to-end encrypted group messaging. But that only reinforces the point: Why ignore what’s already working and extensible?

Use What Works

New ideas are always welcome. Innovation matters. But messaging protocols are infrastructure. Reinventing them lightly, is not harmless, especially when it is done without acknowledging existing efforts.

Instead of multiplying disconnected stacks, we should double down on what works.

XMPP is here. It works. It evolves. It can be extended, adapted, and integrated, even into blockchain-native systems, without sacrificing openness or interoperability.

That may be its most valuable trait today: Still standing, while so many overengineered protocols have come and gone.

Remote Patient Monitoring (RPM) is changing how care is delivered. By tracking health data through connected devices outside traditional settings, it helps clinicians act sooner, reduce readmissions, and focus resources where they’re most needed. With rising NHS pressures and growing demand for digital care, RPM is becoming central to how both public and private providers support long-term conditions, recovery, and hospital-at-home models. This guide explores how RPM works, where it’s gaining ground, and why healthcare leaders are paying attention.

What is Remote Patient Monitoring?

RPM refers to systems that collect patient data remotely using at-home or mobile devices, which clinicians then review. These systems can work in real time or at scheduled intervals and are often integrated with a patient’s electronic medical record (eMR) or practice management system (PAS). The goal is to monitor patients without needing in-person visits, while still keeping clinical oversight.

Devices Commonly Used in RPM

The success of any RPM programme depends on the devices that power it. These tools collect, track, and transmit key health data- either in real time or at regular intervals. Whether issued by clinicians or connected through a patient’s tech, they underpin the delivery of safe, responsive remote care.

These devices support the management of a wide range of conditions, including diabetes, heart disease, COPD, asthma, sleep disorders, high-risk pregnancies, and post-operative recovery.

Device Type	Primary Function
Blood pressure monitors	Measure systolic/diastolic pressure for hypertension monitoring
Glucometers	Track blood glucose levels for diabetes management
Pulse oximeters	Monitor oxygen saturation (SpO2) and heart rate
ECG monitors	Detect heart rhythm abnormalities such as arrhythmias
Smart inhalers	Track usage and technique for asthma or COPD
Wearable sensors	Monitor movement, sleep, temperature and heart rate
Smart scales	Measure weight trends, often linked to fluid retention or post-op care
Sleep apnoea monitors	Detect interrupted breathing patterns during sleep
Maternity tracking devices	Monitor fetal heart rate, maternal blood pressure, or contractions

These tools can either be prescribed by clinicians or integrated with consumer health tech like smartphones or smartwatches. 

For example, a cardiologist may use a mobile ECG app paired with a sensor to track arrhythmias from home.

Safety and Regulation

The boundary between wellness wearables and clinical devices is still being defined. While some tools simply gather data, others have therapeutic applications, such as managing pain or respiratory issues. This matters for compliance. Devices that influence treatment decisions must meet higher regulatory standards, particularly around safety, accuracy, and data security. Developers and suppliers need to stay aligned with MHRA or equivalent guidance to avoid risk to both patients and business continuity.

How Remote Patient Monitoring Works

RPM follows a structured process:

1. Data collection from connected medical devices
   
2. Secure transmission to a clinical platform
   
3. Integration with existing systems
   
4. Analysis and alerting via algorithms or clinician review
   
5. Intervention where thresholds are breached
   
6. Feedback to patients through apps or direct communication

RPM Adoption is Accelerating

Globally, the uptake of RPM is increasing. In the US, patient usage rose from 23 million in 2020 to 30 million in 2024 and is forecast to reach over 70 million by the end of 2025 (HealthArc). The NHS is also scaling digital pathways. Over 100,000 patients have been supported by virtual wards in England, with NHS England increasing capacity to 50,000 patients per month by winter 2024. RPM is central to this shift.

Core Technologies in RPM

These technologies work behind the scenes to capture, transfer, and make sense of patient data, so that clinicians have timely, accurate insights to act on.

Wearables and sensors
Track vital signs like heart rate, oxygen levels, and movement patterns.

Mobile health apps
Used by patients to report symptoms, manage medications, and receive support.

Telemedicine platforms
Enable direct communication between patients and clinicians through chat, phone, or video.

Analytics engines
Help identify risk trends or changes in condition using automated flagging systems.

Why RPM Matters for Healthcare Leaders

The NHS is under sustained pressure. According to the NHS Confederation, over 7.6 million people are currently on elective care waiting lists, while ambulance delays and A&E overcrowding persist. RPM supports care outside the hospital by freeing up beds, reducing readmissions, and improving patient flow. At a system level, RPM:

• Cuts avoidable admissions
  
• Shortens hospital stays
  
• Reduces time-to-intervention
  
• Frees up staff capacity
  
• Lowers infection risk
  

Cost savings are also significant. Some estimates suggest RPM can reduce total healthcare expenditure by 20–40%, particularly for chronic conditions.

RPM in Action: Key Use Cases

The real impact of RPM is seen in the way it supports different stages of the care journey. Here are some of the most common and most effective use cases.

Chronic Disease Management

RPM allows patients with diabetes, COPD, or hypertension to track metrics like blood pressure, oxygen levels or glucose and share results with care teams. Interventions can be made earlier, reducing the chance of deterioration or escalation.

Mental Health Monitoring

Wearables can capture signs of stress or low mood by tracking heart rate variability, sleep patterns, and daily activity. RPM helps clinicians spot early signs of relapse in conditions like anxiety and depression, particularly when patients are less likely to reach out themselves.

Post-Operative Recovery

Patients recovering from surgery can be monitored for wound healing, temperature spikes, or pain trends. A 2023 BMC Health Services Research study showed RPM helped reduce six-month mortality rates in patients discharged after heart failure or COPD treatment.

Elderly Care

For older adults, RPM supports safety without constant in-person contact. Devices with fall detection, medication reminders, and routine tracking can help carers respond quickly to changes, reducing emergency visits and supporting independent living.

Clinical Trials

RPM speeds up trials by reducing the need for travel, offering more continuous data, and improving patient adherence.

Pandemic and Emergency Response

During COVID-19, RPM enabled safe monitoring of symptoms like oxygen saturation or fever, supporting triage and resource allocation when systems were overwhelmed.

Benefits Across the System

RPM not only benefit patients, but it also improves outcomes and operations across every part of the health and care system. Here’s how you can gain from its use.

	Key Benefits
Patients	Greater independence, faster recovery, fewer hospital visits
Clinicians	Real-time data visibility, increased capacity, and better focus on complex cases
Carers	Peace of mind, early alerts, and less reliance on manual checks
ICBs & Providers	Lower readmissions, improved resource use, and more coordinated care

Where Tech Comes In

Behind every reliable RPM system is a reliable tech stack. In high-risk, high-volume environments like healthcare, platforms need to be built for stability, security and scalability. 

That’s why some platforms use programming languages such as Erlang and Elixir, trusted across the healthcare sector for their ability to manage high volumes and maintain uptime. These technologies are being adopted in healthcare systems that prioritise performance, security, and scalability. 

When built correctly, RPM infrastructure allows providers to:

• Maintain continuous monitoring across patient groups
  
• Respond quickly to emerging clinical risks
  
• Scale services confidently as demand increases
  
• Minimise risk from tech failure or data breach

To conclude

Patients recover better when they’re in a familiar place, supported by the right tools and professionals. Hospitals function best when their time and space are reserved for those who truly need them. Remote Patient Monitoring is not just a digital upgrade. It’s a strategic shift, towards smarter, more responsive care.

Ready to explore how RPM could support your digital care strategy? Get in touch.

The post What is Remote Patient Monitoring? appeared first on Erlang Solutions.

Release Highlights:

This release focus on integration in a wider federated network, with support for spam fighting features, better compliance with Matrix network and native support for PubSub Server Information to have your server count as part of the wider XMPP network (for example, you can register your server on XMPP Network Graph).

• Spam filter with block lists support
• Support for XEP-0485: PubSub Server Information
• Support for older Matrix rooms in ejabberd XMPP <-> Matrix Gateway

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

List of Contents:

• Workaround for zip module in unpatched Erlang
• Erlang/OTP 28 supported
• Erlang/OTP 25 required
• New mod_antispam with RTBL support
• New mod_pubsub_serverinfo
• Improvements in Matrix gateway
• XEP-0431: Full Text Search in MAM
• New rest_proxy options
• New auth_password_types_hidden_in_scram1 option
• New host_alias option
• New predefined keywords
• Link to Converse in WebAdmin
• Updates in source code formatting
• New target test-group
• Acknowledgments
• Improvements in ejabberd Business Edition
• ChangeLog
• ejabberd 25.07 download & feedback

Below is a detailed breakdown of the improvements and enhancements:

Workaround for zip module in unpatched Erlang

A vulnerability was published three weeks ago that affects the zip library included in Erlang/OTP: CVE-2025-4748: Absolute path in zip module.

The ejabberd installers and the ejabberd container image already use a patched version Erlang/OTP 27.3.4.1, but the ecs container image uses Erlang/OTP 26.2.

ejabberd 25.07 includes a specific protection that workarounds that vulnerability regardless of what Erlang/OTP version you are using.

Erlang/OTP 28 supported

Updating ejabberd to support Erlang/OTP 28 has required quite some work due to the replacement of ancient ASN.1 modules from Erlang/OTP public_key library.

Improvements were done on ejabberd, fast_xml, p1_acme, xmpp libraries, and also rebar/rebar3 binaries were recompiled.

However, there is still one last problem not yet solved which implies that ACME support is broken when using Erlang/OTP 28.0.1. The fix will probably be included in the next Erlang/OTP 28 release.

Erlang/OTP 25 required

The minimum Erlang/OTP version supported since now is 25.0.

However, we are aware there are still a few specific cases where older Erlang/OTP versions are being used. For that reason, the source code support for those versions is still available, and static source code analysis tools like xref and dialyzer are still run with Erlang/OTP 20 in runtime.yml.

If you really need to use ejabberd with Erlang/OTP 20 - 24, you can bypass the version check during compilation with this ./configure option: ./configure --with-min-erlang=9.0.5

New mod_antispam with RTBL support

mod_antispam is a new module that filters spam messages and subscription requests received from remote servers based on Real-Time Block Lists (RTBL), text lists of known spammer JIDs and/or URLs mentioned in spam messages.

This module is based in mod_spam_filter which was originally published in ejabberd-contrib. If you were using that module, you can update your configuration and start using mod_antispam instead.

New mod_pubsub_serverinfo

mod_pubsub_serverinfo adds support for XEP-0485: PubSub Server Information to expose S2S information over the Pub/Sub service.

This module was originally published in ejabberd-contrib. If you were using that module, you can remove it, as now it&aposs included in ejabberd.

Improvements in Matrix gateway

While we are preparing another big update for the Matrix gateway. The most important change is that we added support to a larger number of room versions. It allows users to let them join a lot of rooms that were already created a while back and running an older version of the room protocol.

Here is the main list of changes to the matrix gateway:

• mod_matrix_gw: Support older Matrix rooms versions starting from version 4
• mod_matrix_gw: Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw: Fix key validation in mod_matrix_gw_s2s:check_signature
• mod_matrix_gw: When encoding JSON, handle term that is key-value list (#4379)

XEP-0431: Full Text Search in MAM

Support for XEP-0431: Full Text Search in MAM has been added. For now, it only works if mod_mam is using the MySQL storage backend.

New rest_proxy options

With those new options you can make modules using rest.erl module (like ejabberd_oauth_rest) use HTTP proxy when performing HTTP requests.

The related new top level options are:

• rest_proxy: Address of a HTTP Connect proxy
• rest_proxy_port: Port of a HTTP Connect proxy
• rest_proxy_username: Username used to authenticate to HTTP Connect proxy (optional)
• rest_proxy_password: Password used to authenticate to HTTP Connect proxy (optional)

New auth_password_types_hidden_in_scram1 option

This option was added to help with adding new password types in auth_stored_password_types option to existing installations. Adding new password type made server advertise it to clients, but that caused problems for users that didn&apost have new password type stored, and which clients used SASL1 authentication, if client tried to authenticate with it, authentications would fail.

With this new option, server admin can choose which password types should not be presented to SASL1 clients (they still will be offered to SASL2 clients for users that have password compatible with this type), to later after users update password to have new type, being able to enable them.

This option takes list of password types from auth_stored_password_types that should be disabled

auth_password_types_hidden_in_scram1:
  - scram_sha512
  - scram_sha256

New hosts_alias option

The new hosts_alias toplevel option is used by the ejabberd_http listener to resolve domain names into vhosts served by ejabberd.

For example, ejabberd is serving the vhost redacted.lan, but you configured DNS so xmpp.redacted.lan resolves to that host. If you configure in ejabberd:

hosts:
  - redacted.lan

hosts_alias:
  xmpp.redacted.lan: redacted.lan

listen:
  -
    port: 443
    ip: "::"
    tls: true
    module: ejabberd_http
    request_handlers:
      "/bosh": mod_bosh
      "/ws": ejabberd_http_ws
      "/conversejs": mod_conversejs

modules:
  mod_bosh:
  mod_conversejs:
    bosh_service_url: "https://xmpp.redacted.lan/bosh"
    websocket_url: "wss://xmpp.redacted.lan/ws"

then ejabberd_http will accept https://xmpp.redacted.lan/conversejs and deliver it to vhost redacted.lan

In previous ejabberd releases, an option called default_host was documented for the ejabberd_http listener, but it didn&apost work at all correctly.

New predefined keywords

A few months ago, ejabberd 25.03 introduced new predefined keywords like HOST, HOME, VERSION and SEMVER.

And now two more predefined keywords are added:

• CONFIG_PATH: Path to the configuration directory, for example "/home/ejabberd/opt/ejabberd/conf"
• LOG_PATH: Path to the log directory, for example "/home/ejabberd/opt/ejabberd/logs"

Those keywords are specially useful when configuring mod_antispam: you can copy text files to the configuration directory where the module will read them, and also configure the module to write the dump file on the log directory.

Link to Converse in WebAdmin

mod_conversejs has a new tiny improvement: it adds a link in the WebAdmin menu to the local Converse instance.

Additionally, when HTTPS with encryption is enabled, that link logins directly with the account used in WebAdmin.

Updates in source code formatting

A year ago, ejabberd 24.06 introduced make format and make indent.

Now that script uses Perl to work correctly in Mac OS too.

And there&aposs a new section in the documentation, see Format that describes how to use that feature, and tips for Git hooks and Git alias.

New target test-group

ejabberd includes a Common Test suite with 1456 test cases, which typically takes around 10 minutes to run.

When developing new source code, you may want to run only tests from a specific group and a specific storage backend, as documented in the ejabberd testing documentation:

CT_BACKENDS=mnesia rebar3 ct --suite=test/ejabberd_SUITE --group=antispam_single

To facilitate this usage, a new target is available:

CT_BACKENDS=mnesia make test-antispam_single

Acknowledgments

We would like to thank the contributions to the source code, documentation, and translation provided for this release by:

• Stefan Strigler and Holger Weiß for mod_antispam and the original mod_spam_filter
• Stefan Strigler for mod_pubsub_serverinfo and test-group target
• Bruno MATEU for the missing comma in postgres schema
• GiannosOB updated the Greek translation
• Tamil Neram updated the Tamil translation
• Максим Горпиніч updated the Ukrainian translation

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

Improvements in ejabberd Business Edition

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

Monitoring

The following new metrics has been added to mod_mon:

• message_receive_packet: number of message stanzas of any type received by the server on c2s connections
• message_send_packet: number of message stanzas of any type send by the server on c2s connections
• iq_receive_packet: number of IQ stanzas received by the server on c2s connections
• iq_send_packet: number of IQ stanzas send by the server on c2s connections
• iq_get_receive_packet: number of IQ stanzas of type get received by the server on c2s connections
• iq_set_receive_packet: number of IQ stanzas of type set received by the server on c2s connections
• iq_result_receive_packet: number of IQ stanzas of type result received by the server on c2s connections
• iq_error_receive_packet: number of IQ stanzas of type error received by the server on c2s connections
• iq_get_send_packet: number of IQ stanzas of type get send by the server on c2s connections
• iq_set_send_packet: number of IQ stanzas of type set send by the server on c2s connections
• iq_result_send_packet: number of IQ stanzas of type result send by the server on c2s connections
• iq_error_send_packet: number of IQ stanzas of type error send by the server on c2s connections

The metrics c2s_receive & c2s_send now count all stanzas on c2s connections.

The cpu_usage probe now gives more reliable values.

Prometheus support has been improved.

A new mod_mon_dump command has been added to dump probe values to help debug the monitoring setup.r

Mobile push

It is now possible to use rest_proxy* options to use a HTTP proxy for mod_applepush & mod_gcm outgoing calls.

ChangeLog

This is a more complete list of changes in this ejabberd release:

Security fix

• ext_mod: Add temporary workaround for zip including absolute path

Compilation

• Raise the minimum Elixir tested version to 1.14.0 (#4281)
• Raise Erlang/OTP minimum requirement to 25.0 (#4281)
• configure.ac: Allow to specify minimal erlang version using --with-min-erlang
• Makefile.in: Add target test-<group>
• rebar3-format.sh: Replace csplit with perl
• Container: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4
• Installers: Bump Erlang/OTP 27.3.4.1, Elixir 1.18.4, libexpat 2.7.1, OpenSSL 3.5.1

Configuration and Tests

• Add rest_proxy* options to configure proxy used by rest module
• ejabberd_c2s: Add auth_password_types_hidden_in_scram1 option
• ejabberd_http: Remove unused default_host option and state element
• ejabberd_http: New option hosts_alias and function resolve_host_alias/1 (#4400)
• New predefined keywords: CONFIG_PATH and LOG_PATH
• Fix macro used in string options when defined in env var
• Use auxiliary function to get $HOME, use Mnesia directory when not set (#4402)
• ejabberd_config: Better lists:uniq substitute
• Tests: update readme and compose to work with current sw versions
• Update Elvis to 4.1.1, fix some warnings and enable their tests

Erlang/OTP 28 support

• Add workaround in p1_acme for Jose 1.11.10 not supporting OTP 28 ecPrivkeyVer1 (#4393)
• Bump fast_xml and xmpp for improved Erlang/OTP 28 support
• Bump xmpp and p1_acme patched with Erlang/OTP 28 support
• Fix make options in Erlang/OTP 28 (#4352)
• Fix crash in rebar3 cover with Erlang/OTP 28 (#4353)
• Rebar/Rebar3: Update binaries to work with Erlang/OTP 25-28 (#4354)
• CI and Runtime: Add Erlang/OTP 28 to the versions matrix

SQL

• Fix mnesia to sql exporter after changes to auth tables
• Update code for switching to new schema type to users table changes
• Add mssql specific implementation of delete_old_mam_messages
• Make delete_old_mam_messages_batch work with sqlite
• ejabberd_sm_sql: Use misc:encode_pid/1
• mysql.sql: Fix typo in commit 7862c6a when creating users table
• pg.sql: Fix missing comma in postgres schema (#4409)

Core and Modules

• ejabberd_s2s_in: Allow S2S connections to accept client certificates that have only server purpose (#4392)
• ext_mod: Recommend to write README.md instead txt (processone/ejabberd-contrib#363)
• ext_mod: Support library path installed from Debian (processone/ejabberd-contrib#363)
• ext_mod: When upgrading module, clean also the compiled directories
• gen_mod: Add support to prepare module stopping before actually stopping any module
• mod_antispam: Imported from ejabberd-contrib and improved (#4373)
• mod_auth_fast: Clear tokens on kick, change pass and unregister (#4397)(#4398)(#4399)
• mod_conversejs: Add link in WebAdmin to local Converse if configured
• mod_mam: Present mam full text search in xep-431 compatible way
• mod_mam_mnesia: Handle objects that don&apost need conversion in transform/0
• mod_matrix_gw: Don&apost send empty messages in Matrix rooms (#4385)
• mod_matrix_gw: Support older Matrix rooms versions starting from version 4
• mod_matrix_gw: When encoding JSON, handle term that is key-value list (#4379)
• mod_matrix_gw_s2s: Fix key validation in check_signature
• mod_mix and mod_muc_rtbl: Support list of IDs in pubsub-items-retract (processone/xmpp#100)
• mod_pubsub_serverinfo: Imported module from ejabberd-contrib (#4408)
• mod_register: Normalize username when determining if user want to change pass
• mod_register: Strip query data when returning errors
• WebAdmin: New hooks webadmin_menu_system to add items to system menu

Full Changelog

https://github.com/processone/ejabberd/compare/25.04...25.07

ejabberd 25.07 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.

In today’s interconnected world, digital sovereignty has become increasingly important for individuals and organizations seeking to maintain control over their data, infrastructure, and technologies. Openfire, an open-source, real-time collaboration (RTC) server that uses the XMPP (Extensible Messaging and Presence Protocol) protocol, offers a secure and customizable communication platform.

About Openfire

Openfire, produced by the IgniteRealtime community, is a mature, robust and scalable XMPP server that facilitates real-time communication and collaboration. It supports a wide range of features, including instant messaging, group chat, voice and video calls, and file sharing. Openfire’s open-source nature and extensive plugin architecture make it a versatile and customizable solution for organizations of all sizes. Openfire’s compatibility with various XMPP clients, including but not limited to IgniteRealtime’s own Pádè and Spark clients, further enhances its versatility and utility.

Data Privacy and Security

One of the key aspects of digital sovereignty is the ability to protect sensitive information and ensure data privacy. Openfire provides a secure communication platform that supports end-to-end encryption, secure authentication, and fine-grained access control. By hosting Openfire in-house or on a private cloud, organizations can maintain control over their communication data and reduce the risk of data breaches or unauthorized access. Additionally, Openfire’s open-source nature allows users to audit the code and verify the security of the platform, further enhancing trust and transparency.

Customization and Flexibility

Openfire offers a high degree of customization and flexibility, enabling organizations to tailor the platform to their specific needs and requirements. With a wide range of plugins and extensions, Openfire can be easily integrated with existing systems and workflows, allowing users to create a communication environment that aligns with their unique processes and preferences. This enables organizations to maintain control over their communication tools and adapt them to their evolving needs.

Compliance and Regulatory Control

Openfire’s customizable and secure nature makes it an ideal platform for organizations operating in regulated industries or jurisdictions with strict data protection laws. By hosting Openfire in-house or on a private cloud, organizations can ensure that their communication data remains within their control and complies with relevant regulations. Furthermore, Openfire’s extensive logging and monitoring capabilities enable users to demonstrate compliance and maintain a clear audit trail of their communication activities.

Interoperability with Other XMPP Solutions

Openfire’s interoperability with other XMPP-based platforms and clients is another significant advantage. By supporting the XMPP protocol, Openfire enables seamless communication and collaboration with users on other XMPP servers and clients, fostering a decentralized and open communication ecosystem. This interoperability allows organizations to maintain control over their communication infrastructure while still being able to connect and collaborate with external partners, customers, or stakeholders. Moreover, Openfire’s compatibility with other XMPP solutions reduces the risk of vendor lock-in and promotes a more open and competitive market for communication tools.

Conclusion

Openfire offers a powerful and secure communication platform that supports digital sovereignty by enabling organizations to maintain control over their data, infrastructure, and technologies. With its robust security features, customization capabilities, compliance-friendly nature, and interoperability with other XMPP solutions like Pádè and Spark, Openfire empowers users to create a communication environment that aligns with their unique needs and requirements. As digital sovereignty continues to gain importance in today’s interconnected world, Openfire provides a valuable solution for organizations seeking to enhance their autonomy, privacy, and security in digital interactions.

---

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

1 post - 1 participant

Read full topic

XMPP Newsletter Banner

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

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

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

XMPP Events

• DebConf25: The 26th Debian Conference in Brest, France, from July 14th to 19th 2025, will feature:
  • Federated instant messaging, 100% debianized by Elena Grandi. A short talk (20 minutes) that will take place at the Grand amphi room on Monday, July 14th at 18:00 hours.
  • Jabber/XMPP BoF session, hosted by Martin. A BoF (Birds of a Feather) meeting (45 minutes) that will take place at ‘Room: B03-035’ on monday July 14th at 14:00 hours.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM UTC+2 (online event, with web meeting mode and live streaming).

Videos

Comunicación Libre, Segura y Descentralizada: Taller abierto de XMPP by Gnuxero for the Club de Software Libre. [ES]

XMPP Articles

• Introducción a XMPP - Capítulo 1 by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 2 - OMEMO by Jacobo Da Riva Muñoz. [ES]
• Introducción a XMPP - Capítulo 3 - Grupos by Jacobo Da Riva Muñoz. [ES]
• Mensajería segura y abierta mediante CONVERSATIONS Xmpp on alt43.es. [ES]
• Recuperando a soberania e a privacidade da sua comunicação pessoal e corporativa by Isadora Ribeiro. [PT_BR]
• Mitigating MITMs in XMPP by Amolith for the JMP Blog.
• Setting up Slidge Gateway with Openfire for use with Whatsapp, Matrix and Telegram by surfbum for the Ignite Realtime Community.
• Per-application passwords in Tigase from the Tigase Posts.
• Join the XMPP-IT Community: Your Help Matters! The XMPP-IT community is launching a call for active collaboration — no need to be an expert, and it’s not paid work, just shared participation. From translations to testing software, writing wiki content or contributing code, there’s room for everyone. [IT]

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-2 for Android.
• Converse.js has released version 11.0.1 of its open-source and web-based XMPP chat client. The desktop version can be downloaded from here. Make sure to check out the release link for all the details!
• Gajim has released version 2.3.0 (2.3.1 and 2.3.2) with a fresh new look featuring Adwaita, adding new features, improvements, quite a few changes and bug fixes. Head over to their news section for more information. And don’t forget to read the changelog for all the details!

Gajim’s 2.3.0 sleek fresh new look featuring Adwaita

• Libervia has received NLnet funding to ‘Implement serverless (with RELOAD) and reduce metadata exposure’ (Serverless and Metadata Reduction for XMPP). This project will reduce metadata exposure and enable decentralized, serverless communication. Work will focus on end-to-end encryption specs for roster (contact list) information. These changes will be implemented in the Libervia ecosystem through Tor integration, which will help anonymize connections and reduce IP tracking. A second focus area is advancing serverless communication by implementing the RELOAD protocol XEP-0415 and leveraging end-to-end authentication via XEP-0416 and XEP-0417. This project will strengthen XMPP and Libervia’s privacy and availability, enabling their use in environments where servers may be unavailable or inaccessible.
• Monocles has released versions 2.0.8, 2.0.9, 2.0.10 and 2.0.11 of its chat client for Android, featuring many new functions and fixes.
• Prose has released versions 0.10.2 and 0.11.0 of its web frontend prose-web-app.

XMPP Servers

• The Ignite Realtime community is thrilled to announce the release of the latest versions of their popular open-source XMPP server. Openfire 5.0.0 just came out, immediately followed by Openfire 5.0.1 which should be its drop-in replacement. The new releases come packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. You can download Openfire 5.0.1 straight from the website and read the documentation to get started. Don’t forget to check out the changelog for a list of all the changes that have been made!
• MongooseIM has released version 6.4.0 of its Enterprise Instant Messaging Solution. This release brings new features, changes, various fixes and improvements. For more information, make sure to check out the changelog and the documentation.

XMPP Libraries & Tools

• go-xmpp versions 0.2.15 and 0.2.16 have been released.
• peertube-plugin-livechat versions 13.0.0 and 14.0.0 have been released.

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.

• Data Policy
  • This document specifies metadata on how an entity handles its data (encryption, data retention, etc).
• Data Forms File Input Element
  • This specification defines an element which can be used with data forms to let users upload one or more files.

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 0.1.4 of XEP-0284 (Shared XML Editing)
  • Fix the registrar section.
  • Format the glossary better.
  • Add missing <state/> wrappers in examples.
  • Write an XML Schema. (egp)
• Version 0.9.0 of XEP-0384 (OMEMO Encryption)
  • Device labels must be signed
  • Allow empty device list in XML schema
  • Reworded security consideration that could be interpreted as forbidding trust mechanisms like BTBV/TOFU
  • Added section about dealing with lack of presence subscription
  • Removed reference to omemo-session-healing (th)
• Version 1.0.3 of XEP-0388 (Extensible SASL Profile)
  • Add missing minOccurs=‘0’ to additional-data in <continue/> in XML schema. (lnj)
• Version 0.1.1 of XEP-0485 (PubSub Server Information)
  • Fixed references to XEP identifier. (gdk)
• Version 0.1.1 of XEP-0498 (Pubsub File Sharing)
  • Fix wrong shortname and add tags. (jp)

Last Call

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

• No Last Call this month.

Stable

• No XEPs moved to Stable 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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• German: xmpp.org
  • Translators: Millesimus
• Italian: notes.nicfab.eu
  • Translators: nicola
• Portuguese: xmpp.org
  • Translators: Paulo
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

In January 2007, Ignite Realtime released the red5 plugin for Openfire which added the flash based open source Red5 media server as a plugin to Openfire (Wildfire). A year later, we added red5Phone, the first open source SIP based soft phone in a web browser.

Eighteen years later, WebRTC is now well established as the leading standard for audio and video conferencing and all that leading edge pioneer work here at Ignite evolved into Pàdé the web client, it’s supporting Openfire plugin and other plugins and clients supporting other audio and video use cases beyond meetings.

XMPP is now back in fashion and Openfire has always been a choice XMPP solution because it has the X factor. It is eXperienced, eXtensible, fleXible, eXperimental and eXciting and allowing use to easily integrate it with a wider diversity of signalling and media protocols and services.

However, the new attraction for XMPP is the push for open standards and messaging interoperability. Consequently, being able to also provide media (audio and video) interoperability in XMPP through Openfire will become one of the things we choose to focus on at Ignite going forward with audio and video communications. As previously hinted, we are moving forward with simplified, easy to maintain open standards that make media interoperability possible.

For now, that will be Online Meetings for audio and video conferencing services that have a web front end UI like Jitsi, Galene and BroadcastBox. For deeper integration into XMPP, that will be the Media Streams which is the XMPP wrapper to WHIP and WHEP.

In practice, it means development will stop on the Pade plugin for Openfire and all Jitsi based development and integration will only continue with Openfire Meetings plugin (ofmeet) which will become XEP 483 compliant. The Galene plugin for Openfire will also become XEP 483 compliant and both plugins can serve the new Online Meetings plugin for in ConverseJS web client.

The Openfire plugin called Ohun for audio conferencing is deprecated and a new plugin called OrinAyo which supports both music streaming and audio conferencing is in development and will become available very soon.

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

2 posts - 2 participants

Read full topic

Openfire 5.0.1 has been released!

Openfire, created by the Ignite Realtime community is a powerful chat server that lets you communicate in real-time with your team or friends. It’s like having your own private messaging solution, but with more control and customization options.

Following the release of Openfire 5.0.0 last week, a few annoying issues were reported. These are addressed in this new release:

• The Windows Launcher works again
• The bundled ‘search’ plugin is updated to address an issue in the admin console
• Certificate-based authentication can be used again with client connections
• Improvements were applied to the detection of invalid (‘ghost’) group chat users that originate from federated domains.
• The Admin Console translations for the French and Dutch languages got a significant update. Many thanks to the community members that provided those translations!

This update should be a drop-in replacement for version 5.0.0. You can find the installers in the usual places, like our Downloads page!

The 5.0.1 release of Openfire is a direct result of receiving contributions and feedback from the community. Keep it coming! As you can see, your effort, no matter how big or small, can have a direct result! Please join our community forum or group chat and let us know what you think!

Finally: GitHub appears to claim that this is our 100th release of Openfire/Wildfire. We’re not at all sure that’s an accurate count, but we’ll take the opportunity to celebrate anyway! Come join the celebrations in our chatroom! The fiftieth person to join wins a no-expenses-paid day trip to the nearest park bench!

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

1 post - 1 participant

Read full topic

Slidge is an XMPP gateway designed to connect your account to third-party chat networks like WhatsApp, Telegram, or Matrix. It acts as a bridge, allowing you to send and receive messages with all your contacts directly from your single, preferred XMPP client.

This guide provides instructions to configure an Openfire XMPP server to work with Slidge and the Slidge WhatsApp plugin as an example.

Openfire requires configuration in its Admin Console to allow external components like Slidge to connect and to grant them the necessary permissions for features like file transfers.

Prerequisites

Before you begin, ensure you have:

• A running and accessible Openfire server.
• Administrative access to the Openfire Admin Console.
• Root or sudo access to the Debian/Ubuntu server where you will install Slidge.
• The Slidge Debian repository added to your system, as per the official Slidge installation instructions (Installation - Slidge documentation).

This guide used the below install method.

• (https://codeberg.org/slidge/debian)

Step 1: Configure Openfire Services

You must configure Openfire to accept the bridge connection and handle file transfers before you configure Slidge.

1.1. Install and Configure HTTP File Upload Plugin

Slidge requires a working XEP-0363 HTTP File Upload component to send and receive images, videos, and other files.

• Log in to your Openfire Admin Console.
• Navigate to Server → Plugins → Available Plugins.
• Find the plugin named “HTTP File Upload” and click the green + icon to install it.
• After installation, navigate to Server → Server Settings → HTTP File Upload.
• Ensure the box for “Enable HTTP File Upload” is checked.

Take note of the configuration. For a standard setup behind a reverse proxy, your public URL might be https://upload.your.domain while the internal service address is httpfileupload.your.domain.
We will use this internal address later.

• Click Save Settings.

1.2. Enable External Component Connections

This step allows Openfire to listen for incoming connections from bridges.

In the Openfire Admin Console, navigate to Server → Server Settings → External Components.

• Ensure the service is Enabled.
• Under the “Allowed to Connect” section, define your new WhatsApp bridge:
• Subdomain: whatsapp (This will create the JID whatsapp.your.domain).
• Shared Secret: Create a new, strong, random password.
• Copy this shared secret to a safe place. You will need it for the Slidge configuration.
• Click “Add”.

Your Openfire server is now ready for Slidge.

Step 2: Install and Configure Slidge

Now, on your server’s command line, we will install and configure the Slidge packages.

2.1. Install Slidge Packages

As per these instructions: slidge/debian: Debian (unofficial) package bundling slidge-based gateways. - Codeberg.org

2.2. Configure common.conf

This file contains settings shared by all your bridges.

• Edit the file: nano /etc/slidge/conf.d/common.conf
• Set the following parameters:

  admins=admin@your.domain
  upload-service=httpfileupload.your.domain
  user-jid-validator=.*@your.domain
  server=localhost
  #port=5347 #(default slidge setting)
  port=5275 #(openfire default)
  

2.3. Configure whatsapp.conf

This file contains the settings for the WhatsApp bridge specifically.

• Create or edit the file: nano /etc/slidge/whatsapp.conf
  (I just did mv /etc/slidge/whatsapp.conf.example /etc/slidge/whatsapp.conf)
• Add the connection details to match what you configured in Openfire:

  # The XMPP address of your bridge component
  jid = whatsapp.your.domain
  # The shared secret you created in the Openfire admin console
  secret = PASTE_YOUR_SHARED_SECRET_HERE
  legacy-module=slidge.plugins.whatsapp
  

Step 3: Start and Verify Slidge

Enable and start the Slidge WhatsApp service:

sudo systemctl enable --now slidge@whatsapp

Check the logs to ensure it started without errors:

sudo journalctl -u slidge@whatsapp -f

Step 4: User Registration and Login

From your XMPP client (e.g., Conversations, Gajim), discover the services on your server. You should see the “WhatsApp” bridge listed.

Register with the service.

The bridge (whatsapp.your.domain) will be added to your contacts. Send it the message login or qr.

(I just started a conversation with a new chat to whatsapp.you.domain and typed help, it gives a list of commands, follow these e.g register)

You may see warnings in the Slidge log about “IQ privileges not granted” for pubsub and bookmarks (XEP-0356).

Troubleshooting: Fixing Permission Warnings (not yet implemented in Openfire so can’t fix this just yet)

For good luck I also did this at the end.

sudo systemctl restart openfire
sudo systemctl restart slidge@whatsapp

3 posts - 2 participants

Read full topic

Say hello to Márton Veres, our new Business Unit Leader for London.
From international consulting to leading delivery teams, Márton’s journey to this role has been anything but ordinary. In our latest team interview, he shares what excites him most about this next chapter, his vision for growing our presence in London, and a personal challenge he’s set for the summer.

Get to know Márton and his take on leadership, community, and what’s ahead.

Congratulations on your new role as Business Unit Leader (BuL) for London. Could you share more about your new role at Erlang Solutions?

Thanks! I’m proud to take on the BuL role after four years in project and delivery management here. I’ll be leading the London team, shaping and executing our business strategy, and driving growth through client relationships and new opportunities.

 I’m looking forward to working more closely with our UK colleagues, connecting with the Erlang and Elixir communities, and strengthening our presence in the London market.

What have been some highlights of your career so far?

My journey has always been at the intersection of business and technology. I spent my first eight years as an IT consultant in FinTech and Telco, helping align business needs with tech solutions. Then, I led project management teams at Deutsche Telekom for eight years, gaining deep experience in large-scale delivery. 

At Erlang Solutions, I’ve worked alongside brilliant engineers on cutting-edge Erlang and Elixir projects. The mix of consulting, corporate, and agile tech environments has given me a well-rounded perspective that I bring into this new role.

What are you most looking forward to in your new position?

I’m especially excited to deepen our work in London’s FinTech, Digital Health, and Energy sectors. I’m passionate about supporting and growing our team using servant leadership and business coaching skills I’ve developed, including through a recent certification programme supported by Erlang Solutions. 

Digital Health is a particular interest of mine, and I’d love to expand on the work we’ve done with the NHS, HCA Healthcare, and Baxter. Being part of the Trifork Group also opens up opportunities to collaborate on end-to-end solutions, especially with their Digital Health expertise.

Outside of work, what are you most excited about this summer in London?

I’m training for the Wimbledon Half Marathon in September. My goal is to finish in under two hours! It’s a great way to stay focused and make the most of the summer. Balancing work and personal goals like this keeps me energised.

Final thoughts

It’s been a pleasure catching up with Márton and hearing about his journey, leadership vision, and what’s ahead for the London team. His story is a great reminder of the passion and purpose that drive our work at Erlang Solutions.

We’ll be sharing more team stories soon. So keep an eye out for the people behind the projects. If you’d like to connect with Márton or anyone on our team, we’d love to hear from you.

The post Meet the Team: Márton Veres appeared first on Erlang Solutions.

We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.

Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:

1. Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
2. Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
3. Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
4. Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
5. Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.

Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!

The changelog lists all of the changes that have been made.

We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.

As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.

Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.

You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.

Here’s to the future of real-time communication with Openfire 5.0.0!

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

40 posts - 14 participants

Read full topic

It is exciting to be able to announce the immediate availability of the beta release of Openfire 5.0.0!

In this release, we have addressed approximately 125 issues! I’ll reserve the details for a blog post on the 5.0.0 (non-beta) release, but some of the important changes are:

• We’ve dropped support for Java 11. The minimum requirement is Java 17 now
• The embedded web server has received a major upgrade
• Various security-related updates were applied, including library updates and code changes that resulted from an independent security audit (more on that later!)

This beta release (and some of its precursors) have been extensively tested by the developers and other members of the Ignite Realtime community. At this stage, we’re not seeing any critical issues. However, prior to cutting the full release, we prefer to have more feedback. That is where you come in!

We are looking for your help!

Please help us test this release! If you host your own instance of Openfire, please consider upgrading it to the new beta release. If you can’t, or if you’re not running Openfire but another brand of XMPP server, please do some interoperability testing with the server at igniterealtime.org.

Are you a client developer? Please see how your application behaves, when connecting to the beta (we can make available accounts for testing to help you do this).

If you’re nothing of a tech-head but can use an XMPP client, try to interact with our domain (for example, join our chatroom at open_chat@conference.igniterealtime.org) to see if there are any issues.

You can obtain the beta from our download page for beta releases or from the GitHub Releases page.

We would love to hear from you! If you have any questions, please stop by our community forum or our live groupchat. We are always looking for volunteers interested in helping out with Openfire development!

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

11 posts - 7 participants

Read full topic

XMPP Newsletter Banner

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

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XMPP Events

• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• The XMPP Sprint in Berlin took place during the 23rd-25th of May 2025. Developers from Germany, France & the United Kingdom representing Conversations, Dino, ejabberd, Kaidan, LiveDashboard, Macaw, Monal, Renga, and Prose gathered to make it happen! The sprint was sponsored by the XSF, Ammonit Measurement GmbH, and Wikimedia e.V..

A still from the XMPP Sprint in Berlin, May 2025

Videos

• Goffi, from Libervia, published a short progress overview of the new web frontend design on the Libervia video channel.

Talks

• On Friday, May 16, Vril hosted the Workshop di XMPP e Free Software all’AntiBiennale di Venezia (a workshop on XMPP and free software) at Cabasego, in Venice, Italy. The whole workshop lasted around one and a half hours and the slides are freely available for you to check out. The event took place in a most beautiful house, incredibly located in the center of Venice, inhabited by people who are always willing to leave their door open to Venice’s underground communities. [IT]

XMPP Articles

• El gran lío de la mensajería instantánea by Jacobo Da Riva Muñoz. [ES]
• Monocles, the project responsible for the XMPP Monocles chat Web and Android clients, started a crowdfunding campaign. The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from March 28 to June 30.
• XMPP is now featured on the list of the ‘Delightful Lists’.
• Towards a Password-Mukt XMPP for some thoughts and fantasies by Badri (Hippo) on how passwordless XMPP login could be achieved, either via an out-of-band mechanism or by authorizing from an already logged-in client.
• XMPP packages coming with Debian 13 as the freeze toward next stable Debian (13 or Trixie) has been engaged, an overview of the XMPP clients, servers and librairies coming with it is provided in this article from the Debian XMPP Team.

XMPP Software News

XMPP Clients and Applications

• Converse.js has released version 11.0.0 of its open-source and web-based XMPP chat client. The Desktop version can be downloaded from here. This release comes packed full of bugfixes, changes and new features. Way too many to list in here. Make sure to check out the release link for all the details!

Converse 11

• Gajim has released version 2.2.0. This release brings three new features: message retraction (via XEP-0424: Message Retraction), blocking participants in group chats, and updated support for modern group chat avatars (via XEP-0486: MUC Avatars), among many other improvements and bugfixes. Head over to their news section or check the changelog for all the details.
• Monal has released version 6.4.11 for iOS an macOS.
• Monocles Chat 2.0.7 for Android, has been released. This version brings fixes for lagging, pinned status message, I2P and more.
• Prose has released versions 0.10.1 of its web frontend prose-web-app.

XMPP Servers

• Prosody IM is pleased to announce version 13.0.2. This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well. Read all the details on the release changelog. As always, detailed download and install instructions are available on the download page for your convenience.

XMPP Libraries & Tools

• Pade plugin version 1.8.4 for Openfire has been released.
• peertube-plugin-livechat version 12.0.4 has been released.
• python-nbxmpp version 6.2.0 has been released.
• strophejs version 3.1.1 has been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• No XEPs proposed this month.

New

• 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

• No XEPs updated this month.

Last Call

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

• No Last Call this month.

Stable

• No XEPs moved to Stable 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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus

Help us to build the newsletter

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

Tasks we do on a regular basis:

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

XSF Fiscal Hosting Projects

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

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

Unsubscribe from the XMPP Newsletter

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.

When you’re moving quickly in a startup, taking shortcuts in your tech stack is tempting. A quick workaround here, a temporary fix there, with plans to tidy it all up later. But later can easily turn into never.

Those early decisions, however small they seem, have a habit of sticking around. Over time, they slow you down, create technical debt, and make it harder to scale. 

This blog looks at how to avoid common startup tech mistakes by making smarter choices early on. You don’t need to build the perfect system from day one, but you do need to build something you won’t regret.

The risks of rushing your tech stack decisions

Your tech stack is the foundation of your product. Making quick choices to just keep things often comes with hidden costs.

Common examples of early tech shortcuts

• Choosing tools based on ease rather than long-term fit
• Using third-party services without proper integration planning
  
• Avoiding proper system design to save time
  
• Stacking too many frameworks or libraries to plug gaps quickly
  
• Skipping documentation, testing, or version control in the name of speed
  

What could go wrong?

Here are some of the common risks that come with rushing tech stack choices:

Risk	Impact
Technical debt	Every short-term choice adds friction later. Over time, progress slows as the team spends more time managing issues than delivering value.
Security gaps	Fast fixes can lead to poorly secured systems, especially when sensitive data is involved or best practices are skipped.
Fragile foundations	A patchwork stack becomes hard to maintain, debug, or scale, and onboarding new developers becomes a headache.
Scaling problems	Systems built for “now” can’t always support growth. Quick fixes often ignore load handling, resulting in slowdowns or breakdowns at scale.
Innovation slowdown	When all your energy goes into fixing past decisions, there’s little room left for building what’s next.

The business cost of technical shortcuts

They directly impact a startup’s ability to grow. From wasted dev time to lost customer trust, the cost of early shortcuts adds up fast. That’s not the kind of overhead most startups can afford.

The long-term cost of technical debt

We touched on technical debt earlier as one of the key risks of rushing early tech decisions. Now let’s look at it more closely, because for many startups, it’s the most persistent and costly issue that comes from cutting corners.

Technical debt is the build-up of compromises made during development, from skipping tests and rushing features to patching bugs without addressing their root cause. These short-term choices eventually slow everything down, making it harder and more expensive to move forward.

Let’s break down the long-term impact:

The hidden costs of technical debt

Consequence	What it means
Slower development	Developers spend more time fixing old issues than building new features, reducing overall velocity.
More bugs, more fire-fighting	Poorly maintained code leads to more frequent and severe bugs, increasing customer support and downtime.
Low team morale	Constantly dealing with messy code creates frustration and burnout, which can hurt retention.
Harder to scale	As the product grows, tech debt makes it harder to add new features or pivot without causing breakages.
Security risks	Outdated code or rushed fixes often introduce vulnerabilities that can be exploited later.
Increased costs	Fixing problems later is far more expensive, both in time and budget.

A Stripe report found developers spend up to 42% of their week handling technical debt. CIO research suggests 20–40% of IT budgets are spent addressing it.

When it gets out of control

Technical debt can halt progress entirely. We’ve seen startups and scale-ups locked into outdated or fragmented systems, where maintaining or updating anything becomes nearly impossible.

Here are a few real-world scenarios:

• Legacy overload: Systems running well past their intended lifespan, no longer supported or secure.
  
• Integration failure: Poorly connected tools and services that don’t talk to each other, slowing everything down.
  
• Scaling bottlenecks: Infrastructure so rigid that every new feature or user pushes it closer to breaking point.
  

Security crises: Outdated code with known vulnerabilities, eventually forcing a full rebuild after a breach.

What startups can do about it:

You can’t avoid technical debt entirely, but you can manage it by:

• Prioritising clean, maintainable code from day one
  
• Setting time aside for refactoring and testing
  
• Regularly reviewing architecture decisions
  
• Choosing tools that support long-term scalability, not just quick wins
  

Startups that manage technical debt proactively stay more adaptable, secure, and focused on building the future.

Why scalability matters from day one

Tech built in a rush might work for an MVP (minimum viable product), but without scalability and maintainability in mind, it becomes a liability, something we cover in more detail in our post on common MVP mistakes.

60% of startups face major scalability issues within their first three years (McKinsey). These problems aren’t just technical; they slow growth, frustrate users, and drain time and resources.

Here’s why it’s critical to get it right from the start:

1. Scaling later is harder and more expensive

Retrofitting scalability into an existing product or tech is rarely clean. The cost (in both time and money) often outweighs what it would’ve taken to plan it earlier.

2. Maintainable code accelerates growth

Clean, modular code helps teams ship faster, fix bugs quicker, and onboard new engineers smoothly. Poor code slows everything down.

3. Users don’t tolerate failure

Unscalable systems break under pressure, which is exactly when users start showing up. That erodes trust, kills momentum, and makes customer retention harder.

4. Bad tech choices can limit your future

Tech that isn’t built to adapt can lock you into tools, vendors, or architectures that no longer serve your goals. That makes pivots and product evolution harder.

Early-stage teams often defer these decisions to “later.” But in startups, later usually means too late. Thoughtful, scalable, and maintainable tech choices aren’t a luxury but a growth strategy.

Doing it Right from the start: In practice

Now that we understand why scalable and maintainable tech decisions are crucial early on, here are some practical strategies to help your startup avoid quick fixes and build a strong foundation.

1. Prioritise Root Cause

 Don’t just patch, find and fix the real problem. For example, optimise slow database queries instead of repeatedly fixing slow responses.

2. Adopt Agile

Work in short cycles and use user feedback. Many fintech startups rely on agile to adapt quickly.

3. Write Clean, Modular Code

Keep code simple and flexible. Use modular design to evolve without costly rewrites.

4. Test Early

Use automated tests early to catch bugs. Improve stability by prioritising testing from the start.

5. Review Regularly

 Hold frequent code and architecture reviews. Startups BoardClic and Metaito used expert code and architecture reviews to ensure scalable, robust platforms.

6. Choose the Right Tech

Pick tools that fit your goals and skills. Many startups use scalable, developer-friendly stacks like Elixir.

7. Document Clearly

Keep documentation up to date to help teams understand decisions and onboard new members fast.

8. Don’t skip security checks

It’s easier to fix security issues early than patch things up later. Audits, such as SAFE (Security Audit for Erlang and Elixir), helped startups like Koll and Twine ensure the security of their systems early on, making it easier to scale with confidence and avoid nasty surprises. 

Starting with these habits cuts costly fixes later and sets your startup up for lasting growth.

Balancing speed and quality without overengineering

Startups must deliver quickly but avoid building overly complex solutions too soon. The key is focusing on essential features that address real user needs, while keeping the system flexible enough to adapt later. This helps avoid wasted effort on premature optimisation or unnecessary features.

For more on this, check out our post: Common MVP mistakes: How to build smart without overbuilding.

Build now, avoid startup tech mistakes later

Startups move fast, but speed shouldn’t come at the cost of sustainability. Those early quick fixes and temporary solutions often end up sticking around. Over time, they slow you down, create technical debt, and make it harder to grow.

You don’t need to build the perfect system from day one. But you do need a foundation that won’t hold you back.

Make smart, thoughtful tech choices early. Keep things simple. Review regularly. Focus on value that lasts. That’s how you stay fast without sacrificing your future.
If you’re ready to avoid common startup tech mistakes and build something that lasts, Erlang Solutions can help, so let’s talk.

The post Avoiding Common Startup Tech Mistakes appeared first on Erlang Solutions.

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

This update addresses various issues that have been noticed since the previous release, as well as a few improvements, including some important fixes for invites. Some log messages and prosodyctl commands have been improved as well.

A summary of changes in this release:

Fixes and improvements

• mod_storage_internal: Fix queries with only start returning extra items
• mod_invites_register: Stricter validation of registration events

Minor changes

• MUC: Ensure allow MUC PM setting has valid value (fixes #1933: PM does not work on new MUCs)
• mod_storage_sql: Delay showing SQL library error until attempted load
• mod_storage_sql: Handle failure to deploy new UNIQUE index
• mod_storage_sql: Add shell command to create tables and indices (again)
• mod_s2s: Fix log to use formatting instead of concatenation (fixes #1461: Logging issues uncovered by mod_log_json)
• modulemanager, util.pluginloader: Improve error message when load fails but some candidates were filtered
• prosodyctl check config: add recommendation to switch from admin_telnet to shell
• mod_storage_sql: Retrieve all indices to see if the new one exists
• prosodyctl check config: List modules which Prosody cannot successfully load
• net.http.files: Fix issue with caching
• util.jsonschema: Fix handling of false as schema
• mod_invites: Consider password reset a distinct type wrt invite page
• configmanager: Emit config warning when referencing non-existent value
• mod_admin_shell: Add role:list() and role:show() commands
• MUC: Fix nickname registration form error handling (#1930)
• MUC: Fix Error when join stanza sent without resource (#1934)
• MUC: Factor out identification of join stanza
• mod_invites_register: Don’t restrict username for roster invites (thanks lissine)
• mod_admin_shell: Fix matching logic in s2s:close (Thanks Menel)
• mod_authz_internal: Improve error message when invalid role specified
• mod_http_file_share: Add media-src ‘self’ to Content-Security-Policy header
• mod_admin_shell: Visual tweaks to the output of debug:cert_index()
• mod_http: Log problems parsing IP addresses in X-Forwarded-For (Thanks Boris)
• mod_http: Fix IP address normalization (Thanks Boris)
• util.prosodyctl.check: Improve reporting of DNS lookup problems

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!

Debian 13 "Trixie" full freeze has started 2025-05-17, so this is a good time to take a look at some of the features, that this release will bring. Here we will focus on packages related to XMPP, a.k.a. Jabber.

XMPP is a universal communication protocol for instant messaging, push notifications, IoT, WebRTC, and social applications. It has existed since 1999, originally called "Jabber", it has a diverse and active developers community.

Clients

• Dino, a modern XMPP client has been upgraded from 0.4.2 to 0.5.0
  Dino now uses OMEMO encryption by default. It also supports XEP-0447: Stateless File Sharing for unencrypted file transfers. Users can now see preview images or other file details before downloading the file. Multiple widgets are redesigned to be compatible with mobile devices, e.g. running Mobian.
• Gajim, a GTK+-based Jabber client has been upgraded from 1.7.3 to 2.1.1
  There are many new features in Gajim, e.g. XEP-0444: Message Reactions, XEP-0461: Message Replies, XEP-0425: Moderated Message Retraction, XEP-0490: Message Displayed Synchronization, voice message recording, migration to GTK 4, and a lot of UI changes.
• go-sendxmpp, a CLI tool to send messages to contacts or MUCs: 0.5.6 → 0.14.1
  New features are support for sending XEP-0066: Out of Band Data and support for several modern authentication features (XEP-0388: Extensible SASL Profile, XEP-0386: Bind 2, XEP-0484: Fast Authentication Streamlining Tokens). New support of modern SCRAM mechanisms (SCRAM-SHA-1(-PLUS), SCRAM-SHA-256(-PLUS), SCRAM-SHA-515(-PLUS)) and SASL SCRAM Downgrade Protection (XEP-0474: SASL SCRAM Downgrade Protection) improve the security of the login process. Also a lot of bugfixes and smaller improvements found their way to the new version, for details see the changelog.
• Kaidan, a simple and user-friendly Jabber/XMPP client is upgraded from 0.8.0 to 0.12.2
  Kaidan supports end-to-end encryption via OMEMO 2, Automatic Trust Management and XMPP Providers. It has been migrated to QT 6 and many features have been added: XEP-0444: Message Reactions, XEP-0461: Message Replies, chat pinning, inline audio player, chat list filtering, local message removal, etc.
• Libervia is upgraded from 0.9.0~hg3993 to 0.9.0~hg4352
  Among other features, it now also contains a gateway to ActivityPub, e.g. to Mastodon.
• Poezio, a console based XMPP client as been updated from 0.14 to 0.15.0
  Better self-ping support. Use the system CA store by default.
• Profanity, a console based XMPP client has been upgraded from 0.13.1 to 0.15.0.
  Add support for XEP-0054: vcard-temp, Improve MAM support, show encryption for messages from history and handle alt+enter as newline char.
• Psi+, a QT based XMPP client (basic version) has been upgraded from 1.4.554 to 1.4.1456
• xmpp-dns, a CLI tool to check XMPP SRV records: 0.3.4 → 0.4.5
  It now supports showing connection targets defined by XEP-0156: Discovering Alternative XMPP Connection Methods/XEP-0487: Host Meta 2 - One Method To Rule Them All and testing of XEP-0206: XMPP Over BOSH and Websocket connections. A detailed list of changes can be found in the changelog.

Servers

• ejabberd, an extensible realtime platform (XMPP server, MQTT broker, SIP service) has been updated from Version 23.01 to 24.12
  Add support for XEP-0425: Moderated Message Retraction, XEP-0402: PEP Native Bookmarks, and XEP-0424 Message Retraction.
• Prosŏdy, a lightweight extensible XMPP server has been upgraded from 0.12.3 to 13.0.1
  Admins can disable and enable accounts as needed. A new role and permissions framework. Storage and performance improvements.

Libraries

• libomemo-c 0.5.0 to 0.5.1
• libstrophe, an XMPP library in C has been upgraded from 0.12.2 to 0.14.0
  It now supports XEP-0138: Stream Compression and adds various modern SCRAM mechanisms.
• omemo-dr, an OMEMO library used by Gajim is now in Debian, in version 1.0.1
• python-nbxmpp, a non blocking Jabber/XMPP Python 3 library, upgrade from 4.2.2 to 6.1.1
• python-oldmemo, a python-omemo backend for OMEMO 1, 1.0.3 to 1.1.0
• python-omemo, a Python 3 implementation of the OMEMO protocol, 1.0.2 to 1.2.0
• python-twomemo, a python-omemo backend for OMEMO 2, 1.0.3 to 1.1.0
• qxmpp 1.4.0 to 1.10.3
• slixmpp-omemo new 1.2.2
• slixmpp 1.8.3 to 1.10.0
• strophejs, a library for writing XMPP clients has been upgraded from 1.2.14 to 3.1.0

Gateways/Transports

• Biboumi, a gateway between XMPP and IRC, upgrades from 9.0 to 9.0+20241124.
• Debian 13 Trixie includes Slidge 0.2.12 and Matridge 0.2.3 for the first time! It is a gateway between XMPP and Matrix, with support for many chat features.

Not in Trixie

• Spectrum 2, a gateway from XMPP to various other messaging systems, did not make it into Debian 13, because it depends on Swift, which has release critical bugs and therefore cannot be part of a stable release.

Digital wallets have transformed how people pay and how businesses get paid. With more consumers choosing contactless and mobile transactions, offering these payment options is part of staying relevant.

That’s why your business needs to understand digital wallet security– how it works, where the risks lie, and what it takes to protect customer data and payment information.

In this guide, we’ll walk through how digital wallets function, the benefits they offer, and why security needs to be a central part of any payment strategy.

Why digital wallet security is important 

You likely already have some understanding of the importance of digital wallet security. But the scale of risk today makes it worth revisiting.

In 2024, scammers stole $494 million in cryptocurrency through wallet-draining attacks, according to BleepingComputer. These attacks hit over 300,000 wallet addresses, a 67% jump in stolen funds compared to the year before. The number of victims? Up just 3.7%. That means attackers are going after (and reaching) higher-value targets.

And it’s not just about crypto. IBM reports that the average cost of a data breach globally is now $4.45 million, up 15% in just three years. For any business handling payments or user data, it’s a direct, growing risk. Understanding how digital wallets work and how to secure them is quickly becoming part of the baseline for doing business responsibly.

What is a digital wallet?

A digital wallet is a software-based tool that stores payment information securely on a smartphone or similar device. It allows customers to pay online or in-store without needing to enter card details or carry cash.

For businesses, it’s a shift in how people expect to transact. Digital wallets offer speed at the till, fewer failed payments, and a smoother customer experience.

More than just payments

Digital wallets do more than handle payments. Many store loyalty cards, ID, tickets, and even crypto. Some link to bank accounts, others work with preloaded funds.

Services like Apple Pay and Google Pay are already woven into consumers’ everyday lives, helping drive adoption. According to Grandview research, the global mobile wallet market reached USD 7.42 billion in 2022, and it’s expected to grow 28.3% annually through 2030, fuelled by smartphone use, internet access and booming e-commerce.

Source: Grandview Mobile Market research

Security is built in from the start

While we’ve touched on the fact that attacks and risks exist, digital wallets are inherently designed with security as a top priority.

What makes digital wallets valuable and viable is the level of built-in protection. Strong digital wallet security is a core feature, not an add-on. Encryption, tokenisation, and biometric authentication all help reduce fraud and protect customer data. The UK market is catching on fast. According to Worldpay, digital wallets are expected to handle over £200 billion in e-commerce transactions by 2027. This shift in consumer behaviour is here to stay. So ask yourself if your payment strategy is keeping up the pace.

How do digital wallets work?

Digital wallets use a mix of mobile technology and built-in security to make payments quick and easy. Whether customers are shopping online or tapping their phone in person, there’s no need to enter card details every time.

The process starts with a secure app or platform. Once a user adds their card and verifies their identity, typically using a fingerprint, face scan or PIN, the wallet is ready to use.

For in-store payments, the customer unlocks their phone, chooses a card, and holds the device close to the payment terminal. For online purchases, they simply select the wallet at checkout and approve the payment on their device.

Key tech behind digital wallets:

• Near-field communication (NFC):
  The most common method for contactless payments. NFC allows smartphones, smartwatches and compatible cards to securely exchange payment data with terminals by holding the device a few centimetres away with no physical contact needed.
  
• Magnetic secure transmission (MST):
  MST mimics the magnetic stripe on traditional cards by emitting an encrypted signal. It’s less common than NFC but still supported by some wallets and terminals.
  
• QR codes:
  Used more often in markets where contactless readers aren’t standard, QR codes allow customers to scan and pay using a barcode displayed on-screen.

Once the payment is sent, the point-of-sale system routes the data to the payment processor. From there, it goes through the standard authorisation process with the customer’s bank.

Are digital wallets safe?

We’ve covered what digital wallets are and how they work. Now, let’s get into the bigger question: how secure are they?

The risks businesses should be aware of

We have mentioned that digital wallets are designed with strong safeguards in place, but there are still risks to be made aware of. 

These typically come from user behaviour, unsecured environments, or sophisticated cyberattacks.

Here are some of the most common risks:

Risk	Description	Impact
Phishing scams	Fake emails or messages are designed to trick users into revealing login credentials or PINs.	Can lead to full access to a user’s digital wallet and financial data.
Malware	Malicious software that can be unknowingly installed on a device.	Allows attackers to access stored wallet data and steal funds or identities.
Unsecured public Wi-Fi	Open networks that allow hackers to intercept data being transmitted.	Sensitive financial information can be captured during transactions.
Device loss or theft	Stolen or misplaced smartphones or tablets containing digital wallet access.	If not secured properly, attackers could gain direct access to stored financial information.
Data breaches & hacking	Cybercriminals target servers or systems where digital wallets are used or managed.	Can expose large volumes of user data, including transaction history and account credentials.
Phishing & social engineering	Deceptive tactics are designed to manipulate users into revealing private information.	Still, the leading cause of data breaches, despite increased awareness and training.

How to use digital wallets safely

If your business offers or accepts digital wallet payments, security is key to safeguarding your customers and protecting your reputation. With the right steps, keeping digital payments secure can be simple.

Here are some best practices businesses and their customers should follow and encourage to make digital wallet use safer:

• Use strong, unique passwords
  Avoid easy or repeated passwords across accounts. Encourage users to choose complex combinations that aren’t reused elsewhere.
  
• Enable biometric authentication
  Fingerprint or facial recognition adds an extra layer of protection beyond passwords and PINs.
  
• Keep software updated
  Regular updates patch security holes in your device’s operating system and digital wallet apps, reducing vulnerability to attacks.
  
• Separate social media and financial apps
  Using different devices or accounts for social and financial activities can lower the risk of cross-app attacks or data leaks.
  
• Be vigilant about phishing
  Train teams to recognise suspicious emails or messages that try to steal login details. Remind customers not to click on unknown links.
  

Many digital wallets come with built-in security features, including:

• Encryption and tokenisation
  These turn sensitive payment details into unreadable codes or tokens for each transaction, making data breaches far less damaging.
  
• Two-factor authentication (2FA)
  Requiring two forms of verification before access helps ensure only authorised users can make payments.
  
• Fraud monitoring
  Some wallets automatically flag or block suspicious activity to prevent unauthorised transactions.
  

In industries such as telecomms, banking and fintech, developers often rely on secure, reliable programming languages such as Erlang and Elixir to build payment systems that can handle high volumes without compromising security. 

These technologies help ensure digital wallets remain both fast and safe for everyday business use.

To conclude

For businesses, digital wallet security is essential for protecting both customers and reputation. Digital wallets include strong built-in protections, but knowing the risks and how to address them helps keep your business and customers safe.

By focusing on security, you create a safer payment environment and earn customer trust. As digital wallets become a standard payment option, staying informed and prepared will keep your business competitive and secure. Ready to discuss strengthening your payment security? Get in touch.

The post The Importance of Digital Wallet Security appeared first on Erlang Solutions.

This release brings three new features: message retraction, blocking participants in group chats, and updated support for modern group chat avatars. Thank you for all your contributions!

What’s New

Gajim 2.2 comes with support for retracting messages via XEP-0424: Message Retraction. This allow you to retract your messages, if you’ve mistakenly sent it to the wrong recipient or group chat. Please note that your counterpart needs to support this feature as well, as a retraction can only be considered an unenforceable request.

In group chats, Gajim now allows you to block individual participants, if need arises. Blocking is available through each participant’s context menu. Block lists are private, but they can be synchronized between devices. This feature is only supported by Gajim as of now.

Finally, official support for XEP-0486: MUC Avatars has been added, which allows group chats to have individual profile pictures.

A note for Windows users: At the time of writing, there are some issues with emoji rendering on Windows. That’s why there is no release of Gajim 2.2 for Windows yet. This issue should soon be resolved and we will post an update once Gajim 2.2 is released on Windows.

More Changes

• Account sidebar now indicates connectivity issues
• Handling of retraction/moderation for corrections has been improved

And much more! Have a look at the changelog for a complete list.

As always, don’t hesitate to contact us at gajim@conference.gajim.org or open an issue on our Gitlab.

A Minimum Viable Product (MVP) is your first real signal to the market, your team, and your investors that you’re solving the right problem in the right way. While it’s often mentioned alongside terms like Proof-of-Concept (PoC), prototype, or pilot, an MVP plays a distinct role: validating real value with real users.

Avoiding common missteps early sets the stage for faster iteration, smarter growth, and long-term success. Startups are under pressure to move quickly, but speed without focus can lead to costly mistakes. Proving value fast is essential, especially with limited resources, but moving too quickly without the right foundation can stall progress just as easily as moving too slowly.

What an MVP should be

An MVP is the leanest version of your product that still delivers real value and helps you learn whether you’re solving the right problem. 

It’s not about perfection, but validation. Will users care enough to try, pay, or share? 

Importantly, a strong MVP also signals to investors that you can efficiently test ideas, understand your market, and move fast with limited resources.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Small by design, smart by strategy

Popularised by Eric Ries in The Lean Startup, the MVP is designed to reduce wasted time, money, and effort. By building only what’s needed to test your core assumptions, you can learn quickly and adjust early, before burning through too much time, money, or energy.

A good MVP doesn’t just mean “basic”

A strong MVP isn’t just a stripped-down prototype. It’s the foundation of your product. Lightweight, but also reliable, secure, and built for change. If it can’t be used, demoed, or trusted, it’s not doing its job.

Focus on what matters, build with intent, and treat your MVP not as a throwaway prototype, but as the foundation of everything to come.

Minimise risk, maximise learning

An MVP helps you move fast and stay focused. It’s not about trial and error. It’s about proving your idea works and showing investors that you’re building something ready to grow.

Common MVP mistakes (and how to avoid them)

Building an MVP is about speed and learning. But moving fast shouldn’t mean skipping the fundamentals. Many startups fall into familiar traps: doing too much too soon, choosing the wrong tools, or cutting corners that cause problems later.

By spotting these mistakes early, you can build smarter, avoid rework, and give your product a better chance of success.

Overbuilding Before Validation

Adding too many features at the start slows you down, increases costs, and weakens your core value. A bloated MVP is harder to test, more expensive to maintain, and often confusing for users.

Why it happens:

• Unclear priorities
• Perfectionism
• Fear of missing out

How to avoid it:

Focus on solving one clear problem well. Use low-code or no-code tools to test ideas quickly without overcommitting time or budget.

Choosing the wrong tech stack

Selecting technology based on trends instead of fit creates long-term issues. The wrong stack can lead to expensive rebuilds, poor stability, development slowdowns, and scaling challenges.

Why it matters:

Your tech choices affect how fast you can iterate, how well you scale, and how easy it is to adapt later.

How to avoid it:

Choose a simple, flexible stack that fits your domain. Use tools that support rapid development and long-term growth. Involve technical partners or advisors with experience to help avoid common mistakes.

Ignoring security and code quality

When speed trumps structure, the result is often messy, unreliable code.

A growing trend, vibe coding, uses AI (especially large language models) to quickly generate code from natural language. While this accelerates initial progress, it often skips testing, documentation, and consistency, leading to hidden risks and technical debt. 

Though fast at first, vibe coding can leave fragile code that’s hard to debug, extend, or transfer, with teams diverging in approach and progress stalling over time.

Why does it happen?

• Misunderstanding MVP as “low quality” rather than “focused and efficient”
• Overreliance on AI-generated code without review or standards
• Lack of experienced engineering oversight

Risks include:

• System instability and hidden failures
• Security vulnerabilities and compliance breaches
• Technical debt and poor maintainability
• Loss of trust from investors and partners

How to avoid it:

Prioritise quality from day one:

• Review AI code for security, clarity, and maintainability
• Apply secure authentication and data encryption
• Set shared coding standards and style guides
• Require basic tests and documentation, even for MVPs
• Limit LLM use in critical paths unless thoroughly validated
• Track shortcuts and log them as technical debt to resolve later

A little rigour early on prevents major setbacks down the line.

What smart MVP development looks like

A smart MVP is fast, focused, and built for flexibility. It doesn’t aim to include everything, just enough to test your core idea with real users.

Here’s what that looks like in practice:

Built fast, not rushed

Speed should serve as validation. The best MVPs reach users quickly without creating confusion or technical debt.

Focus on:

• Delivering one clear value
• Releasing early to gather feedback
• Improving in tight, focused cycles

Easy to change, because feedback is coming

A smart MVP is flexible by design. Once feedback starts coming in, you need to be ready to adjust quickly without overhauling everything.

Make this easier with:

• Modular code
• Clear documentation
• A prioritised backlog for fast iteration

Safe and secure – even if it’s lean

Even a small MVP needs to be stable and secure. If users are testing it, they’re trusting it. 

Trust depends on:

• Data security and privacy (including GDPR compliance)
• A clear, usable interface
• Consistent, reliable performance

A strong MVP is:

• Right-sized: Solves one problem well
• Stable: Works reliably in demos and tests
• Scalable: Built on a foundation that can grow
• Trustworthy: Respects and protects user data

Smart MVP development means building fast, but building right. When you combine speed with strategy, you don’t just ship faster, you learn faster, improve faster, and grow stronger.

Build fast. Build smart. Build for growth.

A strong MVP helps you validate your idea, attract early users or investors, and gather feedback, without overbuilding or overspending. The goal is not just to launch quickly, but to launch with clarity, purpose, and scalability in mind.

Many teams fall into the same traps: bloated feature sets, the wrong technology choices, or neglecting long-term costs. These missteps waste time, burn cash, and kill momentum. The most effective MVPs are built with focus, tested against the right assumptions, and grounded in a foundation that supports growth from day one.

At Erlang Solutions, we can help your startup launch MVPs that are resilient under pressure and built for the future. If you’re ready to build something that works, let’s talk.

The post Common MVP mistakes: How to build smart without overbuilding 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 April 2025.

Like this newsletter, many projects and their efforts in the XMPP community are a result of people’s voluntary work. If you are happy with the services and software you may be using, please consider saying thanks or help these projects! Interested in supporting the Newsletter team? Read more at the bottom.

XSF Announcements

XSF Membership

If you are interested in joining the XMPP Standards Foundation as a member, submissions are open until May 18th, 2025, 00:00 UTC!.

XSF Fiscal Hosting Projects

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

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

XMPP Events

• Berlin XMPP Meetup [DE / EN]: monthly meeting of XMPP enthusiasts in Berlin, every 2nd Wednesday of the month at 6pm local time.
• XMPP Italian happy hour [IT]: monthly Italian XMPP web meeting, every third Monday of the month at 7:00 PM local time (online event, with web meeting mode and live streaming).
• XMPP Sprint in Berlin: On Friday, 23rd, Saturday, 24th, and Sunday, 25th of May 2025.

XMPP Articles

• XMPP Foundation Urges Meta to Allow Interoperability Under EU Rules by Markus Kasanmascheff for winbuzzer.com
• Monocles, the project responsible for the XMPP Monocles chat Web and Android clients, has started a crowdfunding campaign. The main goal is to create a platform where privacy, digital sovereignty and sustainability take center stage. Your privacy is non-negotiable. The funding period will span from 03.28.2025 to 06.30.2025.
• Prav has taken its second major step towards forming a cooperative society in India. Their blog post “Finalising our bye-laws” details the process, including ways you can help out. This is an important step in Prav’s mission to implement community-driven decision making for their XMPP apps and services and give legal teeth to that structure.

XMPP Software News

XMPP Clients and Applications

• Cheogram has released version 2.17.10-1 for Android. This version introduces an initial implementation of Spaces (XEP-503), among other improvements, bugfixes and more!
• Conversations has released versions 2.18.0, 2.18.1 and 2.18.2 for Android. Notable changes include the ability to pick a custom backup location, a prominent backup restore option for Quicksy, and improved support for more kinds of URIs. The latter includes tel phone numbers, mailto email addresses, and more interestingly the web+ap scheme for ActivityPub proposed by Fedi Links.
• Dino has released version 0.5 featuring OMEMO encryption by default, improved file transfers, image preview and other file details before downloading, and two completely reworked dialogs. See the release blog post for all the details.
  • At the same time, Dino has also received funding from NLnet to begin development on a slew of new features. This includes message moderation in group chats, local message deletion, modern connection handling with FAST and SASL2, more formatting options with Message Markup, and more! Visit the project page for all the details.
• Gajim has released versions 2.1.0 and 2.1.1 with a new ‘Activity feed’ page, layout improvements for its ‘Start Chat’ dialog and support for ‘Message Display Synchronisation’ (XEP-0490) across group chats among other improvements and bugfixes. Head over to their News section for all the details.

Activity feed in Gajim 2.1

Account and status selection in Gajim 2.1

• Kaidan has received NLnet funding for various improvement across the board, most notably multi-user chat and support for legacy OMEMO. The second point is significant because while Kaidan is using a newer version of the OMEMO end-to-end encryption protocol, other popular clients including Conversations, Monal, and Dino are still using an older version. Since the two are not compatible, this meant Kaidan users were unable to use OMEMO encryption with users of most other clients. By implementing the older spec as well, Kaidan will help bridge that gap.

• Monocles Chat 2.0.6 has been released for Android. This version brings initial support for file captions, the option to pin an unencrypted message to the top of a conversation, providers list support, and the option to register on your own XMPP server, among many other new features and improvements.

Monocles Chat 2.0.6: Initial captions to files and pin message to the top

Monocles Chat 2.0.6: Register on your own XMPP server or pick one from the providers list

• Movim has released version 0.30 (code named “Encke”), the biggest Movim evolution in many years! This release brings multi-participant calls, reactions being displayed in the detailed message view, support for Unicode 15.1 with plenty of new emojis to use, and avatars that change when a contact adds to their Story.

Movim 0.30 (Encke): Multi Participant Calls. Bob Cat looking disgruntled by the presence of the ‘Hooman’ on the lower right of the screen!

Movim 0.30 (Encke): Meow OwO bedazzled by the looks of Multi Participant Calls on his mobile device!

• and following right on its heels, Movim also published its first bug-fix release: version 0.30.1, adding animated pictures support in the image proxy and a new Avatar and Banner Configuration Panel, as well as implementing (XEP-0392) Consistent Color Generation, among many other improvements and bugfixes. Make sure to check out the official announcements at the Movim Blog for all the details!

Movim 0.30.1: Avatar and banner configuration panel

• Prose has released versions 0.8.0, 0.8.1, 0.8.2, 0.8.3, 0.9.0, 0.9.1 and 0.10.0 of its web frontend prose-web-app.

XMPP Servers

• MongooseIM has released version 6.3.3 of its Enterprise Instant Messaging Solution. This minor update includes various fixes and improvements. For more information, check out the documentation.
• ProcessOne has published ejabberd 25.04. This release brings an important security fix, several bug fixes and a new API command.
• Prosody IM is pleased to announce version 13.0.1, a new minor release from the latest stable branch. It fixes some important bugs that were discovered after the latest release. Read all the details on the release changelog. As always, detailed download and install instructions are available on the download page for your convenience.
• The Prosody app for YunoHost has been updated to provide a bunch of supported XEPs by default, configured for all YunoHost users in just one click. YunoHost is a set of tools to easily manage your own selfhosted services, and while it used to come bundled with the Prosody fork Metronome by default, it has recently bundled its XMPP functionality into a separate “app” so that people can swap in any other XMPP server of their choice.

XMPP Libraries & Tools

• go-xmpp versions 0.2.13 and 0.2.14 has been released.
• libomemo-c version 0.5.1 has been released.
• prose-core-client versions 0.1.103, 0.1.104 and 0.1.105 have been released.
• python-nbxmpp versions 6.1.0 and 6.1.1 have been released.
• Slidge versions 0.2.9 (codenamed “Trixie <3”), 0.2.10, 0.2.11 and 0.2.12 have been released.
• Tinder version 2.1.0 has been released.
• Whack version 3.0.0 has been released.

Extensions and specifications

The XMPP Standards Foundation develops extensions to XMPP in its XEP series in addition to XMPP RFCs. Developers and other standards experts from around the world collaborate on these extensions, developing new specifications for emerging practices, and refining existing ways of doing things. Proposed by anybody, the particularly successful ones end up as Final or Active - depending on their type - while others are carefully archived as Deferred. This life cycle is described in XEP-0001, which contains the formal and canonical definitions for the types, states, and processes. Read more about the standards process. Communication around Standards and Extensions happens in the Standards Mailing List (online archive).

Proposed

The XEP development process starts by writing up an idea and submitting it to the XMPP Editor. Within two weeks, the Council decides whether to accept this proposal as an Experimental XEP.

• No XEPs proposed this month.

New

• 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.3 of XEP-0313 (Message Archive Management)
  • Fixed typo (XEP Editor (dg))
• Version 0.4.0 of XEP-0377 (Spam Reporting)
  • Add spam report processing opt-in.
  • Add Guus der Kinderen as co-author. (gdk)
• Version 1.0.1 of XEP-0421 (Occupant identifiers for semi-anonymous MUCs)
  • Fixed typo (XEP Editor (dg))
• Version 0.3.0 of XEP-0455 (Service Outage Status)
  • Remove all in-band event signaling. (mp)

Last Call

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

• No Last Call this month.

Stable

• No XEPs moved to Stable 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
• 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):

• English (original): xmpp.org
  • General contributors: Adrien Bourmault (neox), Alexander “PapaTutuWawa”, Arne, Badri Sunderarajan, Benson Muite, cal0pteryx, emus, Federico, Gonzalo Raúl Nemmi, Jonas Stein, Kris “poVoq”, Licaon_Kter, Ludovic Bocquet, Mario Sabatino, melvo, MSavoritias (fae,ve), nicola, Schimon Zachary, Simone Canaletti, singpolyma, XSF iTeam
• French: jabberfr.org and linuxfr.org
  • Translators: Adrien Bourmault (neox), alkino, anubis, Arkem, Benoît Sibaud, mathieui, nyco, Pierre Jarillon, Ppjet6, Ysabeau
• Italian: notes.nicfab.eu
  • Translators: nicola
• Spanish: xmpp.org
  • Translators: Gonzalo Raúl Nemmi
• German: xmpp.org
  • Translators: Millesimus
• Português (BR): xmpp.org
  • Translators: 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

To unsubscribe from this list, please log in first. If you have not previously logged in, you may need to set up an account with the appropriate email address.

License

This newsletter is published under CC BY-SA license.