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.
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
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.
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.
Matrix is the opposite of feature creep - there are several features entirely missing from major clients that users of modern chat apps expect to have.
(Examples include: custom emoji, functional search of encrypted chats, pinned messages or some sort of MOTD, forwarding messages, etc)
The matrix developers are experienced IM developers. They've built systems on XMPP and custom protocols before. Their estimate was that because of matrix being federated, every feature was 5-10x harder to implement than in centralized systems.
There are some hilariously ugly things for even trivial things like editing/replies:
Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_content": {...}`, containing the plain-text and HTML versions of the message (while also keeping a copy of both, typically with a prepended "*", outside "m.new_content", for backwards compatibility; yes, that's 4 (four) copies of the message text in an edit; for some while Element generated up to 10 (ten) copies IIRC, due to some proposed extension(s), but that seems to be gone thankfully).
Reply messages get `"m.relates_to": {"m.in_reply_to": {"event_id": ...}}` - an annoyingly different format from the edits. It might look like that that allows an edit to change which message is being replied to, but nope, last I checked, that's not supported. Oh and for backwards compatibility a <mx-reply> HTML element is to be prepended, containing a copy of the replied-to message and its info (and yes, that means that the replied-to message effectively can't be deleted as the reply will still contain its text; luckily clients can choose to do not generate such <mx-reply>, but Element still does). And if you want to actually get proper reliable info about the replied-to event, you have to just make an API request for every single one you want to display (unless you happen to already have a cached copy, which luckily for replies is reasonably common).
And then there's threads - again in the name of crappy backwards-compatibility there's a mess - within-thread replies imitate a reply to the last in-thread message, along with `"m.relates_to": {"event_id": ..., "rel_type": "m.thread", "is_falling_back": true, ...}`, that "is_falling_back" indicating that this isn't actually a reply (being false when you want an actual reply). And clients are "supposed" to also handle replies to in-thread messages without the "m.thread" relation (which'd come from clients not supporting threads), but as far as I can tell there's no way do to it while paginating without making an API request per every single message (and yes Element behaves quite buggily here).
And then there are some things that can't be reasonably handled - the context/message listing/pagination APIs don't give any reaction info (besides the reaction events themselves in chronological position of their addition), so reaction presence/counts in history view must be calculated by clients, and thus won't be able to show ones that were posted a while after the messages. (there used to be some aggregation provided, but it's since been removed!!!) I think the only way to do this properly is truly just making an API request of "list reactions" for every single message the client wants to show.
This may make it seem like Matrix has an extremely firm stance on backwards-compatibility, but nope - recently they deprecated & made non-functional the unauthenticated API retrieval of media, making it impossible for clients not supporting video/audio/image display to just open those in the browser, instead forcing them to have custom file downloading & saving code, and also making it impossible to link to media within a message. There was a window of 6 (or less?) months between the new API being finalized, and the old one being removed.
Many of these problems stem from the fact that matrix is federated. And it's a protocol, not really even for messaging but for a federated graph database. In federation some messages may be missing and arrive out-of-order. And different clients have different capabilities. There's a really simple example client implemented in a couple of lines of bash.
No, most of those are just plain and simple bad decisions due to not having thought out extremely basic things ahead-of-time.
Replies to threads from thread-unsupporting clients are the one potentially-hard thing federation-wise, as doing it properly would require the server to trace back the reply and from that handling it as in the thread, but that's not far from what servers already have to do with edits. Or you could also just not require/suggest that behavior, having replies without thread metadata always be outside of threads; would probably save on confusion too, as the illusion would break anyway when someone on a client without thread support would not do a reply on some message after having used replies on others.
There might be some graph core to it, but it's still primarily a messaging service. Opening the client spec will show you tons of messaging-specific APIs.
I utterly disagree that saving a half-dozen lines in largely-useless toy clients is worth making more feature-complete clients more complex, and doubling the size of every edit event.
All that really shows is "the project has an active community". Have you seen how many XMPP has? Or Python[1]? This is just normal open development metadata.
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))
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.
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
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.
I'd say that the protocol itself is what's doing Matrix in.
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.
Matrix is the opposite of feature creep - there are several features entirely missing from major clients that users of modern chat apps expect to have.
(Examples include: custom emoji, functional search of encrypted chats, pinned messages or some sort of MOTD, forwarding messages, etc)
As a protocol, Matrix has all of these features (custom emoji is a proposal, but many clients implement it).
As a client, Element has all of these (encrypted search only on Desktop for now) other than custom emoji.
The matrix developers are experienced IM developers. They've built systems on XMPP and custom protocols before. Their estimate was that because of matrix being federated, every feature was 5-10x harder to implement than in centralized systems.
Could you elaborate?
There are some hilariously ugly things for even trivial things like editing/replies:
Edits get a `"m.relates_to": {"event_id": ..., "rel_type": "m.replace"}` field in the body, and `"m.new_content": {...}`, containing the plain-text and HTML versions of the message (while also keeping a copy of both, typically with a prepended "*", outside "m.new_content", for backwards compatibility; yes, that's 4 (four) copies of the message text in an edit; for some while Element generated up to 10 (ten) copies IIRC, due to some proposed extension(s), but that seems to be gone thankfully).
Reply messages get `"m.relates_to": {"m.in_reply_to": {"event_id": ...}}` - an annoyingly different format from the edits. It might look like that that allows an edit to change which message is being replied to, but nope, last I checked, that's not supported. Oh and for backwards compatibility a <mx-reply> HTML element is to be prepended, containing a copy of the replied-to message and its info (and yes, that means that the replied-to message effectively can't be deleted as the reply will still contain its text; luckily clients can choose to do not generate such <mx-reply>, but Element still does). And if you want to actually get proper reliable info about the replied-to event, you have to just make an API request for every single one you want to display (unless you happen to already have a cached copy, which luckily for replies is reasonably common).
And then there's threads - again in the name of crappy backwards-compatibility there's a mess - within-thread replies imitate a reply to the last in-thread message, along with `"m.relates_to": {"event_id": ..., "rel_type": "m.thread", "is_falling_back": true, ...}`, that "is_falling_back" indicating that this isn't actually a reply (being false when you want an actual reply). And clients are "supposed" to also handle replies to in-thread messages without the "m.thread" relation (which'd come from clients not supporting threads), but as far as I can tell there's no way do to it while paginating without making an API request per every single message (and yes Element behaves quite buggily here).
And then there are some things that can't be reasonably handled - the context/message listing/pagination APIs don't give any reaction info (besides the reaction events themselves in chronological position of their addition), so reaction presence/counts in history view must be calculated by clients, and thus won't be able to show ones that were posted a while after the messages. (there used to be some aggregation provided, but it's since been removed!!!) I think the only way to do this properly is truly just making an API request of "list reactions" for every single message the client wants to show.
This may make it seem like Matrix has an extremely firm stance on backwards-compatibility, but nope - recently they deprecated & made non-functional the unauthenticated API retrieval of media, making it impossible for clients not supporting video/audio/image display to just open those in the browser, instead forcing them to have custom file downloading & saving code, and also making it impossible to link to media within a message. There was a window of 6 (or less?) months between the new API being finalized, and the old one being removed.
Many of these problems stem from the fact that matrix is federated. And it's a protocol, not really even for messaging but for a federated graph database. In federation some messages may be missing and arrive out-of-order. And different clients have different capabilities. There's a really simple example client implemented in a couple of lines of bash.
No, most of those are just plain and simple bad decisions due to not having thought out extremely basic things ahead-of-time.
Replies to threads from thread-unsupporting clients are the one potentially-hard thing federation-wise, as doing it properly would require the server to trace back the reply and from that handling it as in the thread, but that's not far from what servers already have to do with edits. Or you could also just not require/suggest that behavior, having replies without thread metadata always be outside of threads; would probably save on confusion too, as the illusion would break anyway when someone on a client without thread support would not do a reply on some message after having used replies on others.
There might be some graph core to it, but it's still primarily a messaging service. Opening the client spec will show you tons of messaging-specific APIs.
I utterly disagree that saving a half-dozen lines in largely-useless toy clients is worth making more feature-complete clients more complex, and doubling the size of every edit event.
https://0x0.st/H8h-.png
All that really shows is "the project has an active community". Have you seen how many XMPP has? Or Python[1]? This is just normal open development metadata.
[1]: https://peps.python.org/pep-0000/#
cinny/fluffychat/iamb are the greatest.
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).
[1] https://uhoreg.gitlab.io/matrix-tutorial/sync.html#:~:text=w...
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))
Finally something besides the matrix foundation's "lol the auto-generated API docs are enough" nonsense. This really helps a whole lot better.