The Old Jabber Clients People Keep Asking About
Liberty and Mercury are both XMPP (Jabber) clients, and both predate the current wave of people migrating off proprietary chat platforms. If you are digging through old downloads or inherited servers, you are likely running into them because an old documentation set or an internal wiki told you to. Here is what they actually are and what you do with them. Liberty was primarily known as a Windows-era Jabber/XMPP client built around the same time the protocol was transitioning from the early Jabber.org days into the IETF-standardized XMPP era. Mercury is a different project altogether, mostly recognized as an XMPP client for mobile and desktop that surfaced later, with variants built for Android and sometimes repackaged under slightly different names across forums. Neither of them is part of the current mainstream stack. Most people who are asking about one or the other are dealing with a legacy system and are trying to decide whether it makes sense to keep using it or to migrate somewhere else. The practical problem is that neither client receives active development on a schedule that matches current XMPP requirements. That means you will run into issues with TLS versions, SASL mechanisms, and XEP compliance that do not exist in maintained clients like Gajim, Conversations, or Matrixtalk. I had a situation where an old Mercury build kept rejecting authentication on a 2022-era ejabberd deployment. The server was configured for plain OAuth and SCRAM-SHA-256, but the client only offered PLAIN and an older SASL mechanism. I solved it by disabling the legacy SASL requirement in the server config for that virtual host temporarily, but that is not a sustainable approach. The real solution was to migrate the accounts to a maintained client and update the server config to not accept outdated mechanisms.
Liberty had a similar pattern. It was functional when it was actively maintained, but the feature set was anchored to the expectations of the mid-2000s Jabber ecosystem. If you are looking at Liberty now, you are usually reading someone's archive link or finding it bundled inside a larger open-source repository dump. The codebase is not widely mirrored under its original name because the project stopped being active years ago. What you will encounter most often is a compiled Windows binary or a port that someone kept around for compatibility with an internal Jabber system that never got upgraded.
What actually matters when you pick between them
Most people treat this like a feature comparison, but the real decision point is whether your infrastructure supports either of them without requiring workarounds. If you are running a current ejabberd, Prosody, or OpenFire deployment with modern TLS and standard XEPs enabled, neither client will work cleanly out of the box. You will spend more time debugging connection failures than you will gain from using either application. If your environment is intentionally legacy—maybe you maintain a closed Jabber network for a specific org or you are supporting a small system that has not changed in a decade—then Mercury can still function for basic presence, messaging, and file transfer. Liberty has similar capabilities but tends to show more friction on Windows systems when dealing with newer certificate chains. The difference between the two is not dramatic for simple use cases. The difference becomes obvious when you try to use MAM, OMEMO, or modern discovery extensions. I used Mercury on a small private XMPP network a few years back and ran into a recurring issue where message archival timestamps were misaligned by several hours. The server was set to UTC, but the client insisted on local time for stored messages without accounting for DST transitions properly. I worked around it by enforcing a fixed offset in the server config and switching the client to use a timestamp format that matched the server. That workaround only holds as long as you keep the server configuration static. Any move to a newer version of the backend typically breaks it again.
Get the Full Details
Downsides you should know about
These clients are not going to fix themselves. The main risk is that you will invest time in maintaining compatibility patches for software that is no longer receiving updates. That is a poor use of effort unless you have a hard constraint that requires staying on an older stack. The second risk is security. Older XMPP clients often ship with hardcoded cipher suites, outdated TLS handling, and sometimes unpatched memory safety issues. If you are connecting to any public or semi-public server, that exposure is real. I have seen incidents where old clients connected to insecure endpoints and leaked credentials because the application did not enforce certificate pinning or modern TLS versions. There is also the issue of dependency rot. Both projects rely on libraries and frameworks that have moved on. You will frequently encounter broken installs on modern operating systems because the required runtime packages are no longer available in current repositories. On Linux, this often means compiling from source with pinned dependencies, which is tedious and fragile. On Windows, it means hunting for old Visual C++ redistributables or running the executable in compatibility mode.
When it still makes sense to use them
Legacy support is the main case. If you are maintaining an old internal system and need a thin client that can talk to it without rewriting the backend, either of these can fill that gap. Mercury tends to be the slightly more viable option for that scenario because it has seen more ports and forks over the years. Liberty is mostly useful if you already have a working deployment and do not want to change the client configuration across a whole team. If you are starting fresh or planning a migration, the rational choice is to move to a maintained client. For desktop, Gajim remains a solid reference implementation with good XEP coverage. For mobile, Conversations is the standard pick. If you need something minimal and scriptable, a lightweight command-line XMPP client or an XMPP library in your preferred language will serve you better than either of these two. They are not going to receive security patches, and relying on them beyond their intended lifespan is a maintenance trap. I once tried to keep Mercury alive on a small team for six months because everyone was comfortable with it. The effort to keep it working properly ended up taking more time than a proper migration would have. We eventually moved the accounts over to a maintained client, updated the server config to drop legacy mechanisms, and phased out the old binaries. The migration took about a week for a team of a dozen people. Staying on Mercury cost us roughly three months of intermittent troubleshooting and a couple of close calls with TLS failures.
If you are downloading or sourcing either client, expect to find them on old project archives, GitHub forks, or third-party mirrors. The original distribution channels are largely gone or inactive. Verify checksums whenever possible, and do not assume that an old build is safe just because the project had a decent reputation when it was current. The XMPP ecosystem has moved on, and the weight of that change is visible in every connection failure you encounter with these clients.
