Posted by LorenDB 11/20/2025
I dealt with ~monthly issues around my devices not being correctly verified, messages not correctly decrypting, and various other rough UX edges. There seemed to be a lot of velocity in the beginning but the last couple of years have addressed approximately nothing in terms of the UX and it's a crying shame as Matrix/Element (I no longer fully understand the difference/relationship between these entities) had a lot of potential.
I am fully appreciative of the work that goes into making a product like this, but I’m also tired of this mentality that nobody is allowed to talk about the problems with the product. Even simple comments from people who tried to use the product but encountered show-stopping issues are getting downvoted into gray text in this thread.
This mentality that we must only speak praise and cannot speak of problems because a product is free is further off putting. I’ve given Matrix/Element an honest try many times because some of the OSS projects I’m involved with use it, but month after month it’s the most troublesome of all of the apps in this space that I use, and it’s not even close. If I’ve gone a month without dealing with Matrix and I have to open it again it feels like there’s a 50:50 chance something is going to either be inexplicably broken or cause problems even though I thought I finally had it all working last time.
The contrast between how hard we’re told that Matrix is the great and superior option and the reality of what it’s like to use it as a casual or occasional user is really wearing me out on the project.
I think there's a pretty big difference between constructive criticism vs statements like "The development team seems to not care". To me, it seems pretty clear that the team absolutely cares, but they are also a small and very underfunded team, and things take time. Assuming the worst intentions of a team is the problem and is disappointing to see here.
> I’ve given Matrix/Element an honest try many times because some of the OSS projects I’m involved with use it, but month after month it’s the most troublesome of all of the apps in this space that I use, and it’s not even close.
I don't doubt that, but it does not resonate with me. There have been a few hiccups over the years, eg the database corruption earlier this year (unrelated to the protocol or synapse) resulting in stuck invites, but overall I've had quite a good experience. Far less problems than Teams, and even slack has had issues (mainly, notifications not happening) that I have somehow avoided with Element, although I am aware others have had issues in this area. There are even some things I do with matrix that are simply not possible/practical with the others to begin with.
I find a lot of value in Element as is, I'm glad they bothered.
Their server clearly doesnt care that a single federated server was sending out thousands of invites, and there's no way to avoid the spam.
In general using matrix was always a pain in the rear for one reason or another.
(yes I'm salty about that still)
Matrix is developing a privacy IM, you do not really moderate that now, do you? Leave the rooms that raise your cortisol level.
It isn't reasonable to expect users to be 'mentally prepared' to have their devices download child porn because they visited a chat room for support about the chat app they're using.
Imagine someone sending you a link that you open and then now you have child porn or whatever else on your hard drive, cached. Quite a shitty situation to be in.
Perhaps avoid non-technical rooms or rooms in which you do not trust people.
I guess the correct legal approach would be to go to police with this.
And the correct technical approach to keep online spaces clean, is the ability to kick, mute or ban people who violate the rules.
Saying, "just be mentally prepared" sounds to me like accepting it. Well, I don't. I go somewhere else.
> Saying, "just be mentally prepared" sounds to me like accepting it. Well, I don't. I go somewhere else.
Exactly! You should be going somewhere else. Another Matrix instance, or at the very least another room, and you will be fine.
Well, but I never decided to hang around for longer. Maybe it is because the moderation tools are simply lacking? I would miss the option of not restricting certain users to send pictures in a group.
I would not consider Windows secure at all, and it seems futile to use a privacy-oriented IM on Windows, it really defeats the purpose.
Imagine using Windows with Recall enabled that takes screenshots of your conversations all the time. You can be using the most effective IM for privacy but it would not help.
So what is the moral of the story? We have shitty laws, and you should not use Windows. :P
This is unacceptable.
I mean, when does this actually end up with consequences for anyone? Even on managed and surveilled company devices I'm not expecting this to cause any harm to anyone involved. IT staff at previous employers and clients had other things to worry about.
Maybe I'm just not familiar with some legal jurisdictions or cases where this was a cause of concern. Let me know.
Users tend to be less aware of these things than the operators of such servers (or at least, that's how it should be).
> Matrix is developing a privacy IM, you do not really moderate that now, do you?
No, but you can create mechanisms for the users to flag problematic accounts.
> Leave the rooms that raise your cortisol level.
The filth will follow the users. That's the whole game plan here: to cause grief.
As for flagging problematic accounts: how would that work in a decentralized E2EE system, and do you think it cannot be abused? What would you want them to do if I flag your account a million times? Keep in mind they probably may not be able to keep up with it, nor do I expect them to. Additionally, you still should be able to use the service due to its decentralized, privacy-preserving nature, so the worst thing that may happen is getting banned from a Matrix instance, or a room.
At this point the majority use case I have for matrix is to bridge to IRC with heisenbridge and be able to use signal on my laptop through mautrix-signal and nheko. The number of native channels I’m in continues to shrink.
There's also the split room bug (feature?) that allows banned users to still be in rooms where the honeserver doesnt ban them. And then, distributes connection shows ongoing banned content (primarily, you guessed it, CSAM) and the better-moderating admins can't do anything about it.
I'm basically in a few well moderated rooms (Gnuradio, other topics). They do extraordinarily well in not getting many trolls, and for garbage collection.
The only one we're seeing spammed is for some cryptocurrency site Liquid something. But its just commercial spam.
Also do you want the development team to moderate self hosted chat servers? How would that work?
But Zulip’s default view is a list of all messages in all threads in all channels which has no context for the individual messages, like
The combined feed is helpful for some (e.g., in lower-traffic organizations, or if you like to see messages as they come in), and was the default home view many years ago.
(I have no idea that’s the BS I was told when we left slack for teams)
If I were to upgrade an IRC-based community to something newer and richer, I'd go with Jabber, well-known, well-established, with a ton of various clients and several servers. Yes, it's not ideal, but it's still a massive upgrade compared to IRC, if your server supports a good list XEPs and your community members agree to use non-esoteric clients that also support them.
IRC has encryption too. You run it over TLS.
Presumably if you want to send an encrypted message from one literal endpoint to another, you'd use some other technology. I'm prepared to bet there are enough people doing just that, too.
It still has.
And with Element X they have greatly improved the UX.
Plus utd errors have been reduced by a lot.
That said, I haven't ever had issues with devices not being correctly verified ( I use that feature since it was released - and can still recover the encrypted messages of that time).
This sucks to hear. I thought they had made massive improvements in the last year or so (I don't know because I feel too burnt by past experience).
In either case, that's a no for me dawg.
When attempting to verify iOS, Desktop linux didn’t work. When attempting to verify Desktop Linux, Desktop Windows didn’t work. When verifying Android, iOS didn’t work. Every verified official client for every platform was verified, tried a different verification method than expected, and failed.
All of this to say, this isn’t the first time this has happened to myself and others. Forcing verification is otherwise known as unexpected “offboarding”. If some verification methods have problems, publish a blog about their deprecation instead.
I love element, but this can’t be done without prior work to address.
All this will do is make me lose EVERY profile.
I like the idea, but the effort to reward ratio for using the product has not been good. It has caused visible churn and attrition in the few channels I’ve tried to participate in and it’s become a problem for the OSS projects I’m part of that try to use it for their communication. Of course, there are some people who like it that way and think making communication spaces difficult to access is a bonus, but that’s another topic.
I have never heard of such issue and not experienced it despite intensive use, so it's a bit strange that you and people you know have experienced this repeatedly.
Meanwhile, an app like Signal can do none of that, and that's by design.
If you're looking for a privacy oriented messaging system, you'd best look elsewhere.
I'm new to Matrix and found this comment on reddit. How much of it is accurate and does it actually contribute to whether or not the future of the protocol is promising?
However, work is ongoing to improve the situation; more importantly, Matrix is a different threat model (in my opinion), and allows for different trade-offs.
When I use Signal, I have to trust Signal's servers and their admin team. With Matrix, we get to keep trust circles smaller (friends and family on smaller servers, where we already trust the people running them). We have no hard requirement to federate either - if I want something just for people I know, we leak less data than Signal does to the outside world. We also get to host Matrix servers in areas we're comfortable with, whether that's our living room, or any nation that isn't America.
Matrix isn't perfect, but I appreciate how quickly they're improving, and the areas they're focusing on.
I would probably characterize Signal as "most possible safety for the average nontechnical user" which entails trade-offs against absolute safety for certain UX affordances (and project governance structures that allow for these decisions to be made), because if said affordances are not given, the average nontechnical user either simply won't use Signal or will accidentally end up making themselves even less secure.
This "average nontechnical user" stuff, though, miss me with. For 2 decades people have been encouraging the "average nontechnical user" to do incredibly unsafe things on the premise that any kind of message encryption is the best alternative to sending plaintext messages. No: telling people not to send those kinds of messages at all, unless you're dead certain the channel they're using is safe, is the only responsible recommendation.
I want there to be something like Matrix that is designed first and foremost as a large-group realtime chat program (really, as a meaningful FOSS alternative to Discord), and it should make different tradeoffs than Signal. I'm actually willing to entirely forego encryption, at least at first, to make this happen - IRC wasn't encrypted and Discord isn't either, and these are things I want to replace with something better. Matrix's UX is still noticeably worse than Discord's, and I'm skeptical that the ostensible security gains from the encryption are worth it, especially given the problems with device verification UX, metadata leakage, and the fact that as the number of people in a group chat grows the possibility that they will take a screenshot of the encrypted message sent to them and leak it to the press grows higher and higher.
Eh. You misunderstand me. I don't really have too much of a view on this personally. Unless you specifically think that the term "average nontechnical user" is a bad term.
N.B. for other readers of this thread to flesh out my initial point:
Signal specifically didn't do that recommendation until they got sufficient critical mass of users in 2022. In particular Signal gracefully degraded to unencrypted SMS if the other side didn't have Signal.
Likewise Signal required phone numbers until 2024 when it shifted over to usernames, with all the security vulnerabilities that entails.
Signal has repeatedly made trade-offs that prioritize UX over absolute security even in 1-1 chat settings. That's not to criticize those trade-offs, there's a variety of reasons why they make sense or don't. But Signal has consistently demonstrated that it is not willing to make severe compromises to the UX and understandability in the name of absolute security and that it will balance the two.
Also to your point
> For 2 decades people have been encouraging the "average nontechnical user" to do incredibly unsafe things on the premise
Sure I can agree with that. But that wasn't my point either? Unless again you specifically object to the term "average nontechnical user."
If nothing else it’s an incredible foot in the door for a lot of people to make the leap to something like jellyfin later.
To go maybe too literal: when I'm working on machines that could physically eat me, I don't trust myself with just one off switch -- I want redundancy. And since computers are horrible piles of ridiculous complexity, the closest I can get (and not really get close) is trusting some of the top minds to overthink the crap out of it in a way that I can't do with the systems I manage.
But again, YMMV.
That said, the uptime is still probably worse than Signal. I didn’t mean trust the reliability. I meant the security.
matrix's users want it to be a decentralized/encrypted irc/slack, but unfortunately matrix's maintainers believe their mandate is to build a next-gen tcp/ip (or something very close to that)
which dooms the project
unsure what makes you think we want to build a next-gen tcp/ip, but can I have some?
So you end up with a similar problem to Mastodon where either you are facing problematic or inexperienced admins, servers shutting down, and everyone centralising on the main server.
Matrix seems to have a lot of these structural flaws. Even the encryption praised in the Reddit post has had problems for years where messages don't decrypt. These issues are patched slowly over time, but you shouldn't need to show me a graph demonstrating how you have slowly decreased the decryption issues. There shouldn't be any to begin with! If there are, the protocol is fundamentally broken.
They are slowly improving everything, with the emphasis on "slowly". It will take years until everything is properly implemented. To answer the question of whether the future of the protocol is promising, I would say yes. This is in no small part because there are currently no real alternatives in this area. If you want an open system, this is the best option.
The huge amount of unencrypted metadata is pretty hard to avoid with Matrix, though. It's the inevitable result of stuffing encryption into an unencrypted protocol later, rather than designing the protocol to be encrypted from the start.
I've had similar issues with other protocols too, though. XMPP wouldn't decrypt my messages (because apparently I used the wrong encryption for one of the clients), and Signal got into some funky state where I needed to re-setup and delete all of my old messages before I could use it again. Maintained XMPP clients (both of them) seem to have fixed their encryption support and Signal now has backups so none of these problems should happen again, but this stuff is never easy.
This is wrong, because afaik these errors happen due to corner cases and I really don't like the attitude here.
It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.
I'm not saying that building a federated chat network with working encryption is easy. On the contrary, it is very hard. I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.
for me it wasn't really; occasionally it would hit me, but mostly it worked, and I have been using it for encrypted communication since 2020.
> It frequently occurred on the "happy path": on a single server that they control, between identical official clients, in the simplest of situations. There really is no excuse.
There still can be technical corner cases in the interaction of clients
a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI
> I'm sure the designers had the best intentions, but they simply lacked the competence to overcome such a challenge and ensure the protocol was mostly functional right from the outset.
well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.
I think the statistic said that around 10% of users receive at least one "unable to decrypt" message on any given day. That's a lot. Perhaps not for devs who are accustomed to technical frustrations, but for non-technical people, that's far too frequent. Other messaging systems worked much better.
> There still can be technical corner cases in the interaction of clients
> a talk for details: https://www.youtube.com/watch?v=ZUSucR2axWI
You linked to a German political talk show. If you wanted to show me the talk in which the guy listed reasons such as "network requests can fail and our retry logic is so buggy that it often breaks" and "the application regularly corrupts its internal state, so we have to recover from that, which is not always easily possible", let's just say I wasn't that impressed.
> well, even if this was true, they still were brave enough to try and eventually pull it off eventually. Perhaps complain to the competent people who haven't even tried.
It isn't a problem that the Matrix team are not federated networking experts. At the time, they had already received millions in investment. That's not FAANG money, but it's still enough to contract the right people to help design everything properly.
I'm not mad at them. Matrix was a bold effort that clearly succeeded in its aims. I'm just disappointed that it was so unreliable for such a long time, and still is to some extent.
> I wasn't that impressed.
If you think, I want to impress you, you are wrong.
And: a phone number is still required, a PIN is not, so by default it's susceptible to phone/SIM spoofing attacks. This one really boggles my mind, it's not that I personally am afraid of this vector, but I don't understand why they would insist on phone numbers at this point.
My suspicion is the real problem that exists now originated from the bifurcation of desktop and mobile. Mobile broke the true p2p decentralization which was easy on desktop, and the split between Android and iOS makes it worse. Users expect an experience on iOS and Android which has parity with desktop. And the entire thing has to be as good as Discord.
I've taken a hard look at all of the truly open source alternative messaging options, and almost nothing handles multi-platform very well. Even when you expand it to commercial options, for a very long time, all of the Slack clones had mediocre mobile apps -- which basically was a death sentence if you weren't Microsoft. This is true today, but I expect it will change in 2026 and onward with the rapid increase in software development driven by AI agents.
Edit: I looked up and apparently Mattermost would be out of the question for their feature downgrades in the community version as of late...
REALLY feels like no one talks about how "permanent and duplicated" is very much an anti-feature if autonomy and safety and freedom is your goal?
Like, no actually - automatically saving everything all the time is bad. I thought we sort of already knew that.
I then stumbled upon their internal Rust SDK[1] that they use for Element X, which is actually quite nice, and even has FFI bindings for Python and Kotlin[2]. Unfortunately the documentation was really lacking at the time. I managed to put something together with the help of an LLM and the source code and examples to find my way around the various APIs, and it actually works with emoji verification and E2EE (although there are weird bugs around synchronization, but that's probably just an API misuse on my end).
It seems they've improved the documentation since and even provide a reference client[3] to see how things work.
[1] https://github.com/matrix-org/matrix-rust-sdk
[2] https://github.com/matrix-org/matrix-rust-sdk/tree/main/bind...
[3] https://github.com/matrix-org/matrix-rust-sdk/tree/main/labs...
> After Alice logs in on a new device, she uses her cryptographic identity to demonstrate to Bob that the new device genuinely belongs to her, rather than being added by someone else with access to her account. She can do this either by entering her recovery key (which gives the new device immediate access to her cryptographic identity ), or by carrying out an interactive verification from an existing verified device.
I have had all variations of clients ignoring requests, reporting requests only for the requesting client to ignore the response. Both ends quitting declaring that the other end cancelled, asking for the other end to input a code while the other end shows no interface for doing so.
It marked the end of me using Matrix as a platform. I'd go back to the old IRC channels if there were anyone still there.
I still have my encrypted messages available from 2020
- no unnecessary coupling to a phone client
- no coupling to any other client - I can just put my recovery key in and be verified without having to deal with other apps.
The numerical Signal PINs are basically just for when you bootstrap your Signal identity from a telephone number.
It involves doing one of these things:
- Comparing a short sequence of emoji on each device and confirming that they match.
- Using one device to scan a QR code displayed by the other.
- Entering a recovery key (a line of text) that you were given when you first set up the account.
Pretty quick and easy in most cases, although some clients can be glitchy in this area and require trying again.
(Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
The experiences reported here seem to say otherwise...
As others, anyhow, I haven't tried again recently
> (Gripe: The recovery key approach was unfortunately made painful and error-prone in recent Element releases, by disabling the option to choose a passphrase instead, but most people can simply use one of the other two approaches.)
I last tried Element about six months ago, but for years using the recovery key was either impossible or close to it, and mostly just for idiotic UI mistakes that were never corrected (something like you had to enter the key where they wanted the passphrase or the opposite).
To my recollection the version from six months ago worked better in that regard, but it was still asking to enter the passphrase where you actually had to enter the recovery key.
Also, other clients exist.
For whatever it's worth, I've been using Matrix for about five years, including some of its roughest times. I seldom see errors these days, but I can understand how folks who were frustrated with earlier iterations would still be soured to it. Such is the nature of an ambitious work in progress, I suppose.
I use it because there is nothing else with the combination of features that are most important to me, and because (despite my gripes) I can see slow and steady improvement. I think it's moving in the right direction overall. I could picture introducing family members to it once Matrix 2.0 is released and the implementations shake out any early problems.
In short, the passphrase works with both and the recovery key with neither, specifically:
Element classic has two separate fields; if I input the recovery key (in the correct field), I get told "Backup could not be decrypted with this PASSPHRASE: please verify that you entered the correct recovery passphrase."
That's how it was the last time I used it, and if I'm not mistaken it's been for years.
Element X has a single field, that supposedly takes both passphrases and recovery keys, but if I enter the recovery key I'm directed to a "Verify with another verified device" screen, even if I had logged out from all other sessions.
Funnily, by the way, it seems that with Element X you can't do anything if you don't manage to get verified, there just doesn't seem to be a way to skip it.
Furthermore, after signing out from Element X I'm unable to even just logging back in, I get an error ("Sorry, an error occurred") after I enter the credentials; even after clearing all the app's storage. Very, very weird.
The new login-via-browser is pretty problematical, by the way, I could only make it work with Chrome.
I have just tried this on Android.
I am directed to
1) "Device verified - Now you can read or send messages securely, and ... - [Continue]"
2) "Help improve Element X ... [OK] [Not now]"
3) list of chats
Element X Android fyi. No problems logging in using Firefox.
However, a couple of things occur to me:
- No Matrix client that I know of supports setting both a randomly generated recovery key and recovery passphrase on the same account. So in order to test both, you would have to use a separate account for each. If you tried to test both on the same account, it's expected that one of the two would be rejected.
- You didn't specify a platform, but since you wrote "Element classic", I guess you must mean Android or iOS. I used Element Desktop / Web to set up my accounts, which could explain why I saw different prompts.
I hope you reported the error message referring to a passphrase when a key had been entered. I imagine that could leave the user wondering whether they had made a typo or the app had misinterpreted what they typed, which would not inspire confidence in it.
That is true, but what weakens my confidence is that the Element/Matrix team often doesn't present it that way. So much communication from them is about how it's amazing and great and the best messaging app in the world. If they presented it more like a typical slow-growth open source app I think they'd garner more goodwill. By setting high expectations they increase the likelihood of disappointment.
honestly it's the best thing ever they have done:
- I have heard of someone who failed to use Matrix, because he got frustrated of having not a secure enough passphrase
- people don't choose secure passphrases
- it provides options making things more complex (especially when guiding others)
- you know you won't memorize it, so you are more likely to put it down
2. Better yet, a "secure enough" passphrase could be generated by default, à la Correct Horse Battery Staple. A user wouldn't be forced to choose one.
3. When adding an option, interface complexity can be avoided by simply not showing it by default, or by placing it off to the side in collapsed state where it doesn't draw attention.
4. If you're worried about people writing down a passphrase, you should be even more worried about a string of 50 random characters.
That last one is important. Nobody is going to memorize a random key, which means everyone has to write it to a file (or painstakingly write it on paper) for long term storage. When verifying remote devices, they also have to get the key to the other devices, so they are likely to use copy/paste, which will put it on at least two devices' clipboards, where it will be available for harvesting by nosy apps/websites or accidental pasting to random ones. They also have to figure out a way to transport the key from one device's clipboard to another, which might be email or SMS or some other insecure channel that they're accustomed to using. Or in the unlikely event that they choose paper, they have to painstakingly transcribe it again at the other end.
In other words, forcing the use of a random key does not increase security vs. a well-implemented passphrase system, but instead pushes responsibility for security out of the software and into the hands of people who aren't trained in it. Inviting more big mistakes.
A passphrase would avoid most of those exposure risks by not having to be written down or copy/pasted or sent through insecure channels. And with the right UI, it wouldn't be more complex to use or less secure.
Fortunately, Matrix supports passphrase-derived keys at the protocol level, so client developers who understand how to implement them well for humans can still do so. I hope Element's product managers will come around eventually.
This has been in Element/Matrix since forever and I found it the easiest verification mechanism of all the encrypted messengers I've tried. I'm not surprised they're making this part of the standard process, but the wording in 2025 is... unfortunate. Or perhaps that adjective should be applied to the rest of the world since it's not the Matrix Foundation which changed. For the reader to decide ^^
For encrypted search on desktop it has to fetch batches of messages and this is configurable in settings. It just had a number? what is that? how large the batch is, how many ms? no clue! good thing we can’t do encrypted search on mobile/web.
I empathize a lot with the negative experiences shared in this thread.
I think the problem is that every little decision in Matrix might be reasonable to the people who have complete context about the decision, but all of the churn and rough edges have added up to a very bumpy ride. Not only that, but it has been a poorly communicated and documented ride as many in this comment section can attest.
I suspect all of these issues and changes feel like no problem to people who are active in Matrix every day and have a support network to chat with where they all get through the issues by sharing tips and info. For the rest of us who are casual users who only occasionally log in it feels like I’m rolling the dice every time I have to use it. Some times it works like it did last time, some times I have to go on a 30 minute adventure with Google and play games across devices to get it back into a working state again.
The guides are written for cryptographic infrastructure nerds and not regular normal users that have a habit of forgetting their own passwords after six months. Not to mention the fact that the Element UI tends to churn a lot.
I didn't even know that they deprecated creating new passphrases, and that's what I was telling my users to do!
Probably just bad UX to let people skip the verification step.
(This general flakiness of features just sometimes not working as they should is probably the main reason I haven't tried to recommend friends to switch to element)
one method of verification suffices (be it recovery key or using a different device)
if you use key backup
I think it's not the requirement itself that's the crucible of discussion but the issues are rather that the blog post should have explicitly defined what verification is in it's second sentence and that matrix/element still is barely useable even for reasonably technical users.
My entire family (including my elderly mother) would be very interested to learn how technical they are!
Clicking verify in any client does nothing. No popups in any other clients - doesn't ever seem to do anything. Sometimes Element will pop up a QR reader but there's no QR presented in the other clients. The UX around Matrix is a nightmare.
There has never been a better time to (re)embrace XMPP as your decentralized chat option. The clients are less buggy, handle missing features gracefully, & best part is, not being built on an eventual consistency model, you don’t have the constant syncing issue with delayed messages. If you wanted you could make an XMPP client in a day since the base spec is small/simple—& features like device verification would be seen as mandatory in the base specification.
I would like to replace Matrix at work with an XMPP server, but to convince my colleagues I would have to show something better than that :/
Open app with device management (e.g. Element Desktop) and remove the unverified devices you don't intend to verify.
Regarding XMPP: With the lack of Cross Signing, key backup and consistent storage of messages, it can't be expected to provide the convenience Matrix does for the foreseeable future - just my personal opinion. The matrix-rust-sdk should it also make easy to get started with a client.
So, last year i tried to play briefly with Prosody server to re-acquaint myself with xmpp...and it wasn't so bad. Not as great as i expected for this day ana age, bbut not terrible. The server setup felt like i needed to study a bunch of different docs...and ultimately was smoother than expected....so i think documentation is either outdated, or was written a little less clear than expected. That being said, the low resource usage was ridiculously pleasant compared to matrix homeserver! The fact that an xmpp server allows for such scalability on such low resources is a great testament! And, that was prosody, which some folks state is not even as performant, scalable as ejabbered....so they say...so wow, that's impressive if that's true. Regardless, xmpp servers that can run on such low resource hardware but enable so many users to chat...is quite awesome!!! The client side of xmpp was a different matter; i wasn't so happy. I blame myself because maybe there might have been plugins that maybe i didn't install correctly on server side, i don't know...but it felt not as easy as i expected. The clients were a little disappointing; again not terrible but not great.
Maybe i'm spoiled? Or, maybe i did too much wrong? But if that's the case, the maybe there's an opportunity for better documentaiton? I don't know....i really like both matrix and xmpp because both live in the realm of free and open source software.....so i really want both or either to succeed. I want to live in a world where we are not beholden to only proprietary options, like whatsapp, crappy sms/text messaging, etc. I want to give props to all the folks who made and maintain all aspects of xmpp...as much as i am whining, i don't want to take away from all the hard work that they have freely given; super props to them!!!
What i really want is a modern, free and open source version of IRC, with plenty of modern features (E2EE, file uploads, presence detection, etc.), decent desktop and mobile clients, easy server installation and management, and said server-side software would ideally not need such beefy hardware to run...Or, is my wish too far fetched?
Also independently, Movim keeps advancing and Libervia is doing a ton of cool work. I'm sure I am missing others.
This is what frees a barrier to decentralization & actually owning one’s data. A few of my friends are now running their own single-user or small XMPP servers since it doesn’t use much in terms of resources or storage in comparison.
> The server setup felt like i needed to study a bunch of different doc
I believe this is what the Snikket project is trying to be. That said, XMPP servers are used for a lot more than just chat which is why most of them don’t have good defaults for merely chatting with friends since that isn’t the only or a generic enough use case (XMPP is behind Zoom, Jitsi, Fortnite, etc.).
> The clients were a little disappointing; again not terrible but not great
True. But I appreciate that there are many options & most features gracefully fallback even on TUI clients (like ‘reactions’ just being a message reply with a single emoji). If Element adds a feature (like polls), the other clients, the new feature just doesn’t show up. For a web client, the NLNet funding is really giving a boost to Movim as a reasonable alternative to Discord that is self-hostable & federated so users—taking back the meaning of “join my server” to literally mean someone’s server & without needing to create another account just to join that server.
As for the wish… this is what XMPP MUCs are—IRC with niceties like moderation, optional encryption, & file uploads. You said yourself the resources for servers is small & for your stated use case, most existing clients can handle being IRC+features while also not being centralized unlike IRC.
Great point! I forgot that xmpp can/is used for other use cases that are not just chat.
Also I guess I should be a little more forgiving about the MUCs, and client features in particular because you are right that fallbacks tend to be graceful.
I suppose both points make sense!
also, instead of hosting your own server or using some (more or less well-financed) public servers, you can simply throw some money at [2] to pay for hosting for your group of friends or family or whatever. (not affiliated, but I like the idea)
[1] https://media.ccc.de/b/conferences/matrix-conf [2] https://etke.cc/
Riot.im/Element.io really knows how to shoot themselves in the foot.