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...
ddq7 hours ago
At this point, I simply want to pick whichever protocol has the highest concentration of my kind of folks. The Discord audience is not it.
weitendorf13 hours ago
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
Arathorn11 hours ago
> 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.
weitendorf10 hours ago
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.
amelius12 hours ago
> and ran into the same issues with Matrix. How the hell did they manage to make chat so complicated?
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.
Look into the history of Matrix and Element and I think you'll drop that belief. It might not curb the cynisism, though.
yaky10 hours ago
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.
rascul14 hours ago
> IRCv3 is probably an interesting story but I don’t know anything about it right now; are there people out there trying to use it?
But if they don't care for IRC then v3 probably won't do much for them.
emptysongglass6 hours ago
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.
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.
BrenBarn8 hours ago
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.
liotier1 hour ago
> 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.
PaulHoule3 days ago
[flagged]
dang16 hours ago
"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 added this to my uBlock filters to hide that stupid anime girl on every site that has it:
||*anubis/static/img/pensive.webp$image
DoctorOW3 days ago
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".
palata11 hours ago
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.
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...
At this point, I simply want to pick whichever protocol has the highest concentration of my kind of folks. The Discord audience is not it.
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.
> and ran into the same issues with Matrix. How the hell did they manage to make chat so complicated?
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.
You may be interested in this week’s Matrix Live (https://www.youtube.com/watch?v=OyuqM7RbX5E - transcript at https://gist.github.com/ara4n/190ad712965d0f06e17f508d1a45b5...) to see Matrix’s thoughts on this post and others, and whether your cynicism is warranted.
Look into the history of Matrix and Element and I think you'll drop that belief. It might not curb the cynisism, though.
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.
> IRCv3 is probably an interesting story but I don’t know anything about it right now; are there people out there trying to use it?
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.
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.
https://ircv3.net/support/networks
I've been running a Prosody server for a month or so. Thus far a positive experience.
I'm adding chat to my site, and I'm writing it from scratch. Somebody stop me!
The anime is great by the way, way better than cloudflare checkbox - where can I hire her to protect my chat users?
I believe the tool is Anubis: https://github.com/TecharoHQ/anubis
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.
[flagged]
"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."
https://news.ycombinator.com/newsguidelines.html
I added this to my uBlock filters to hide that stupid anime girl on every site that has it:
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".
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.