[hashworks]

The official client is clunky and being electron on the desktop doesn't make it better. Messengers live and die on UX. Since it's an open protocol alternative clients exist of course, but are often not feature complete. Things are often slow, especially with large group channels with lots of messages.

If you host a server yourself - it's great that you can! - you'll try the official implementation, synapse — ...and discover that it's a resource hog. Things got a bit better with some streaming sync protocol or something like that, but last time I looked it up that was still experimental and the server is still a chonker. Again, alternative servers exist, again the problem with feature parity.

I feel like the protocol is bloated as well, but I didn't dive into it too much to have a good opinion on that.

When choosing a messenger, I go to Signal for security, to IRC for simplicity and to Telegram for UX. I never thought "Oh let's use Matrix"...

[doubled112]

Alternative clients feel like a broken promise to me, since features seem to be optional or implemented differently. You're basically stuck with Element if you want to be reasonably sure you're seeing what other people are.

Even the official clients are a little weird. Element X, their next gen super fast client released in 2023, still won't allow me to create a thread on iOS. It will let me put a caption on a photo though, but Element won't.

[ElijahLynn]

"Messengers live and die on UX" - THIS

[encom]

From time to time, I go and check if there's a stable non-Electron Matrix client available - Qt would be nice. Thus, I'm still on IRC. I've tried participating in some bridged Matrix channels, but the IRC bridges I've encountered were super annoying. All messages come from one user, the bridge. Very often, the same message gets repeated twice or more, for some reason. I guess Matrix has no limit on usernames, so some users have names that are more than a line long. It's all very tedious.

[WD-42]

The QT client for Matrix is called Nheko: https://nheko-reborn.github.io/ There's a client in just about every toolkit. Just takes a cursory internet search...

[cyphar]

Unfortunately, they still use libolm[1] for e2ee which is deprecated[2] and has known security issues[3]. The maintainers appear to not be interested in switching to the newer Rust-based library. Matrix argue that the timing channel attacks are not possible over a network, but the history of timing channel attacks argues that this very few protocols are this fortunate (most people thought timing attacks against TLS were impossible too, until someone bothered to attack them).

[1]: https://github.com/Nheko-Reborn/nheko/issues/1786 [2]: https://matrix.org/blog/2024/08/libolm-deprecation/ [3]: https://soatok.blog/2024/08/14/security-issues-in-matrixs-ol...

[BrenBarn]

Yeah, although Matrix is theoretically about being an open protocol supporting a range of clients and servers, in practice it winds up being heavily skewed to just Element/synapse. I think this is partly because there is still too much churn in the protocol. A decent amount of that churn is improving things, but it still makes it too hard for average-joe devs to keep up with what's hip. I don't think there's much chance of a real menu of feature-rich clients until the protocol becomes stable. Unfortunately, I don't foresee that happening soon.

[sneak]

AFAIK none of that churn is around functionality that actually matters that much to end users, however. Certainly nothing as important as “working clients”.

[Arathorn]

There's also a really great Gtk client called Fractal from GNOME; it uses the same matrix-rust-sdk as Element X: https://gitlab.gnome.org/World/fractal.

Meanwhile the plan for Aurora (Element X Web) is to run it in Tauri or similar to placate all the Electron-haters: https://github.com/element-hq/aurora

[rd07]

There is also Neochat from KDE, not fully featured like Element and E2E Encryption still experimental the last time I checked, but it is a nice alternative if you want a non-Electron client.

[mqus]

> synapse — ...and discover that it's a resource hog.

I thought that, too, but at the very least it probably grows with usage. On my single-user-server, synapse currently needs ~100MB of RAM and does not consume CPU at all. It's not "slim" but I wouldn't call it a resource hog either.