It's also a typical reason why the age verification ideas are always a bad idea. In the rarest case it'll be an anonymized official system from the state, and in all others some 3rd party vendor you wouldn't give you email in any other circumstance.
I don’t really like the platform anyway… currently, I sometimes sign in if I’m collaborating with people who already use it. But I don’t like to stay signed in on my laptop; it makes slack look light weight, and I’m using my laptop for things that are both more important and resource-hungry like VMs and JetBrains editors. I’ll probably give up the first time this requirement introduces any new friction for me.
If this breaks anything it’ll most likely erase my willingness to sign in at all.
I had to read the "End to end encryption is another misfeature for public channels" section multiple times to process it (thankfully, it's short!), and I'm surprised that I agree with it upon further consideration, but I really do strongly agree with that. The way you stated the point resonates with me, and I expected to disagree with you about that part of the piece, based on the header.
That said, Zulip was about to be my next choice for a social club. Can you elaborate more on why you don't think it's a good fit?
That said, Zulip was about to be my next choice for a social club. Can you elaborate more on why you don't think it's a good fit?
The threading model is polarizing and mostly useful for keeping multiple on-topic threads together while multiple are being posted to. It works really well for i.e. technical communities or corporate instances because of that; I'm using it for such a community. For a social thing, you don't need that level of hierarchy, it just imposes friction. That said, Zulip has unthreaded channels now, so that may be better, but I still think it's not the right choice for that.
The lack of a smooth A/V experience is the other, but that's dependent on the community. I write this in mind with hanging out in a voice channel with friends, so...
I don't really want threading, I want lightweight UI for side discussions. The text equivalent of a breakout discussion. My key requirements are:
It should be trivial to say 'let's move this off the main channel'.
There should be a breadcrumb so that people who want to see the discussion can do so and join in, but the rest of the side discussion should not flood the channel.
There should be a trivial way of promoting a side discussion to a discoverable channel if it ends up being long running.
Having a hundred short-lived side discussions in a week should not clutter the UI
There should be a gentle way to nudge folk who continue posting on the main channel towards the new side-channel (IIRC Zulip let users move other peoples messages into a sub-thread, which helped a bit here)
Maybe? I got less than 20% into the Slack T&Cs before deciding I would never agree to them. What does their UI look like for 'we've started a conversation that most of this channel isn't interested in, let's move it to a new place' look like?
you can reply to any message to start a thread and that's it. there's no way to move messages into the thread or anything like that. it's awkward and does lead to confusion when somebody thought the conversation died but actually it's active in some thread, but I am not sure I've seen any tooling that solves this without increasing complexity drastically
End to end encryption is another misfeature for public channels
I have a pet theory that the reason Matrix is bad is that it's half made by people who want it to replace IRC and half made by people who want it to replace Signal. Everything that makes it good as an IRC replacement makes it bad as a Signal replacement, and vice-versa. Pick a lane!
This way you end up with Soatok posts about how horrifying the bugs in the E2EE are and then people like me who are all "I literally do not care even one tiny bit" but the amount of effort and noise that goes into addressing those issues, ugh.
I think that's a really good take. And I might steal it, though I'm unlikely to specifically refer to Signal under any circumstances at all. The considerations for those two types of chat are different and competing. And while it's quite tempting to assume that private chat features are good for every kind of chat, that just turns out to be untrue when you apply a moderate amount of pressure.
My theory is that Matrix is bad because it tries to be pure P2P but lots of features (like moderation and spam filtering) need a source of authority. So they end up tacking those on afterwards and then nothing works particularly well.
I disagree with it, but for a technical reason that they don't mention.
E2EE encryption needs cover traffic in order to prevent trivial metadata recovery. If one message goes in one device and comes out another, you know who was talking. If a thousand messages do that. You need to do a lot more work. Especially if the server deliberately tries to obfuscate.
Group chats participating in E2EE even if they don't need it helps provide cover traffic for the people who do need it.
That was my stance going into the read. Reading the piece and some of the linked materials made me reconsider it. The piece is specifically talking about public group chats. And the public part is really load bearing there. It means anyone can join the chat. So, for instance, imagine for a second that liberachat was end-to-end encrypted, and that we hosted the lobste.rs chat there. The lobste.rs chat is fully public. Anyone who learns of its existence is allowed to join (unless they've been banned, but that really does practically equate to "anyone" for all reasonable purposes).
That means that all of the metadata is already public. Any interested party can join and see it.
Using an e2ee scheme for that and sending it through the same channel as something that is actually private involving some set of the same participants could actually help leak interesting metadata, especially if there's some weakness in the e2ee scheme. I hadn't thought of that before, despite having actually worked out a proof-of-concept attack along these lines against an encrypted email list (using the S/MIME CMS) before.
In general, I like the idea of chaffing and winnowing as one layer of protection, but I think in the specific case of e2ee over this kind of public channel, I'm now convinced it could be harmful.
I think the "Discord killer" will come out on top based on its VoIP and video features. Screen sharing, webcam sharing and noise cancelling are the three necessary features for any post-Discord chat application to implement to win.
I really miss going on mumble, truly great lightweight software with amazing sound quality and impossibly low latency. Very easy to run a server too. Still way ahead of its competitors in many regards, but these days people want more features I guess
A facelift to the Mumble client and an improved support for text chats could be enough to make it work for more or less everything mentioned in the post.
Plus I guess official iOS and Android apps, and a web client?
Still way ahead of its competitors in many regards
Exactly, has Discord come even close to implementing something like the Positional Audio API? Mumble has this for literally over two decades now.
This can work even if the game is not cooperating, e.g. I used to reverse memory addresses in GTAV to map voice streams to the matching in-game locations of the player. Being able to locate other players just from audio is really useful, another usecase ruined by anti-cheat alongside to general Linux support (memory addresses were identical when run through Wine).
Interestingly positional audio can become disorienting at the same time during jet dog fights, since now you are able to orientate freely around every single axis, plus the general 3rd person camera orientation. It's really not easy to make it feel natural for all cases, the writeup by a Guild Wars audio engineer on the topic is much recommendable.
I still use it—watched the Super Bowl just a couple days ago with a friend over it. It serves the purpose, it’s just a bit annoying that it needs to operate out of band with our primary chatroom (or DM in this case, lives elsewhere), but it isn’t that weird on strange. While something like MUC integration would be nice, I think it would be nice to have my XMPP status wired up to the room/server I am in.
What alternatives are there that are friendly to people who are tech-illiterate or adjacent? Matrix seems to be the only one I can think of. Why hasn't anyone created a discord-like client on the AT protocol (that I am aware of)?
The author rates "Openness" and "Decentralization" separately, and includes ratings for "Security", "Functionality", and "Safety". I don't think it's complete, but it did point me at a couple things I hadn't considered, so I recommend at least skimming.
Our community switched to Revolt/Stoat. We've decided to fork their legacy codebase instead of following along the Stoat rebrand (because a lot of things are in flux and we're looking for stability.) We've got an awesome maintainer who's contributed improvements already.
Meanwhile, it looks like the Zig folks are making their own OSS Discord alternative in Zig? I approve of this ecosystem diversity: let's see how the new victors emerge!
I approve of this ecosystem diversity: let's see how the new victors emerge!
There isn't any actual benefit to everyone inventing their own brand new protocol or project. It simply prevents alternative ecosystems from showing up in force, and ultimately leaves people asking "why aren't we just using discord?"
I was thinking about how to reply to this, but then https://sporks.space/2026/02/10/a-few-design-decisions-for-a-new-chat-platform shot to the top of lobste.rs and it really explains it better than I could have. I'm trying to do what this blog post is saying. I don't think any open-source chat platform does these things yet.
Movim is also an XMPP web client that has voice/video calls for chatrooms which is pretty new in the space (most clients only support voice/video in DMs, tho Jitsi can also be setup which uses XMPP).
Mumble can also fill the VoIP gap. I have ran a node for years & have had little trouble with it, but I have seen some whine & throw fits that you start with a 2-step wizard to configure your audio levels & they know nothing of their audio devices or stack (& these were developers‽) so YMMV depend on if its setup is too “technical”. That said, when the levels were configured right on all ends, you could eat & such without it going thru anyone’s mic—with old RNNoise locally cutting out a lot of garbage without some new super fancy AI audio processor on the server.
There's a newer alternative called Root that has come a long way in the last few months. I was able to point some of my less tech-literate friends to it and they got up and running without much issue
friendly to people who are tech-illiterate or adjacent
Probably none. Most of the things suggested here would be a pain even for me to use and I'm somebody with decades of experience in software engineering and (alt) online applications.
I often read stuff like that and it makes me think that my 67 years-old mother must be one hell of a computer nerd because she texts, calls, sends me pics and videos using Conversations. During COVID lockdown, just before she retired, her work used Discord for a few days and she was not able to understand how the thing worked though, because too many features and things that blink and pop (they ended up just using WhatsApp, the norm around here).
I know that we cannot battle with armies of developers, focus groups, UX designers, A/B testing [...] of FAANGs but a FLOSS chat app being "a pain even for somebody with decades of experience in software engineering", are you serious?
I came home from college (so, prior to the turn of the century) and discovered that my mother had been sent instructions via email from one of her friends to install and configure an IRC client, and had been happily chatting with her friends all over the world for a few months.
My mother was intelligent but not at all tech-savvy. We underestimate what the majority of people can do in pursuit of a goal.
What does Discord get out of doing this? Rolling out an age gate in regions where they're not legally required to do seems like a net negative for everyone, and in particular it's going to drive users away from Discord, so I can't figure out why they've chosen to do this.
They're preparing for IPO, and they have a not-so-quiet reputation of being a place where minors can easily be exploited by predators. Their gain here is putting up an image to prospective investors that they are working to clean up that mess.
Will that gain be net-positive? Hard to say for sure. My guess is that it will be, unfortunately. Discord has both platform-inertia and all the features that people are used to having: text chat, voice chat, video streaming, custom emotes, etc.
This, but also since anyone can set up a Discord instance, there are a large number of NSFW Discord instances. I'm assuming they believe that building taller walls around their garden will shrink that part of their (undesirable, to them) user base. They're probably right.
What people actually want out of federation (fewer apps and fewer accounts) could instead be achieved through single-sign on and a single client that supports multiple servers with the same API.
Hot-button topic of the post, huh?
A single client that supports multiple servers with the same API sounds great... except I want to use this client on my desktop and my phone. Oh, and on my laptop. Oh, and on my friend's laptop that I'm borrowing for 10 minutes to show them something cool. This requires storing my client data somewhere... ID, keys, which servers I'm in, who's in my contact list, etc. Syncing data peer-to-peer between clients a la Syncthing just kicks the can down the road, so we need to store it on a server.
Great, we now need a server that stores some user info for a particular account. Who runs it? Well, some mythical third party that also does SSO and solves all the management and administration problems involved with it. You know, banning abusive accounts, dealing with spam, etc. How do they make money to run the server and manage the SSO system? Hmm, I wonder...
The pure p2p people get angry at federated approaches for being "centralization through other means"? Turns out I can get just as angry at this idea for being "a straight-line funnel straight into the Torment Nexus".
I bridged the nerd channel of the discord I frequent the most to an IRC channel and pretty much speak exclusively from the IRC side. It's nice saying hi and bye to people, and feels more like a place I can visit, then I sign off to come back to the real world, instead of being chronically online.
Great to reconsider supposed certainties from time to time. End-to-end encryption is one such certainty. It is not a value in itself, but rather a means to an end, and may not always be well suited to that end. Federation likewise.
(Mods: your call if you want to merge this into the "Discord is shitting the bed" thread. The events inspired me to write this, but it's a bunch of opinions I've had for a while.)
It is well known that all federation gets you for a community use case is single sign on. I don't agree that makes it a no go though. Of course there are other ways to implement single sign on with various small trade offs, but federation is a perfectly sensible way to do this.
The content is hosted by the community not by your personal instance, so by accessing via your instance (federation) what you get with a forum/chatroom/etc is equivalent to SSO
That's 1:1 chat and not the forum or chatroom anymore. The side benefit of also getting this for the non community parts if you use federation for the community part is one of the biggest arguments in favour of using the federated implementation, IMO
I wish that platforms had a better way to verify authenticity without invading privacy.
Projects like world.org (wish it had nothing to do with finance) are a huge step forward, although still far from perfect.
I've been impersonated over and over again on discord and people are being tricked into scams over my name and there's little I can do. I get multiple messages per day about this.
What people actually want out of federation (fewer apps and fewer accounts) could instead be achieved through single-sign on and a single client that supports multiple servers with the same API.
Unfortunately, new chat platforms, even open-source ones (Matrix, Mattermost, Zulip, rocketchat, stoat, DeltaChat are the ones I know), tend to implement their own new NIH client to server protocol, so that generally means one client (usually a web client) per chat platform. https://prose.org/ moves slowly but decided to go in a direction I prefer (I'm obviously very biased towards what they chose).
What people actually want out of federation (fewer apps and fewer accounts) could instead be achieved through single-sign on and a single client that supports multiple servers with the same API
You can't support multiple servers nicely for a single chat app, because mobile apps have to hard-code the push notification server.
I don't think I quite understand your point here. As a counter-example, I use pushover for push notifications from multiple servers, including lobste.rs. Also including some of my own. There's no need to hardcode the push notification server; I actually have it as a per-user-account thing on mine. user1 could use a different pushover server than user2 without any hardcoding.
That's different sources, on Android they still all need to go through Firebase Cloud Messaging before you receive them. That's why Bitwarden provides the centralized service to have self hosted instances support realtime push updates through them. See paragraph 2 here: https://contributing.bitwarden.com/architecture/deep-dives/push-notifications/mobile
Third-party push notification services are forced to run on your device the whole time to receive notifications which effectively makes them closer to long polling than push notifications, making them quite power inefficient. It really is FCM or bust on Android, which is rather unfortunate and I presume the story is similar for the iOS ecosystem.
Actually, it's apple notification thing or bust on iOS, but on Android it is a bit better (you might have to fight vendor-specific so-called "battery optimisation" features through deep settings menu though).
Source: been running Android for 10+ years and getting live notifications for my chats without relying on FCM at all. Conversations run in the background, maintains its connection to my server, and it does not drain battery at all (unlike, eg, Signal, under similar conditions).
UnifiedPush has the same problem, they just optimize for it by delegating it to a shared "distributor" app that captures notifications for all your notification-wanting-apps rather than 10 separate apps doing it individually. Here's the NextPush app, which declares its use of a persistent foreground service to receive notifications.
What people actually want out of federation (fewer apps and fewer accounts) could instead be achieved through single-sign on and a single client that supports multiple servers with the same API.
I largely agree, though I think at this point the issue becomes which identity provider you use, who owns it and whether you can trust them, and whether the individual servers accept it.
But ignoring that and pretending we found a good way to handle decentralized auth, it would be interesting to build a Frankenstein chat "platform" that relied on existing but separate protocols for public chats that don't require E2EE (Zulip)?, group and 1:1 chats with E2EE (Matrix)?, and voice chat (Mumble?), all packaged up in a single Discord-like UI that removes (or at least hides) the seams between them.
I don't think e2ee is a deal breaker for many people, especially public servers. Private servers and DMs on the other hand require some form of encryption to be enticing.
What people actually want out of federation (fewer apps and fewer accounts) could instead be achieved through single-sign on and a single client that supports multiple servers with the same API.
Hot-button topic of the post, huh?
A single client that supports multiple servers with the same API sounds great... except I want to use this client on my desktop and my phone. Oh, and on my laptop. Oh, and on my friend's laptop that I'm borrowing for 10 minutes to show them something cool. This requires storing my client data somewhere... ID, keys, which servers I'm in, who's in my contact list, etc. Syncing data peer-to-peer between clients a la Syncthing just kicks the can down the road, so we need to store it on a server.
Great, we now need a server that stores some user info for a particular account. Who runs it? Well, some mythical third party that also does SSO and solves all the management and administration problems involved with it. You know, banning abusive accounts, dealing with spam, How do they make money? Hmm, I wonder... Saying "use single sign on" is really just "give someone else power over me, I don't care who as long as I don't have to worry about it".
The pure p2p people get angry at federated approaches for being "centralization through other means"? Turns out I can get just as angry at this idea for being "a straight-line funnel straight into the Torment Nexus".
You can’t say we didn’t try to warn you when you built communities in a platform your community can’t actually own, control, & set its own terms. What frustrates me the most is that we have seen this play out so many times that these platforms can/will make things worse, but community leaders aren’t taking a bold enough stance to say “no, this is not for us & we will not support or bridge this corporation since we have already seen this song & dance before”.
msfjarvis | a month ago
Considering how well this has been going I am personally looking forward to never verifying my age for the platform.
proctrap | a month ago
It's also a typical reason why the age verification ideas are always a bad idea. In the rarest case it'll be an anonymized official system from the state, and in all others some 3rd party vendor you wouldn't give you email in any other circumstance.
hoistbypetard | a month ago
I don’t really like the platform anyway… currently, I sometimes sign in if I’m collaborating with people who already use it. But I don’t like to stay signed in on my laptop; it makes slack look light weight, and I’m using my laptop for things that are both more important and resource-hungry like VMs and JetBrains editors. I’ll probably give up the first time this requirement introduces any new friction for me.
If this breaks anything it’ll most likely erase my willingness to sign in at all.
offby1 | a month ago
Nice, this is a good reminder to cancel my paid Nitro subscription.
hoistbypetard | a month ago
I had to read the "End to end encryption is another misfeature for public channels" section multiple times to process it (thankfully, it's short!), and I'm surprised that I agree with it upon further consideration, but I really do strongly agree with that. The way you stated the point resonates with me, and I expected to disagree with you about that part of the piece, based on the header.
That said, Zulip was about to be my next choice for a social club. Can you elaborate more on why you don't think it's a good fit?
calvin | a month ago
The threading model is polarizing and mostly useful for keeping multiple on-topic threads together while multiple are being posted to. It works really well for i.e. technical communities or corporate instances because of that; I'm using it for such a community. For a social thing, you don't need that level of hierarchy, it just imposes friction. That said, Zulip has unthreaded channels now, so that may be better, but I still think it's not the right choice for that.
The lack of a smooth A/V experience is the other, but that's dependent on the community. I write this in mind with hanging out in a voice channel with friends, so...
david_chisnall | a month ago
I don't really want threading, I want lightweight UI for side discussions. The text equivalent of a breakout discussion. My key requirements are:
danielrheath | a month ago
untitaker | a month ago
so slack mostly nailed it? you can xpost comments to the main channel to remind people the thread is ongoing.
david_chisnall | a month ago
Maybe? I got less than 20% into the Slack T&Cs before deciding I would never agree to them. What does their UI look like for 'we've started a conversation that most of this channel isn't interested in, let's move it to a new place' look like?
untitaker | a month ago
you can reply to any message to start a thread and that's it. there's no way to move messages into the thread or anything like that. it's awkward and does lead to confusion when somebody thought the conversation died but actually it's active in some thread, but I am not sure I've seen any tooling that solves this without increasing complexity drastically
technomancy | a month ago
I have a pet theory that the reason Matrix is bad is that it's half made by people who want it to replace IRC and half made by people who want it to replace Signal. Everything that makes it good as an IRC replacement makes it bad as a Signal replacement, and vice-versa. Pick a lane!
This way you end up with Soatok posts about how horrifying the bugs in the E2EE are and then people like me who are all "I literally do not care even one tiny bit" but the amount of effort and noise that goes into addressing those issues, ugh.
hoistbypetard | a month ago
I think that's a really good take. And I might steal it, though I'm unlikely to specifically refer to Signal under any circumstances at all. The considerations for those two types of chat are different and competing. And while it's quite tempting to assume that private chat features are good for every kind of chat, that just turns out to be untrue when you apply a moderate amount of pressure.
icefox | a month ago
My theory is that Matrix is bad because it tries to be pure P2P but lots of features (like moderation and spam filtering) need a source of authority. So they end up tacking those on afterwards and then nothing works particularly well.
orib | a month ago
I disagree with it, but for a technical reason that they don't mention.
E2EE encryption needs cover traffic in order to prevent trivial metadata recovery. If one message goes in one device and comes out another, you know who was talking. If a thousand messages do that. You need to do a lot more work. Especially if the server deliberately tries to obfuscate.
Group chats participating in E2EE even if they don't need it helps provide cover traffic for the people who do need it.
hoistbypetard | a month ago
That was my stance going into the read. Reading the piece and some of the linked materials made me reconsider it. The piece is specifically talking about public group chats. And the public part is really load bearing there. It means anyone can join the chat. So, for instance, imagine for a second that liberachat was end-to-end encrypted, and that we hosted the lobste.rs chat there. The lobste.rs chat is fully public. Anyone who learns of its existence is allowed to join (unless they've been banned, but that really does practically equate to "anyone" for all reasonable purposes).
That means that all of the metadata is already public. Any interested party can join and see it.
Using an e2ee scheme for that and sending it through the same channel as something that is actually private involving some set of the same participants could actually help leak interesting metadata, especially if there's some weakness in the e2ee scheme. I hadn't thought of that before, despite having actually worked out a proof-of-concept attack along these lines against an encrypted email list (using the S/MIME CMS) before.
In general, I like the idea of chaffing and winnowing as one layer of protection, but I think in the specific case of e2ee over this kind of public channel, I'm now convinced it could be harmful.
apropos | a month ago
With regards to alternatives: an extremely relevant blog post, and its discussion from ~a month ago.
WilhelmVonWeiner | a month ago
I think the "Discord killer" will come out on top based on its VoIP and video features. Screen sharing, webcam sharing and noise cancelling are the three necessary features for any post-Discord chat application to implement to win.
cjs | a month ago
I noped out of the handful of Discords I was in a month back to cut down on online distractions, this further solidifies that decision.
benoliver999 | a month ago
I really miss going on mumble, truly great lightweight software with amazing sound quality and impossibly low latency. Very easy to run a server too. Still way ahead of its competitors in many regards, but these days people want more features I guess
payne | a month ago
A facelift to the Mumble client and an improved support for text chats could be enough to make it work for more or less everything mentioned in the post.
Plus I guess official iOS and Android apps, and a web client?
vimpostor | a month ago
Exactly, has Discord come even close to implementing something like the Positional Audio API? Mumble has this for literally over two decades now.
This can work even if the game is not cooperating, e.g. I used to reverse memory addresses in GTAV to map voice streams to the matching in-game locations of the player. Being able to locate other players just from audio is really useful, another usecase ruined by anti-cheat alongside to general Linux support (memory addresses were identical when run through Wine).
Interestingly positional audio can become disorienting at the same time during jet dog fights, since now you are able to orientate freely around every single axis, plus the general 3rd person camera orientation. It's really not easy to make it feel natural for all cases, the writeup by a Guild Wars audio engineer on the topic is much recommendable.
toastal | a month ago
I still use it—watched the Super Bowl just a couple days ago with a friend over it. It serves the purpose, it’s just a bit annoying that it needs to operate out of band with our primary chatroom (or DM in this case, lives elsewhere), but it isn’t that weird on strange. While something like MUC integration would be nice, I think it would be nice to have my XMPP status wired up to the room/server I am in.
parisosuch | a month ago
What alternatives are there that are friendly to people who are tech-illiterate or adjacent? Matrix seems to be the only one I can think of. Why hasn't anyone created a discord-like client on the AT protocol (that I am aware of)?
Gaelan | a month ago
The AT protocol has zero provision for non-public data.
makeworld | a month ago
This is being worked on, though!
parisosuch | a month ago
Wasn't aware of this. Thanks!
jmelesky | a month ago
This is from a few months back: https://taggart-tech.com/discord-alternatives/
The author rates "Openness" and "Decentralization" separately, and includes ratings for "Security", "Functionality", and "Safety". I don't think it's complete, but it did point me at a couple things I hadn't considered, so I recommend at least skimming.
icefox | a month ago
XMPP:
No particular protocol:
abnercoimbre | a month ago
Our community switched to Revolt/Stoat. We've decided to fork their legacy codebase instead of following along the Stoat rebrand (because a lot of things are in flux and we're looking for stability.) We've got an awesome maintainer who's contributed improvements already.
Meanwhile, it looks like the Zig folks are making their own OSS Discord alternative in Zig? I approve of this ecosystem diversity: let's see how the new victors emerge!
ambee | a month ago
There isn't any actual benefit to everyone inventing their own brand new protocol or project. It simply prevents alternative ecosystems from showing up in force, and ultimately leaves people asking "why aren't we just using discord?"
abnercoimbre | a month ago
There’s no contender that can dethrone Discord’s UX. We need competition on that score before concerning ourselves with network effects.
ar-nelson | a month ago
Currently working on developing a federated Discord alternative, though it got delayed because my first child was recently born. Starting to find some time to work on it again though.
icefox | a month ago
Devil's advocate: How is it different from Polyproto, XMPP, Stoat, and/or IRCv3?
ar-nelson | a month ago
I was thinking about how to reply to this, but then https://sporks.space/2026/02/10/a-few-design-decisions-for-a-new-chat-platform shot to the top of lobste.rs and it really explains it better than I could have. I'm trying to do what this blog post is saying. I don't think any open-source chat platform does these things yet.
revx | a month ago
Zulip, maybe? It's a little more message-board like but still has support for synchronous chat.
toastal | a month ago
https://snikket.org/
Snikket is XMPP with all the default set up for chatting in this scenario.
https://movim.eu/
Movim is also an XMPP web client that has voice/video calls for chatrooms which is pretty new in the space (most clients only support voice/video in DMs, tho Jitsi can also be setup which uses XMPP).
http://mumble.info/
Mumble can also fill the VoIP gap. I have ran a node for years & have had little trouble with it, but I have seen some whine & throw fits that you start with a 2-step wizard to configure your audio levels & they know nothing of their audio devices or stack (& these were developers‽) so YMMV depend on if its setup is too “technical”. That said, when the levels were configured right on all ends, you could eat & such without it going thru anyone’s mic—with old RNNoise locally cutting out a lot of garbage without some new super fancy AI audio processor on the server.
sanqui | a month ago
The AT protocol currently defines no means for private communications, but there have been attempts to build a messaging platform on top of it, notably Roomy (https://roomy.space/, https://blog.muni.town/roomy-chat-alpha-2/).
zerebos | a month ago
There's a newer alternative called Root that has come a long way in the last few months. I was able to point some of my less tech-literate friends to it and they got up and running without much issue
alper | a month ago
Probably none. Most of the things suggested here would be a pain even for me to use and I'm somebody with decades of experience in software engineering and (alt) online applications.
nicoco | a month ago
I often read stuff like that and it makes me think that my 67 years-old mother must be one hell of a computer nerd because she texts, calls, sends me pics and videos using Conversations. During COVID lockdown, just before she retired, her work used Discord for a few days and she was not able to understand how the thing worked though, because too many features and things that blink and pop (they ended up just using WhatsApp, the norm around here).
I know that we cannot battle with armies of developers, focus groups, UX designers, A/B testing [...] of FAANGs but a FLOSS chat app being "a pain even for somebody with decades of experience in software engineering", are you serious?
dsr | a month ago
I came home from college (so, prior to the turn of the century) and discovered that my mother had been sent instructions via email from one of her friends to install and configure an IRC client, and had been happily chatting with her friends all over the world for a few months.
My mother was intelligent but not at all tech-savvy. We underestimate what the majority of people can do in pursuit of a goal.
alper | a month ago
I can get anything to run. I won't be able to get anybody else on whatever that is. Then I'll be sitting there all lonely by myself.
You really don't need any of this to make a product that works and is simple.
lilyball | a month ago
What does Discord get out of doing this? Rolling out an age gate in regions where they're not legally required to do seems like a net negative for everyone, and in particular it's going to drive users away from Discord, so I can't figure out why they've chosen to do this.
lhearachel | a month ago
They're preparing for IPO, and they have a not-so-quiet reputation of being a place where minors can easily be exploited by predators. Their gain here is putting up an image to prospective investors that they are working to clean up that mess.
Will that gain be net-positive? Hard to say for sure. My guess is that it will be, unfortunately. Discord has both platform-inertia and all the features that people are used to having: text chat, voice chat, video streaming, custom emotes, etc.
bityard | a month ago
This, but also since anyone can set up a Discord instance, there are a large number of NSFW Discord instances. I'm assuming they believe that building taller walls around their garden will shrink that part of their (undesirable, to them) user base. They're probably right.
icefox | a month ago
Hot-button topic of the post, huh?
A single client that supports multiple servers with the same API sounds great... except I want to use this client on my desktop and my phone. Oh, and on my laptop. Oh, and on my friend's laptop that I'm borrowing for 10 minutes to show them something cool. This requires storing my client data somewhere... ID, keys, which servers I'm in, who's in my contact list, etc. Syncing data peer-to-peer between clients a la Syncthing just kicks the can down the road, so we need to store it on a server.
Great, we now need a server that stores some user info for a particular account. Who runs it? Well, some mythical third party that also does SSO and solves all the management and administration problems involved with it. You know, banning abusive accounts, dealing with spam, etc. How do they make money to run the server and manage the SSO system? Hmm, I wonder...
The pure p2p people get angry at federated approaches for being "centralization through other means"? Turns out I can get just as angry at this idea for being "a straight-line funnel straight into the Torment Nexus".
williewillus | a month ago
I wrote a little onboarding guide for IRC in case people want to throw back like it's 2008 https://www.vincent-lee.net/blog/2026-02-09-irc/
I bridged the nerd channel of the discord I frequent the most to an IRC channel and pretty much speak exclusively from the IRC side. It's nice saying hi and bye to people, and feels more like a place I can visit, then I sign off to come back to the real world, instead of being chronically online.
BD103 | a month ago
Thank you for this! I was always curious, but never got the chance to dig into IRC before this :)
mro | a month ago
Great to reconsider supposed certainties from time to time. End-to-end encryption is one such certainty. It is not a value in itself, but rather a means to an end, and may not always be well suited to that end. Federation likewise.
calvin | a month ago
(Mods: your call if you want to merge this into the "Discord is shitting the bed" thread. The events inspired me to write this, but it's a bunch of opinions I've had for a while.)
singpolyma | a month ago
It is well known that all federation gets you for a community use case is single sign on. I don't agree that makes it a no go though. Of course there are other ways to implement single sign on with various small trade offs, but federation is a perfectly sensible way to do this.
Student | a month ago
Surely not just single sign on? You also have a community pool of content.
singpolyma | a month ago
The content is hosted by the community not by your personal instance, so by accessing via your instance (federation) what you get with a forum/chatroom/etc is equivalent to SSO
bramh | a month ago
What about the ability to message people from other instances?
singpolyma | a month ago
That's 1:1 chat and not the forum or chatroom anymore. The side benefit of also getting this for the non community parts if you use federation for the community part is one of the biggest arguments in favour of using the federated implementation, IMO
Riolku | a month ago
Hm, why would this be?
domenkozar | a month ago
I wish that platforms had a better way to verify authenticity without invading privacy.
Projects like world.org (wish it had nothing to do with finance) are a huge step forward, although still far from perfect.
I've been impersonated over and over again on discord and people are being tricked into scams over my name and there's little I can do. I get multiple messages per day about this.
nicoco | a month ago
Unfortunately, new chat platforms, even open-source ones (Matrix, Mattermost, Zulip, rocketchat, stoat, DeltaChat are the ones I know), tend to implement their own new NIH client to server protocol, so that generally means one client (usually a web client) per chat platform. https://prose.org/ moves slowly but decided to go in a direction I prefer (I'm obviously very biased towards what they chose).
calvin | a month ago
If most people switch to a specific thing, then you can use that app for multiple communities, even with their own servers.
nicoco | a month ago
Yes? My point was that unfortunately, the wheel keeps on being reinvented.
danielrheath | a month ago
You can't support multiple servers nicely for a single chat app, because mobile apps have to hard-code the push notification server.
calvin | a month ago
Zulip solves this by centralizing push notifications (optionally, there are alternatives if this is unacceptable).
hoistbypetard | a month ago
I don't think I quite understand your point here. As a counter-example, I use pushover for push notifications from multiple servers, including lobste.rs. Also including some of my own. There's no need to hardcode the push notification server; I actually have it as a per-user-account thing on mine. user1 could use a different pushover server than user2 without any hardcoding.
msfjarvis | a month ago
That's different sources, on Android they still all need to go through Firebase Cloud Messaging before you receive them. That's why Bitwarden provides the centralized service to have self hosted instances support realtime push updates through them. See paragraph 2 here: https://contributing.bitwarden.com/architecture/deep-dives/push-notifications/mobile
Bitwarden uses the Azure Notification Hub abstraction to make this cross platform, which eventually delegates to the blessed platform native solution: https://learn.microsoft.com/en-us/azure/notification-hubs/notification-hubs-push-notification-overview
Third-party push notification services are forced to run on your device the whole time to receive notifications which effectively makes them closer to long polling than push notifications, making them quite power inefficient. It really is FCM or bust on Android, which is rather unfortunate and I presume the story is similar for the iOS ecosystem.
nicoco | a month ago
Actually, it's apple notification thing or bust on iOS, but on Android it is a bit better (you might have to fight vendor-specific so-called "battery optimisation" features through deep settings menu though). Source: been running Android for 10+ years and getting live notifications for my chats without relying on FCM at all. Conversations run in the background, maintains its connection to my server, and it does not drain battery at all (unlike, eg, Signal, under similar conditions).
kitkat | a month ago
From what I understand, UnifiedPush doesn't have this problem, though I know ntfy uses WebSockets, so it might still be effectively long polling.
msfjarvis | a month ago
UnifiedPush has the same problem, they just optimize for it by delegating it to a shared "distributor" app that captures notifications for all your notification-wanting-apps rather than 10 separate apps doing it individually. Here's the NextPush app, which declares its use of a persistent foreground service to receive notifications.
steinuil | a month ago
I largely agree, though I think at this point the issue becomes which identity provider you use, who owns it and whether you can trust them, and whether the individual servers accept it.
But ignoring that and pretending we found a good way to handle decentralized auth, it would be interesting to build a Frankenstein chat "platform" that relied on existing but separate protocols for public chats that don't require E2EE (Zulip)?, group and 1:1 chats with E2EE (Matrix)?, and voice chat (Mumble?), all packaged up in a single Discord-like UI that removes (or at least hides) the seams between them.
audy | a month ago
Possible silver lining: all user data (unless verified) will receive additional privacy protections (via COPPA, GDRP/CCPA, etc)?
parisosuch | a month ago
I don't think e2ee is a deal breaker for many people, especially public servers. Private servers and DMs on the other hand require some form of encryption to be enticing.
icefox | a month ago
Hot-button topic of the post, huh?
A single client that supports multiple servers with the same API sounds great... except I want to use this client on my desktop and my phone. Oh, and on my laptop. Oh, and on my friend's laptop that I'm borrowing for 10 minutes to show them something cool. This requires storing my client data somewhere... ID, keys, which servers I'm in, who's in my contact list, etc. Syncing data peer-to-peer between clients a la Syncthing just kicks the can down the road, so we need to store it on a server.
Great, we now need a server that stores some user info for a particular account. Who runs it? Well, some mythical third party that also does SSO and solves all the management and administration problems involved with it. You know, banning abusive accounts, dealing with spam, How do they make money? Hmm, I wonder... Saying "use single sign on" is really just "give someone else power over me, I don't care who as long as I don't have to worry about it".
The pure p2p people get angry at federated approaches for being "centralization through other means"? Turns out I can get just as angry at this idea for being "a straight-line funnel straight into the Torment Nexus".
toastal | a month ago
You can’t say we didn’t try to warn you when you built communities in a platform your community can’t actually own, control, & set its own terms. What frustrates me the most is that we have seen this play out so many times that these platforms can/will make things worse, but community leaders aren’t taking a bold enough stance to say “no, this is not for us & we will not support or bridge this corporation since we have already seen this song & dance before”.