|
|
Log in / Subscribe / Register

Open-source Discord alternatives

By Daroc Alden
February 20, 2026

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.

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.


to post comments

Fluxer

Posted Feb 20, 2026 17:21 UTC (Fri) by tbodt (subscriber, #120821) [Link]

https://fluxer.app/ also exists, having popped up in the last few weeks. It's another very polished highly compatible Discord clone. The blog has a lot of info https://blog.fluxer.app/

Rocket chat

Posted Feb 20, 2026 18:33 UTC (Fri) by sramkrishna (subscriber, #72628) [Link] (17 responses)

There is also rocket chat and mattermost as well if you're looking for alternatives that isn't on this list.

GNOME and KDE both use matrix, the experience has been good and bad. But both of us were hit by CSAM and so there are definitely need some work with moderation tools. At the recent FOSDEM, there has been some focus on better moderation tools.

I like matrix, but the clients could use a lot work. There hasn't been an client that has a UX that lets me efficiently monitor conversations in various rooms. For instance, I do not see one that allows for "most recent activity".

It would be nice to be able to apply some external algorithm that I can use to monitor rooms when there are a lot of them.

mattermost

Posted Feb 21, 2026 17:11 UTC (Sat) by marcH (subscriber, #57642) [Link] (3 responses)

I once used "mattermost" at $WORK and I was very, very impressed. While I'm not an "advanced" user, for me mattermost did everything Slack does and just as well. Certainly much better than MS Teams.

It was self-hosted at the time. It's apparently 100% open-source but please don't take my word for it.

mattermost

Posted Feb 21, 2026 17:32 UTC (Sat) by dskoll (subscriber, #1630) [Link]

Yes, I like Mattermost quite a bit. I have a self-hosted instance for a few friends and me. That said, it's a bit of a nag and constantly tries to upsell you to the paid version. I guess I could build my own from source with the nagging removed, but that seems like a big hassle compared to downloading the pre-built binaries.

The Mattermost user experience is quite similar to Slack, but without Slack's anti-features.

mattermost

Posted Feb 23, 2026 8:22 UTC (Mon) by rnestler (subscriber, #160299) [Link] (1 responses)

I also used mattermost at a former employer. One nice thing is, that it is bundled with GitLab, so if you self-host GitLab it's very easy to just enable the mattermost server as well and integrating it with the user management of GitLab (https://docs.gitlab.com/integration/mattermost/).

We also use it in our Hacker- / Makerspace as the main communication tool and it works very well for us.

mattermost

Posted Feb 23, 2026 13:15 UTC (Mon) by ABCD (subscriber, #53650) [Link]

Unfortunately, Mattermost will no longer be bundled with GitLab as of 19.0 (which I believe is scheduled to be released in May 2026).

Rocket.Chat experience

Posted Feb 21, 2026 23:39 UTC (Sat) by hailfinger (subscriber, #76962) [Link] (1 responses)

Speaking as someone who is a Rocket.Chat (co-)admin for a self-hosted community instance for a FOSS project: do not recommend. (This advice does not necessarily apply to the enterprise version, I haven't used that.)

The release management is horrible. Regular regressions (sometimes also within patch releases), only fixed two feature releases later instead of in a patch release if you're unlucky. No mention of those regressions in the release notes, you have to trawl through the open and closed bug reports opened since the last upgrade. That may take hours and then you have to decide whether you break usability or stay on an old version. You can't stay indefinitely on an old release if you want push notifications in the app, though. Those push notifications will be cut off 6 months after the first release of a minor version if you stay on that minor version regardless of patchlevel. Official Docker images are not always available if you're looking for the latest patchlevel of still-supported older releases.

The upgrade procedure is somewhat reliable. Always make backups of your database and of the installed Rocket.Chat version. A version rollback is documented to be impossible once the database has been accessed by the newer version and I had to rollback after an upgrade more than once. Server snapshots FTW.

Warning messages about deprecations (e.g. for certain MongoDB versions in the backend) do not correspond to the documentation.

Warning messages in general stack up, even if the warnings are identical. If a warning "doesn't disappear" after dismissing, it's because you're seeing another identical warning in the same place. Such warnings can stack 20-high or more, creating a click orgy to dismiss them.

The security model is weird: Installed Rocket.Chat apps on mobile devices will still receive push notifications including the full message text after the user is logged out in the app. (This may be time-limited, but I only waited a few days before logging in again.)

If you're not willing/able to pay for enterprise and want to use the self-hosted community edition, the following restrictions will bite you:

Federation is an enterprise feature, i.e. you don't get it in the self-hosted community edition, so participation from people registered on other servers is not possible.

You have a push notification limit of 10,000 push messages per month. That sounds a like lot, but for a community of 50 people in a chat room with only a single phone each, you reach the absolute limit for the whole server after 200 messages in that chat room. Apps on mobile devices will still receive push notifications including the full message text even after they are logged out, possibly even after the mobile device doesn't exist anymore (commenters in the Rocket.Chat forum seem to disagree on whether that counts towards the total message limit). You can't find out which chat or which account is causing all the push notifications and exceeding the limit. If you don't have access to the Rocket.Chat central services console, you can't check how many push notifications you already used. No, you can't buy additional push notifications, you have to move to the Enterprise version if you want that. No, you can't use your own push gateway without recompiling the Rocket.Chat mobile app and uploading it to the various app stores.

If you become admin of a server which has been registered with Rocket.Chat central services (mandatory for push notifications), not having access to the email address used for registration means you can't log in to their central services console. You can get that fixed via support, but only if you buy the enterprise version. You're stuck if you only have the community edition.

On the positive side, Rocket.Chat had better usability (and easier administration) than Slack and Matrix back in 2021. Back then, we chose Rocket.Chat for those advantages and we're thankful for what we got. However, the Matrix world has evolved quite a bit, whereas Rocket.Chat stagnated. Currently, we're migrating to Matrix for our community.

Rocket.Chat experience

Posted Feb 22, 2026 1:53 UTC (Sun) by sramkrishna (subscriber, #72628) [Link]

For a period of time GNOME did use rocket chat and it seemed ok. One of the co-founders of Matrix, Matthew Hodgson spent a lot of time with us and in fact one of our members works for Matrix org so we have some close relationships. We moved to Matrix because of overall it seemed the closest to IRC. We still have some bifurcation where IRC was still something a lot of our members prefer because it doesn't have a lot of things that cause distractions like emojis, images, and giphy type things.

Rocket chat

Posted Feb 27, 2026 10:27 UTC (Fri) by anton (subscriber, #25547) [Link] (10 responses)

I am using Mattermost in one of the communities I am in. Works nicely.

At work we used to use Rocket chat. The way that it aggregated a new message to an older message by the same poster while there had been several intervening messages by others proved to be a real problem for one application where we used the chat for coordinating timing: a start command was aggregated to an earlier message, and some of the intended recipients did not notice it.

At work Rocket chat has been replaced by Matrix (using Element as the software). Works fine for the stuff we have done with it (but we no longer use the chat for coordinating timing in the same way, so I don't know if the problem mentioned above exists there); I also started out with a session that adjusted it to work well for that use. I find the thread feature not so great for many uses: I want to use it to keep a subthread together, but it basically hides all the answers (which may also be a legitimate use, but not always what is wanted); I have not worked much with threads in other chats, so this problem may not be limited to Element/matrix.

As a user of the chat parts of these systems, they all appear pretty similar (and similar to the chat part of Discord). One thing I hate about all of them is that, by default, pressing Enter sends the message. Someone showed me how to change that for one of them, and it's probably possible for the others as well, but having to adjust that on every application (and maybe every client) is annoying.

Rocket chat

Posted Feb 27, 2026 12:42 UTC (Fri) by taladar (subscriber, #68407) [Link] (9 responses)

Most modern chat software seems to have converged on using shift-Enter for line-breaks without sending the message in my experience.

Rocket chat

Posted Feb 27, 2026 15:31 UTC (Fri) by Wol (subscriber, #4433) [Link] (8 responses)

The trouble with using "Enter" to send a message is it is objectively bad by most measures. Primarily the "principle of least surprise".

Likewise "tab" is horribly abused,

Both come from typewriters, and are learnt by anyone using a word-processor - "enter" is even synonymous with "return" - and there are no obvious alternatives - unsurprisingly because these meanings are about 150 years old.

Then they got hijacked by web technology to mean other things, but it's the classic "muscle memory" problem - if the instinctive reaction actually does the wrong thing, then it's almost impossible to fix, and no - improved training is NOT a fix when the environment re-inforces the wrong behaviour.

If I'm used to using "return" to mean "return" then absolutely no amount of training will help me to learn that actually, "enter" really means "send"!

Cheers,
Wol

Rocket chat

Posted Feb 27, 2026 15:42 UTC (Fri) by geert (subscriber, #98403) [Link]

Eagerly awaiting the return of keyboards with a big lever for carriage return?
Oh wait...
https://www.7keysworld.com/products/tw1867-retro-typewrit...
https://www.pcmag.com/reviews/qwerkywriter

Now all we're missing are mechanical sliders for margins and TAB stops ;-)

Rocket chat

Posted Feb 27, 2026 15:47 UTC (Fri) by jzb (editor, #7867) [Link] (6 responses)

If I'm used to using "return" to mean "return" then absolutely no amount of training will help me to learn that actually, "enter" really means "send"!

Well, perhaps no amount of training will help you but this is something I got used to before the turn of the century. ;-)

If I recall correctly, "Enter to send" has been standard behavior for IRC clients and early chat platforms since at least the mid-90s. I'm always surprised when I have to do "Shift+Enter" to send a message. Fewer and fewer users have muscle memory from using typewriters or word processors. (That is, word processor devices, like the poor, overworked Brother WP that I used early in college...)

That said, it should ideally be configurable behavior in any well-designed client. Users should be able to set one or the other to suit their preferences.

Rocket chat

Posted Feb 27, 2026 17:09 UTC (Fri) by Wol (subscriber, #4433) [Link] (1 responses)

> (That is, word processor devices, like the poor, overworked Brother WP that I used early in college...)

Except that return/enter in word processors / text editors like Word, WP, Writer, vim, emacs et al still means return ...

And I probably use them a lot more than I use IRC/Chat/whatever. I think about the only time I use an app where "Enter" means "Send" is the work Slack client ...

Yes it is people-dependent, but for us old-schoolers, our daily grind still re-inforces "enter means return". :-)

Cheers,
Wol

Enter meaning send or return

Posted Feb 27, 2026 17:45 UTC (Fri) by farnz (subscriber, #17727) [Link]

At least in the chat clients I use, bar IRC which is line-oriented anyway, I can configure them such that Enter means "new line, don't send yet", and I use Shift-Enter to send. I've done this to work's Slack client, because Enter is muscle memory for me when I finish a logical line, and Shift-Enter is not, so I don't accidentally send things when writing longer resposnes.

Rocket chat

Posted Mar 4, 2026 8:13 UTC (Wed) by anton (subscriber, #25547) [Link] (3 responses)

My muscle memory comes from Email and Usenet where sending the message is definitely different from adding a line break, which I do with Enter/Return. The same is also true for various web fora.

I have never used IRC, and maybe sending a message on Enter was appropriate for that. But with modern chats that use Markdown, where you have to insert newlines because the format requires it, I don't think that sending on Enter is appropriate.

On at least one of the chats I use, I can switch to Enter->insert newline, Shift-Enter->send message, but the problem is that I use several chats, and several clients for these chats, and I have to perform the switch using some chat-specific way on every chat and maybe even on every client on every chat. It would be great if there was some general way to do that, like Unix's use of environment variables like $EDITOR.

Rocket chat

Posted Mar 4, 2026 10:16 UTC (Wed) by rschroev (subscriber, #4164) [Link]

I feel like shift-enter should always be the "softer" version, the one that e.g. starts a new line instead of a new paragraph, and especially never finishes and sends the message. I prefer using ctrl-enter for actually sending the message, leaving both enter and shift-enter for formatting the message (even when both enter and shift-enter act identically). It's what I'm used to in Thunderbird, but I think I've seen it in other mail clients and in chat boxes as well.

Rocket chat

Posted Mar 4, 2026 10:54 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

To me it seems like any chat system I have ever used has used Enter for sending and if it supports multi-line at all Shift-Enter for soft newlines without sending, seems reasonably close to a universal standard that we probably shouldn't screw with it because we can hopefully all agree that having different behavior in different chat applications would be the worst of all worlds.

Rocket chat

Posted Mar 6, 2026 15:02 UTC (Fri) by Wol (subscriber, #4433) [Link]

> because we can hopefully all agree that having different behavior in different chat applications would be the worst of all worlds.

because we can hopefully all agree that having different behavior in different ---- applications would be the worst of all worlds.

There. Fixed it.

Cheers,
Wol

Or maybe just stop?!?

Posted Feb 20, 2026 19:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

PLEASE stop using Discord/Matrix/whatever for support.

They're not indexed and any knowledge you put there _will_ get lost. Just use something like Discourse or phpBB. Heck, I _prefer_ phpBB these days.

Or maybe just stop?!?

Posted Feb 21, 2026 3:13 UTC (Sat) by josh (subscriber, #17465) [Link]

1) Discord/Zulip/etc are not in the same category as Discourse/forums/etc; the latter is for long-form posts with a higher latency, the former is for live chat with (usually) a lower latency. They aren't interchangeable.

2) Zulip web-public channels can be automatically published to zulip-archive, which can be indexed by search engines, in addition to Zulip having its own search. And eventually, Zulip web-public channels will be *directly* indexable.

Or maybe just stop?!?

Posted Feb 21, 2026 17:07 UTC (Sat) by marcH (subscriber, #57642) [Link] (8 responses)

> They're not indexed and any knowledge you put there _will_ get lost.

It is very annoying when people reference Discord/etc. discussion in some forge issue without summarizing it; you have a point there. But as Josh just wrote, that "loss" is a feature, not a bug. Often enough you do want "instant" messaging to be ephemeral - by design. Different types of tools for different use cases. Would you want all your _oral_ conversations to be systematically recorded and archived? Some yes, most not.

I see unfortunately not much besides education to stop people from confusing ephemeral discussions with permanent ones. C'est la vie. Maybe some sort of recurring warning/reminder when using an ephemeral tool that it is ephemeral? In other words: education...

Or maybe just stop?!?

Posted Feb 21, 2026 17:12 UTC (Sat) by intelfx (subscriber, #130118) [Link] (3 responses)

> But as Josh just wrote, that "loss" is a feature, not a bug. Often enough you do want "instant" messaging to be ephemeral - by design. Different types of tools for different use cases.

Except that the "use case" is often not known in advance. You can't know whether the conversation you are going to have will constitute an exchange of knowledge worth preserving for future reference.

> Would you want all your _oral_ conversations to be systematically recorded and archived? Some yes, most not.

Perhaps don't use public project spaces for those conversations that you wouldn't want to be systematically recorded and archived?

Or maybe just stop?!?

Posted Feb 21, 2026 17:31 UTC (Sat) by marcH (subscriber, #57642) [Link] (2 responses)

> Except that the "use case" is often not known in advance. You can't know whether the conversation you are going to have will constitute an exchange of knowledge worth preserving for future reference.

Yes: communication is not an exact science. Never has been. Must still keep trying!

> Perhaps don't use public project spaces for those conversations that you wouldn't want to be systematically recorded and archived?

This is not really an issue. When in a public space, most people nowadays are aware there is a good chance they can be recorded and archived for some unknown amount of time, possibly infinite.

The real issue raised by Cyberax was the other way round: users wrongly expecting public discussions to be recorded and available. This is the only issue I was referring to.

> > Would you want all your _oral_ conversations to be systematically recorded and archived? Some yes, most not.

What I meant here: ephemeral discussions are a common and valid use case, so it's not a surprise that tools for ephemeral discussions exist. It's not just about privacy, it's about being ephemeral by design.

Or maybe just stop?!?

Posted Feb 21, 2026 17:37 UTC (Sat) by intelfx (subscriber, #130118) [Link] (1 responses)

> Yes: communication is not an exact science. Never has been. Must still keep trying!

This is inconsequential. I demonstrated a specific reason why "use right tools for right use-cases" is not a solution to the problem Cyberax raised.

> The real issue raised by Cyberax was the other way round: users wrongly expecting public discussions to be recorded and available. This is the only issue I was referring to.

Well, what *I* meant was that it is not a wrong expectation. It is a correct expectation.

Or maybe just stop?!?

Posted Feb 21, 2026 17:53 UTC (Sat) by marcH (subscriber, #57642) [Link]

> I demonstrated a specific reason why "use right tools for right use-cases" is not a solution to the problem Cyberax raised.

There is no other solution and it solves the issue the majority of the time. It will never be 100% of the time because communication is not an exact science.

> > users wrongly expecting public discussions to be recorded and available.

> Well, what *I* meant ...

I assumed you were answering the bit you quoted.

> ... was that it is not a wrong expectation. It is a correct expectation.

Back to reality, the need for ephemeral discussions will always exist and "incorrect" tools for them will too. I'm sorry but the world will never get rid of those "incorrect", ephemeral tools just because you don't like them. At best you can dictate and inconvenience the projects you have a strong influence on. Merely inconvenience because people will find and use other ephemeral channels.

Here's a typical example:
- I couldn't figure how to do X, does anyone know?
- Did you check page Y?
- Ha! No I missed Y, thanks. How come it's not linked from Z that I did fiund?
- Good idea: Z should link to Y. Can you send a pull request?
- Will do! Thanks again.

Projects generally do not want to record and archive these, hence direct them to ephemeral tools. Yes, there will always be collateral damage where some things that should be archived, won't. I'm afraid we can only try to mitigate that collateral damage.

Or maybe just stop?!?

Posted Feb 21, 2026 19:53 UTC (Sat) by josh (subscriber, #17465) [Link]

> But as Josh just wrote, that "loss" is a feature, not a bug.

I did not say that. I was talking about the difference between real-time and forum-style communication; I didn't say there's no value in indexing both. As mentioned, Zulip supports indexing the real-time communications that occur on it, if you have them in a "web public" stream; currently that's indirect through zulip-archive, but eventually it can happen directly.

Whether a channel is private or public is something to be determined on a channel-by-channel basis.

Or maybe just stop?!?

Posted Feb 21, 2026 20:02 UTC (Sat) by excors (subscriber, #95769) [Link]

> Often enough you do want "instant" messaging to be ephemeral - by design. Different types of tools for different use cases. Would you want all your _oral_ conversations to be systematically recorded and archived? Some yes, most not.

In some ways, Discord is the worst of both worlds: all your messages _are_ recorded and archived forever(ish), and anyone who wants to hurt you can join a Discord server and trivially find every message you ever sent there (just put "from:username" in the search box), and find six lines to hang you or uncover personal information you wanted to keep to a limited audience. But also the messages are not indexed in a way that is helpful for people trying to benefit from the knowledge represented in the archive.

Sometimes people manually summarise and organise knowledge in read-only channels full of FAQs and useful links - but that's still only accessible via the Discord client, and will be lost if the Discord server owner deletes the channel or the server, so there's no proper long-term archive.

(Some researchers recently downloaded two billion messages sent across a decade on public Discord servers and published them online with ineffective anonymisation: https://discord-unveiled.niko.lgbt/ . Evidently Discord does not have good protection against scraping, so a long-term archive is possible but only for people nefarious enough to violate the Terms of Service.)

Or maybe just stop?!?

Posted Feb 23, 2026 11:26 UTC (Mon) by khim (subscriber, #9252) [Link] (1 responses)

> Would you want all your _oral_ conversations to be systematically recorded and archived? Some yes, most not.

This would depend entirely on type of archive. Would I want to have them all recorded and made accessible to me? Absolutely. Would I want to have my call to bank support be published on the open web? Probably not.

I don't see how archival makes things worse if it doesn't violate privacy settings.

Yes, sometimes keeping things private is safer by keeping talks “off record”, but if I had a guarantee that what's private would stay private… my memory is not perfect, damn it! Gimme these archives!

Or maybe just stop?!?

Posted Feb 23, 2026 19:44 UTC (Mon) by rgmoore (✭ supporter ✭, #75) [Link]

This would depend entirely on type of archive. Would I want to have them all recorded and made accessible to me? Absolutely. Would I want to have my call to bank support be published on the open web? Probably not.

There are definitely legal implications to inherently ephemeral means of communication. If you're ever involved in a lawsuit (in the USA, at least), the other party can demand you turn over all communications that might possibly be related to the suit. Your ephemeral media can't be turned over, but there's a good chance some of your ephemeral conversations will be referenced in a permanent medium. Depending on how that happens, it could create the impression that you're deliberately moving sensitive conversations to ephemeral media to avoid creating incriminating records. If the judge thinks you're deliberately hiding something that way, they can apply a variety of penalties, like telling the jury they can assume whatever was said in the ephemeral medium was bad for your case.

Or maybe just stop?!?

Posted Feb 22, 2026 20:15 UTC (Sun) by sturmflut (subscriber, #38256) [Link]

How is anything on Discoed not also lost?

Or maybe just stop?!?

Posted Feb 23, 2026 0:42 UTC (Mon) by schrmh (guest, #182480) [Link]

Matrix could very well be index. In fact, there has been an official archive:
https://archive.matrix.org/
https://matrix.org/blog/2023/07/what-happened-with-the-ar...

Matrix is also not only a protocol for chat – fun fact: originally the devs needed a protocol for a VRChat-like thing; Third Room – one could very well build a forum on the Matrix protocol. There have been clients that offered Facebook and Twitter-like experience but a full-fledged (web & search engine) accessible forum is sadly still missing.

Or maybe just stop?!?

Posted Feb 23, 2026 17:19 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

Totally agree, thanks for saying it so that I'm not the only one!

well-known instead of DNS SRV

Posted Feb 21, 2026 8:25 UTC (Sat) by ptman (subscriber, #57271) [Link]

Matrix actually prefers using a small JSON file under /.well-known/matrix/ instead of DNS SRV records these days.

There’s an elephant in the room

Posted Feb 21, 2026 15:41 UTC (Sat) by Baughn (subscriber, #124425) [Link] (1 responses)

Won’t the same EU laws also apply to these systems?

There’s an elephant in the room

Posted Feb 23, 2026 13:59 UTC (Mon) by daroc (editor, #160859) [Link]

As is always the case in matters of law, it depends.

I have not deeply investigated the recent EU laws, but the UK's online safety act, for example, has specific exceptions for services with small numbers of users.

IRC

Posted Feb 21, 2026 17:20 UTC (Sat) by marcH (subscriber, #57642) [Link] (12 responses)

> For everyone who doesn't want or need a Discord-like "modern" chat experience — IRC will always be an option.

I suspect one of main reasons IRC has been dying is: bad "offline" experience.

"Out of the box" IRC experience: all messages missed when offline!

I once tried Quassel briefly and it seemed to work but it required some effort - and of course it forces you to use a specific client which loses one of key advantages of IRC.

I heard about IRC "bouncers" but none of them seemed "beginner-friendly".

So when I hear "modern" I understand that out of the box I can go offline and not miss messages. Maybe even have multiple devices (e.g. laptop+phone) in sync with each other. I suspect most people take that for granted in this day and age.

IRC

Posted Feb 21, 2026 20:57 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> I suspect one of main reasons IRC has been dying is: bad "offline" experience.

...And numerous "walled garden" alternatives pushed quite heavily by $pre_bigtech that have risen and fallen in line with their inevitable enshittification.

IRC

Posted Feb 23, 2026 3:26 UTC (Mon) by marcH (subscriber, #57642) [Link]

Walled gardens never get any sympathy and can be blamed for many things but in this particular IRC case they sound a bit like a scapegoat.
Even while dying, IRC has always attracted tons of "hackers" and they did not all suddenly abandon IRC and all migrate overnight to these walled gardens which they hate. So why didn't these hackers help make the IRC experience more "modern"? Either because the protocol is poorly suited, or because they didn't care enough about being "modern". I don't know which it is but in any case the enshittified wall gardens are not much to blame here. Sometimes "yourself" is where most of the blame lies (apologies for anthropomorphizing IRC)

IRC

Posted Feb 22, 2026 13:29 UTC (Sun) by excors (subscriber, #95769) [Link]

That's the biggest reason I wouldn't go back to IRC. I mainly participate in channels where the volume is low enough that I can read every message, and I don't need to worry about missing potentially important or interesting conversations that happen while I'm asleep or on holiday etc. And, crucially, I know the other participants won't miss conversations either - I can reply to something they said hours ago without having to care whether they're currently online or not, and without having to switch to a different asynchronous messaging platform (like email).

I used to use IRC with irssi+screen+ssh for persistence, and it sounds like Quassel provides similar functionality with a slightly less rubbish UI, but it still doesn't allow that semi-asynchronous communication unless everyone else is using the same non-default client (and they almost certainly aren't).

IRC

Posted Feb 22, 2026 19:04 UTC (Sun) by NightMonkey (subscriber, #23051) [Link] (4 responses)

ZNC is really nice for that "offline" experience (https://wiki.znc.in/ZNC). It speaks the IRC protocol to connecting clients, so any IRC-capable client will work fine. It has a plugin ecosystem, which includes a web interface (that you must not put onto the public Internet...). While initial configuration and learning may seem a steep climb, my experience has been that it is mostly 'set it and forget it'.

I use Weechat on my desktop/laptop and "IRC for Android" on my phone with ZNC as the bouncer (aka "offline IRC proxy"). Sadly, "IRC for Android" seems to be abandoned as a project, and backups don't work, but I don't care about backups... since I use ZNC as my "single source of truth" for all my IRC accounts (Libera.Chat, OFTC).

ZNC is certainly oriented towards a DIY approach to computing services. Is DIY for 'beginners'? Not really. But, then again, DIY is not really for beginners, but everyone is a beginner at some point. :)

IRC

Posted Feb 22, 2026 19:23 UTC (Sun) by dskoll (subscriber, #1630) [Link]

+1 for znc. And if you pair it with matterircd, you can also interact with Mattermost and Slack over IRC. It's not a huge with for Mattermost, but gating Slack through IRC give you ways to block the Slack anti-features like the stupid Slackbot.

I leave znc running on my Raspberry Pi 4 server 24/7.

IRC

Posted Feb 22, 2026 20:10 UTC (Sun) by josh (subscriber, #17465) [Link] (2 responses)

That's definitely a long way from "sign up, start using it, it just works".

IRC

Posted Feb 22, 2026 20:30 UTC (Sun) by NightMonkey (subscriber, #23051) [Link] (1 responses)

Sure. It depends(tm) on what you want from your computing environment, including considerations around the level of surveillance, advertising and commodification of your time and attention you are willing to put up with for less apparent effort.

"No such thing as a 'free lunch'." was such a illustrative phrase. (https://en.wikipedia.org/wiki/No_such_thing_as_a_free_lunch)

IRC

Posted Feb 23, 2026 3:15 UTC (Mon) by marcH (subscriber, #57642) [Link]

> "No such thing as a 'free lunch'."

While proprietary solutions are generally more user-friendly, I hope it's only because they have more resources and are ahead of the curve, not because user-friendliness and privacy are technically incompatible with each other. We are only talking about messaging here; I don't know whether it's a "basic human right" but it certainly should not be rocket science. Maybe asking for privacy + user-friendliness while not paying anything is still a bit too much (someone has to pay for those cloud bills...), but it should be technically possible to have at least the first two at the same time? Looking forward to it.

PS: I have no idea whether something more "modern" could be built while preserving the IRC protocol. I'm only noticing that none of the very many alternatives seems to try that.

IRC

Posted Feb 23, 2026 2:20 UTC (Mon) by mroche (subscriber, #137163) [Link] (2 responses)

> So when I hear "modern" I understand that out of the box I can go offline and not miss messages. Maybe even have multiple devices (e.g. laptop+phone) in sync with each other. I suspect most people take that for granted in this day and age.

Have you taken a look at the IRCv3 developments in the works. Several of its goals are addressing issues related to these problems.

https://ircv3.net/

IRC

Posted Feb 23, 2026 3:31 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

I had never heard of IRCv3, sorry I kept writing "it's dying" above. Maybe it's not too late?

IRC

Posted Feb 24, 2026 3:00 UTC (Tue) by mroche (subscriber, #137163) [Link]

First sentence was supposed to end with a question mark 😅

I personally don't use IRC anymore. The need ended when Fedora and CentOS migrated to Matrix. But I do find the v3 work interesting, but like anything else it only moves forward if people put in the effort.

IRC

Posted Feb 23, 2026 9:28 UTC (Mon) by taladar (subscriber, #68407) [Link]

I suspect another reason with software projects in particular is that the ability to just quote a multi-line piece of code with formatting preserved it quite useful in these discussions.

Correction: Zulip is not centralized

Posted Feb 22, 2026 15:39 UTC (Sun) by tabbott (subscriber, #60572) [Link] (7 responses)

> Since Zulip is centralized, users on one server cannot easily and directly talk to users on another server.

Just a correction on the terminology: I lead the Zulip project and was quite surprised to see Zulip described as "centralized".

It seems the article mixes up "centralized" with "federated", which are independent concepts. Zulip is not centralized: Self-hosted Zulip servers can be completely self-contained, with the typical server only making outgoing network requests when it is configured to do so and to support a feature that is impossible without those requests (sending email, sending mobile notifications, fetching websites for previews, etc.).

Zulip clients are designed to support connecting to many different Zulip servers. So with Zulip, you can absolutely chat with people who primarily use a different Zulip server with your Zulip client without installing anything new -- you just need to do the bit of overhead of making an account on that other server. There's a valid debate to have on what the right security/account management model is -- there are benefits to having a "single" account that federates to other servers, and benefits to the accounts being independent, which makes moderation and data portability a lot simpler. (There's also several FOSS clients, like Rambox, Ferdium, and Pidgin, that support lots of chat protocols in a single app, so you don't need server-to-server federation in order to have the human user experience of chatting with whoever you like from a single app).

But that's about federation, which is just a different axis from centralization. You can have centralized but federated (say, the US banking system, or email, where not using a centralized service for spam filtering is impractical) or decentralized but not federated, like Zulip.

Correction: Zulip is not centralized

Posted Feb 22, 2026 17:16 UTC (Sun) by iabervon (subscriber, #722) [Link] (2 responses)

I think the right way to phrase it is that Zulip is not centralized but that a Zulip server is centralized. Any particular conversation happens in a single place, with exclusively participants known to that place; conversations that happen in a different place have participants whose identities are not connected to the identities in the first place, even if the same client has both of them. On the other hand, the same server and client software and protocol can be replicated many times; while Facebook and Discord are different software with a single instance of each, different Zulip installations work the same way and run on the same software.

Correction: Zulip is not centralized

Posted Feb 22, 2026 18:10 UTC (Sun) by josh (subscriber, #17465) [Link] (1 responses)

I think "decentralized but not federated" captures that nicely.

I'd say that's probably the biggest difference people would end up dealing with, if they switch from Discord to Zulip: you have one account per server, and DMs are per-server.

Correction: Zulip is not centralized

Posted Feb 23, 2026 2:04 UTC (Mon) by iabervon (subscriber, #722) [Link]

I think of "decentralized but not federated" as like classic IRC, where there were multiple disconnected networks (so, not federated), but each network also had no single server necessary for having a conversation on that network (users would pick somewhat randomly between servers that weren't too far from them).

None of these options are going to be centralized in the sense of having only one instance, since anyone can get the server software to run their own instance.

Correction: Zulip is not centralized

Posted Feb 23, 2026 14:05 UTC (Mon) by daroc (editor, #160859) [Link] (3 responses)

That's an interesting distinction. It doesn't match my understanding of the definitions of 'centralized' and 'federated', but I can see how your version holds together. I tried to get around terminology issues by putting in that little definitions box, but clearly that was insufficient. My copy of Merriam-Webster does not have the technological definitions, unfortunately, just the historical ones.

Correction: Zulip is not centralized

Posted Mar 9, 2026 1:14 UTC (Mon) by tabbott (subscriber, #60572) [Link] (2 responses)

In my view, Signal or Proton would be good examples of apps that are open-source but centralized and not federated. (Well, email is federated, but I think Proton has various services that are not).

If you can self-host a self-contained server, and thousands of people including the majority of actual users in fact do that, I don't think there's a serious sense in which it is centralized.

Correction: Zulip is not centralized

Posted Mar 9, 2026 7:05 UTC (Mon) by zdzichu (subscriber, #17118) [Link] (1 responses)

FTR, Signal was federated some time ago. There was another client WhisperPush shipped with CyanogenMod for Android devices. Federation ended and was deemed "degrading user experience" and "holding back development".

Correction: Zulip is not centralized

Posted Mar 9, 2026 10:28 UTC (Mon) by paulj (subscriber, #341) [Link]

Or holding back Five Eyes¹ monitoring

1. They prefer to call themselves the "Five Sisters", amusing institutional sensitivity.

No discussion on voice/video channels?

Posted Feb 25, 2026 20:32 UTC (Wed) by tbelaire (subscriber, #141140) [Link] (6 responses)

It's interesting what LWN's article writer considered important in these comparisons, compared to what the discord migration discussion I have personally seen compared.

In particular, being able to screenshare and voice chat at similar levels to Discord were table stakes level, while federation is not important to that group at all. So Mumble, Vent, and Teamspeak were considered, along with Stoat and Root.

I even looked into selfhosting Jitsi, alongside a text chat.

No discussion on voice/video channels?

Posted Feb 25, 2026 21:09 UTC (Wed) by daroc (editor, #160859) [Link] (1 responses)

... this might be my aversion to video calls showing up as a bit of a bias. My hobby communities have been having the Discord migration discussion as well, but we don't tend to use video or voice chats at all, so it wasn't at the top of my mind.

Zulip has a Jitsi integration that allows one to start a Jitsi call via a configured server directly from a Zulip chat. Matrix has native VoIP, although one has to configure an appropriate STUN server and client support is limited. There's also an XMPP extension for voice and video calls, but client support is a problem there too.

No discussion on voice/video channels?

Posted Feb 27, 2026 11:30 UTC (Fri) by taladar (subscriber, #68407) [Link]

FWIW I prioritized text over voice or video just like you did since I can barely remember the last time I used Discord for either and in general only used it a handful of times in the 10 years or so on there.

No discussion on voice/video channels?

Posted Feb 27, 2026 9:37 UTC (Fri) by anton (subscriber, #25547) [Link] (3 responses)

In one of the communities I am in, we use Mattermost for chat, and BigBluebutton (BBB) for voice chat. This works quite nicely, with one caveat: people tend to use the ephemeral (lost when the session ends) text chat within BBB when we are voice chatting, while in many cases the text chatting would be more appropriate on Mattermost: If it's about the discussion topic, Mattermost is better, whereas for questions concerning the voice chat ("do you hear me?") the BBB chat is better.

BBB also provides Etherpad (shared document editing), but in our experience it's better to post different text/code variants on Mattermost, so that we can go back and forth, compare, and pick and choose, rather than having just one version with Etherpad; copying and editing in Mattermost is hardly harder then editing in Etherpad.

No discussion on voice/video channels?

Posted Feb 28, 2026 3:28 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

This sounds like the terrible Google Meet in-call messaging that is ephemeral. It'd be really nice if it were possible to just stick it as a thread in an existing space instead of making it go away so easily when all participants are part of the same workspace.

The Direct Message chats it opens for meetings are also terrible: no thread support and cannot be converted to their own spaces. So the conversation *also* gets stuck in a purgatory. But at least search can find it again.

No discussion on voice/video channels?

Posted Mar 2, 2026 8:57 UTC (Mon) by taladar (subscriber, #68407) [Link] (1 responses)

Actually they changed the Google Meet one now so it turns into a Google Chat channel you can refer to afterwards.

No discussion on voice/video channels?

Posted Mar 2, 2026 11:05 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

It's definitely not automatic at least. Or we haven't gotten the rollout applied.

Does it capture all chat or just what the person doing the conversion has in their history (because when the network drops, I tend to lose the chat history too)?

Self-hosting without federation seems a weird trap

Posted Feb 25, 2026 23:04 UTC (Wed) by LionsPhil (subscriber, #121073) [Link]

Self-hosting without federation seems a weird trap. If you're moving communities, the odds each will end up on the same self-hosted server seems slim. So now you need to manage N accounts for those N servers, and need a client that can likewise be signed into them all.

IRC clients can often do that, and you can go register with NickServ on each, but it's one of IRC's weird, complex warts. And even then, a lot of IRC activity ends up collapsing down to "big" networks like Libera.Chat.

It seems more likely that everyone just moves onto the "default" instance, and what you have is a centralized service that is only *theoretically*, but not practically, self-hostable. It's more technically possible to fork/resurrect if something catastrophic happens with the main operator, but you're still largely at their mercy (and any gentle turning of the monetization screw) until then.

usenet anyone?

Posted Feb 26, 2026 12:58 UTC (Thu) by nbecker (subscriber, #35200) [Link] (2 responses)

You know, I really miss usenet. Using knode for example as a reader, I've still not found any of these web-based clients to provide a UI that as efficient for me to quickly find articles of interest in groups I participate in. Not to mention that, back in the day, all the different projects I watched all used usenet, so I just needed one client to follow them all. Now it's a pain to even figure out which projects are (primarily) using which services and clients to try to follow.

usenet anyone?

Posted Feb 27, 2026 9:42 UTC (Fri) by anton (subscriber, #25547) [Link]

Usenet is still here. There are also a number of old and new users on Usenet, although many former regulars no longer post on Usenet.

usenet anyone?

Posted Feb 27, 2026 12:00 UTC (Fri) by taladar (subscriber, #68407) [Link]

We might need something in .well-known in some standard format to describe a company's or project's communication channels perhaps?


Copyright © 2026, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds