RabbitIm: a cross-platform XMPP client with a plugin system

An XMPP client, and a checklist you can read in a minute

RabbitIm is an open source cross-platform instant messaging system that supports several protocols, and the repository description puts the scope in Chinese: text, audio and video, a whiteboard and remote control.

The primary language is C++ and the licence is GPL-3.0, and the author is Kang Lin, with a project page at kanglin.github.io/RabbitIm. The repository is mirrored in China on Gitee and on GitLab, which is the arrangement you would expect for a project with a Chinese user base, and the topic tags are im, video and xmpp.

What makes the README worth reading is that it is written as a checklist rather than as prose. Every feature has a box, and the legend explains that a checked box means the feature is done in the current version and an empty box means it is planned for a future one. Nothing is implied.

Under the XMPP protocol entry, point to point messaging is checked for text, emoji, voice over peer to peer, video over peer to peer and file transfer, while remote desktop and remote control are empty. Group support, described as a meeting room function, is checked for text and emoji, and empty for voice, video, file sharing and the electronic whiteboard. The tox protocol entry is empty.

So the state of the project in one line: the private conversation is complete and the group conversation is not. That is a specific and useful thing to know before you evaluate it, and it is a great deal clearer than a feature list would have been.

The remaining entries cover automatic updates, skin changing, multiple languages, the plugin system, and the cross-platform column.

Plugins, skins and the platform column

The plugin framework is the part of the project with the most unusual scope, and its checked items are revealing.

Exercise, QR code recognition and generation, and screen capture are all present. Screen capture is checked for Windows and for Unix and Linux, and empty for Android. Everything else in the plugin list is unchecked: screen recording, calendar, face recognition, electronic whiteboard support, and remote desktop and remote control.

So the plugin system is real and already carrying the plugins that are convenient on a desktop, and the whiteboard and the remote control are the two things the project's own description promises that are not there yet. That is worth stating plainly, because a reader looking at the repository description alone would assume the opposite.

The cross-platform list is checked for Windows, Linux and Android, and empty for macOS and iOS. The reason given is unusually direct: the author does not have a macOS or iOS device, and asks anyone who has one to compile and test it themselves. It is the most honest kind of note in a README, and it tells you the platform is unblocked rather than abandoned.

Beyond those, the application itself supports automatic updating, skin changing and multiple languages. The skins are visible in the screenshot section, which shows a dark style and a default style side by side for the login, list, chat and file transfer windows on Windows and on Ubuntu.

The build, the CI matrix and the container recipe

The repository is a C++ project built with CMake, and the build environment is described by the Dockerfile at the root.

The image starts from Ubuntu and installs the build tools, then clones the repository and runs the third party build scripts:

FROM ubuntu

export BUILD_TARGERT=unix;

The toolchain install is the part worth noting, because it tells you what the project needs: g++, cmake, git, subversion, wget and ant. Ant and subversion point at the era of the dependency management, since the third party libraries are fetched by those tools rather than by a modern package manager.

After the clone, the script exports a build target variable and then runs three scripts in sequence from the ThirdLibrary directory: build_depends.sh, build-before.sh and build-and-test.sh. The spelling of the variable is BUILD_TARGERT rather than BUILD_TARGET in the file itself, which is the kind of detail you would rather know about before you grep for it.

The continuous integration badges are organised as a matrix of platforms and branches. There are Linux, Windows and Android workflows, and each is shown for both the master branch and the Develop branch, with ubuntu.yml, msvc.yml and android.yml as the workflow names. So the project tests two branches across three operating systems.

The rest of the tree supports the build and the packaging. There is CMakeLists.txt with a cmake/ directory, vcpkg.json for C++ dependency versions, .gitmodules for the third party libraries, a debian/ directory with build_debpackage.sh for a Debian package, Install/ and Update/ for the installer and the updater, App/, Src/, Plugin/ and Resource/ as the application directories, test/ for the tests, tag.sh for tagging releases, and Doxyfile templates for generating the developer documentation.

