Discord is being forced to enshittify by its new corporate overlords, and so the people on the internet who actually care about it being the internet1 are trying to jump ship. So I’ve made this page to collect thoughts and experiences on the various alternatives that people bring up.
Are you ready for a heckin chonker of a writeup? A big honkin’ bohungus? A giant hungalungamungus? Buckle up, ’cause this is a people problem, not a tech problem. So it’s complicated.
Last updated Feb 2026.
Background and scope
I like Discord. I use it daily. I spent a couple years as a moderator on the Programming Language Theory, Development, and Implementation Discord server, which has a few thousand members. There’s many complaints to be had about the Discord client being obtuse, resource-hungry, the search sucking, etc etc and all of them are true, but all of them are layered on top of the fact that it basically Just Works, and has for years.
I turned 41 last month. I’ve been chronically online since I was 17. In that time I have used: AIM, YIM, MSN, Skype, IRC, self-hosted XMPP, GChat, Mumble, Skype again, IRC again, Telegram, Signal, and Discord, often multiple at once. Every single one of them that was run by a company has died except for the latest generation, and all of them died in basically the same way. They got established, went from “we need to make enough money to keep going” to “we need to produce value for our shareholders”, got shitty, people jumped ship, and the platform died. Every. Single. One.
I’m sick of this shit. The point of going through this is to make sure our children don’t have to go through it again. I want to get off the wheel of saṃsāra and achieve nirvana, where I don’t have to uproot half my online life every 3-5 years.
Requirements:
- Needs to actually work
- Needs to be good for a small community of 10-50 people
- Needs to be self-hostable – whether or not you personally want to host it yourself, it needs to be possible
- Needs to be open source
- Needs to have voice chat
- Needs to have decent open source clients for web, Linux and Android – sorry, other OS’s are on their own, but frankly Linux and Android are probably going to be the last systems that get good clients, so we’ll set the bar high and assume other OS’s meet it.
- Convenient to use – This basically means that I can copy-paste an image into the client, write some markdown or something, and It Works. If it can do that then just about any other shiny media whozits will work sooner or later.
- Not absurdly insecure – there’s no reason not to use TLS in 2026, but you’re probably gonna have to trust a server owner to not be a scumbag one way or another for reasons discussed below.
Stretch goals:
- Good for a medium-sized or largeish community of ~1000-10,000 people
- Some amount of useful moderation tools
- Video chat/streaming/screen sharing – if it can do voice chat it should be able to do this, it just involves a couple orders of magnitude more bandwidth and more client-side work
These goals disqualify the following closed-source bullshit:
- Slack
- Whatsapp (are you fucking kidding me)
- Discord
- Telegram
- Signal (though it’s currently pretty good for one-on-one communication)
- Steam chat (though Valve tends to be a pretty benevolent overlord)
- Teamspeak
- Root
This article is also very good.
Single-server solutions
Here’s a list of all the things I could find that don’t do any federation or P2P communication. You set these up on a server somewhere, or use someone else’s, and everything you do stays on that instance forever. You know, like Discord.
Don’t use any of these. Use XMPP instead. It’s pretty ok and won’t tie your life to a single person or company. Yes, I’m biased. If a system doesn’t have some amount of inter-server communication then it’s always going to be a local enclave of some kind or another, and that makes it hard for me to want. Local enclaves still need interact with the outside world, and the easier they are to create and join the more healthy they are. It’s difficult to staple inter-server communication onto a system that isn’t built around it from the start. And people being isolated to a single server instance has problems:
- You can’t talk to other people using the same program/protocol but not on the same server, which is dumb
- People have login fatigue, or at least I sure as hell do
- I think that in the long run they will get eaten by systems that allow more free movement between servers/topics, the same way that forums got eaten by reddit.
You’re basically signing up for an email account on hotmail.com that can’t talk to email accounts on gmail.com, and vice versa. How does that feel?
Again, I want to get off the wheel of reincarnation.
This piece has gone around a bit and suggests “federation isn’t useful, what you actually want is just an SSO system”. Except I want to use a chat client both 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 chat rooms 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, making sure the data is always available requires storing it on an always-on server. The alternative is to call up your roommate and tell them to turn your desktop on and start Syncthing, which I have done before and which sucks. And not everyone can host an always-on server in their closet, which I have also done before. And if you make my cell phone the source of authority you have to ask what happens when I drop my phone down a mountain, which I have also done before.
Great, we now need a server that stores some user info for a particular account. Who runs this server? 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…
To build the future I want we need some way to not have everything walled into individual servers or clusters. Whether we do that now or soon or with XMPP or something else, honestly I don’t care. But I want something in my life that does inter-server operation, we’ve been having half-assed attempts at it for thirty fucking years, and going back from that level of interoperation is stupid.
That said, these single-server solutions are easy. They’re good, ’cause they’ve limited the scope of the problems they want to solve to something manageable. “Make a single server or cluster of servers that distributes messages among a bunch of people” was basically a solved problem by 2006; in 2026 a savvy teenager can do it with off-the-shelf parts and get pretty good results. I know, because that’s what half these systems are. Use them if they fit your needs, because frankly we need something, just be aware of their limitations. In the long run I can only really recommend them for closed communities – groups of friends, families, other invite-only systems. We can do better by now.
Conclusions
This ain’t a research paper, I can put the conclusions first if I want to. Most people just want an answer without thinking, so here you go.
Not what I want for this use case:
Not production quality:
Not production quality yet but I’m hopeful:
Go ahead and use it, though it will have rough edges:
Also, heckin’ none of these things seem to do video or screen sharing yet. Apparently that’s fairly difficult, fairly resource intensive, and not in super high demand compared to other features. (Also it seems like some of them have had it working in the past, or claim that they have it; I might have just missed it, or they might not have been functioning when I tried them out. Absolutely all of these are getting completely slammed with new users, for some reason…)
In the end, the difference between Valour, Fluxer and Stoat will come down to management more than technology. Which one is a more successful project, rather than which one has better code. The code is part of that, but it involves many other things: server infrastructure, money, licensing, advertising, community building, moderation, more advertising, recruiting, vibes, luck, business model, more advertising, more money, communication, leadership, charisma, more luck, technology, feature prioritization, cat-herding, more money, lots of luck, and more advertising.
Which will “win”? For me, it’s too early to tell.
Zulip, RocketChat and Mattermost
All of these are not really a community chat server as much as a project management system. They’re a replacement for Slack, not Discord. Perfectly fine for that, but not what I want here.
Zulip’s UI seems to be kinda love it or hate it. Probably depends on whether someone wants a project management tool or a chat server.
RocketChat and Mattermost are technically open source but kinda freemium. Both brand themselves as “suitable for a defense contractor”, so… eeeeeh. I’ve seen mention of people forking them, removing some of the limits, and running them for internal stuff just fine. But I don’t think you should need to do that to get a self-hosted chat server in 2026.
Jitsi
Open-source teleconferencing software. It’s more a replacement for Zoom than for Discord though. As far as I can tell you basically just make meetings and let people join them, and it works for that, but any sharing of meetings or stuff like that happens outside of it.
Fluxer
It works well, ’nuff said. That’s the highest praise I can give anything, really.
Literally the morning I started writing this, this statement appeared in the Github repo’s readme:
Holy smokes, what a ride. Fluxer is taking off much earlier than I’d expected. …
I know it’s hard to resist, but please wait a little longer before you dive deep into the current codebase or try to set up self-hosting. I’m aware the current stack isn’t very lightweight. In the next update, self-hosting should be straightforward, with a small set of services…
Self-hosted deployments won’t include any traces of [the paid tier], and nothing is paywalled. You can still configure your own tiers and limits in the admin panel.
I thought I could take it a bit easier while shipping this stabilising update, but Discord’s recent announcement has changed things.
So that seems to answer the question of “where is this project” pretty well. Forced into an open beta earlier than they wanted, but optimistic about it.
Trying it out, it works fine. No noticeable complaints. It’s not perfect, but it’s good.
That said, it’s very… company-y. It’s a paid product. The code is AGPL, AKA “we want to say we’re open source as long as we get to stay a monopoly in practice”. I forget, does AGPL preclude other people from running their own paid instances of the software? No, it just forces them to open-source any changes they make. But apparently they require a CLA when contributing, which really just makes it ready for a rug-pull somewhere down the line. (Edit: The CLA has been removed since I wrote this.)
This is made by a company, so my default assumption is if it’s successful it’s just going to end up doing exactly what Discord has. It’s a Swedish company though, so they’re subject to different laws and ecosystem pressures. If you believe what they say, they’re trying not to give in to the horrors: https://blog.fluxer.app/how-i-built-fluxer-a-discord-like-chat-app/ and https://blog.fluxer.app/roadmap-2026/ are long but very poignant reads. But I’m long past “trust but verify” and into “don’t bother trusting”. Remember when Google’s terms of service included “don’t be evil”? How long did that last? How well has that aged?
…jeez the creator is just 22? He’s a baby. It’s weird being old. Do I trust a baby to build something as big and complicated as a chat system? Sure. To manage the project for it though? …Maybe if he has some very good friends and family helping him out, and learns fast. I like his writing though. You don’t spend X years writing half a million lines of Typescript without some capital-D Determination.
Several people have noticed that the current Fluxer github repo has a grand total of 94 commits on it, and the first one is like half a million lines of code. Accusations of LLM generated code are the obvious conclusion, but the author says they just worked on it privately for years, and uploaded their work to a fresh repo when they made it public. I dug through the code a bit and it’s plausible with what I saw. Could be any number of reasons for doing that: early versions could have been under a different license, could have included proprietary or incompatibly-licensed code, or they may just be embarrassed to show their old work. So it’s a bit of a warning sign at first glance but probably a spurious one.
Of course, they could have done that and vibecoded this stuff. He mentions in one of those blog posts he uses LLM’s in limited ways for rubber ducking and boilerplate but that’s about it. No idea, I’m not his mom. But if the creator had whipped this all up in a couple weeks with a shitbot I’d expect the result to work a lot less well.
Oh right, it also has clients for Linux, Windows, Mac and web. Any mobile? Not yet but it’s on their to-do list. Trying to download the Linux appimage though, twice it got partially through and hung forever. I suspect their servers are kinda slammed right now. I was able to download it from my Hetzner VPS.
All in all Fluxer is very compelling. Very tempting. Feels too good to be true. Tentative approval?
Stoat
Once called Revolt, their biggest claim to fame is a) making a Discord knockoff long before it was cool, and b) copying the UI and theming so accurately that they got a cease-and-desist from Discord and had to rebrand themselves.
That’s ok, stoats are pretty adorable:
(from Wikipedia: Giles Laurent, CC BY-SA 4)
Ahem, back on topic. Chat works, voice chat works, you can self-host it. It’s written in Rust but uses a fairly beefy set of other services as well: Redis, MongoDB, RabbitMQ, Maildev and Minio. Not sure whether this is a good thing or a bad thing; they wanted to make sure it’s Enterprise Ready I guess. Not sure why you’d want both Redis and Mongo, and you’re better off not relying on Minio these days. But if you want to be able to shard a server across multiple machines, you’ll either end up using something like that stack or reinventing it yourself, so maybe they’re just ahead of the game.
Actually using it, it works fine. It feels a little jankier than Fluxer, but not by much. Has clients for all desktop OS’s, and beta clients for mobile. I have a friend who self-hosted a test server, and that works but it takes some effort and using it isn’t exactly the smoothest of experiences.
In general I approve.
Valour
Okay, “corporate-but-supposedly-open-source” thing number two.
Huh, they ask me to enter my age to make an account but the client neither limits the input client-side nor gives me a widget for it. Oh but it does say “if you are actually 192 years old, please contact us at support@valour.gg and we will buy you a cake.” lmao, good for them. But if I put the default of “today” in then it silently ignores me and I can’t make an account, oops. Apparently saying I’m 110 years old is okay though.
Holy shit. It… it actually innovates on Discord’s UI. Multiple guilds (“planets”) show in a tree view on the side, and each chat opens in a new tab. I actually quite like it.
Basic stuff works. Voice chat works in the web client. No desktop or mobile clients yet. No video chat yet. Quality and availability of the audio is a bit WIP as well, from the sound of it. While I was there someone found a way to join a voice chat multiple times and proceeded to have some fun with it, so you know, it’s still alpha.
Has some cryptobro red flags: a headline feature is the ability for different planets to each make their own microcurrency and trading API, and an example bot plugin screenshot on their website shows a candlestick chart for Ethereum. But none of that is currently obligatory, or especially intrusive. Their talk about microcurrency stuff is mostly in terms of a generic replacement for the “XP” minigame features common to some Discord bots. Not exactly thrilling, but it doesn’t seem to cause any practical problems so far. We’ll see if it grows AI Chat Agent Integration.
Like Fluxer, they plainly want to turn this into a business. Like Discord did, they’re appealing to gamers and coders. So I don’t trust it. But, you can self-host it. The code is AGPL but there are apparently no proprietary bits – it’s not freemium. (Yet.) Apparently the server is C#. The devs claim federation is on the to-do list.
I want to like it.
Nerimity
It works pretty much as you would want. But it’s a one-person side-project, currently appears dedicated to staying that way, and thus has some institutional issues. Currently this is the contents of the development announcements chat channel:
Mad props to the author for setting scope and sticking to it though.
Chatto
…Chatto is also designed to be highly scalable; even just running a single instance of it on very modest hardware will likely be sufficient for most use cases (I don’t have any hard numbers yet, but I’m gunning for thousands of concurrent users served by a single Chatto process.)
If you want High Availability, you can connect multiple Chatto instances to form a cluster, giving you replication of all data and self-healing failover capabilities.
Props for prioritizing self-hosting.
The hosted platform will provide options for free public spaces for your friends or your community, as well as paid private instances for teams and businesses.
Instance: An instance is a complete deployment of Chatto, with its own database, configuration, and users.
Spaces: Chat rooms within an instance are organized into spaces. A space acts as a collection of rooms, with its own members, permissions, and settings.
Chat seems to work okay. The web UI is a little slow but generally fine. But it’s young. There currently is no:
- Voice chat
- Video chat
- Source code release (see the timeline)
- Binary code release
- Non-web client
Sharkord
Designed to be small scale and self-hosted. It basically gives you a single Discord “server”, aka guild. Not a place for multiple disparate communities to each have multiple channels. Within those limits, it doesn’t do too bad, but it is very firm about those limits.
Why not large communities? While Discord is built for large-scale communities with thousands of simultaneous users, Sharkord is designed to deliver fast, reliable, and meaningful conversations without the noise.
This is not peer to peer, every connection goes through the server. Normal users cannot see each other IP’s in any circumstance, only administrators can see them.
Looks like the client is web-only for now, no mention of any plans for other platforms. They probably have enough work to do already. In principle I don’t mind, in practice I’m gonna have to ding them for that.
Voice chat works at least, though apparently the test server doesn’t have the resources to run it for more than a few users at a time. I hopped into it on the test instance and had an entertainingly awkward 30 seconds of trying to speak with someone I shared no languages with. On the whole, it works fine for self-hosting, and is probably easier to self-host than Stoat or Fluxer.
Tailchat
Not sure if it’s federated. Doesn’t seem so. Might be dead now? Not much activity in github the last two years. …Yeah it looks pretty dead. Original dev is still active on other stuff though, so might be tempted to come back to it, or someone well-intentioned might pick it up and dust it off.
Campfire
Really it positions itself as an institutional-internal chat system: it talks about using it to replace Slack or MS Teams, and tells you to get your IT department to host a server for you. It runs on a single server only, no clustering, no federation. Despite it being MIT licensed on Github, for some reason the default download link on its website takes you through a payment portal where you are charged $0.00 for it. It’s… a little mystifying.
Sorry, I didn’t even try to install it. :-/ Just use Zulip?
Mumble
Ahhh, it takes me back to the heady days of 2009, playing dungeons and dragons with my friends who were all fresh out of university like me and had scattered to the four winds. It hasn’t changed a bit since then, either. Bare-bones, but perfectly cromulent self-hosted voice chat rooms for up to a few dozen people, and that’s it.
Honestly, if someone would fork it and integrate it with IRCv3 they might have something good going.
Spacebar
Spacebar is a free and open source, full stack reverse engineering and reimplementation of Discord.
lmao that’s a wild idea. Basically the idea is that you can self-host a drop-in-compatible server that that implements Discord’s bot API’s, talks with 3rd-party Discord clients,
That said, the client (called Fermi) has some rough edges. It took some guessing to set up an account and voice chat didn’t work for me on Firefox. So, a bit rough.
A friend says that with a patched Discord client, Spacebar works great. But Spacebar is already is already skirting the rules (their FAQ includes “is this illegal?”), so it’s not something they can exactly share. “Look, use a patched official discord client for our server, here’s a download.” lawsuit ensues
Neat idea, but not super compelling to use compared to others yet.
IRCv3
Well this was originally in the “federated” category but apparently I had been misinformed. From the IRCv3 FAQ:
Where there is only one client-to-server (C2S) protocol, there are a multitude of server-to-server (S2S) protocols. The client protocol can be extended in a relatively standard way, whereas the server protocol cannot because there is no single ‘server protocol’ in use today.
So this is not truly a federated protocol, the only thing that keeps it looking kinda like one is clients having good support for different servers. That’s better than most, but still.
I’m having trouble finding a client that actually does anything particularly novel with it, sadly. I don’t really feel like re-learning how to configure irssi. And I find nothing in the docs about being able to do voice or video chat. So, while it appears a nice improvement over stock IRC, it doesn’t do what I want. It’s okay for IRC to remain a weird niche thing for nerds, I guess.
Federated
These are things that work like email: you make an account on a server, send messages to that server, and if the recipient of the message is on a different server then your server finds it and sends your message to them.
This means anyone can run a server and talk to anyone else’s. This also means that anyone can run a server and spam anyone else, or otherwise cause abuse, and you have to have some way of dealing with that, but unlike decentralized systems you have at least a prayer of blocking abusive servers. This also means that you have to trust the server you use: usually the way these things work, the server can read any message you send. (This is usually true for single-server systems too ofc, and not fundamentally untrue for distributed systems.) So both users and server owners have to be mindful of quality-control.
Conclusions
This section will also be long, so I’ll put conclusions at the front again.
- XMPP works, often very well, sometimes very jankily
- Polyproto is still WIP
As has been demonstrated with email and Mastodon, when you have a bunch of servers and let people choose which ones they want, they will tend to cluster into a power-law-like distribution: you have a couple BIG servers, a double handful of medium servers, and innumerable tiny servers. This sucks, ’cause it means the big servers have lots of power over the community and the technology. I think that this is just kinda how the physics of information works out, though. We see the same patterns in biology, airline and internet routing paths, human social networks, anywhere that communication is cheap but not free. Centralized systems are more efficient and decentralized ones are more resilient, so when you combine them they tend to self-organize into something with that shape.
But as has also been demonstrated with email and Mastodon, once you get a critical mass of different servers, these systems are basically impossible to kill entirely. They are also very useful for giving someone a unified, unique identity across many different domains of control, and also for letting someone have multiple identities with different domains of control. (ie, your work email address and personal email address.) Telephone systems are basically built as federated systems, just federated between different telecom companies. There’s a reason that every single account-recovery mechanism in the universe uses email or text messages.
Yeah this can lead to hateful communication monopolies like Ma Bell and Verizon, but how is that different from what Discord is right now? At least with federation you have a fighting chance. Keeping federation alive is a human problem, not a technical one, but that also means the decisions you make matter.
XMPP
The OG federated chat system, developed in the late 1990s and early 2000s when XML was inhabiting the “take money from gullible companies” ecosystem currently filled by pushers selling LLMs. Since then XMPP has become steadily less cool, but is still kicking around in various low-key places: company chat systems, the guts of Whatsapp, portions of soft-phone telecom systems, stuff like that. It does it’s job, it’s just not very exciting.
Like Matrix, I looked at this a little while ago. The server software is basically bulletproof, there’s very little wrong with it and it scales up far past any use case I’m ever going to have to host it for. Prosody is good for small-medium systems that a single person wants to self-host, and ejabberd is good for big systems that need many nodes.
The problem is getting clients and servers to work together. The XMPP protocol is a collection of standards written by various volunteers and companies, and it’s a giant fucking mess. A client built for actual humans needs to implement like a couple hundred different documents to actually do everything it needs to do. Servers may be configured to support or not support various features based on whatever they feel like. And when there’s a mismatch you generally get zero helpful feedback, something just Doesn’t Work. The whole ecosystem desperately needs a WHATWG-style takeover where the people actually writing these things get together, say “this is what actually needs to happen” and coalesce all the standards into something that someone can actually read and use2. With compliance tests. That’s just also a lot of work, and not very fun work like writing a new protocol and client is, so people want to write new protocols and clients instead.
But I really want this to succeed, so lemme put my money where my mouth is and tell you how to use this for real.
Servers
There’s three common options: the smol-and-easy one (prosody), the big-and-powerful one (ejabberd), and the new kid on the block (snikket)
Prosody took me a couple hours to set up, all in all. It required dinking around with DNS records, reading docs in a few different places, getting SSL certificates, updating firewall settings, and tinkering with settings to make it serve HTTP file uploads. Most of it was just figuring out how to fit it into my existing infrastructure, since I already have a web server, DNS records, SSL certs and all that. This was honestly more work than I wanted, but if this is all stuff your comfortable with then it’s not a huge deal.
I feel pretty confident based on my past experience with Prosody that it’ll take about 3 minutes of upkeep a year. It is currently consuming about about 25 megabytes of RAM. Prosody’s official docs are good, there’s good tutorials out there already, and it all seems to default to sane 2020s-era values: requires SSL, doesn’t allow unencrypted connections with servers or clients, uses server dialback to confirm that incoming connections aren’t being spoofed, etc.
Prosody requires an external TURN/STUN program to help voice/video chat, and it looks even simpler to get something working than using Prosody, but I didn’t feel like setting that up right now. However, voice and video chat between my phone and laptop worked fine with both on the same wifi connection. So P2P video chat Just Works when both sides are on the same network, but if you’re behind a NAT like 99% of the universe you’ll need a bit extra work. Wish Prosody had a TURN/STUN server built in, the protocol seems easy enough. It has an HTTP server built in for file uploads/downloads, seems like a TURN server wouldn’t be too hard?
ejabberd is fine. I ran it Back In The Day, and I don’t expect it’s changed much. It’s big and complicated but very much learnable for a dedicated tinkerer, I just don’t need it. If you want to set up a hosting company with a cluster of XMPP servers, use ejabberd.
Snikket is an attempt to re-bundle an XMPP server and client into a convenient single product that doesn’t use the word “XMPP” anywhere. It’s basically a docker image containing Prosody and whatever else it needs, and a reskinned copy of Conversations as a client. I thought it had a web client too, but apparently not, just Android. But you can pay them to a private server for $6/month, which is fairly nice, even if the results are pretty minimal. Feels very much like a new hosting company, in terms of product, but all the stuff works. I made my own server and dinked around a little and it worked exactly as expected. Occasionally had some flaky results with voice/video chat for some reason, unfortunately. But only with some clients! Yay, The XMPP Problem.
Haven’t tried self-hosting Snikket, sorry. I wanted to but I’m just out of spoons. It’s probably fine?
Clients
There’s lots of very mediocre clients out there. I went though a bunch of them but don’t feel like collecting a whole list3. The category of “mediocre clients” includes most of the ones that xmpp.org suggests to you, IMHO. So here’s the ones that don’t suck:
- Conversations.im for Android. It’s not Discord, but it works okay.
- Dino for Linux desktop. It’s not Discord, but it works okay. It’s excessively minimalist but it handles video and voice calls well.
- No fucking clue for iOS or MacOS. Don’t use ’em. Monal got some praise from some people?
- Oh right, Windows still exists. Same story there.
The “imperfect but promising” category is a lot larger though, and has some interesting highlights:
- Movim for web is very cool. It kinda is Discord, but there’s some jank around calls and encryption. But they are also playing with features to use the general-purpose-pubsub of XMPP to publish blog posts and stories in an RSS-like feed, which is fucking cool. I found its UI flaky in general sometimes, but a friend has been using it semi-regularly for a week or two now and likes it a lot.4
- Converse.js is a quite nice web+electron client… but it doesn’t handle voice. But it’s pretty. It’s cool. I want more of it.
- Similarly, Fluux is a nice web+desktop client, but also doesn’t handle voice or E2EE yet. But it’s made by the same company that puts a lot of work into ejabberd, was publicly released just recently, and has that magical lost art known as a 🧙🔮 protocol debug window 🔮🧙. I shall watch its progress with interest.
Unfortunately… I hate to say it, but they all have The XMPP Problem. 98% of the time everything works fine, and the last 2% breaks for no goddamn reason, and which 2% is broken varies based on your combination of server and client.
Voice+video chat worked fine using conversations.im (with the conversations.im server) and dino (using the mov.im server), but the movim client had some issues with it, just with those servers. Just mysteriously didn’t show the “call” button for the conversations.im acct, though it did just fine with my account on my self-hosted prosody server. Movim also had flaky problems with OEMEMO encryption; in general it works, but I had issues with it not turning on and it seemed one of those “works with this one thing and not this other thing” problems. If it can’t get browser permission to use your camera or you don’t have one, then it doesn’t even try to offer video calls? It has some odd text in a few messages. I had some weeeeird interactions between the Snikket account and my conversations.im account too, where using the Snikket client voice calls could work one way but not the other. No idea what’s going on there.
Despite its problems, I actually enjoyed Movim the most, with Converse and Fluux tying for second. Dino doesn’t spark much joy but functions very well. Your mileage may vary.
I love Movim’s tech and Converse’s aesthetics. Less of this, please:
And don’t even bother with this:
I want to live in a synthwave cyberpunk future, with useful controls in good places and a neon color palette with just a bit of adornment:
Heck yeah. (It’s been pointed out this UI is scuffed af. It absolutely is, and I still love it.5)
Polyproto
I’ve heard Polyproto mentioned several times in the past and glanced at it, but never dove deeper. It seemed Fine on the barest technical level: a pubsub system shuffling JSON messages around over HTTPS or WebSocket.
I dug a little deeper and it got a little confusing though. The repo talks about “the Polyphony project”, not Polyproto itself. Some of the repos talk about being “Polyphony and Spacebar compatible”. Some things link to a client, but the client is old and not maintained anymore while they work on the core protocol?
So what’s going on? Who’s making this anyway? Oh wait, this “Flori Ava Star” person contributing to it on Codeberg looks familiar, didn’t they join a friend’s Discord server a while back? Oh, yeah that’s totally them. Through the power of Discord making it super easy and convenient to have little enclaves of queer Rust weirdos, I can just sit down with one of the creators of polyproto and get a ten-minute precis.
It makes a lot more sense in context. Polyphony is the name of the project, and Polyproto is the protocol they’re developing. They started off by saying “I wanna write a client for Spacebar’s knock-off of Discord’s protocol” and couldn’t resist the urge to tinker and fix and clean up the protocol. Then they realized that the Spacebar project really wanted to stay a reverse-engineering project, not a next-gen replacement. They met someone else who was doing the same thing, and also wanted to tinker and fix stuff instead of just reimplementing Discord. And it basically just snowballed from there. So I forgive them for the messaging being a bit scuffed: “Since its inception as just a Spacebar client, the project has changed meaning 3x I think. And maintaining all the documentation is A Lot.” I feel that in my soul.
It was a fun talk. Apparently along the way they looked at other federation options like XMPP and Matrix and concluded they weren’t what they wanted. They checked out options for serverless identities like DeltaChat and SimpleX and “that in particular was very interesting but I then figured out that it’d be very very complicated.”
So, yeah. Can you stand up a Polyproto server and invite some friends to it and have a nice client like Fluxer or something? No. Can you write some software with it incorporating their libraries and have it talk to other instances of itself? Yes-ish. It’s not an immediate solution, but probably worth working on.
I’ll end with a quote from them that really sums up the state of chat systems right now:
Well, Signal, Delta and SimpleX have more of a focus on absolute security than anything else
but the people yearn to be seen
Discussion
Ugh. Fuck. Goddammit. XMPP is the obviously right solution. Fucking hell, it is. But it’s an uphill fucking battle to recommend it. Still, it’s the closest thing that exists for what I want.
After talking about Polyproto, and comparing it with the high-security options like DeltaChat, you can see why this problem is hard in general: the problem isn’t shuffling messages from point A to point B. We have tech to do that decently. The problem is making a tool to build communities. There aren’t many of those that don’t suck.
So yeah, you should probably use XMPP, but if I tell my 70-year-old non-techie aunt to use XMPP and help her set it up and make it all work perfectly, it will work perfectly sometimes in some situations and then break mysteriously and she’ll just go back to WhatsApp.
But doing nothing sure won’t make anything better.
Distributed
These are things where you can run a server if you want, but servers just shuffle messages from point A to point B without really doing anything else, and you shouldn’t have to care much about what server you’re using. In theory chats and user accounts aren’t attached to particular servers, at least not very strongly. In practice the boundaries are fuzzy and this is a bit of an “everything else” category, so don’t get too worked up about them. All categories are false.
Matrix
The big daddy Other Chat System. I looked at Matrix already about six months ago. Check that out, as far as I know the landscape hasn’t changed too much. In general, and with love, I don’t think it works very well and I don’t see that changing any time soon. It’s either a good implementation of a bad idea or a bad implementation of a good idea. IMO probably a good implementation of a bad idea6. Sorry.
- Clients: Element, ElementX, Commet, Cinny
- Servers: Synapse and that’s about it
SimpleX
SimpleX is a bit of an odd duck. It’s not quiiiiite distributed, but I’m putting it in this category anyway ’cause it’s a lot closer than most. The idea is that everything is stored on the client, including account information, group membership, contacts, etc. This makes life a lot easier for true end-to-end encryption, the server just shuffles encrypted messages from point A to point B and truly has no idea who is talking to each other. There’s no global user ID’s or anything, each user has a set of different ID’s for their own particular contacts and chats.
That’s the promise, anyway. Digging into the specs, it appears some parts are still WIP. And from the whitepaper:
Although end-to-end encryption is always present, users place a degree of trust in servers they connect to. This trust decision is very similar to a user’s choice of email provider; however the trust placed in a SimpleX server is significantly less. Notably, there is no re-used identifier or credential between queues on the same (or different) servers.
So the server still knows the conversation is taking place, and when stuff is sent to people even if it can only guess who they are, but each server’s history might look different so whose accounts are talking to each other is somewhat obfusticated. To much get better than that apparently you still need something like Tor, plus a client that emits a constant stream of noise to random parties to hide your real messages in. The whitepaper claims SimpleX “supports” these things, but whether that means it actually does them, I don’t know.
This has some consequences. Accounts are all local, verification is all out-of-band, etc. Basically your physical phone becomes your identity, and your phone’s contacts list is attached to that. Want to use a laptop? Tough cookies I guess. I don’t see any non-mobile clients at all.
Neat idea, but it sure doesn’t do what Discord does.
I tried using it; there’s only a mobile app at the moment, but it’s available on F-Droid. The UI is a little… fiddly. I tried joining the test chat room, and it had a pinned message saying I had to message the admins to get access. So I hit the link it gave me to message the admins and got a chat with a bot, and couldn’t go back to read the rest of the pinned message. I then said hi to the bot and it very slowly and laggily said I’d failed the captcha and sent me a new one. But it had somehow desynced between what message I was sending from what the captcha was, so each time I sent a message with the captcha’s contents it said I’d incorrectly answered the previous captcha and sent me a different one, until I failed five times and it booted me.
Soooooooo we’ll put this one on the “maybe someday, for someone” list.
DeltaChat
This was originally in the “federated” category but that isn’t quite accurate. When I first saw this it was touted as “a chat system built atop email” and, as someone who self-hosts their own email server for fun, I automatically went “wow that sounds like a terrible idea.” But I fired it up anyway and the results were a lot different than I expected.
Turns out they’re more building a new protocol starting from a chopped-down subset of email to coordinate resources, same way XMPP uses chunks of XML to tell clients “download this HTTP link” or “talk to this WebRTC stream for voice chat”. They call the result “chatmail” and have built dedicated low-latency server software for it, and have a list of a dozen or so public relays. Apparently you can run it off a normal email server though it warns you not to use the account for anything else. So of course I tried to attach it to my normal email address, but alas didn’t get any fun results out of it.
The thing is, this is all very encrypted and private. There’s no non-E2EE option. There is no public directory or index of chat rooms. In practice it works a lot like SimpleX does: you create an ephemeral contact address, share it with someone else out-of-band (send a link by other means, scan a QR code, etc), and then you can talk to that one person. There’s group chats as well, but not large ones. Whether this is by design or there’s some technical limitation, I dunno yet. There’s no live voice or video chat either, as far as I can tell. But everything else pretty much just works as designed.
So, DeltaChat isn’t a replacement for Discord. It’s a replacement for Signal. And a pretty decent one, from what I’ve seen. No idea how well it stands up to real use though.
Discussion
Distributed chat systems have some problems.
The tech is hard. Matrix has consistent performance and security problems and it seems like every time one is solved two more crop up. I do not know enough about Matrix to say for sure why it has these problems, but my guess is that the P2P model as Matrix does it isn’t a good fit for large, low-latency chats. Some things just can’t be sent efficiently peer-to-peer and so the server adds new features to help, and that produces new security holes. And so on and so on. 7
Additionally, Matrix has a spam problem. It’s hardly unique in this regard, and it’s not an insurmountable problem, but how bad it is and how people are building mitigations really highlights that distributed, zero-trust systems have some serious management problems:
- Someone needs authority to get rid of bad actors or whitelist good actors
- Currently this seems to be done via bots run by particular communities, which have admin rights to particular groups
- So you’re just giving the keys to the kingdom to whoever runs the auth bots
- And you’re now back to “hand power to someone you trust”
The “super-secure server-knows-nothing” style of chats have the same problem though! They just approach them from a different angle. Everything in them is purely client-side, and that makes it inconvenient as heck. It’s difficult to use for anything other than point-to-point messaging. Apparently E2EE encryption for large chat rooms has performance problems too, though I didn’t really try that too hard, ’cause… I couldn’t find any large chat rooms. They might be out there, but I couldn’t just look up what chat rooms exist, say “oh, Minecraft server, that’ll have some traffic” and pop in to say hi.
Nobody can spam you just by searching through a public list of server users, but nobody can reach you at all either. To do anything with these systems beyond point-to-point chat with someone you’ve met face to face and set up your account with, you need to put in a fair amount of work. There are no tools for community management, so if you build them from scratch you’ll end up in the same boat as Matrix, reinventing the federated approach but badly.
Truly distributed management of large human groups is not a problem we know how to solve right now, so it devolves to either federation or centralization. Also known as “representative democracy” or “dictatorship”. Both can work very well and both can work very poorly, but if there’s a way to make a true democracy or anarchy work at scale without degenerating into one or the other, I don’t know it.8
Once again, the people yearn to be seen.
So WTF do I actually do?
Well this spiralled out of control incredibly rapidly and became a stupid amount of work. Here’s the skinny:
- Use XMPP and for a server choose conversations.im, mov.im or self-host it9. Use Conversations on Android, and Dino or Movim or Fluux or whatever else sparks joy on real computers.
- If that doesn’t work, use Stoat, Fluxer or Valour, in that order, and be prepared to move again
- If you want something secure like Signal, use DeltaChat
Upon reflection, the “centralized” vs “distributed” vs “federated” lines I attempted to draw really don’t work that well. The world is messy and complicated. In reality the distinctions are more like:
- Everything is tied to a single service provider that doesn’t talk to anything else: Fluxer, Stoat, Valour, Mumble, etc
- Accounts and messages are on servers and servers talk to each other: XMPP, Polyproto
- Accounts and messages are kept entirely client-side and the servers shuffle anonymous messages: DeltaChat, SimpleX
- Whatever the heck Matrix is doing, which isn’t much like anything else besides Bitcoin or IPFS
Each of these get you a vastly different experience when you scale them up to a large chunk of the world, and are best for different use cases. But as I realized when talking to Flori, we have tools for getting messages from point A to point B but what we need is a good, open tool for building communities.
So, I see a few possible futures for the “people who want to ditch Discord but like how it works” community:
- We all shotgun out and go our separate ways and eventually re-converge onto Stoat, Fluxer, Valour, or something like them and stay there until they enshittify and then we do this all over again and again for the rest of my goddamn life
- We all converge on XMPP and force it to be good to the point that someone unfucks the standard enough to make an actual client and server that talk to each other and work with all relevant features 100% of the time, not 97.3% of the time when the phase of the moon is correct and the server owner has waived a dead chicken over its config file
- We all use Stoat, Fluxer or Valour but we get involved in their code and force them to federate with each other, using XMPP or Polyproto or whatever else works
Choose wisely.10
Bridges
I think that whatever we use, we’re gonna need to step up the game on inter-network bridges. Several people are already hopping in on the “hosting chat systems” market. A savvy entrepreneur will next hop into the “hosting chat system bridges” market. Where is a nice, DigitalOcean-like service where I can go and pay $30/year and get a bot that will bridge Discord, IRC, XMPP and Fluxer servers together? Maybe they exist, I haven’t looked. But until everyone decides to use XMPP and/or Polyproto, and even after that point, such a thing will be invaluable.
Encryption
Currently there’s pretty much two tiers of encryption:
- TLS
- end-to-end encryption (invariably using something related to Signal’s protocol)11
With TLS, I send an encrypted message to a server, the server decrypts it, figures out what to do with it, then re-encrypts it and sends it off to whoever it’s destined to. With end-to-end encryption, the same thing happens but the server can only decrypt a tiny piece of the message to figure out what to do with it, not the whole thing. The server knows who you’re talking to, but that’s about it.
Almost everything I’ve talked about here has “the server can read your messages” levels of security. Nothing besides Signal (and maybe DeltaChat???) has reliable, usable end-to-end encryption that hides what you’re saying from the server. And what little I know about security tech is that a) encryption shouldn’t be able to be turned off no matter what, and b) bad encryption tends to be worse than none.
However, my main experience with end-to-end encryption was summed up by a friend of mine: “I love E2EE. You can be sure no one can read your messages. Not even you!” The only system I’ve seen do E2EE that doesn’t cause this problem is Signal. That said, Signal isn’t perfect either. From another friend: “yea signal is great, I lost my phone and while I had the pin and backups set up, for some reason I couldn’t find it in my password manager which made me confused, so i clicked ‘forgot my pin’ and that deleted everything with no way to go back.”
So in general, E2EE is not a solved problem. It’s certainly a problem that’s been solved badly more often than well. But I am not an expert on security and encryption, so I will defer to a representative of the critical technical caste that keeps the internet operating: a furry.12 Long story short:
- Signal’s security is probably as good as they say it is and nobody else even comes close,
- XMPP has TLS by default and an end-to-end encryption option called
OMEMO, but no guarantees that one server can’t just say “oops I can’t do
that” and your server won’t say “ok then I’ll just send everything in
plain text”. It depends on the server’s configuration.
- XMPP’s E2EE protocol is also not that great and has plenty of problems.
- Matrix’s E2EE is pretty much in the same boat
- Nothing else I looked at had even a whiff of end-to-end encryption besides Delta and SimpleX
- This still matters
- We need to get off our asses and make it work
- But there are real non-technical problems around E2EE as well that might or might not be solvable.
The real message is to fight the stupid fucking laws that are mandating these things, tooth and nail. Whether they’re the governments making these laws or the companies complying with them, none of these assholes have your best interests in mind. To poignantly quote the comment in that last link:
…“E2EE solves government overreach” is roughly the same kind of argument as “cryptocurrency solves payment processor censorship”. I think this comes from a fundamental misunderstanding about how the world works. You don’t solve governments doing bad things with technology. That never works. You can resist those bad things, and you need the tools to be available for that. That’s what Signal is for. But there seems to be this utopian belief that “if only we could make these technologies ubiquitous, governments would just go ‘[it can’t be helped]’ and leave us alone” and that’s incredibly naive. Governments never just “give up”.
A Discord alternative does not currently exist. And if you prioritize E2EE when building one, if you even manage to get there at all, you will be so far behind that a non-E2EE alternative will have already taken over and won.
Economics
Here’s some random thoughts I’ve had about why these companies keep failing:
- In the end, “make an account and you can use the app to talk to people” comes down to selling server hosting.
- To get users, most systems will say “using this is free”, which means you’re not selling server hosting, you’re selling your users (or losing money).
- Selling hosting is a tough market in a federated system ’cause there’s lots of competition and low barriers to entry. People only really differentiate on price and reliability/convenience.
- The easiest way to differentiate your product then is adding features, but that tends to break federation.
- That’s why Discord, Telegram, WhatsApp, and every other commercial chat system ever has insisted on being a walled garden.
- But a chat system is, in the end, fairly interchangable and easy to make, and not that expensive to start running out of your garage.
- So the walled garden’s walls aren’t that tall.
- The companies that actually host chat services and have for a long time (Meta with WhatsApp, telephone companies with SMS/MMS/RCS, etc) do it as a loss-leader for some other product – ie, they lose money on it.
- And even then they really want to keep their walled gardens.
- One company that keeps cropping up when I research XMPP is ProcessOne, who appears to be one of the few companies in this space that has actually been a good open-source steward for a long time, as far as I can tell. They maintain ejabberd, they just recently released Fluux, etc.
- Process One is a consulting company. They don’t sell server hosting, they sell expertise.
You can draw your own conclusions there.
Random junk
“Have you heard of MLS yet?”
Yeah but it’s not a program you can install and use, it’s like, an idea for people to implement. XMPP and Polyproto people need to think about MLS, not you and me. (Well maybe me, I’m probably gonna play with working on XMPP or Polyproto at some point.)
And also not having photos of their face connected to their Discord ID and sold to Palantir.↩︎
Just, you know, with less shitty results than WHATWG came up with.↩︎
don’t talk to me about Gajim, I don’t like it and I’m sick of trying to. Sorry.↩︎
Though they also have recently started collecting physical cassette tapes and tape players, so they might have different opinions than most people.↩︎
I might also have different opinions than most people.↩︎
Matrix chats act a lot like git repos, or at least that’s the concept however it works in practice. You have a bunch of different versioned histories of changes, and then you can bring them in sync between servers and clients by exchanging history diffs. This approach is awesome but has issues scaling up, and so it can’t scale forever. From what I’ve seen Matrix has vividly hit the limit of how well it can scale. It might be able to keep going, but it’ll either be a shitton of work or it will involve fundamentally changing how it works.↩︎
The Matrix Rant goes here: I’d love low-latency, high-traffic P2P chat to be able to exist with history and search and all the other features we take for granted these days, but I don’t see it happening with the Merkle DAG model that seems to be the best we have right now. Merkle DAG’s are great for write-seldom, read-often data, but not for something like a chat room that mutates a lot and builds up a huge history that needs to be shared among thousands or millions of nodes. Maybe there’s ways around this, maybe not, but either way it’s an absurdly complicated and resource-intensive process compared to message-based protocols like XMPP, Discord, IRC, email, and whatever else. When your chat is based around a “send message” operation rather than a “merge history” operation it is basically a pubsub system: a server has a list of topics, a client subscribes to a list of topics, and when something happens to a topic it gets shotgunned out to all the clients that are interested in the topic, while history is recorded optionally by servers and distributed on-demand. Servers talk to each other basically through the same mechanism, all the complexity is basically just around “is this server who it says it is”. Pubsub is in general a super efficient way to get things done, a good general-purpose pubsub service can be run on an ESP32. “Shuffle messages from point A to point B” is not a fundamentally new or unsolved problem, it’s literally the only thing the internet does, but Matrix’s P2P approach turns it into something absurdly more complicated and resource intensive.↩︎
The main objection against democracy is that it tends to devolve into oligarchy. This is a valid problem, but not a fatal one. The PLTDI discord server was an explicit oligarchy, and I was one of the oligarchs for a while. Oligarchy works pretty well when you have good oligarchs, which generally means “choose level-headed people with good judgement who really don’t want to be oligarchs”. The real issue is that anarchy tends to degenerate into dictatorship, and getting rid of bad oligarchs is a lot easier than getting rid of bad dictators. Oligarchy also scales up better and fails more softly than dictatorship does. I’ve also helped run a hackerspace that was very much a pure democracy/anarchy, and it evolved into a de-facto well-run-oligarchy in a similar way. Some people are just generally moral and pretty competent and all around trustworthy, and others aren’t. The trick is distinguishing the two and making sure you have a good supply of the first kind. …And finding ones who have free time.↩︎
I’m sure there’s other good public XMPP servers, I don’t want to make a list and double the size of this stupid post. Do your own work.↩︎
and for the love of all that is sacred don’t make your own chat system. For fuck’s sake. Find an existing one to contribute to, I really don’t care what. This list needs to be shorter, not longer.↩︎
Well, there’s also “didn’t even try” levels of encryption, but that’s thankfully gone out of fashion since 2013.↩︎
Like me, they have their own biases. You want good opinions, you do your own research; I just want an overview with citations.↩︎