Breaking the 100bps barrier with Matrix, meshsim and coap-proxy (2019)
matrix.org
matrix.org
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 :)
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.
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.
It really depends on what you value.
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 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.
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.
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.
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...
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”
I still use Element/Matrix because I like the mission but I have a Linux computer and an Android phone, so I use the clients that are available.
So we use Matrix briefly during the conference and then switch back to Discord.
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.
This is exactly my stance. Appreciate the bit of motivation to keep using Matrix for the conference!
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.
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.)
Today I use the F-Droid Element client and Element web client for all my chat needs and they just work for my needs. YMMV.
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.
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.
[send the audio]: https://maya.land/monologues/2021/08/05/matrix-bot-transcrib...
Blind amplification
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.