Request for sources: Discord alternatives
81 points by icefox
81 points by icefox
I'm writing up a survey post on "chat systems you might actually want to use besides Discord", and it seems like every time I talk about this someone chirps up and asks about something new I've never heard of before. So, I want to try to head this off at the pass and collect as much as I can right off the bat. So, anyone have anything they want me to cover?
Things on the list so far:
I'd love to see a list of alternatives for people who like Discord in general.
For example:
I often see these lists come up and get a bit confused because for example IRCv3 is pretty much incomparable to Discord unless you limit Discord's functionality significantly (for those coming from Discord). I feel like "alternative" should be... mostly comparable?
There are also definitely things I don't like about Discord, of course, but from the perceptive of someone who is mid-30s, dad of two young kids, does OSS for fun on the side, etc. I really just want something I can pay for and forget.
I think that https://fluxer.app/ is exactly what you are referring to
Mobile apps underway
This is a big one. Fingers crossed they do well with it, because it otherwise looks nice.
For a huge volume of users, a necessary feature of a Discord replacement is good video support.
Is it? Do you mean desktop share (streaming) or video calls (conferencing)?
Both, simultaneously. Screensharing and video conferencing, with noise cancellation at least as good as Krisp.
Out of the FOSS Discord-likes, Fluxer seems to be the most polished and least shady option.
The only thing it doesn't have yet among your requirements is client diversity, in part due to how new it is. The main developer has however expressed openness to third-party clients.
There's a lot more information on the how and why Fluxer was built in this blog post:
https://blog.fluxer.app/how-i-built-fluxer-a-discord-like-chat-app/
Not the mention the "IRC-like" channels in Discord. Some of these options listed do not mimic IRC servers.
I often see these lists come up and get a bit confused because for example IRCv3 is pretty much incomparable to Discord unless you limit Discord's functionality significantly (for those coming from Discord). I feel like "alternative" should be... mostly comparable?
ObsidianIRC is decently competitive with Discord for text chat UX. i would really love if someone smashed Mumble into IRCv3 at high speed for voice chat capabilities though.
smashed Mumble into IRCv3 at high speed for voice chat capabilities though.
IRCv3 has been in development for well over a decade and barely has seen adaptation other than the most basic things. I remember IRCCloud being one of the bigger drivers behind v3, but their blog has been quiet since 2022.
Even with sleek apps like the one you are linking (or ircclour, the lounge, etc) I'd still not recommend that people switch back to IRC. Don't get me wrong, I like idling on #lobsters with the folks there. And I really used to be a die hard IRC user to the point of having written this thing just so I didn't need to switch to discord.
But, IRC simply isn't an ecosystem that fits with what people expect these days. Heck, even over a decade ago it already didn't fit what most people wanted out of a chat service. I remember trying to get a channel going for various communities and subreddits over the years and never really succeeding. As soon as we put up a discord link in the subreddit people started flooding in simply because of how much lower the barreer of entry is compared to IRC and still very much is.
Yes it is fine for technical people if they sit down for a moment to figure it all out. But that in itself already says something about how accessible IRC is compared to something like Discord. Already a mental hurdle sometimes for (slightly) technical people, not to mention the masses. Which is extremely easy to forget as well, because once you have figured out IRC it doesn't seem all that difficult. Causing a lot of IRC users to suffer from the curse of knowledge in discussions like these.
Work on IRCv3 continues at a steady pace, by a fairly small community of advocates, including James Wheare from IRCCloud.
I am sure people are still working on it. In fact, I applaud their dedication and the effort they put in. But progress on both the specs and maybe more importantly their implementation has been such that it isn't making a huge difference to the current situation.
I'm not sure what barrier to entry you are referring to. If you use a web client and don't require registration is the barrier not actually the same as or lower than discord?
The simple answer to that is have a look at the libera.chat "basic" documentation for people new to IRC.
If you don't require registration people will not always get the same nickname when they rejoin for starters. You can set up discord that it also doesn't require registration, but generally that is a bad idea for moderation purposes. Anyway, assuming you do so people still have the option to create an account from within the discord client.
Compare that to IRC on the other hand. Registration of your nickname can be different per network. So you need to be aware of the network you are on, know the syntax for command registration. Heck, you even need to be aware that there are different networks. The fact that there are different networks also means that you as a user are now dealing with account fragmentation. Not necessarily a big deal, but still a thing.
On joining there is also the privacy aspect. Many networks don't cloak your IP by default. Which isn't entirely transparant either.
There is the fact that by default IRC clients don't have message history. Something that trips up a lot of new people who aren't aware of this at all. Which leads to situations where people will join, hang around for a minute, leave, mis a lot of conversation, rejoin and think nothing has happened.
Even if you do accept that IRC is more bare bones than discord (no chat history, no included media hosting, etc) it still requires more work as a user to get started and join somewhere.
These are just the first things that come to mind. There are many more things that make IRC just not as straightforward. Again, if you are slightly technically inclined it is easy enough to figure out. But that is exactly my point, you need to figure out how to work with IRC much more so than a lot of people will ever do so. And again, the fact that this is needed is often forgotten by people who have been using IRC for years.
There is the fact that by default IRC clients don't have message history. Something that trips up a lot of new people who aren't aware of this at all. Which leads to situations where people will join, hang around for a minute, leave, mis a lot of conversation, rejoin and think nothing has happened.
Depending on your IRC server and client, this is no longer true! IRCv3's chathistory extension doesn't only allow a smoother experience when connecting to IRC bouncers (like soju), but normal IRC servers have the choice to provide history, and at least both Ergo and UnrealIRCd do, per IRCv3's server support table.
no included media hosting
Almost the same deal! draft/FILEHOST is a proposed IRCv3 extension that's already supported by soju, Ergo, and UnrealIRCd (contrib). ObsidianIRC both supports it as a client and implements some extensions of its own (+obsidianirc/link-preview-{title,preview,meta}) (implemented server-side in an UnrealIRCd module) that use it to provide modern-style link previews.
This is what I find exciting about ObsidianIRC as a project—people are working to make at least one blessed IRCv3 client-server pairing legitimately competitive with Discord's feature set. A randomly chosen IRCd is still likely to be pretty primitive and not implement even just the ratified IRCv3 extensions, but there are small communities pushing to see what's possible when not necessarily designing for wide IRCd adoption. Fluxer and Stoat only currently care about one respective blessed client-server pair. I think it'd be most fair to evaluate ObsidianIRC the same way here.
Again, I applaud the work that as been done on IRCv3 and by extension people implementing it in clients like ObsidianIRC and server implementations like you mention.
But, you yourself also recognize the current context this is happening in.
A randomly chosen IRCd is still likely to be pretty primitive and not implement even just the ratified IRCv3 extensions, but there are small communities pushing to see what's possible when not necessarily designing for wide IRCd adoption.
Maybe in the future we see a comeback of IRC because of all this. But at the moment that is not the reality we find ourselves in. At least not in the original context I made my comment in. Which is the comment it all started with
There are also definitely things I don't like about Discord, of course, but from the perceptive of someone who is mid-30s, dad of two young kids, does OSS for fun on the side, etc. I really just want something I can pay for and forget.
IRCv3 doesn't offer that and even if we put water in our wine and tone down our expectation it still isn't that accessible. I can't help but mention the curse of knowledge again. Which I already gave context for, but as another example. Soju is a bouncer, which is a foreign concept for most people. In fact, it comes on top of getting to know the basics of IRC as it is an extra concept.
Even if we focus on just the client side. If you look at the landing page for obsidianIRC it still has some barriers in place. Let's assume people are familiar with discord it is clear that it styled like it. But, there are only a few networks available (likely those with ircv3 support) where most seem to be test networks and while I can connect to those without any context they would leave me confused (where are the channels, how do I discover channels).
Certainly, it is a lot better compared to many old school irc clients. But it effectively still requires that someone has read up on irc basics, knows what they want to join, likely has gotten some instructions, etc. Not to mention that for the features you might expect you really need to be on a server supporting them (which might be one of the more confusing things).
Where with discord people just click a link and are being onboarded to whatever server the link points to.
Again, I honestly do applaud the work people still do on IRCv3 and I really don't want to trivialize or downplay the work they have been doing. All I am saying is that for mass adoption, which I think you agree with, it isn't the right tool for the job. At least not at this moment.
From the name I assumed it was a plugin for Obsidian Notes, but I'm glad to see I was wrong. It does look to have a lot of the same Discord UX, but I really wish they would do something different. It shouldn't be too hard to add some sort of voice chat bridging.
What's Matrix missing in that list? It feels the most full featured honestly
I had an absolutely terrible time with Matrix the two times I tried it (Nix and Gnome). The problem could be totally with me, but I used their official clients and just... couldn't connect, couldn't talk, took seconds to join servers. Everything felt really brittle (just a feeling). Like I said, totally could be my problem but the first user experience was atrocious and it happened twice to me across months of time difference.
I also felt that the client I was using was aesthetically very very bad, and I think for this type of software aesthetics does matter a lot. I'd give it a lot more slack (no pun intended) if everything else was smooth but this on top of the bad experience really left me a bad mark on me.
The last time I tried was maybe 6 months ago. I'm willing to try again.
The last time I tried was maybe 6 months ago. I'm willing to try again.
I know the client cinny has made decent progress in that time frame and it's worth another look. It's also aesthetically much nicer to my eyes than Element. And even today the Element client is stuff just as rough around the edges in my opinion as it was 6 months ago.
hum, sorry about that :/ Was this on desktop or mobile? Element Web generally gets good reviews for aesthetics. Element Classic on mobile is awful, but has been in maintenance mode for 3 years now; Element X on mobile on the other hand should be best-in-class (rust core + SwiftUI/Compose native UI on top).
In terms of server performance: joining perf is a known problem area. But once you're in a room, things should be fine - unless you're on a server which is struggling. Would be super interested to understand what went wrong here, it really shouldn't be that bad :(
Matrix is extremely brittle and janky. It has the basic features but falls over in real-world use because its design puts E2EE and federation first (which led to the whole "it's really a distributed database masquerading as a chat system" design), and it turns out when you do that, you just can't build a Discord competitor that actually works well.
Just yesterday I had a weird desync in a chat group that affected all my clients, some unfixably. Apparently it was root caused by... server load issues? No other chat system out there persistently corrupts room/sync state when the server has some transient load issues... and this was in a server hosted/managed by Element themselves.
Not to mention the moderation problems. Last year were getting CSAM auto-loaded and cached on their computers due to spam attacks, and there was nothing the moderation tools could do within the existing ecosystem.
Matrix is a neat idea and all that, but as a viable chat platform for the masses, it's sadly a failed experiment.
To me, the best alternative right now for "it just works" is probably Root. It's not open source or federated or privacy oriented so a lot of people will have justified concerns there. But, it has pretty much all the features of Discord and already has cross platform (including mobile) support.
There's also a lot of potential there for apps and bots as they have a much deeper integration than in Discord. It's also not just a straight rip of Discord's UI like Fluxer and includes a lot of UX improvements.
XMPP implementers and standards folk absolutely need to get together and come up with some kind of profile of "modern" XEP's to support and give that profile some kind of marketable name like "XMPP2" or whatever. The incredible level of inconsistency in implementation support is not just a problem on its own in terms of adoption, it is also a social issue in that what those inconsistencies are and what they mean is inscrutable to all but the more savvy of users, which plays a part in driving away many from the platform.
IETF XMPP2 was one of the talking point of this year's XMPP Summit. Everybody agreed it would be very good to have but we are not sure we have the human resources (and time) to go through the process, unfortunately. It should be done because if you implement the RFCs you are not going to be able to federate with anybody. Example: plaintext streams are theoretically allowed, but forbidden in practice if you want to federate with anybody (or even allow clients to connect to your server), despite what some bloggers say. However, compliance suites and XEPs are most likely here to stay, because no one thinks it would be a good idea to put stuff like "how to emoji reaction" in the RFCs.
(this was my attempt at quickly summarizing what I understood from summit, I'm actually very far from understanding the implications of RFCs and inner workings of IETF, I'm just a privacy and self-hosting enthusiast that happen to have fun developing chat high-level gateways as a hobby)
EDIT: I should have added, since I mentioned the lacking human resource. There are very few of us. Discussions happen in the open and everybody is welcome. Lots of little things could be done, from improving tooling, the website and stuff like that. Becoming a XSF member is not even required to do so, but easy if you want to. Join us!
Really appreciate the response, and I'm not surprised you've all already discussed this. I can totally relate to the lack of human resources aspect; if I don't end up personally finding time to contribute, I wish you all luck and share the personal reminder of something I'm sure you also already know: it's a marathon, not a race. It is usually wise to not commit to something with high burnout/failure potential, even though everyone agrees it's a "good idea".
My understanding is that this work has been done and continues to be done. For example:
https://xmpp.org/about/compliance-suites/
As with anything that isn't dictated by a single entity, it takes a lot of time and effort to get people from different projects with different priorities to agree on things. This is a standard built by countless people around the globe over the last 25 years. Even with that in mind, there's plenty of consensus on the major pieces and things are continuing to evolve in cross-compatible ways between server and client vendors. I access people and multi-user chats hosted on multiple servers from multiple clients, and I have all the chat features I want (message history, reactions, etc.) across all of them.
I am aware of the compliance suites, but while they are a step in the right direction in some ways, they go absolutely the wrong direction on the subject of my comment in just introducing frightening levels like "advanced server"/"advanced client" that would just drive non-technical users away from the clients they would probably prefer. And this problem is made self-evident by the fact that (to my knowledge) none of the clients made for non-technical users advertise their compliance suite level.
It seems the best thing for nontechnical users is to not refer to how the sausage is made at all. The end-user work is being done with projects like Snikket, providing a clear brand that users can look to knowing they'll get relatively the same features everywhere. Anyone working with XMPP should be well suited with the compliance suites, and anyone who doesn't need to know about the compliance suites shouldn't care that it's called XMPP at all.
I'm not sure why an end user would care? I hope they never hear the word "XEP" at all...
Cos otherwise it's a surprise when they use a client that sounds like it will work, and at least some regular-ish users will want to try out other clients.
What's the harm in putting a small note somewhere that says that snikket client supports xmpp 2, or "xmpp advanced client 2026” or whatever? Makes things easier for people who get a bit curious about stuff, and for people who want to hack on it.
Using a third party client is always going result in at least a subtly different experience. This is true with silos too. People who want the experience of the product use the flagship app.
Such profiles have existed for years. There's very little inconsistency in practise with any app that's been updated in the last decade. But also I don't think have different apps that want different experiences is always such a bad thing. If you want exactly the same experience you should use exactly the same app, same as you do with a silo.
Calls didn't work properly for icefox. They also reported that 98% of the time everything works and 2% of the time things are broken inscrutably on some clients but work on others.
Maybe all those issues are down to bugs, but are you saying you believe none of this is due to incompatible extensions or whatever?
Isn't this mainly a question of somebody showing up and saying "here's a client server pair that works well with XMPP support"? At least for me google/gchat felt like that.
And hey... now might be a good time to do that. I don't think XMPP standards bodies have to get involved so much as somebody showing up with the "this is what you want to se to have XMPP + mobile apps + desktop apps`", and show up with a snappy name or something.
Right now I'm looking at setting up a matrix server because there at least I don't have to do that much research, but I think I wouldn'd mind something XMPP-like if I knew of client + server pairs that most definitely worked well enough
EDIT: this convo got me willing to start trying to set un an XMPP server and there's probably also some more basic problem of futzing with server setup, even for the "easy" case of prosody.
And hey... now might be a good time to do that. I don't think XMPP standards bodies have to get involved so much as somebody showing up with the "this is what you want to se to have XMPP + mobile apps + desktop apps`", and show up with a snappy name or something.
In the same way that HTTP didn’t tell you that you needed TLS or QUIC or WebSockets. XMPP at the core is super generic, prescribing very little.
Yeah but for a decent mobile experience or, say, Discord similitude you have a set of things one would want (dumb things like emoji reactions which are experimental , push notifications are their own mess but looking into this today it seems more possible than it used to be)
This is what the compliance suites do—& those suites are updated.
Anecdotally, I have used emoji reactions across 4 different XMPP clients for at least the last year, if not 2 (it’s been a foggy last 2). I get proper notifications across both phones, my e-reader, & my laptop—& a while back before switching to Ejabberd, using Prosody’s+Cheogram’s builtin UnifiedPush server+client to, of all things, get notifications for Molly (Signal) + Element (Matrix). I mean there’s a reason Nintendo uses XMPP for their account presence, & League of Legends + Fortnite use XMPP for chats & handshakes since it “just works” for presence, messaging, & notifications.
mobile
Is this maybe an iOS-specific issuesʔ̦ since Apple OSs have long had issues in this space including denying PWAs notification access for the longest time. If one considers how hostile Apple has been to FOSS developers, no one should be surprised if these low/no-budget, community-driven projects don’t prioritize an expensive platform that doesn’t align with their philosophy (I don’t think you can even publish GPL’d apps to the Apple Store).
But also, I’m sorry but Discord isn’t ‘peak chat UX’ & I don’t think it’s should be a goal (look at how bad they poisoned the word “server”). There are ideas to borrow sure, but trying to be a clone I don’t think is a smart goal that ends up leading to more frustration when a client doesn’t then behave like Discord despite superficially looking similar. Being your own thing, playing to your strengths, & doing small innovations is what I would rather see.
To be clear I wasn't implying that mobile is entirely busted or whatever. But on conversations.im's page:
Low impact on battery
Even though Conversations keeps its own connection to the XMPP server and thus is independent of Google’s push messaging system (GCM), it does a lot of work to keep the impact on battery life as low as possible.
This is awkward! I don't care about push privacy, lemme have GCM! My understanding is this is the flagship mobile app. UnifiedPush is a very hefty workaround that I would prefer not to pay if possible
My reading of the Push notifications XEP is that this is a solvable issue.
The play store version has GCM as a fallback for broken devices. GCM will always be worse for battery and performance than a perperly managed direct connection, but sometimes it is needed and that's why it is supported.
AFAIK the Play Store versios does uses GCM if available (but has a price, that's how the developer makes some money). The F-Droid version does not use GCM at all.
The Grafana link I had is down from a while back but someone ran a head-to-head of XMPP vs. Matrix vs. some other stuff (probably WhatsApp, & the like) on Android metering the data usage & batter. Conversations ranked #2 in least battery usage & #1 in least data usage despite maintaining it’s own connection to the server. It does a shockingly good job, & I’m happy I can get access to Cheogram (fork) on Sailfish OS thru their Android compat layer.
UnifiedPush seems like a standard built to sell a product, but it had a bit of adoption in apps I was using. My microG for Lineage OS was unGoogled so it was better than polling. But ultimately I was happier, like, not getting notifications from these services after being afraid I would miss out on something big not having UnifiedPush with Ejabberd.
Honestly, UnifiedPush is pretty nice in that it provides an abstraction over your choice of push provider. At minimum XMPP and Ntfy (both self-hostable) or GCM (not, obviously).
It is solvable, but it requires server side support, and I think also server administrator support for things like setting up an API key for Firebase. On the other hand, I wouldn't call UnifiedPush hefty at all - every push implementation comes with a small non-zero cost, it's just that you're probably already paying the cost for GCM. But I'm also already using Conversations+Prosody, so I'm glad that other apps (e.g. SchildiChat Next) can use the same connection for their push. Honestly, I have 3 push systems on my phone right now: GCM, UP, and IMAP IDLE. If I could get Thunderbird+dovecot to use UP, I'd be over the moon.
This is the first of these write-ups that touches on (but still doesn't manage to fully formulate) the vast feature set that Discord has and how many different groups of users use it.
I think that's the main point. Some things you can basically only use in one way (or somehow misuse as a solution for your own problems) but for Discord just in my light use I see these things that may or may not overlap:
Maybe we'll simply see several exoduses to different platforms, based on people's needs, not a 1:1 replacement like the freenode-libera event.
Interestingly I'm also still in some very old pre-Discord Slack communities, where the loss of messages after 3 months is not a huge deal. Doesn't mean I am advocating for Slack, but some things I kinda like better than on Discord.
Then again I'm apparently certified old because I've been on IRC for 25 years and find it ok, I'm on Slack and find it ok, and although my Discord account is from 2015 I've never loved it.
In my opinion Discord was never perfect at anything it does. If it wasn't for the conviniece to have things in the same spot, Discord wouldn't have survived. There are better messaging platforms imo, and there are better voice chat systems(mumble), but none of them are good together. I say this as someone that has been moderating big discord server for a few years now and I have had to experience first hand some of the stupid limitations discord has.
It does also seem like different groups use different feature subsets, so whenever someone argues that you can move to X, they can point out that X doesn't have Y, which is obviously the crucial feature of Discord, and shows why person 1 doesn't understand Discord enough to be advocating replacements.
Doesn't have to be perfect to be good enough. Especially for not-so-technical users.
I personally don't care so much about the massive servers, as long as mods can ban spammers and delete their messages, not sure if that is already a high bar. Maybe because these huge communities with open invites exist are a problem in itself for discussion about alternatives.
Mumble is great if you don't need streaming. Mumble's chat is so bad that I would bet that 75% of people in a call might miss that someone posted something at all. IIRC PTT on mobile was also not great.
I'm counting 7 discount "servers" I'm reasonably active in, 2 could be downright merged because 80% overlap, so let's say 6.
One I have never seen anyone speak in voice - this could be any text chat.
One I have seen people use voice/streaming once per month although it's massive, so people could move to something external if there's a blessed way.
4 make heavy use of voice chat and chat. Loss of streaming might be tolerable for 2-3 of them, but annoying.
DeltaChat with its ChatMail servers. I'm not a user yet for lack of mutuals (i.e. the messenger issue), but looks interesting.
Not sure if everyone would regard it a Discord alternative, but since we're listing stuff like Signal here...
Thank you for gathering all this info as you see things! I like seeing these personal takes on the state of the art, and all the more when the same conclusion is reached as my own: just use XMPP ;-).
I agree that the current client situation is lacking, but the great thing is there's no reason you couldn't build something exactly like Discord using XMPP. Jitsi is Prosody! Snikket is Prosody! The Cheogram and Snikket folks are working on a new SDK (Borogove) that will bring a more unified experience across all platforms for the specific use cases Cheogram and Snikket target, and then I hope someone takes Borogove and builds a Discord competitor, too. The protocol is there, we just need to build the UI/UX.
Exciting things are happening in the world of XMPP. Also to your point about WHATWG-style governance, that's basically the XSF and some of what you describe is happening. There are differing opinions of how things should work, but mostly I see XSF members building the things they want to standardize.
I agree - wonderful resource on discord alternatives.
Regarding Snikket vs "plain" Prosody - the author of both made a few comments over on the orange site, such as:
https://news.ycombinator.com/item?id=47039555
And: https://news.ycombinator.com/item?id=47037214
At least I was persuaded that if the goal is small-scale self-hosting - Snikket might be the better choice for most.
I am not really happy with the proposed snikket example docker-compose file. It might work but I don't think it's beginner friendly, zero explanations or hints at troubleshooting. (I only looked at it)
What do our expect to need to troubleshoot? A lot of people who use it have never used dicker before and they want it to just work.
First let me note that I'm evaluating these alternatives in the context of a friend group chat, not a large community server.
While not open like other alternatives, Steam has recently updated their group chats to implement most of Discord's basic functionality, making a group chat roughly equivalent to a discord server (with multiple text chats and voice chats).
Steam's streaming/screen sharing tech is kinda lacking, and entirely nonexistent on linux, so for that I've been looking into Broadcast Box, which has an online and a selfhostable version and seems easy enough to use (provided that WebRTC works), though obviously not as convenient as just pressing a button while in a voice call.
Personally I've also been evaluating Mumble, Teamspeak, Matrix and Rocketchat, but almost everyone is already using Steam regularly, so it seems like the 'easiest' move.
First let me note that I'm evaluating these alternatives in the context of a friend group chat, not a large community server.
This is where I feel it's really hard to compete with Discord. It is able to cater to both single digit friend groups and 10k+ communities. Smaller groups probably value voice, video, and screen sharing while large communities need user management and moderation tools.
These lists of alternatives always feel off because they don't state what group they are targeting.
Aeledfyr from IRC recommends:
Nerimity (nerimity.com) is an open-source community-focused discord alternative that's a bit more polished than the other open source ones (like Stoat).
It's not a well-known as Stoat, but it's been more reliably maintained and has a less buggy frontend (from experience contributing to both Stoat and Nerimity). I'm not associated with the project, though I have contributed some fixes.
Update on Fluxer licensing: https://old.reddit.com/r/FluxerApp/comments/1r8724q/heads_up_fluxer_has_a_big_red_flag_it_requires/o62u82f/
The CLA has been removed in the refactor branch: https://github.com/fluxerapp/fluxer/commit/3dce089fe2ea372d6f70c024fe060a2afefc4ce2
As for voice and video calling, I have managed to get it working in Linux while running Fluxer inside a web browser. However, I've seen reports of screensharing not working in the Linux client due to problems related to Wayland? Unfortunately those reports happened in the main Fluxer HQ community, which has been down for days due to how many people are in there.
Slack. (I’m not saying you should use Slack, but if you’re writing an article about this you should probably mention it, if only to say “I don’t think Slack is a viable alternative because…”)
Minor correction: “mov.im” should be “Movim” for XMPP clients.
mov.im is the showcase Movim client + an XMPP server (which is free to join & hosted in the EU). This can be a bit confusing since you can use mov.im’s client to connect to any server (it’s just a web client after all), but Movim, the client application, is AGPL & self-hostable. I’m happy its on the list since you were last asking around.
A lot of folks use Ejabberd (Erlang) as their XMPP server. Snikket is also just a preconfigured Prosody (Lua) IIRC. There are others, tho active are less popular.
Movim is not just a web client, it has a web frontend+a php backend that connects to (and maintains) the connection to your XMPP server. I would add gajim to the list of XMPP clients, but full disclosure, I am a contributor.
Very true. I was quite focused on the other part that you don’t need to access it thru mov.im. I use Gajim every day so +1.
Oh great to see this post finally out since icefox seems to have put serious thought & effort in this from the “What are you doing this week” posts. The last chat post was equally thorough. I’m very happy the finally tried Movim after I had asked, but I think they missed some things.
The conclusion of running my own tests of the landscape a few years ago landed me at the exact same spot
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.
I haven’t quite felt comfortable to recommend the extended family to use it for this reason, but I got my immediate family & some tech friends to try it out. We all seem satisfied, not blown away & that’s more than I can say about the alternatives which have something that irks me to no end. The biggest pain point has to do with dropping old OMEMO keys when returning to a client you haven’t accessed in a while & not being able to get everything back in sync—however, this is literally the exact same issue as Matrix since the both are effectively using libsignal.
The Matrix people have done a lot more work to get E2EE multi-device support working. It's still kind of a pain in the butt (verify each new client via an old one), but the "Can't decrypt message" issues that used to be ubiquitous with Matrix are now mostly a thing of the past. I'd love to see OMEMO updated to the same standard, because I'm otherwise happier with XMPP than Matrix.
Not sure if whatsapp should also belong on this list - the "rest of the world" uses it for easily setting up group chats.
I think it should. Also, Signal; but I think both are more suited to closed-ish communities.
Although I've never used it, I understand that Telegram also hosts lots of groups, some very large.
WhatsApp has support for communities with multiple sub-chats, moderators, and stuff now. It's better-suited as a Discord replacement than Signal is, but of course it's Meta
Re: Jitsi integration (e.g. limits of Jitsi integration with Zulip), maybe we shouldn't underestimate the power of a channel where only links to long-standing Jitsi rooms are allowed to stay, and maybe we should make sure that this idea is obvious to everyone.
(I still think that the best online conference solution to outside-the-talks discussion for online conferences was not any of the GatherTown exercises but NixCon 2020 having a link to a shared pad with links to Jitsi rooms by topic, with some catch-alls)
As someone who is only seriously looking at XMPP due to recent events, one thing that gives me pause is that it seems that XMPP is just flat group chats? One valuable thing about discord is that a 'server' could have multiple channels in it, similar to matrix's spaces. I came across an XEP about spaces, but it hasnt been implemented by anything yet. Also, is it possible to have persistent 'hop on hop off' voice/video channels in XMPP?
Since group chats have an address of the type room-name@rooms.example.com, there is already a way of grouping rooms together: have them all on rooms.example.com. This is how the joinjabber project structures its rooms, as you can see in this web client, and most clients do have UI to "discover public rooms" of a given domain (although it may be a bit buried in the UI). This is not discord-server like in the sense that right now, you basically need to be the admin of a server to be able to create a (sub)domain like that.
I am one of the authors of XEP-0503, along with the developer of movim, who has started implementing it. The idea is to have something a lot more discord servers-like. For full context, I develop gateways and my main motivation for the spec was to be able to advertise that rooms are part of a "group of rooms" and use that for bridging Matrix spaces, WhatsApp communities, Discord servers and Mattermost teams. Happily enough, at least one client developer is on board to provide UI for this, now. :)
Also, is it possible to have persistent 'hop on hop off' voice/video channels in XMPP?
I don't know much about the subject since I have never been a user of such things, but I know it is planned for movim too.
There's experimentation going on with better integration of Jitsi to offer that kind of group audio/video call connected to a chat. All the components are there; it's just a matter of wiring it up in a way that people like.
XMPP channels are naturally grouped into "servers" just like discord and the platforms that inspired discord. However you are right that very few clients expose this is a way that fits with the discord UX hierarchy. Prose is an example of one that is closest I think.
I don't think it's that "naturally" for users, assuming you mean that they are grouped by the domain of the server hosting them? Or is there another grouping mechanism I'm not aware of?
Yes by the server. Just like discord and mumble and ventrillo.
There is some movement in the community to make it easier to get your own server, including snikket and snikket hosting (though those focus on a different use case generally)
Even as someone somewhat comfortable running services "want a new group of channels? setup another domain and server" is not a particularly nice answer, and not like Discord or Matrix where it's a few button presses.
That was discord's big selling ferture yes. Making it easy. Push a button get a server. This isn't a protocol thing it's a hosting thing. Snikket provides this with snikket hosting, but with a different focus. As I said there is work in the community on starting up more hosting providers as more people see the need.
Point is there is absolutely no reason for it to be tied to an actual server vs being a grouping one server can store many of (that Discord happens to call "server", but e.g. Matrix wisely doesn't). More hosting providers are the wrong level.
You still need a server to host the channels on.
A server doesn't mean a physical server it just means a virtual entry in a config somewhere.
And when mainstream clients have a standardized button to create said entry in the server config of a server I do not own you've actually achieved UX parity. That feels needlessly complicated, but would indeed work.
Eh, what Discord calls a "server" is what Matrix calls a "space", and I don't think there's any exact equivalent in XMPP. You could set up multiple subdomains (even with one server?) for XMPP (chat1.example.com, chat2.example.com), but it's not really the same since it's 1) more work, and 2) doesn't provide a listing of all rooms on the server to the client. That's the main benefit of Discord servers and Matrix spaces, related room discovery. I'm glad to hear Prose handles that in some way, though.
There's no reason for it to be more work. And it does provide a listing of rooms to the client.
Anyone know of a iOS XMPP client that feels as modern as Conversations for Android?
The iOS users at my organization are kind of being left out to dry, unfortunately. Monal is... Ok? Snikket does not have working push notifications, as far as I can tell. The apps feel like they're out of the 90s, weird visual bugs, UI completely inconsistent with modern design guidelines on iOS.
The Snikket iOS push notifications should work fine with a Snikket server, but most of the free public XMPP servers won't work with it.
Monal should be fine with any server. It is probably overall your best bet for iOS right now and is under quite active development.
The general "out of the 90s" thing is being fixed (we're working on a total overhaul of Snikket iOS, and Monal is currently in the process of rewriting their UI - I believe you can switch between the old/new UI in the settings).
Generally there is more friction for open-source apps on iOS. I don't think there's one factor, but many. Part of it is that the intersection of "open-source developers" is much larger with Android than iOS, so it's hard to find people to work on it. Nevertheless, we're committed to improving the situation :)
(any iOS developers reading this who are interested in lending a hand... give me a shout!)
The iOS users at my organization are kind of being left out to dry, unfortunately.
Good.
Someone picked an OS from an FOSS hostile company, why would we care to support them?
Working on iOS applications is a nightmare for someone that is not in iOS ecosystem, and it is all artificially and on purpose done by Apple. The basic fact that I can't easily cross-compile to iOS or run an iOS emulator, is not up to FOSS to fix.
Just let them pay 30%, scan their faces and someone charge them for dealing with Apple.
I find this attitude nonconstructive. Many people own these devices, telling them to buy another one/carry around a second device just because no one has developed a good messaging app for it is unreasonable.
The development experience is bad, sure, but that doesn't mean we have to leave all the users out to dry. Part of OSS evangelism is meeting users where they are, offering a superior experience on the devices they already own.
edit: Also, the Monal repo has instructions to develop without a Mac.
Does anyone have any more color on the matrix data storage scope? Sounds like if I set up a homeserver then I would have to store all the logs of all the chats that I'm in, but would I also have to store chats for other people a la bitcoin etc?
Inversely, given that it sounds like other homeservers would also store that info... does it mean I could actually log in via other homeservers..???
Matrix indeed replicates events on all participating servers. But if you don't have users from your server participating in a room, it will not be stored on your server.
You store all the events for every chat that anyone on your own server participates in, but none that you don't have any users in.
The main benefit of that model isn't that you can log in via other homeservers, but that rooms are server-independent. I can create a room on my server, invite people from other servers, have my server go down for a weekend, and everyone else sees the room without interruption.
DeltaChat being a replacement for Signal is incredibly funny. Moxie has criticized e-mail and its ecosystem so much that I wouldn't stop laughing if a system built on top of email were to replace it.
Note that I have only had limited experience with DeltaChat. I was surprised how well it worked however. The focus and choice of features (and their ordering) felt spot on, at least for me.
See also soatek's perspective (a cryptographer) https://soatok.blog/2026/02/11/on-discord-alternatives/
This made me laugh out loud:
Actually, I need to add one more thing Discord is:
Solely responsible for muddying the waters for most people on what a fucking “server” is.
I usually avoid Discord because it doesn't run very well (IMO) on my computers. But after "I don't think it works very well" and "I object to the company's policies", sowing confusion about what a fucking "server" is may be my biggest complaint about it.
I am not really buying that though.
Yes, Discord may have currently more users than my examples but let me put up a list of stuff that came before and also did the exact same thing
So what exactly makes a Discord "server" worse than anything else? Because they are all at the same company? Because you can't selfhost (cf WoW and Slack).
And they called them guilds internally (it's still in the source) and (I can only guess) renamed to server because everyone in gaming was calling them that anyway.
I have many bad things to say about Discord but I find this a bit ridiculous. A completely non-technical person has no proper understanding of a server anyway. Every file share is "the server".
I've used Slack so much more, with so many more organizations than I've ever wanted to. Slack calls them "Workspaces" as far as I've seen and as far as I've observed its users when they refer to the service.
I don't dispute that Quake and WoW did this before. I'm agreeing with soatok's tounge-in-cheek statement that discord is the reason that this malapropism leaked from the gaming world to people I know who are neither gamers nor techies. I was amused to see someone share my mild annoyance.
You've never talked with heavy Discord users. Every heavy Discord user I've talked to has been misled about guilds. Misconceptions include:
This is all because they think that a server is physical hardware while a guild is actually a row identifier in a database.
We seem to be talking to people of different misconceptions. I doubt most could really answer on the spot what a server means to them exactly and might start guessing.
Also I wasn't even disputing that any user calls them servers, only that Discord is the original perpetrator that they do.
Nobody said that discord committed the original sin of this confusion. Only that for most people (under the age of 40, as it seems) it is solely responsible for it.
RE: XMPP
It's a mistake on XMPP's part they clearly do not make it obvious enough that the audience of the specifications is "developers who are prepared to implement XMPP". If one was not so convinced this was how they were meant to interact with the existence of XMPP, they might notice you are supposed to match clients and servers to compliance suites.
There is no lack of information, it is not hard to access, but if people are going to keep opening the standards documents and expect easy answers, then people will continue to be disappointed.
Also I might add that I have found XEPs to be far better at answering questions than most standard / specification documents. The people involved have genuinely put in the work to make this accessible to the correct audiences and it does show.
Edit: I can concede that they might as well name compliance suites "XMPP 2.3" or some fancy name, but the problem is VoIP is a nightmare to implement, even with the way XMPP diverges from a full SIP flow, and the PubSub features are not the instant messaging features and shouldn't be in most clients. Movim is a great example of this for me. I do not want to mix messaging and social media, even if other people think this is a great idea. Other people can just use Movim, I can stick to conversations, and we're both happy.
Hmm. Do you have suggestions how we could make it clearer that xmpp.org content is targetted at protocol developers?
One way I do this is by never saying "xmpp" to friends or family despite them all using it. They don't care about the protocol they just want an app that works.
I am in-favor of matrix, bunch of clients, open, encrypted and looks like it has a strong future.
I did not mind it too much when I set it up for my friends to try, but they hated it. This points out that one of the biggest draws to Discord is the accesibility to non-technical people, which I think is something that needs to be considered and discussed in OP's article. Lots of alternatives on the list are pretty cool, but most are nowhere near as simple as downloading an app for your device from its default app store, or simply clicking on an invite to join a new server like Discord.
Most users want something they don't have to think too hard about using, whereas my goal was to find a federated/decentralized alternative where I could monitor and maintain the instance. The obvious problem being why bother when nobody shows up because there's a "convenience barrier" to entry.
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.
No? You don't need centralized identity with SSO, you can just have OIDC or whatever. Signing in with yout account is a password manager's problem. Again, think of Zulip - you run the server (or not), you can use i.e. whatever OIDC provider like GitHub to reduce friction.
frankly Linux and Android are probably going to be the last systems that get good clients
My experience so far is that when it comes to open source systems, iOS tends to lag behind the most in clients. With chat apps: Matrix has the outdated Element, the featureless Element X, the “it works okay but feels weird and looks weird because Flutter” Fluffychat; XMPP has Monal which I get the vibe of an IRC client from 2010. For pretty much other protocols, we get nothing.
I get why this happens, Apple and their high bar of developing (get Apple hardware) and publishing (give money to Apple on yearly basis). Still, this is the bane of me trying to explore other options and recommending them to people with less comfort in dealing with janky things.
I know that this is also an issue on iOS but that is why I have gravitated towards self hosted PWAs over the years for a lot of this stuff. The situation on Android is better, but I have still found that a lot promising apps often stop being developed before they are production ready. It also gives me the benefit of a more consistent user experience across platforms.
For example for IRC I have been using "the lounge" for years.
I daily drove my XMPP PWA on iOS for awhile before starting on the native app. It can work pretty well (though safari has some hilarious storage bugs sometimes...) The main thing is that you can't do VoIP pushes so incoming calls are never going to be awesome.
Interesting! Personally I have two PWAs on my iphone, Phanpy for Mastodon/Fediverse and Miniflux for RSS. I have not found any satisfying chat PWAs though, they all seem fairly clunky (the unfortunately unusual in 2026 size of my iphone 12 mini does not help)
Telegram? Not ideal in many ways (like Discord), but did feel at least as polished as Discord last time I used it. Could be useful for smaller public communities.
Yeah I understand why it won't be palatable for many, but its open source clients and welcoming policy toward new clients, its general features, and its bot API/libraries, make it my favorite chat platform by far.
If they can solve the bots issue then it’s worth a shout. Telegram is just too easy on them, and Pavel wouldn’t even try to solve it.
@icefox I’m getting bounced by your Anubis instance. It says my hash was calculated correctly and then a second later says invalid response.
That's odd, I haven't done anything to it. Just tested it and it works fine with Firefox?
iOS Safari in Private Browsing mode.
Sounds like this issue. Sadly it appears unsolved, though apparently refreshing repeatedly sometimes lets you get through? Might work if you disable one of IPv4 or IPv6?
I have never used it myself but SimpleX looks interesting, am curious how it compares.
Delta Chat, too (though I think that's more for small chats).
One of the best posts I've seen around this topic. I'm personally bit "locked" to Matrix due to KDE using it, but I think I would set up XMPP otherwise.
I’d also be interested in the ways people use Discord now. Probably there are lots of different scenarios (text-chat only; audio/video-only; background voice chat), and untangling it may help figure out whether existing alternatives help with specific use cases.
As mostly a lurker, I prefer reading IRC logs and my several attempts at discording fizzled out (every time I thought to open discord, it insisted on self-updating, which annoyed me; AFAIU this doesn’t happen to people who have it open all the time).
In the spirit of throwing in something new most people here haven't heard of: XMTP (eXtensible Message Transport Protocol)
https://docs.xmtp.org/chat-apps/intro/what-is-xmtp
It's one of the more complete audited MLS encryption implementations (large-scale group e2ee similar to Signal) and has some good SDKs, and several app implementations, but there hasn't been one that is quite focused on being a Discord-alternative yet.
AFAIK the main consumers of the protocol at this moment are crypto apps like World and Base, and a bunch of bot/agent things.
Identity is rooted with an onchain signer, which can be anything expressed as a program (even just a passkey) and self-sovereign by design.
Not exactly a drop-in replacement for Discord yet but worth keeping an eye out, could be a good foundation.
I wonder how people here are using Discord?
I've mostly used it as an MSN Messenger and later Skype replacement, only for text chats with few friends.
One server started out as a place for my friends and so we could use voice chat while gaming without having to talk in team chat (a la Mumble or Teamspeak back in the day). It's grown to something like 70 people but it's like ~20 of us that actually use it regularly. That's basically the only place I use the voice/video capabilities of it.
Other than that, I mostly use it to stay in touch with other communities or, occasionally, to find support for communities that have decided they want to use Discord awful search.
to find support for communities that have decided they want to use Discord awful search
This is 100% of my discord use and I find it so overwhelming and confusing. You join and are bombarded with stuff, dozens of channels... I just want to ask a question!
Excellent. Fluux seems really promising -its demo worked well.
A review of GetSession?
https://github.com/session-foundation/session-desktop
A Decentralized, Onion Routed, Private Messenger
mobile and desktop, no web. Group chats. self hosting relays might be resource intensive.
only started it once, want to like it…
I know we've had a lot of Discord-related posts, but I think this is now getting a bit too far into off topic for this site.