This work has progressed a lot since 2019, although the blog post here describes the original spurt of work on it. Nowadays Matrix has MSC3079 to formally spec low bandwidth transports: https://matrix.org/blog/2021/06/10/low-bandwidth-matrix-an-i... and we’ll be building it into clients & servers by default in future.
The final major unsolved problem is that the sync API doesn’t support pagination yet, so on a big account you can end up burning bandwidth (and cpu) syncing data for rooms or room members that the client doesn’t care about. This is the final piece of the puzzle, and the lowbandwidth team is working on it right now - and will probably be the most exciting and fundamental improvement in Matrix in years :)
It's fascinating to see so much fundamental work taken on by the team at matrix.
One thing I still can't understand though, as a matrix user, I try to get on my circle onto it. But instead of hearing praises for the technological superiority of the network, all I get is hate and quick dump of its use.
I wondered why. And then realise their claim is justified. The market is dominated by centralised pseudo e2e encrypted services. And people stick to them for two reasons, network effect and the fact it just works. The official client is plagued with UX bugs. Push notifications works some of the time, sometimes the app would hang trying to open or access a channel, some message get stuck as the last entry with no means to delete them. It makes the network barely usable since clients can't keep up with whatever is going on at the network level.
I think technological advances shouldn't be made at the expense of the UX. Today's problem with matrix is adoption, and the slow adoption rate isn't due to not breaking the 100byte barrier.
People would greatly benefit in getting an alternative car engine that doesn't burn polluting fuel, and matrix is delivering a propulsion engine to send us to Mars, at zero cost to consumers.
I still admire the project and its contributors, I just wish those hundreds of real issues on each of their github projects were being prioritised over cutting edge innovation.
Agree. As a pretty knowledgeable tech person, I tried a few days ago to get an account working with Element, and I almost failed entirely. Different logins failing to sync with each other, one login which claimed that it could not verify ITSELF as a valid login, the "emoji check" button doing quite simply nothing at all. And on top of all that, the security aspects of Matrix are sufficiently non-obvious that even I am not confident that I have things set up securely, what the relevant trade-offs are (if any), and what security model the default setup is using.
It's shocking but 100% true that I feel more confident in my ability to communicate securely with someone using GPG than with Matrix at present.
> I think technological advances shouldn't be made at the expense of the UX.
Disagree. Every other service out there, including Signal (especially Signal) has focused on getting UX right and making it easy to use. Matrix is trying to solve a hard problem with decentralized communication, and we need someone out there trying to solve that problem. They've deliberately set themselves up for UX difficulties by refusing to compromise on features. It would be a problem if everyone did that, but not everyone is doing that - Matrix is more or less going it alone. Matrix is best understood as an experiment; maybe it will work, maybe not. I think we just have to wait and see - though I agree with you that it's not usable yet for the general public.
I really wish I understood comments like these as what you describe is just not my experience at all in over a year.
My partner, entire social circle, etc and I all communicate via matrix, via a mix of clients ranging from Element to Weechat to Fluffychat across a number of different servers for both personal and business.
I have helped migrate hundreds of people to matrix and in the last year or so I have not had to hand hold people anymore as UX has improved dramatically. They just go sign up and drop in just like they would with Signal or WhatsApp or any other messenger.
I also admin a number of rooms with hundreds of people and everything just works.
Personally Matrix and IRC (often also via Matrix) are all I use for messaging.
I login with a new device, have an existing device verify me when prompted, then type messages in boxes to people and people see them, with end to end encryption that works. For conversations that require high trust I additionally do key verification.
I do encounter minor bugs from time to time like stuck messages, or occasional slowdowns of the giant primary matrix.org server, but honestly I have found it dramatically more reliable than SMS for me, but with actual E2EE.
We really need the internet to be open and decentralized and that happens with technical people going all in on efforts like Matrix and helping report any bugs found and get then fixed.
Element -was- for sure as buggy as you describe in my experience for many in my circle a couple years ago but even then we were happy to accept occasional glitches than continue to build our social graph in walled garden ecosystems that don't care about censorship resistance, security, or privacy.
> They just go sign up and drop in just like they would with Signal or WhatsApp or any other messenger.
Are they actually verifying each of their devices and getting full end-to-end encryption across all their devices with each of their one-to-one conversants? I will grant you that if you don't care about encryption at all there aren't that many issues to worry about.
If not, well, to each their own? I can't deny that you personally and a bunch of people you know use Matrix without any problems. You can't deny that I (and many, many other people) have encountered these problems. So the bugs are out there, but may not affect everyone.
I'd be rather shocked if no one you know has encountered problems with the emoji-based verification thing. I have experimentally used Matrix on and off for maybe five years now. It has never (no not even once) simply worked for me when setting up a new device / reverifying an old device. I click the button and nothing happens. I click it a few more times, nothing happens. Sometimes, 15 minutes later, I'll get a popup about it on another device, but by then I will have given up and clicked out of the modal on the original device. It's just been insanely broken in my experience.
I value what matrix is providing. Thus I continue to use it despite what could call minor issues that other mainstream messengers aren't experiencing.
I think the question is what is most important. Adoption or those principles. Here the article is about yet another break through the matrix team is accomplishing. Great. And they should not shy away from that, but given what they already accomplished ,in providing a true e2e decentralised messaging system, they should focus more resources they have towards making it work properly. I'm not talking about adding mainstream features such as voice messages. Just getting the core feature reliably working. Notifications issues and the client freezing at startup until reinstalling the app is something more than one users I know , including myself have faced. Such a great project deserve to be perceived as reliable. And unfortunately it doesn't, other than for the geeks we are who understand what's behind the scene and what's continously brewing.
It isn't an attack on the team, just voicing how the lambda users perceive the app, and how it's holding many to get their circles of connection onto it so that the wall gardens can be entirely avoided.
> The official client is plagued with UX bugs. Push notifications works some of the time, sometimes the app would hang trying to open or access a channel, some message get stuck as the last entry with no means to delete them. It makes the network barely usable since clients can't keep up with whatever is going on at the network level.
Speaking as the project lead, one of the controversial decisions we made with Matrix was to try to seed the ecosystem with effectively three entirely independent clients. Element Web, iOS and Android share zero code (other than the low-level E2EE library). The reason we did this was to dogfood the protocol, avoid a client monoculture, ensure that multiple independent clients would work well together, and also provide native SDKs for the three main platforms that others could build on or fork.
This strategy worked to some extent... but the major downside has been that it's more than tripled the dev efforts on the clients (relative to doing PWAs or React Native or Flutter or whatever), and each client has ended up with a completely different set of problems and bugs. For instance, the things you've complained about above all sound specific to Element Android (other than slow room joins, which is a serverside issue that we're working on right now: https://www.youtube.com/watch?v=z7tGU6vv6ZQ). It's rather sad to dismiss Matrix (or even Element) as a whole due to bugs on one specific app on one specific platform.
We've also ended up being massively distracted by building out the non-optional fundamental work such as E2EE and the core decentralisation bits of Matrix (as well as stuff like low bandwidth, which has been driven by paying customers who care less about UX and more about capabilities). This has in turn ended up undermanning the core app teams fairly catastrophically. Until this week there was effectively only one guy paid to work fulltime specifically on the core app for Element Android - and it's only been in the last few months that we've been able to put more than one person on Element iOS and Element Web. Everything else has been stuff which has indirectly landed via customer projects for people like the French govt or German Bundeswehr, or FOSS contributions.
So, the good news is that this is being fixed (better late than never) - there are ~5 people working on improving core UX in Element Web right now, ~3 on iOS and 2 on Android. The improvements on iOS & Web over the last few months should be really quite palpable - e.g. all the stuff on https://element.io/blog/introducing-voice-messages-and-so-mu.... Android should be starting to catch up quick too.
Meanwhile, if anyone likes Matrix and wants to help us improve the clients, we're frantically trying to bring on more people to work on it fulltime to fix this faster - see https://element.io/careers for details.
Please don't take my comment as dismissing the platform. The team behind the network, and the apps have done a phenomenal work. And I still use the occasionally buggy clients on a daily basis, and I pull as many people I know as I can to use Element.
My comment was on the fact that the UX is what always fires back at it, most if not all peers I've introduced the app to have told me they don't like it because it doesn't work reliably. I keep telling them that's the cost of using a truely open and secure messenger.
Thanks for pointing out the new focus on the UX aspects, and yes your approach of 3 separate code base is an ambitious endeavor. But I also think it was the right call to make. The Web client is the best messenger client I have ever used. And each mobile client are an absolute delight in term of near native feel.
Aren't android and desktop clients using Electron? So I assume at least Web+Android+Desktop (or maybe + iOS) should share lots of code?
Also, may I ask whether you considered Qt or why you dismissed it? As an example, I think Telegram's UX is so ahead of the competition...so if it were me, I'd have simply forked Telegram...
Android is not using Electron; it’s a completely separate codebase to the web app (hence the complaints about it in this thread which don’t apply to Web or Desktop). On the other hand, Web and Desktop is basically the same app.
We dismissed Qt because it’s bad enough managing 3 separate apps without adding a 4th one too.
Telegram’s UI is great, but it’s also tightly coupled to Telegram’s backend, which is not Matrix. It’s like saying “Word is a great word processor; I don’t understand why you can’t edit PDFs with it”
Thank you for writing this because I'm using Matrix for my engineering conference [0] and I believe in the project. However, no one in our online community (4k members) is willing to switch for good. Virtually no one likes the client's UX at all -- they see it as strictly a downgrade.
So we use Matrix briefly during the conference and then switch back to Discord.
Matrix is a massive upgrade from Discord, and I applaud you for trying to offer people healthy alternatives.
Humans love easy button tasty junk food that put "flavor" or "UX" above all else with no regard for long term consequences. Sometimes those of us that are decision makers have to put responsible healthy options on the table for everyone's benefit even if they don't care about the benefits and also in order to avoid excluding people with higher standards for themselves.
I for one don't accept the terms of service for centralized proprietary chat services like Discord, Slack, etc, and I have stopped attending or participating in communities and conferences that insist on them without at least an IRC or Matrix bridge option. I don't find it ethical to force people to accept privacy and freedom hostile terms of service in order to socialize. It is gross that has become normalized. I hope we look back on these times like when we allowing smoking everywhere in most US restaurants.
Some things matter more than having the absolute best in industry UX. Freedom, privacy, and security are not optional. I would go back to AIM UX before I would give those up. Thankfully Element and other matrix clients have dramatically better UX than that, and with federation, E2EE, message editing, etc.
It is a downgrade from Discord, but from Facebook Messenger, WhatsApp, Google Hangouts and the pile of shit that is Skype it is an upgrade. Element is a bit buggy (just like Skype and Hangouts) but otherwise it is a pretty good client compared to its competitors.
Not just UX.. one day Element just wouldn't connect anymore (and in a typical webapp fashion, no useful error messages). Nuking its config directory and starting from scratch fixed it (never needed to do that in 20 years of using irssi).
I've seen other issues like video previews getting their bottom half completely crippled. Can't make a video call just sharing the desktop with someone -- it demands a microphone. Can't disable read markers that are broadcast to everyone (bad for privacy imo). They were working on this when I looked into it but I've no idea if they've fixed it yet.
And yes I've seen UX bugs such as some UI setting getting stuck in a state when you try to toggle it in the settings.
I'm guessing these are more Element issues rather than Matrix issues (except for the read markers). But I get the vibe that we won't be seeing a client I like anytime soon; or it'll be a very minimalistic client with no support for all the fancy modern features, in which case I'd likely get the same or better experience with IRC anyway.
> But I get the vibe that we won't be seeing a client I like anytime soon; or it'll be a very minimalistic client with no support for all the fancy modern features, in which case I'd likely get the same or better experience with IRC anyway.
I don't know if you're the Emacs type, but you might be interested in https://github.com/alphapapa/ement.el. It feels kind of like an upgraded IRC, with support for features like images and rich text, and it tries to be privacy-respecting (e.g. read receipts and typing notifications are enabled by default, to imitate Element, but optional).
It doesn't support E2EE natively, but E2EE works through the Pantalaimon proxy, so it can be used with E2EE rooms that way. (Or if you don't care about E2EE rooms, like me (I mostly don't), you can use it in unencrypted rooms without using Pantalaimon.)
I don't know why people just keep comparing the core protocol to the client. They can both be developed independently, in fact, you don't even need to use the official client, there are many open source alternatives.
If you think something is broken, you are free to contribute to a patch, the project is open source.
It's change-your-distro/DE all over again. Each one of them has their unique pluses and oddities.
> you are free to contribute to a patch
Hi, average joe! You know, you should be using Matrix so your chat logs are not sliced and diced by corpos for profiling, right?...ahh what's that? You can't jump to your last mention? Just file a bug report in GitHub issue tracker bro. PR welcome.
The competition is fierce. It's really sad so many FOSS projects have moved to Discord. I hope Matrix win.
As an admin and end user, I'm gonna tell you that the most exciting improvement was voice messages, which I am so happy to have again and definitely didn't get as much attention as they deserved. Wish I could buy y'all a beer. I made a bot [send the audio] to a speech-to-text API so I've got the feature I really missed from Google Allo.
The lower-level work is real interesting, but I hope people in this thread are also aware that the user experience is improving a lot all the time because y'all are working on features like that too.
This is awesome. Hope this will be adopted eventually for their P2P project - would do wonders over slow mesh networks, additionally to stuff like Tor.
I'm sorry if I miss it, but no protocol in this millennium should be without mitigation for denial of service. DJB's curveprotect uses fixed sized packages (refusing small ones) to kill amplification attacks. I wonder if they considered such issues.
iirc curveprotect is effectively a replacement for TCP which uses EC crypto to encrypt each packet individually, and protects against DoS by each packet being cryptographically authenticated. Ultra low bandwidth Matrix does the same thing but using Noise instead.
Some protocols allow attackers anywhere on the Internet to generate a packet that will trigger a much larger outgoing packet from the server to a victim address selected by the attacker. The issue here isn't the availability of that protocol; the issue is that the protocol is amplifying the attacker's resources, damaging availability for the rest of the Internet. The worst offender at the moment is DNSSEC, which has set up a remote-controlled machine-gun pool containing more than 2000 servers with amplification factors between 30 and 95 and with an overall outgoing attack capacity estimated to be close to 50 gigabits per second.
With CurveCP, the first incoming packet from the client is padded so that it is as large as the outgoing packet from the server. If this padding is missing, the server won't respond. Subsequent packets from the client need to repeat server cookies and can't be generated blindly.
Right, understood - it’s the same reason that QUIC pads incoming packets to MTU. We deliberately don’t do this on ultra-low-bandwidth Matrix (as described in the original post) to save bits, so you would typically use it on a private network. For low-bandwidth matrix we use DTLS rather than Noise, which gets this right.
The final major unsolved problem is that the sync API doesn’t support pagination yet, so on a big account you can end up burning bandwidth (and cpu) syncing data for rooms or room members that the client doesn’t care about. This is the final piece of the puzzle, and the lowbandwidth team is working on it right now - and will probably be the most exciting and fundamental improvement in Matrix in years :)