The closed-source chat platform Discord
announced on February 9 that it would soon require some users to verify their
ages in order to access some content — although the company quickly
added that
the "vast majority
" of users would not have to. That reassurance has to
contend with the fact that the UK and other countries are implementing
increasingly strict age requirements for social media. Discord's age
verification would be done with an AI age-judging
model or with a government photo ID. A surprising number of open-source
projects use Discord for support or project communications, and some of those
projects are now looking for open-source alternatives. Mastodon, for example,
has moved discussion to Zulip. There are some alternatives out there, all
with their own pros and cons, that communities may want to consider if they want
to switch away from Discord.
Matrix
Centralized, federated, decentralized
Chat applications generally fall into three distinct groups: centralized services (where one server manages all communication), federated services (where there are multiple servers hosting different users that can all talk to one another), and decentralized services (where clients talk to each other directly without servers). In a centralized system, all usernames live in the same namespace. In a federated system, each server forms a separate namespace, so users have to pick a specific server to join. Decentralized naming schemes are more complicated — and also out of this article's scope, since none of the options listed here are decentralized.
The
Matrix project started in 2014; it is an attempt to build a federated messaging and
synchronization protocol that gives people full control over their own
communication. The project's
manifesto says: "The
ability to converse securely and privately is a basic human right.
"
The project has been
welcoming former
Discord users, after seeing a huge spike of sign-ups to the matrix.org "homeserver" —
the server that the Matrix.org Foundation runs as a way for people to easily
start chatting on the network.
Many users do eventually move to another homeserver, self-hosted or otherwise; there are many independent server implementations, fitting a variety of different needs. Seven are listed as actively maintained, with eleven more that have been abandoned for one reason or another. There are even more client applications, including a handful that act as web front-ends for people who don't wish to download and install another application.
This variety of implementations is both a blessing and a curse for Matrix. On the one hand, they're a clear sign of a vibrant community and a diverse software ecosystem. On the other hand, many of the clients are missing specific features, meaning that users will need to shop around a little to find a client that fits their needs. Generally, all clients support joining rooms (analogous to Discord channels) and doing basic chatting. The way the Matrix protocol is structured also means that they universally support synchronized use of the same account on multiple devices, even across clients. When new clients sign into an account, there's a short authentication dance involving the previous clients to ensure they're authorized. (Or a recovery procedure, for those who have lost their previous device.) Some security researchers have raised concerns about the cryptographic implementation in existing libraries [although the Matrix Foundation has published a rebuttal], so that is another factor that varies across implementations.
Most clients support organizing rooms into "spaces" (groups of related rooms that you can invite other people to, analogous to Discord "servers" or "guilds"), adding and viewing emoji reactions, and splitting side conversations into separate "threads". Custom emoji reactions are also well supported. Having multiple accounts signed in on the same client, on the other hand, is not well-supported; the advice seems to be to run multiple separate clients if one wants to keep work and personal accounts separate, for example.
On the protocol level, Matrix does a good job of abstracting over the federated nature of the network. Rooms and spaces can be transparently shared with users on other homeservers, spaces can include rooms from multiple servers, and so on. One can even create a room on one server, have a user on another server join, and then have the first server leave the room, passing off the responsibility for operating the room to the new server. Individual servers going down, therefore, has little impact on the network as a whole.
Like what you are reading? Try LWN for free for 1 month, no credit card required.
At a lower level, Matrix communication is sent over HTTP or HTTPS. This adds some overhead to the protocol compared to operating directly over a TCP socket, but it makes it easy to run a Matrix server from a residential connection and put an HTTPS proxy in front of it. The protocol also supports using DNS SRV records to separate the domain name of a homeserver from its actual hosting location.
Overall, Matrix is a reasonable alternative, especially for users who care about seamless federation. Server software is relatively easy to set up for projects wishing to self-host. The main downside is that some of the software involved is a little unpolished; of the clients I tried, several of them had small bugs or user-interface glitches. Element is probably the most polished, but its support for threads wasn't as nice as some of the other clients.
Jabber
Jabber, also known as XMPP, is a federated open standard for online communication and messaging. It's considerably older than Matrix, dating back to 1999. Despite that, it supports a number of modern chat features through protocol extensions, such as emoji reactions, typing notifications, and so on. Its long history also means that it has a large number of client and server implementations. Those clients run the full range from simple proof-of-concepts to well-designed applications, and from normal desktop and mobile applications to special-purpose tools. The libpurple C++ library has a generic XMPP implementation that makes it possible to write personal tools that use the protocol. Each server has its own ways to register, but the project maintains a list of public instances for people to try.
Jabber was historically designed for one-on-one chats, with multi-user chats (MUCs) being a later addition to the protocol. Consequently, it lacks the server/channel/thread hierarchical organization that Discord has. On the other hand, the protocol has stood the test of time, and seems unlikely to be going anywhere. For its core use case of chatting with friends, it is well-polished and usable. Jabber clients also tend to have good support for multi-account usage, and there are a number of bridges that can facilitate communication between Jabber accounts and other chat services. Some Jabber clients, such as Pidgin even have native support for other protocols as well.
Jabber's federation system lets users from different servers chat seamlessly with one another, but it doesn't make migrating MUCs around quite as transparent as migrating Matrix rooms: MUCs are created on a specific server, and rely on that server staying up to remain usable. That isn't normally too much of a problem, however; if one's Jabber server goes down, one can't participate in chats anyway.
On a protocol level, Jabber does its own communication over TCP, so one needs a handful of externally accessible ports to self-host a server. That is just about the only requirement, however. Projects like Snikket or Openfire provide self-contained Jabber servers requiring minimal setup. For people who just want to chat with their friends with minimal hassle, using mature tools that work reliably, Jabber is a good choice. Projects that want to make it easy for new contributors to join their discussions might find Jabber's group-chat-oriented organization less helpful, however.
Zulip
Zulip is a centralized chat platform that focuses on making it easy to follow multiple threads of conversation. Zulip is primarily developed and maintained by a company called Kandra Labs, which offers paid hosting for people who want a solution where someone else does the relevant server administration. The software itself is completely open source under an Apache 2.0 license.
Since Zulip is centralized, users on one server cannot easily and directly talk to users on another server. The project does expose an API for bridging software to use, and specifically recommends matterbridge as a way to connect Zulip channels to chats on other protocols.
Zulip organizes channels on a given server into folders, and then supports "conversations" as a subdivision of an individual channel. The user interface, which comes in both web and desktop versions, sports a combined activity feed that makes it easy to see what has changed in the conversations that one has actively participated in. That makes it handy for large projects that have a number of discussions going on at the same time. Zulip boasts a large number of moderation and organization features as well.
Self-hosting is fairly straightforward, although the installer assumes that Zulip is the only software running on the server and will freely install and configure additional dependencies, so it's best to install in a container or virtual machine. The requirements are also a bit heftier than Matrix or Jabber. Zulip can be hosted behind a HTTPS proxy, although using the optional email integration requires access to incoming port 25.
The one difference between the self-hosted version and the paid version, which are otherwise completely feature equivalent, is that the self-hosted version is limited in the number of mobile devices it can push notifications to. Open-source projects, academic researchers, and non-profits can have that limit raised for free. The limitation comes from the fact that Google and Apple require a single server to send all push notifications to the Zulip mobile apps, so self-hosted installations have to relay them via the central Zulip server.
The desktop and mobile clients support signing into multiple Zulip servers, but the web interface requires the use of separate tabs for separate servers. The interface is generally clean and usable, although the lack of alternative clients makes that somewhat understandable. Overall, Zulip would be a good choice for larger projects that want a modern, polished experience and care less about federation. Even if Zulip uses a centralized architecture, however, its almost-all-open-source nature and ability to export history significantly reduces the risk of lock-in.
Stoat
Stoat chat is another centralized, self-hostable chat platform. It has a smaller development community than Zulip, but it has an interface and structure that more resembles Discord. It also has a single main server, stoat.chat, with little interest so far in any kind of federation or interoperability. The project's documentation doesn't completely rule out the possibility, however — it just indicates that it's not on the project roadmap for now.
Users who want a Discord-like experience, including having a single central server, but who want the possibility of self hosting in the future, might like Stoat. It is licensed under the AGPL v3.0, and hosting costs are currently covered by donations. In the future, the project may look into charging on a usage basis, to defray costs, but promises not to charge for premium features the way Discord does. Stoat's lack of import/export support and interoperability make it a less good choice for projects that don't want to put all of their eggs in one basket, however.
Spacebar
Ultimately, people often don't want to stop using the software that works for them. For people who really miss Discord and want the exact same experience — down to the level of API compatibility — there is Spacebar. This project is an attempt to reverse-engineer Discord and create a self-hostable AGPL-licensed version. The project was started in 2020, and the server software is mostly working. The client implementation, however, is still new and experimental. The project doesn't recommend using it yet, and bugs are inevitable.
The server software is designed to implement the exact same API as Discord itself does — although, since the Discord client is closed-source, it can't be pointed at a Spacebar server. That identical API means that bots and integrations written for Discord can be pointed at a Spacebar server, however, and theoretically run without ever knowing that they've been redirected.
Spacebar is under active development, with a healthy development community. People who just want "Discord, but open-source" and are willing to pitch in, or to wait for Spacebar's client implementation to catch up, might find Spacebar the simplest replacement.
Conclusion
This list is by no means exhaustive. There are so many other open-source technologies and protocols with overlapping use-cases that a complete list would be impossible to construct. But these alternatives seem like the completely open-source applications most capable of replacing Discord and the things that people use it for at the present moment. For everyone who doesn't want or need a Discord-like "modern" chat experience — IRC will always be an option.