Openfire5.0.1
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
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
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.
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 JIDwhatsapp.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 didmv /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
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:
- 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.
- 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.
- 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.
- 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.
- 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
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
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
paradoxicalsphere in "
kaushal kate in "