The documentation set and where the plan lives

The README links the project's documentation as a table, and the columns are a map of what you would need to work on it.

There is the licence agreement, License.md, the change log in ChangeLog.md, the project plan in TODO.txt, a development guide at docs/develop.md, build instructions at docs/INSTALL.md, and development notes under docs/Books. The README also points at the change log and the project plan for the wider set of features beyond the checked list.

The naming convention in the table is worth noting: the plan is called TODO.txt at the root rather than living in a docs folder, which is the older convention and matches the era of the project.

The change log is also the project's release history in practice. The tagged releases are v0.0.1 and v0.1.0, both dated 2016-05-10, and there has been no new tag since, while the last push to the repository was on 2026-10-02. So the code has been worked on for a decade after the last release, and the releases page is where you find binaries rather than the repository itself.

For anybody evaluating this, the sensible order is the README's feature list first, since that is the most accurate statement of what works, then the plan in TODO.txt for what is coming, and only then the code.

One more thing about the project's posture, which the README states openly rather than hiding. Alongside the invitation to donate or contribute code, it explains that the author offers to compile the program on request at 200 yuan per hour, and to build an entire system, port or customise the development at 2000 yuan per working day, with payment required before the work starts. It also asks that questions be asked after a donation has been made. That is a personal project run by one person, and the commercial terms are stated in the same document as the feature list.

Where RabbitIm is the wrong tool

There are clear cases where this client is not what you want, and they follow from the checklist rather than from the marketing.

If you need working group voice or group video, this is not it. Meeting rooms have text and emoji and nothing else in the current version, and the whiteboard that the project description advertises is unchecked in the plugin list as well as in the room list. If your requirement is a team communication tool, the gaps are in exactly the features a team needs.

If you are on macOS or iOS, the answer is that it does not run there yet, and the person who would make it run needs to own the hardware.

If you want a client with a release cadence, the two tags from 2016 are not that, whatever the state of the master branch. The repository was pushed to recently, so the code is not frozen, but there is no versioned artefact to pin, and the README's own downloads badge points at the releases page, which has not moved since 2016.

If you want a modern XMPP client with a maintained ecosystem, this is a project built around a 2016 dependency toolchain, with ant and subversion in the Dockerfile, and a single maintainer whose commercial terms are published in the README.

There is also a protocol point. The tox protocol entry is empty, so this is an XMPP client only, and it talks to XMPP servers rather than to a peer to peer network.

The alternative approach is to use an existing XMPP client and live with what it offers, or to write a plugin for it. The difference in approach is that RabbitIm's value is the extension framework, where the exercise, QR code and screenshot plugins show that the plugin path works, and the cost is that the features the framework was supposed to host, the whiteboard and the remote control, are exactly the ones still missing.

Editorial conclusion

RabbitIm suits somebody who wants an XMPP client they can extend, who needs the plugin framework for their own plugins such as the QR code and screenshot tools, and who is prepared to build from source on the platform they care about. It does not suit somebody who needs the group features today, because voice, video, file sharing and the electronic whiteboard in meeting rooms are all still unchecked in the README, and it does not suit a macOS or iOS user, because those platforms are marked as unfinished. Check three things before you adopt it: which of the feature boxes correspond to what you actually need, since the README is explicit about the difference between the done and the planned items, whether the releases page still has a build for your platform, since the tagged versions are v0.0.1 and v0.1.0 from 2016 while the repository itself was pushed to on 2026-10-02, and whether you can live with the build environment, which needs a C++ toolchain, CMake and the third party libraries referenced through the submodules and vcpkg.json. The licence is GPL-3.0, so modifications you distribute carry that obligation.

Frequently asked questions

Official sources

1. Issues
2. KangLin/RabbitIm on GitHub
3. License: GPL-3.0
4. README
5. Releases