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, by your own server, 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 .