[iqihs]

I think Matrix as a protocol has been pretty ineffective, as their top priority seems to be keeping data permanent and duplicated. Both performance and privacy are at the bottom of their priority list. The one good thing I can say about it is that encryption of message contents is enabled by default in conversations and available in groups, but that's about it - nothing else is, or can be, encrypted. In other words, every participating server knows who is talking to who, and how much, and when, and in what rooms, and what those rooms' names are, and what those rooms' descriptions are, and who moderates them, etc.

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?

[xethos]

@Arathorn would be an objectively better person to discuss this, but the Redditor isn't completely off the mark: metadata is (currently) not nearly as well-guarded on Matrix compared to Signal.

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.

[tptacek]

Matrix and Signal have very different objectives. Matrix wants to be an encrypted IRC or Slack. Signal wants to be a secure messenger you can entrust your life to. They are both worthy projects; there's not as much overlap as people think.

[pkulak]

I trust my life to the server I host in my own closet. People can lecture me all day long about the superiority of Signal's encryption, and I'll just slowly rotate my chair to point my index finger at the Dell OptiPlex behind me.

[tptacek]

That's fine. You'll pardon me if I'm unwilling to trust my own safety to your Dell OptiPlex. Whatever you think about Signal, the fact is that Matrix --- which is what the thread is about --- makes decisions that serve the IRC/Slack use case at the expense of the "absolute most possible safety" use case. That makes sense: some of larger-scale group chat's goals are in tension with "absolute most possible safety".

[dwohnitmok]

I wouldn't characterize Signal as "absolute most possible safety" as you are implicitly doing here.

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.

[tptacek]

I couldn't be less interested in arguing with you about Signal. My point is that it doesn't make as much sense to compare Signal and Matrix as people think it does. Large-scale group chat is intrinsically less safe than the kind of chats most people use Signal for. You can substitute whichever other secure messenger you prefer.

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.

[Forgeties79]

This is basically the same logic for why I often recommend Plex over jellyfin to people. Yes Plex is not proper self hosting. Yes Plex the org is making increasingly questionable decisions. But for people who want to get away from the major streaming services and maybe even want to dip their toes into something that resembles self hosting, there really is no other option like Plex. It’s so insanely turnkey and easy to install on every device. You also don’t have to worry about exposing your network if you don’t know what you’re doing.

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.

[NegativeK]

I obviously can't speak for you, but there's not a freaking chance I'd trust my life to the servers I run.

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.

[pkulak]

Well, when US-EAST-1 went down, my family was still chatting. Same with Cloudflare. Even if I lose internet, we can all chat so long as we’re on the network.

That said, the uptime is still probably worse than Signal. I didn’t mean trust the reliability. I meant the security.

[kiitos]

> Matrix wants to be an encrypted IRC or Slack

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

[tptacek]

Hey, I've been there!

https://web.archive.org/web/19991128144800/http://sonicity.c...

https://web.archive.org/web/20010223171430/http://www.sonici...

[Arathorn]

speaking as Matrix’s lead maintainer: we are focused on it powering decentralised and encrypted whatsapp (or teams) alternatives.

unsure what makes you think we want to build a next-gen tcp/ip, but can I have some?

[butvacuum]

When you leak that much metadata, it's disenginious to call it encrypted.

[Gigachad]

In the real world friends and family aren’t running their own matrix servers. At most they are signed up for whatever random one came up first in the search results.

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.

[Klaus23]

It's pretty accurate. I was a bit shocked when I saw that room names were not encrypted. I thought that was such a basic privacy requirement, and it's not hard to implement when you already have message encryption.

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.

[jeroenhd]

The decryption problems I've experienced have a been fixed a while ago. There was a push to fix these last year or the year before that, and at this point I'm pretty sure only some outdated or obscure clients with old encryption liberties still suffer from these problems.

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.

[Klaus23]

Yes, messaging protocols, especially federated ones, are never easy. I just wish we could have skipped the three or four years when Matrix was basically unusable for the average user because end-to-end encryption was switched on by default. Perhaps a clean redesign would have been better. Now they have to change the wheels on a moving car.

[tcfhgj]

> 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.

This is wrong, because afaik these errors happen due to corner cases and I really don't like the attitude here.

[Klaus23]

It's not just a corner case. The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.

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.

[tcfhgj]

> The issue was so prevalent for years that if it was limited to just a few corner cases, the entire protocol must consist of nothing but corner cases.

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.

[Klaus23]

> 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.

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.

[tcfhgj]

Correct link: https://www.youtube.com/watch?v=FHzh2Y7BABQ

> I wasn't that impressed.

If you think, I want to impress you, you are wrong.

[the_gipsy]

To be fair: signal means everybody trusts one central authority. Doesn't matter that it's a foundation or non-profit or whatever.

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.

[this_user]

I think part of the problem may be that Matrix is just pretty complex, because of its modular and decentralised design. Meanwhile, Signal is much more centralised and monolithic. And while they have added a few features over the years, its core functionality is relatively simple, and they were initially just focussed on getting that right.

[AJ007]

The "decentralization" of Matrix is true in some respects, and false in others. Which would be ok, but if all of the complex architecture and issues are in the support of being decentralized, then this seems like an early planning failure.

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.

[Gigachad]

I remember reading some of the pdf on state management in matrix. The math and logic behind working out what the current name of the group chat is made my head spin.

[kachapopopow]

it's pretty on point, it's mostly a "trusted" platform as long as you trust the host with the messages between two people (or more?) being (optionally) encrypted.

[RicoElectrico]

I wish FOSS communities that want an alternative to Discord or Slack ditched Matrix altogeter. It sucks for that. Better use Zulip or Mattermost, both of which are self-hostable.

Edit: I looked up and apparently Mattermost would be out of the question for their feature downgrades in the community version as of late...

[broken-kebab]

Correct me if I'm wrong but I believe Zulip's licensing de facto restrict self-hosting solution for 10 users (others won't see notifications on their mobiles or something like that). This is important for non-commercial communities.

[tabbott]

No. See the "Sponsorship and discounts" section on the pricing page, which makes clear the 10 users limit for free usage of the mobile notifications service is for workplace use, not communities.

[jrm4]

Okay so -- this and Bluesky.

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.

[sroerick]

Pretty crazy, right? It almost seems like a honeypot