The lack of good clients is really holding Matrix back. Element is rather bloated, and most of the other clients are missing significant amounts of features.
Element X (https://element.io/blog/deep-dive-into-element-x) is intended to spell out how lightweight and unbloated an Element-style client can be. The only main missing features are threads and spaces which should land in the coming months.
What are you thinking of in particular? Fwiw, as project lead, i would be first to admit that there were slow bits - eg sync v2, which is why we built sliding sync… and crypto was easy to get wrong, hence shipping a highly polished implementation in matrix-rust-sdk. But what do you have in mind? Otherwise this doesn’t sound very wellfounded…
In order to support bridges to so many different proprietary platforms Matrix needs to have a superset of their features, so the feature creep is probably intentional. It does make it harder for clients to keep up though.
I _really_ wish that if Element has an update prompt for me almost every single time I open it, that it would just update during the startup sequence on its own.
Or at least have an option for it. Not a 'Oh you loaded, now click this button to load again please' prompt whenever I launch it.
Very very true. I self host synapse, and generally speaking the ability to bridge my ~3 most used messengers into one app (ElementX) adds value. However, the lacking features and bizarre feature disjoints between Element (supposedly EOL) and ElementX (suppose next gen) are jarring
There was a comment here complaining that Matrix is a failure as an open protocol because encryption in Matrix is too complex and hard and PFS is overrated and "why can't we have a simple protocol for chat like Wireguard is for VPNs"... but it got deleted while i as writing my reply. I'll post the reply anyway:
With encryption, inevitably things get way more complicated - especially in a decentralised network which needs to be byzantine fault tolerant. As you say, we've successfully simplified this by providing best-in-class implementations like matrix-rust-sdk-crypto - which i'd argue is the equivalent to Wireguard (which under the hood is a bunch of gnarly crypto, even if the API it exposes it simple).
In the end, encrypting messaging is just way harder than a VPN. The encryption hooks need to know the membership of the room (as users), the membership of the room (as devices), verify identities of all devices and their users to prevent MITM, verify that only the right devices can be added to the room, handle accessing history for new logins and new joiners, handle backing up history if you log out of all devices, handle receiving msgs if you log out of all devices, handle encrypted push notifs and allow multiple processes (push, share extension, etc) to share the same crypto state, scale to thousands of devices, etc etc.
Meanwhile if you simplify that by removing PFS - sure, some of it gets better ("the room history gets encrypted by a static password!") but then breaching that secret from any client at any point trivially leaks the whole history of the room.
In terms of "Matrix as an open protocol isn't very successful", i suggest taking a look at https://2024.matrix.org/watch/ for the zeitgeist from a few weeks ago. It's working for some folks at least.
The thing is, while we were all waiting for Matrix clients to handle Encryption several other encrypted messengers came out and seem to handle it just fine.
For example I've been using SimpleX in a group chat for a year now and had no issues at all.
I'd argue that SimpleX has probably learned from the path Matrix has been on... and so has Matrix. So you end up with multiple viable options to pick from, and to drive each other forwards; sounds like a good outcome to me.
me too. but like all the more scifi Matrix projects, the core team does not have the funds to work on it, so it's stuck in favour of foundational work. Others are welcome to pick it up and contribute it, or apply funding to the core team to let us work on it again: https://matrix.org/blog/2024/01/2024-roadmap-and-fundraiser/
I have notifications set up for anything Matrix/ XMPP on HN, and I very often see you in the comments. Some of the threads on here are really harsh and unnecessarily snarky, I don't know how you do it. You're doing great.
I deleted it as I was anticipating exactly such replies that just tell me all the ways in which I'm wrong and just make me feel dumb for voicing an opinion, and I realize I don't enjoy these kind of discussions anymore. It was up for like 3 minutes before I realized my mistake, sorry about deleting it I guess.
Don't take it too personally, they seem to be speaking from some automatic playbook.
I run indie conferences for a living [0]. From 2020 - 2023 we gave Matrix a serious shot: enough to risk losing audience members who found the UX unbearable. Then a third of my ticket holders threatened to leave if we kept using it. I was forced to drop it [1].
This year, I’m self-hosting Revolt, a lightweight Discord clone. Unlike Matrix my community's actually loving it. If Matrix leadership is reading this, take heed.
I've been setting up servers for everything ranging from IRC to Teamspeak, Exchange, and you name it. But how come setting up a Matrix server is still a science in itself?
Yes, I'm aware of the Ansible script, but should that really be the only somewhat reasonable option? When Matrix wrote " Matrix 2.0 a new chance if you gave up on us in the past".
I listened, but without a somewhat reasonable setup process for the server and the ongoing confusion in terms of clients, it hasn't gotten any easier to onboard to Matrix, unfortunately.
Self-hosting Conduit as my homeserver using SQLite as by database and Caddy as reverse proxy.
That is: 2 binaries (conduit + caddy) + 5 lines of toml config for Conduit and 2 line of config for Caddy + 1 database file. That's all you need for a basic homeserver.
I have to agree with you. Not having a proper, understandable documentation is part of what drives people away from Matrix, IMO.
And shoving the ansible script into people's faces is not a solution. I never used Ansible, and I won't start using it just because it's "easier" to setup Matrix with it, instead of setting it up by myself.
All services I self-host are quite easy to setup, Matrix so far has been a bit more difficult, but not that hard.
I’ve been wanting to write a Matrix client for a while now, but found myself too caught up in getting even an existing library to work: The Rust SDK, the most maintained and batteries-included SDK, doesn’t have JS bindings and the JS SDK is insufficiently documented and generally seems a bit crusty.
In general I find there to be a bit of a lack of guides on implementing Matrix, which is probability a factor in there not being that many implementations.
Would really really be nice to have the
-user management -> registering -> device management
A hello world example for v3 that will be great. To understand how to actually register a new account on the matrix server with Registration Token enabled server.
I tried to do something similar. It's infuriating how the client must be stateful and have local storage, for both the access_token and even last message recieved. That's right you must remember as the client where the last events [1] you've seen (even if you already told the server to mark it as read) was or else the server will happily send you the same messages over and over again.
I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).
At least that means that you will never have messages get dropped due to network issues, or even restarts if you persist the token across such. (the API will jump forwards if there are too many unsynced messages, but at least it should then be providing a "limited: true" so that one can paginate in the omitted events if so desired (or not if undesired))
Readit News
Or at least have an option for it. Not a 'Oh you loaded, now click this button to load again please' prompt whenever I launch it.
Matrix without encryption is as simple as it gets - e.g. here was a younger, happier me writing a working client in 8 lines of bash: https://news.ycombinator.com/item?id=20948530
With encryption, inevitably things get way more complicated - especially in a decentralised network which needs to be byzantine fault tolerant. As you say, we've successfully simplified this by providing best-in-class implementations like matrix-rust-sdk-crypto - which i'd argue is the equivalent to Wireguard (which under the hood is a bunch of gnarly crypto, even if the API it exposes it simple).
In the end, encrypting messaging is just way harder than a VPN. The encryption hooks need to know the membership of the room (as users), the membership of the room (as devices), verify identities of all devices and their users to prevent MITM, verify that only the right devices can be added to the room, handle accessing history for new logins and new joiners, handle backing up history if you log out of all devices, handle receiving msgs if you log out of all devices, handle encrypted push notifs and allow multiple processes (push, share extension, etc) to share the same crypto state, scale to thousands of devices, etc etc.
Meanwhile if you simplify that by removing PFS - sure, some of it gets better ("the room history gets encrypted by a static password!") but then breaching that secret from any client at any point trivially leaks the whole history of the room.
In terms of "Matrix as an open protocol isn't very successful", i suggest taking a look at https://2024.matrix.org/watch/ for the zeitgeist from a few weeks ago. It's working for some folks at least.
For example I've been using SimpleX in a group chat for a year now and had no issues at all.
Also, this blog post is still I'm hoping for to be realized sometimes soon: Breaking the 100bps barrier with Matrix, meshsim and coap-proxy (2019): https://matrix.org/blog/2019/03/12/breaking-the-100-bps-barr...
I hope you're okay.
I have notifications set up for anything Matrix/ XMPP on HN, and I very often see you in the comments. Some of the threads on here are really harsh and unnecessarily snarky, I don't know how you do it. You're doing great.
I run indie conferences for a living [0]. From 2020 - 2023 we gave Matrix a serious shot: enough to risk losing audience members who found the UX unbearable. Then a third of my ticket holders threatened to leave if we kept using it. I was forced to drop it [1].
This year, I’m self-hosting Revolt, a lightweight Discord clone. Unlike Matrix my community's actually loving it. If Matrix leadership is reading this, take heed.
[0] https://handmadecities.com
[1] https://handmadecities.com/news/new-discord-server/
Yes, I'm aware of the Ansible script, but should that really be the only somewhat reasonable option? When Matrix wrote " Matrix 2.0 a new chance if you gave up on us in the past".
I listened, but without a somewhat reasonable setup process for the server and the ongoing confusion in terms of clients, it hasn't gotten any easier to onboard to Matrix, unfortunately.
That is: 2 binaries (conduit + caddy) + 5 lines of toml config for Conduit and 2 line of config for Caddy + 1 database file. That's all you need for a basic homeserver.
And shoving the ansible script into people's faces is not a solution. I never used Ansible, and I won't start using it just because it's "easier" to setup Matrix with it, instead of setting it up by myself.
All services I self-host are quite easy to setup, Matrix so far has been a bit more difficult, but not that hard.
I’ve been wanting to write a Matrix client for a while now, but found myself too caught up in getting even an existing library to work: The Rust SDK, the most maintained and batteries-included SDK, doesn’t have JS bindings and the JS SDK is insufficiently documented and generally seems a bit crusty.
In general I find there to be a bit of a lack of guides on implementing Matrix, which is probability a factor in there not being that many implementations.
A hello world example for v3 that will be great. To understand how to actually register a new account on the matrix server with Registration Token enabled server.
Deleted Comment
I kind of miss making IRC bots where things were much simpler and ... quicker honestly (latency wise).
[1] https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w...
Deleted Comment