The problem I see with chat protocols is that it's all about network effect.
How do you get people to leave WhatsApp for something better? - You don't. They just stay on WhatsApp.
One problem being that if you want better security (Signal), you lose a little bit in UX. If you want better UX (Telegram), you completely lose the security aspect. So WhatsApp seems like a local optimum: relatively secure, and you can find your friends there.
Then we can discuss all we want about the merits of Discord/Slack/Matrix/Zulip, but the truth remains this: if you ask someone who mostly uses Discord what they want you to use for your new community, they will say Discord. If they mostly use Zulip, they will say Zulip. People don't want the better solution, they want the least effort.
I have seen multiple open source communities (who spend a fair share of their time complaining about how people don't support open source instead of using the proprietary alternative) choosing their chat system: people were fighting between Slack and Discord, nobody gave a damn about using an open source system. How hypocritical...
I looked into this recently too and ran into the same issues with Matrix. How the hell did they manage to make chat so complicated?
I found Zulip pretty interesting because it’s made a lot of smart UX decisions that let it double as a kind of inbox/task system and serve needs like customer support pretty well.
My main worry would actually be that even though I prefer its UX, the complexity and 2010s-style design would churn some first time users. If anybody has used it for engaging with external users I'd be very keen to learn how that went
> How the hell did they manage to make chat so complicated?
This is a bit like saying “CVS works fine; how the hell did they manage to make git/mercurial/monotone/etc so complicated?”
The point of Matrix is to replicate conversation history across participating servers without a single point of control. To make it impossible for a Facebook or similar to act as a gatekeeper on a conversation. It’s decentralised just as a DVCS is.
Just because we haven’t executed well enough yet on the implementation (due to getting stuck between Element and Element X on the clientside, and having to focus on govtech featuees on the serverside to try to keep the lights on) doesn’t mean the underlying idea of replicated chatrooms is bad. It just needs a git-equivalent implementation, where the perf and benefits mean folks stop fixating on the underlying complexity.
That's a very reasonable response and I appreciate you showing up to explain the actual implementation challenges. That's a problem many ambitious projects have and I hope you guys are able to execute on the vision.
I will say, as a vaguely interested outsider (but not so invested in the premise of decentralization that I am going to jump through hoops to use matrix) my impression of the user story "Ok I guess I'll finally check out that matrix thing and see what it's like" was that it assumed I had an understanding of various matrix concepts while getting started, and didn't really guide me down a happy path towards opening a functioning matrix client.
Eg here https://matrix.org/try-matrix/. I suspect 90-99% of first time users would want to just go straight to https://app.element.io/ but instead I had to figure out what the distinction between clients/servers/auth really meant, click through to install element, then select the rightmost icon to open it in my browser.
Some of the docs are similar (https://matrix.org/docs/chat_basics/matrix-for-im/#creating-...) - most likely I just want to make an account for the first time but the content is covering a ton of ground and arguably even introducing complexity (I can use any provider, but I don't have to, but need to keep in mind how it impacts data migrations, anyway this is the company behind matrix, they have an app, go here).
The subtext I sensed when I went through this for the first time was not exactly just that Matrix was complex. It was that the culture/expectations set by the people behind it was using it required me to learn/account for all this stuff even though I just want to open your chat app. To a certain extent as a nerd I am interested in your app, and I know a lot of the existing community is very interested in the technical details. But ultimately I'm just trying to check out a chat app, in fact I have already made the decision to go open it, and all the focus seems to be on selling its configurability/flexibility/potential rather than helping me chat.
The problem (exhibited all over this thread) is the conflation of protocols and apps. You misled yourself by overthinking it. This happened a lot a couple of years ago when people fled Twitter for Mastodon, putting themselves off by assuming they needed to understand nuts and bolts irrelevant to their use case. Did you need to know how HTTP works to use a web browser? Of course not. Likewise, most people confused about Mastodon would be better served if they understood they just had to sign up on a website and start talking to people, same as anything else. In this case, if all you wanted was to try a chat app, you should’ve started at Element and you never needed to even know about Matrix. People using these things interchangeably has done enormous harm to the decentralisation movement.
> Lemme tell you a secret about global event ordering in chat rooms: nobody cares. These aren’t bank transactions. If two users get the same two messages in opposite order from each other then it’s fine, even in a formal setting like a university talk or a work chatroom, and it can be fixed by the client as soon as the authoritative server decides on what ordering is correct.
Well, it depends on the level of inconsistency. Ironically, I'm in a bridged Tg-to-Matrix chat room on the Matrix side and regularly get dozens of messages in a shuffled order. Even though the messages have timestamps, it's very confusing. I tend to just ignore this room. So much for ordering guarantees.
I hosted Matrix Synapse for a few users and some bridges for many years, and I get some of the sentiment.
Synapse is okay, and bridges were the main reason for me. Documentation for setup and configuration is good now. No built-in admin panel, but I wrote my own. The bad things are:
- room replication means rooms stay on your server even after you leave them, and require manual cleanup.
- state_group_states is an append-only table that bloats the DB to incredible sizes, and also requires manual cleanup via SQL queries.
- media is not deleted when associated event is deleted and must be cleaned up manually.
- users cannot be deleted (in a reasonably simple way) at all. IMO a GDPR violation right there, but what do I know.
Element is great because it is consistent across platforms, but "share to" functionality was broken on iOS last that I checked, and image captions are not supported (although visible on long-press?).
ElementX is supposed to be better, but calls are not backwards compatible (why?), "share to" and a lot of other functionality is absent.
Both still have to rely on Google Play Services for timely notifications while Conversations.im manages to get instant notifications even without Play Services.
Bad example as Libera doesn't use most of the IRCv3 spec and they don't seem to be in any rush to become compliant. Shame because truly IRCv3 compliant networks do really feel modern, with QOL features like persistent sessions.
Sounds a bit like a rant. There may be interesting information between the rant and the assumptions ("I think it's kinda doing this?"), but if I quickly look at what it says about Signal, it's completely off. Marlinspike hasn't been involved in Signal for years, yet the article (updated in 2025) says that Signal may die when Marlinspike leaves?
Not to mention that it's not exactly "diving" into chat protocols.
While I love IRC, and freely admit it’s dead, dead, dead for good reasons, I still value it for a few things:
- Fast to build on. You can write a functional client without a huge budget or a research team.
- Decentralized by design. Centralization is ultimately about trust. One provider can shift policies or “enshittify” whenever its business model changes, making your community fragile.
- Zero-friction guest access. It’s refreshing to pop into a random IRC server without handing over an email address or pinning it to my Discord sidebar before I know if I even like the place.
For most of my chat use cases I don’t care about end-to-end encryption. If I need privacy with someone I meet on IRC, I’ll just send them a Simplex link. I’d rather keep the protocol lightweight and let each public space define its own standards than overload it with features I don’t need.
Spelling and grammar fixes via ChatGPT because I’m on mobile, sorry.
This was a pretty fun read. I like that the author gives their impressions and seems reasonably knowledgeable but also admits they don't know all the ins and outs of some of the things they address.
I find myself leaning more these days towards the view that the whole "eventually consistent JSON database replicated across all participating servers" thing is maybe too much of a reach. One big reason is that I think the challenges of moderation put a cap on how decentralized any usable communications system can be, so decentralizing things beyond the level of moderation doesn't actually add much, and can in some ways make things worse.
It's abundantly clear that you can't run any kind of public anything on the internet these days without some sort of moderation. It's also clear that moderation ultimately requires humans making decisions; you can have bots reacting in various ways to filter spam but you always need humans at the top who can override and tune those bots. For public forums, the capacity of those humans to keep things running in a sane manner is the bottleneck on centralization, not any technical decentralization of the protocol.
What this means is that if you have a chat room with a three-person mod team, there is not much to be gained by having the underlying protocol decentralized across the servers and/or clients of all 100 or 500 or 10,000 users in the room. Everything that every user sees is already subject to the decisions of the three mods and is therefore effectively "gatekept". Moreover, what it means for the room to be healthy is that all those users are basically satisfied with the moderation, which means that letting unmoderated traffic flow in a free and decentralized manner is actually not what people want --- it just means they'll see more spam.
A possibility to explore would be something that has some kind of partial or two-tiered decentralization in which (within the context of a given room) moderator servers have different status than ordinary-user servers. This might mean, for instance, that non-moderator servers simply trust moderator servers about state, rather than every server doing the full state resolution for every room. It could also mean that when moderation is overwhelmed by a flood of spam, there is a mechanism that can throttle traffic to the non-mod users, so that the room just appears quiet, rather than the whole flood of spam being replicated to everyone.
This idea is half-baked but I feel like something along these lines could mitigate some of the worst cases I've seen on Matrix, which can arise when the spam effectively DDoSes the moderators and the moderation actions (such as redactions or bans) become stuck in the processing queue behind spam messages.
In any case, though, it's clear that moderation needs to be baked into the protocol at a lower level than it currently is.
> In any case, though, it's clear that moderation needs to be baked into the protocol at a lower level than it currently is.
Lesson learned and relearned across all social and communication software... Moderation cannot be grafted on later: it is core, it makes or breaks the social experience.
HN, Bluesky and Reddit, for example, got it right, each in their own way for their own use case, and I believe it one of the main reasons of their success.
"Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting."
I find it strange that this comment first advocates the website author subsidize data collection for big tech, a group which it immediately clarifies "make people's lives miserable".
How do you get people to leave WhatsApp for something better? - You don't. They just stay on WhatsApp.
One problem being that if you want better security (Signal), you lose a little bit in UX. If you want better UX (Telegram), you completely lose the security aspect. So WhatsApp seems like a local optimum: relatively secure, and you can find your friends there.
Then we can discuss all we want about the merits of Discord/Slack/Matrix/Zulip, but the truth remains this: if you ask someone who mostly uses Discord what they want you to use for your new community, they will say Discord. If they mostly use Zulip, they will say Zulip. People don't want the better solution, they want the least effort.
I have seen multiple open source communities (who spend a fair share of their time complaining about how people don't support open source instead of using the proprietary alternative) choosing their chat system: people were fighting between Slack and Discord, nobody gave a damn about using an open source system. How hypocritical...
I found Zulip pretty interesting because it’s made a lot of smart UX decisions that let it double as a kind of inbox/task system and serve needs like customer support pretty well.
My main worry would actually be that even though I prefer its UX, the complexity and 2010s-style design would churn some first time users. If anybody has used it for engaging with external users I'd be very keen to learn how that went
This is a bit like saying “CVS works fine; how the hell did they manage to make git/mercurial/monotone/etc so complicated?”
The point of Matrix is to replicate conversation history across participating servers without a single point of control. To make it impossible for a Facebook or similar to act as a gatekeeper on a conversation. It’s decentralised just as a DVCS is.
Just because we haven’t executed well enough yet on the implementation (due to getting stuck between Element and Element X on the clientside, and having to focus on govtech featuees on the serverside to try to keep the lights on) doesn’t mean the underlying idea of replicated chatrooms is bad. It just needs a git-equivalent implementation, where the perf and benefits mean folks stop fixating on the underlying complexity.
I will say, as a vaguely interested outsider (but not so invested in the premise of decentralization that I am going to jump through hoops to use matrix) my impression of the user story "Ok I guess I'll finally check out that matrix thing and see what it's like" was that it assumed I had an understanding of various matrix concepts while getting started, and didn't really guide me down a happy path towards opening a functioning matrix client.
Eg here https://matrix.org/try-matrix/. I suspect 90-99% of first time users would want to just go straight to https://app.element.io/ but instead I had to figure out what the distinction between clients/servers/auth really meant, click through to install element, then select the rightmost icon to open it in my browser.
Some of the docs are similar (https://matrix.org/docs/chat_basics/matrix-for-im/#creating-...) - most likely I just want to make an account for the first time but the content is covering a ton of ground and arguably even introducing complexity (I can use any provider, but I don't have to, but need to keep in mind how it impacts data migrations, anyway this is the company behind matrix, they have an app, go here).
The subtext I sensed when I went through this for the first time was not exactly just that Matrix was complex. It was that the culture/expectations set by the people behind it was using it required me to learn/account for all this stuff even though I just want to open your chat app. To a certain extent as a nerd I am interested in your app, and I know a lot of the existing community is very interested in the technical details. But ultimately I'm just trying to check out a chat app, in fact I have already made the decision to go open it, and all the focus seems to be on selling its configurability/flexibility/potential rather than helping me chat.
The cynical side in me thinks that Matrix was invented by big social media companies trying to keep Open Source from dominating the chat space.
Well, it depends on the level of inconsistency. Ironically, I'm in a bridged Tg-to-Matrix chat room on the Matrix side and regularly get dozens of messages in a shuffled order. Even though the messages have timestamps, it's very confusing. I tend to just ignore this room. So much for ordering guarantees.
Synapse is okay, and bridges were the main reason for me. Documentation for setup and configuration is good now. No built-in admin panel, but I wrote my own. The bad things are:
- room replication means rooms stay on your server even after you leave them, and require manual cleanup. - state_group_states is an append-only table that bloats the DB to incredible sizes, and also requires manual cleanup via SQL queries. - media is not deleted when associated event is deleted and must be cleaned up manually. - users cannot be deleted (in a reasonably simple way) at all. IMO a GDPR violation right there, but what do I know.
Element is great because it is consistent across platforms, but "share to" functionality was broken on iOS last that I checked, and image captions are not supported (although visible on long-press?).
ElementX is supposed to be better, but calls are not backwards compatible (why?), "share to" and a lot of other functionality is absent.
Both still have to rely on Google Play Services for timely notifications while Conversations.im manages to get instant notifications even without Play Services.
It's in use right now on Libera.
https://libera.chat
But if they don't care for IRC then v3 probably won't do much for them.
https://ircv3.net/support/networks
The anime is great by the way, way better than cloudflare checkbox - where can I hire her to protect my chat users?
Not to mention that it's not exactly "diving" into chat protocols.
- Fast to build on. You can write a functional client without a huge budget or a research team.
- Decentralized by design. Centralization is ultimately about trust. One provider can shift policies or “enshittify” whenever its business model changes, making your community fragile.
- Zero-friction guest access. It’s refreshing to pop into a random IRC server without handing over an email address or pinning it to my Discord sidebar before I know if I even like the place.
For most of my chat use cases I don’t care about end-to-end encryption. If I need privacy with someone I meet on IRC, I’ll just send them a Simplex link. I’d rather keep the protocol lightweight and let each public space define its own standards than overload it with features I don’t need.
Spelling and grammar fixes via ChatGPT because I’m on mobile, sorry.
I find myself leaning more these days towards the view that the whole "eventually consistent JSON database replicated across all participating servers" thing is maybe too much of a reach. One big reason is that I think the challenges of moderation put a cap on how decentralized any usable communications system can be, so decentralizing things beyond the level of moderation doesn't actually add much, and can in some ways make things worse.
It's abundantly clear that you can't run any kind of public anything on the internet these days without some sort of moderation. It's also clear that moderation ultimately requires humans making decisions; you can have bots reacting in various ways to filter spam but you always need humans at the top who can override and tune those bots. For public forums, the capacity of those humans to keep things running in a sane manner is the bottleneck on centralization, not any technical decentralization of the protocol.
What this means is that if you have a chat room with a three-person mod team, there is not much to be gained by having the underlying protocol decentralized across the servers and/or clients of all 100 or 500 or 10,000 users in the room. Everything that every user sees is already subject to the decisions of the three mods and is therefore effectively "gatekept". Moreover, what it means for the room to be healthy is that all those users are basically satisfied with the moderation, which means that letting unmoderated traffic flow in a free and decentralized manner is actually not what people want --- it just means they'll see more spam.
A possibility to explore would be something that has some kind of partial or two-tiered decentralization in which (within the context of a given room) moderator servers have different status than ordinary-user servers. This might mean, for instance, that non-moderator servers simply trust moderator servers about state, rather than every server doing the full state resolution for every room. It could also mean that when moderation is overwhelmed by a flood of spam, there is a mechanism that can throttle traffic to the non-mod users, so that the room just appears quiet, rather than the whole flood of spam being replicated to everyone.
This idea is half-baked but I feel like something along these lines could mitigate some of the worst cases I've seen on Matrix, which can arise when the spam effectively DDoSes the moderators and the moderation actions (such as redactions or bans) become stuck in the processing queue behind spam messages.
In any case, though, it's clear that moderation needs to be baked into the protocol at a lower level than it currently is.
Lesson learned and relearned across all social and communication software... Moderation cannot be grafted on later: it is core, it makes or breaks the social experience.
HN, Bluesky and Reddit, for example, got it right, each in their own way for their own use case, and I believe it one of the main reasons of their success.
https://news.ycombinator.com/newsguidelines.html