After more than 7 months of active development, Converse 4
has finally been released.
Converse is an open source XMPP-based chat client written in
This release contains lots of highlights, including rewriting the UI to use
Bootstrap 4, support for OMEMO Encryption
of private messages, message corrections and file-sharing via HTTP file upload.
XMPP is an IETF standardized messaging and presence protocol with multiple
independent server and client implementations.
Unlike other popular open source teamchat applications like Mattermost and
Rocket.chat, Converse doesn't depend on any particular server (e.g. backend) application.
Any XMPP server which supports the relevant extensions (aka XEPs) will do.
XMPP server, which you can either set up and host yourself or you can sign up on an
XMPP's killer feature
XMPP allows for something called federation. Even if you've never heard the word
being used in this context, you already know what it means if you've used email.
When you sign up for an email account from one provider (for example Gmail,
Fastmail or Kolab), you can still send emails to people who have accounts at other
providers. That's because Email is also federated.
A federated protocol allows you to communicate with user-accounts on foreign hosts.
The network is decentralized between many providers (who all adhere to a common protocol),
instead of being controlled by a single centralized behemoth (like Facebook, Twitter or LinkedIn).
Federation is getting quite a lot of renewed attention lately, in large part
due to the hype around the federated social networking site Mastodon
which is based on the recently published ActivityPub standard.
You're not forced to federate when running an XMPP server for your organisation,
friends or family, and sometimes it makes sense not to.
However it's in my opinion the killer feature of XMPP and one of
the main reasons why I'm working on Converse.
Federation implies user-freedom and user-choice, and it's one thing that Slack
or Discord simply cannot do. Not because it's not technically feasible, but because
their business models, based on user lock-in and control, don't allow it.
It's also something which the open source Slack-alikes like Mattermost and
Rocket.chat don't have.
I believe people should have the freedom to use the chat app of their choice, while
still being able to effectively communicate with their contacts who prefer
to use a different chat app.
XMPP and federation can make this a reality.
In a world of federated chat apps, some people will use a commandline client
like Poezio, a desktop client like Dino or a mobile client like Conversations
(or a combination of all three).
There will also be a growing need for web-based chat clients, and that's were Converse comes in.
Federation not only provides choice between chat clients, it can also foster
inter-departmental or inter-organisational communication.
In Germany, where I currently live, there is a lot of talk of digitization of
government. Government bureaucracy often consists of various different
departments who need coordinate and send resources around.
The same of course applies to large enterprises.
A decentralized and federation communications protocol can play a large role
here, and I'm not just talking about chat apps.
The Salut à Toi project has shown how you can create
a decentralized and federated issue tracker, while Movim
has blogging and microblogging capabilities, all based on XMPP.
Converse was originally developed at Syslab.com
as part of a web-based intranet for the Star Alliance airline group.
Back then it was developed as a Gtalk-like popover chat, like you still see on
After open sourcing it, my initial goal was to make it as
configurable and capable as possible, so that it could be used in any
website in almost any conceivable manner.
A powerful plugin architecture and API was added, which allows you to add or remove
features and change just about any behaviour.
Over time, as the project matured and people started using it, it became clear
that there are many more usecases for a webchat than simply popover chats.
Full-page teamchat apps like Slack also became spectacularly successful.
I subsequently updated Converse to have different "view modes", which enable
you to use it in different ways, depending on your needs.
The focus also shifted slightly from presenting it merely as something to be
integrated into an existing website, to showing that it can be an independent
chat client in its own right.
There is the "overlay" mode, which matches the original UX design:
A screenshot of Converse with overlayed chatboxes
Then there are the "embedded" and "mobile" modes:
A screenshot of Converse in embedded mode
A screenshot of Converse in mobile mode
And lastly there's the "fullscreen" mode, more similar in UX to teamchat applications like
Slack and Discord.
A screenshot of Converse in fullpage mode
view modes. Currently it's not possible to do so without reloading the page,
but we'll work on making that possible as well.
Working on Converse fulltime
In the beginning of this year, I decided to drop other work commitments and to
dedicate this year fully to working on Converse and to see where that leads me.
This was in many ways a daunting leap into the unknown, because I knew I would
now have to find more ways to try and earn a living off this work.
I've been doing consulting and custom development around Converse for a few years,
but never exclusively. I also wasn't sure what business model I should adopt.
Consulting? Proprietary plugins? Hosting? Sponsorships?
I decided to first just focus on building the product, to make Converse better,
and not to worry about making money just yet.
In part this is due to my bias as engineer, and being out of my comfort zone
when trying to monetize something.
But I also believe that a compelling product, that users love, can go a long way
to helping you come up with a sustainable and feasible business model.
I hoped that along the way people might appear who would help me realize this vision.
It's the "if you build it, they will come" approach.
During this time, various people did in fact reach out to me and some of them
funded further development.
I also got enough consulting and development gigs to keep the lights on and to
keep me going.
Marc Laporte from Wikisuite funded many
hours of work moving the UI to Bootstrap 4, and then some more.
Converse will become part of Wikisuite, together with the OpenFire XMPP server.
He gave me valuable advice on how to make a living off open source
software and encouraged me to make the leap.
I also got a call from Happy Dev, who needed a
federated webchat solution for their Startin' Blox project (more on that in
future posts). We're doing some interesting work for them, which addresses some
pain points with XMPP and will be of benefit to the larger community.
Nicolas Vèrité, of Nayego funded responsiveness
improvements while individuals like Christian Weiske and Rafael Munoz
generously contributed funds as well.
Some people also backed me on Patreon and
Every gig or donation I got was for me a vote of confidence, and gave me the
opportunity to stay the course and continue down this path.
Besides monetary contributions, many people contribute features and
bugfixes, and hang out in the Converse chatroom, answering questions, providing
their expertise and generally making it a more lively, interesting place.
In many ways this release would not have been possible without all of their
contributions, and I therefore dedicate it to everyone who has contributed
money, time or energy (all interchangeable actually) to this project and
therefore has contributed to its success. Thank you!
The archetypal nature of free software communities
Over the last year I've witnessed the Converse project becoming a community and not just a collection of software.
It's a subset of the larger XMPP community and one that overlaps with various other XMPP and free software
This has been for me one of the most magical and satisfying things about being involved in open source.
Community is archetypally feminine , in the sense that it's something that
cannot be enforced, demanded or created out of domination, control or
rule-making (which are archetypally masculine attributes). Instead, it's something that arises
seemingly spontaneously, after an unknown period of gestation and only after the groundwork
has been laid and perhaps after enough loving care and attention has been provided.
Its organic, emergent nature means that it doesn't strictly adhere to top-down schedules and deadlines.
My wife and I, both interested and fascinated by Jungian archetypes,
are amazed at the archetypally feminine aspects of her
pregnancy, which is soon coming to an end (and new beginning).
As much as we as a society try to control, monitor and manage a pregnancy, if you decide to
have a natural birth, then you're waiting for it to happen on its own accord,
and aren't able to impose your will and deadlines on it.
In some ways the same is true for a software commons. A commons is a shared
resource which no-one has exclusive control or ownership of. This lack of
ownership and exclusive control makes people resilient against the software
being used as a tool for domination and exploitation. It also means that the
project (i.e. the software and its surrounding community) is more organic.
This coming together between software as inanimate artifact, and community as a living
breathing organic hive-mind, brings to mind a Taoist union of Yin and Yang, the
archetypal feminine and masculine.
Incidentally, the Converse logo is a stylized Yin Yang symbol. Many people
don't know this because I did such a poor job of designing it. I'm still
looking for a better logo design which encapsulates these principles of harmony
between community and software.
What does the future hold for Converse?
This has turned out to be a relatively strange blog post, where I wanted to
originally write about the features of the 4.0 release and instead took an ever
more esoteric detour.
In any case, let's try to salvage what's left of the original intent by closing
off with what's in the pipeline for future releases.
Converse still doesn't support markdown-like syntax highlighting. This is a
top-priority for future releases.
With voice messages I mean sending voice recordings, not audio streaming
(although that might also come sometime).
My wife, friends and family use voice messages (via Conversations)
a lot and I believe they'd be a useful addition to Converse as well.
One area where XMPP needs to improve is sending (email) notifications when
you're offline and mentioned in a groupchat. XMPP's groupchat presence rules
have made this difficult. Together with Happy Dev and Matthew Wild from Prosody
I'm working on a potential solution.
Some of the code for this solution is already in Converse, and we'll submit
a specification for standardization (a so-called XEP) once the time is right.
Making Converse a progressive web-app
There are various features of so-called progressive web apps which will make
Converse a much better client, such as:
- Push notifications even when Converse is not open.
- Using IndexedDB for caching, thereby avoiding storage limitations of localStorage and sessionStorage.
- Offline support for editing and sending messages.
Other webchat clients like Mattermost and Rocket.chat can keep you constantly
logged in via cookies or perhaps JWT.
XMPP-authentication isn't cookie-based and it's not safe to store user
credentials in the browser cache. This means that users often have to login
anew when they open Converse in a browser tab.
The Credential Management API
might help here, but it's still Chrome-only and I haven't studied it enough to
know whether it's a solution.
Another approach is to allow Converse to also use authentication cookies by
adding support for them to XMPP servers.
Matthew Wild has already added support for cookie authentication to Prosody but
more work needs to be done to get this working on conversejs.org.
Converse already supports OAuth-based login, but it's not yet deployed to
conversejs.org and more work can be done to fetch
and show your user profile from the OAuth provider.
Let's build this together
There are many more features and improvements planned, too many to list here.
The health and sustainability of this project depends in large part on its
community of users and contributors.
The community is invaluable in finding bugs, making feature suggestions and
doing quality control that would otherwise not be possible given the
Another important requirement for the long-term health and viability of the
project is funding.
I and others are spending much of our own time working on Converse, but to make this project sustainable
we need more funding. Either through donations (e.g. Patreon),
funded feature requests or by using my services as an XMPP and Converse consultant and developer.
Another option is allowing an employee to spend some of their paid time on helping the
project with bugfixes and other contributions.
This applies in general to open source projects. Companies derive immense value
from them, and the vast majority don't have wealthy corporate backers like Facebook and Google.
I also intend to soon start offering hosted solutions for organisations who want to
use Converse as their preferred teamchat solution.
Please reach out to me here if you're interested.