Spark: an XMPP desktop client aimed at organisations rather than consumers

What Spark is, and the pitch it makes

Spark is described as an Open Source, cross-platform IM client optimized for businesses and organizations, and the feature list is short enough to quote in full: Group Chat, in-line Spell Checking, end-to-end message encryption with OTR, tabbed conversations, file transfer, screen capture sharing and message translations.

The framing that matters is the second sentence of the README. Combined with the Openfire server, Spark is presented as the easiest and best alternative to using unsecure public IM networks. That is a different product strategy from a consumer chat client. The argument is that an organisation which runs its own XMPP server, and its own Spark clients on top of it, gets messaging that does not route through a public network, and gets a client built for the features a business needs rather than for the audience a consumer app targets.

It is also an Ignite Realtime community project, and the parent organisation describes itself as an open source community of end-users and developers interested in applying innovative, open-standards-based real time collaboration to their businesses, and says it is aimed at disrupting proprietary, non-open standards-based systems.

The topics on the repository list collaboration, cross-platform, jabber, java, openfire, spark and xmpp, with xmpp-client as the specific one. The primary language is Java, the licence is Apache-2.0, and the homepage is the Ignite Realtime project page for Spark. The last push was on 2026-10-05 and the project is not archived.

The release history is where the caveat sits, and it is worth stating early. The tagged releases are 3.0.2 from 2023-03-31, 3.0.1 from 2022-12-12 and 3.0.0 from 2022-11-14. So the last tagged release is more than three years old, while the source tree is still receiving commits. For an application that people install rather than depend on as a library, the nightly build is the artefact most users actually run.

Installation: a bundled JRE, a nightly build, or a source build

The install section gives you three routes, and the choice of route tells you how actively you intend to track the project.

The first is the last release from the GitHub releases page, or a nightly build with the latest changes. For Windows, the README makes a specific recommendation: if you are not sure, it is recommended to download the spark_*-with-jre-amd64.exe that has a bundled JRE. That is a useful default because a JRE-bundled installer removes the single most common reason a Java desktop application fails on a work machine, which is that the user has no Java, or has the wrong Java, or has a corporate JRE policy that blocks the app.

The second route is running from sources, which is four commands:

git clone https://github.com/igniterealtime/Spark.git
mvn verify
cd Spark/core
mvn exec:java

The clone and verify steps are ordinary Maven, and the cd into Spark/core followed by mvn exec:java runs the client from the built artifacts. For an IDE there is a Main class named org.jivesoftware.Spark, and a VM option of -Ddebug.mode=true, with per-IDE setup guides linked for IntelliJ, Eclipse and Visual Studio Code.

That Main class name is a small but telling detail. The class name is documented in the README's run-from-sources instructions, and its use in the 3.x line means the entry point has stayed stable across the recent releases.

The third route is a plugin development guide, linked from the README, which is a strong signal about the shape of the project. A client with a formal plugin guide and a Sparkplug development model is a platform for other people to build on, and the repository tree backs that up: there is a plugins/ directory alongside core/, distribution/ and emoticons/, plus a pom.xml at the root, which is the aggregator for a multi-module Maven build.

The feature set, and what each entry actually implies

It is worth reading the feature list as a set of engineering decisions rather than a shopping list, because each item maps to a specific piece of the XMPP protocol surface.

Tabbed conversations and group chat are the core of a business client. The group chat entry corresponds to Multi-User Chat, and the README's screenshots include a MUC view, so multi-party rooms are a first-class part of the interface rather than an afterthought.

File transfer and screen capture sharing are the two features that separate a business client from a personal one. Both are things a consumer client tends to omit because they are hard to do well, and both are things a work client cannot omit, since sharing a screenshot with a colleague is a daily act. The repository has a file transfer implementation in its own right, and the top-level emoticons/ directory tells you that the older emoticon support is still there too.

