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

I get regular requests and issues have been raised about upgrading the Jitsi meet code in the Openfire Pade plugin to the latest versions. Unfortunately, this task is much more difficult than it sounds.

Jitsi Meet has evolved a lot since the early days of WebRTC. It has moved from being a Java platform agnostic, XMPP compatible self-hosting application into a Linux cloud hosted service.
The current code still depends on our Smack project for the XMPP client, but it uses Prosody as the XMPP server with quite a few extensions and modules coded in Lua which need to be ported to Java. Apart from not having time to work on it, I have also lost the motivation to step up to the challenge as I am more interested in using WHIP and WHEP with XMPP.

Nevertheless, an issue can round last week requesting for support of AV1 codec. This sparked enough motivation for me to spend my Easter holidays trying one more time to make the upgrade happen. The bad news is that I failed yet again, but the good news is that I was able to update the existing code to support AV1. Please note that codecs have pros and cons. VP9 is probably the best all rounder. H264 is best with devices that have hardware encoders and AV1 handles low bandwidth the best.

Openfire Pade plugin version 1.8.4 now supports the AV1 codec. You get the best results with P2P calls. As it is it more CPU intensive than VP9, you make get lower frame rates on low-spec servers. The latest Jitsi code has a lot more improvements and if you really need AV1 with many participants, seriously consider deploying the Jitsi Meet self-hosted instance in a container or VM.

As always, your instance of Openfire should automatically make available to update. Alternatively, you can download the new release of the plugin at the Openfire Pade plugin’s archive page.

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

When I explain to others what I do for a living, I often ask why it is that we are not surprised that one can use a Gmail account to send an email to someone who uses an Outlook account, yet many people fully accept that you can’t send a message to someone using WhatsApp from a Telegram account. We’re not surprised that we can use our phone to set up a call with someone who uses a different brand of phone (or is subscribed to a different provider), yet, for instant messaging, we find ourselves in a world of walled gardens.

Walled gardens refer to ecosystems where companies control access to their platforms and restrict users’ ability to freely interact with other services, creating barriers that prevent open communication and fair competition.

Recognizing this, legislation is slowly being put in place to improve things. The Digital Markets Act (DMA) is a regulatory framework established aimed at ensuring fair competition and improving the functioning of the digital economy. One of its primary objectives is to dismantle these walled gardens and promote messaging interoperability. The DMA seeks to break down barriers and ensure that users have more freedom to engage with different platforms and services, while also enabling interoperability between messaging services.

Meta (of WhatsApp and Facebook fame) is designated as a “gatekeeper” under the DMA. This means that Meta holds a dominant position in the market, controlling key access points that can potentially limit competition or consumer choice. The act outlines various obligations that Meta must comply with to ensure a fairer and more open digital environment.

The XMPP Standards Foundation is now publishing an Open Letter to Meta, to advocate for the adoption of XMPP for messaging interoperability. It argues that Meta’s proposal falls short: Meta’s current approach to interoperability, which relies on restrictive NDAs, proprietary APIs, and centralized control, is not true interoperability.

The XSF argues that Meta should adopt XMPP (eXtensible Messaging and Presence Protocol), a proven, open standard that allows for true federation, decentralization, enhanced privacy, and scalability. XMPP enables seamless communication between different services, akin to email or phone networks. Meta has previously utilized XMPP for WhatsApp and Messenger and has embraced federation for other services, showing that adoption and implementation are not only achievable, but has already been proven to work.

The XSF urges Meta to adopt XMPP for messaging interoperability to comply with the DMA and build a competitive, open messaging ecosystem. The XSF is ready to collaborate and evolve the protocol as needed.

The Ignite Realtime community is based on the strength and flexibility offered by XMPP. Projects like Openfire, Smack, Pade and Spark are direct implementations of the XMPP protocol. We have firsthand witnessed the flexibility, reliability and maturity of the protocol, and have been successfully applying it for years, if not decades. We should therefore fully endorse the XSF’s call to action!

It is time for real interoperability. Let’s make it happen!

You can find the Open Letter of the XSF here: XMPP | Open Letter to Meta: Support True Messaging Interoperability with XMPP

A accompanying technical briefing is also published: XMPP | Detailed technical briefing: The Case for XMPP – Why Meta Must Embrace True Messaging Interoperability

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