7 ms·

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.

ericjmorey 2y ago
I'd say that the protocol itself is what's doing Matrix in.
- alwayslikethis 2y ago
  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.
  - cmeacham98 2y ago
    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)
    - ptman 2y ago
      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.
    - Arathorn 2y ago
      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.
- isaacaggrey 2y ago
  Could you elaborate?
  - ranger_danger 2y ago
    https://0x0.st/H8h-.png https://0x0.st/H8h-.png
    - Groxx 2y ago
      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/# https://peps.python.org/pep-0000/#
      - jeroenhd 2y ago
        > Have you seen how many XMPP has? Or Python[1]? Python has had 664 PEPs in 23 years (29 per year). XMPP has received 495 XEPs in 23 years (22½ per year). Matrix has received about 650 in 8 years (>81 per year). Four times the change rate is quite annoying when writing code against the spec. Plus, most XMPP clients only support a fraction of the full spec, so by that comparison the impact of the rate of change is even worse. Furthermore, most XEPs and PEPs are mere (optional) extensions, whereas a lot of MSCs are alterations of existing APIs. Any JSON parser used for Matrix needs to anticipate fields changing or being added all over the place because you never know when random fields show up all over the input data because of a spec change. The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. The rate of change is high and almost all changes are done to serve new features for the two or three major players that bought into the Matrix ecosystem. One recent change that comes to mind is the move from secret, public URLs for media, to authenticated URLs. The setting to force that changeover won't apply everywhere for a while, but it'll completely break every media-supporting client written before the spec change. Nothing wrong with extending the spec to improve the product, but with how fast the protocol is growing, I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.
- Arathorn 2y ago
  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…
  - lifty 2y ago
    It's been a bumpy road but I think now Matrix has gotten to a good place. What's still missing is for the ecosystem to catch up a bit, both on the home server side and on the client side, and implement some of the new usability improvements brought by sliding sync and the rust sdk. Looking forward to see it happen!
heroprotagonist 2y ago
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.
paulcarroty 2y ago
cinny/fluffychat/iamb are the greatest.
itsthejb 2y ago
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
Arathorn 2y ago
Element X (https://element.io/blog/deep-dive-into-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.

ericjmorey 2y ago

I'd say that the protocol itself is what's doing Matrix in.

alwayslikethis 2y ago
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.
- cmeacham98 2y ago
  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)
  - ptman 2y ago
    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.
  - Arathorn 2y ago
    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.
isaacaggrey 2y ago
Could you elaborate?
- ranger_danger 2y ago
  https://0x0.st/H8h-.png https://0x0.st/H8h-.png
  - Groxx 2y ago
    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/# https://peps.python.org/pep-0000/#
    - jeroenhd 2y ago
      > Have you seen how many XMPP has? Or Python[1]? Python has had 664 PEPs in 23 years (29 per year). XMPP has received 495 XEPs in 23 years (22½ per year). Matrix has received about 650 in 8 years (>81 per year). Four times the change rate is quite annoying when writing code against the spec. Plus, most XMPP clients only support a fraction of the full spec, so by that comparison the impact of the rate of change is even worse. Furthermore, most XEPs and PEPs are mere (optional) extensions, whereas a lot of MSCs are alterations of existing APIs. Any JSON parser used for Matrix needs to anticipate fields changing or being added all over the place because you never know when random fields show up all over the input data because of a spec change. The way the Matrix spec is developed feels a lot more like a proprietary company spec that happens to be published on Github than the IETF/XMPP/Python spec process. The rate of change is high and almost all changes are done to serve new features for the two or three major players that bought into the Matrix ecosystem. One recent change that comes to mind is the move from secret, public URLs for media, to authenticated URLs. The setting to force that changeover won't apply everywhere for a while, but it'll completely break every media-supporting client written before the spec change. Nothing wrong with extending the spec to improve the product, but with how fast the protocol is growing, I wouldn't want to be tasked with maintaining a Matrix client and I don't have much faith in the forward compatibility of the few Matrix bots I've written either.
Arathorn 2y ago
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…
- lifty 2y ago
  It's been a bumpy road but I think now Matrix has gotten to a good place. What's still missing is for the ecosystem to catch up a bit, both on the home server side and on the client side, and implement some of the new usability improvements brought by sliding sync and the rust sdk. Looking forward to see it happen!

heroprotagonist 2y ago

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.

paulcarroty 2y ago

cinny/fluffychat/iamb are the greatest.

itsthejb 2y ago

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

Arathorn 2y ago

Element X (https://element.io/blog/deep-dive-into-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.