Message translations and in-line spell checking are the two quality-of-life features that the business positioning depends on. A translation feature matters when your colleagues are spread across languages and on unencrypted consumer networks you are trying not to depend on, and spell checking is what makes non-native typing bearable in a client aimed at professional communication.

End-to-end encryption with OTR is the one feature with a security claim attached, and it is worth being precise. OTR is a protocol for encrypting one-to-one chat sessions, and it is the older generation of the technology. It sits in tension with multi-user chat, because OTR is a two-party protocol, so group conversations are not covered by the same mechanism. The README lists both features without a note on that interaction, and anyone assessing the encryption posture for a deployment with confidential group channels should check how the two behave together rather than assume group messages are protected by the same feature.

Where the project is hosted, and how bug reports actually work

The resources section lists six places, and they are worth reading as a map of how the project is run.

Translation runs on Transifex, at explore.transifex.com for the Spark project, and the tree confirms it with a .transifex.yml file at the root. Documentation lives on the Ignite Realtime project site, in the Spark documentation page. The community forum is on Discourse, at discourse.igniterealtime.org/c/spark, and the Spark Dev category is where development discussion happens.

The bug tracker is Jira, at igniterealtime.atlassian.net, and the README is unusually specific about who can file there: only a few users have access for filling bugs in the tracker, and new users should create a Discourse account, log in, click the New Topic button, and choose the Spark Dev category to provide a detailed description of the bug. There is also an instruction to search for existing issues in the tracker before reporting.

So the reporting route for a new user is the forum, not the tracker, and the tracker is for the people who have already been granted access. That is an unusual arrangement for an open source project, and it is a governance fact rather than a technical one, but it has a direct effect on what an outside contributor should expect.

Two more resources matter for a deployment. There is a nightly builds page on the Ignite Realtime downloads site, which is where the current code actually is, given the age of the last tag. And there is an XMPP compliance listing at xmpp.org for Spark, which is the place to check interoperability claims against a third party rather than against the project's own description.

Maintenance reality and what it means for a deployment

Two facts sit next to each other and have to be read together.

The source is alive. The last push was on 2026-10-05, the repository is not archived, there is a Travis build status badge on the master branch, and the tree contains a SECURITY.md, an AGENTS.md, a .github/ directory and an .aiignore file. Somebody is working in it.

The releases are old. The newest tag is 3.0.2 from March 2023. There is no 3.1, no 4.0, and the version has not moved in more than three years, while the commits have.

The resolution is in the README's own install advice, which points to a nightly build for the latest changes and offers a nightly downloads page. So the project has a rolling release channel and a frozen tagged channel, and the version number on the About screen tells you which one you are on.

For an organisation evaluating Spark, the questions that follow are concrete. Whether the XMPP server you would pair it with is Openfire, and whether the nightly build is one you would be comfortable deploying, since a nightly build carries no stability promise and no tag to pin to. Whether the plugin ecosystem you depend on is maintained against the current code, since the plugin development guide is versioned separately from the client. And whether the OTR-based encryption and the multi-user chat features are sufficient for the confidentiality your organisation needs, given that the two do not cover the same traffic.

What Spark is not trying to be is a consumer messaging app. It is a client for a deployment where the server and the network are yours, and the features are the ones that come up in a company that has decided to run its own messaging.

Editorial conclusion

Adopt Spark if your organisation already runs or plans to run an XMPP server such as Openfire and you want a desktop client that keeps conversations on infrastructure you control, with group chat, file transfer and screen sharing rather than the consumer messenger feature set. Do not adopt it as a general consumer chat client, and do not assume its end-to-end encryption covers your group channels, because the OTR feature it advertises is a two-party protocol while multi-user chat is a separate feature. Before you commit, check the last tagged release against the nightly build you would actually install, since the newest tag is 3.0.2 from 2023 while the source is still moving, read the plugin guide if you rely on extensions, and confirm the server pairing and the encryption coverage match what your compliance requirements ask for.

Frequently asked questions

Official sources

1. igniterealtime/Spark on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases