Disclaimer: I work on the project.

Matrix started out with its early DNA in focusing on the problem of how to create a decentralised e2ee multi-client messenger.

Getting that right took a lot of time and effort, which initially came at the expense of UX.

Elsewhere in the comments, it is clear that there are not many (any?) similar projects out there that solve the same problem, especially to the level of maturity where it is trusted by governments and civil institutions around the world.

So the effort was worth it, and we have the proof points to show that Matrix solves a real problem. Now we need to continue to work hard to create a UX that matches (perhaps exceeds?) the quality of the proprietary, centralised and non e2ee messaging apps that set the UX standards users have come to expect.

This needs to happen both at the protocol level and in the client and server implementations. For me personally, this means Synapse and the Element clients, but we have many quality implementations in the wild.

Matrix 2.0, mentioned above, is part of this initiative, though there is a lot of additional work in progress to both improve existing features (like Spaces and Threads) and add expected features, such as user status.

The post calls out running on Dendrite, which, as a project not under active development, contributes to some of the problems. However, I would not want that to be an excuse, because there is legitimate feedback in the post overall.

If someone reading this is new to the project and wants to host their own server, I'd recommend checking out [ESS Community](https://github.com/element-hq/ess-helm) - though other distributions exist.

Thanks everyone for flying Matrix and sharing your experiences (good and bad), we're getting there.

What you are writing may be true but what the article is about shows the exact opposite of "some form of technical elegance". This thing seems to be bug-ridden for feature areas off the mainstream usage path.

What helps against this are a rigorous design, testing, perhaps some formal methods sprinkled in (because distributed systems are really hard). That's what a tinkerer community could do that does not have an investor with strict timelines and profit requirements breathing down their neck. But the community apparently does not. At the least they should mark features as experimental that clearly have such fundamental issues.

Nope, just Matrix. Second best option is XMPP with various cobbled together XEPs but that has its own set of problems.

For all the (sometimes rightful) grief Matrix gets, it's essentially the only solution targeting hard problems like multi-device encrypted group chats[0] or truly federated multi-user chats. It can also be a very quickly moving ecosystem, which is difficult to handle when you're an open federated spec. Hence why several of the complaints in this post are caused by old and no longer supported clients and servers.

[0] Infamously, WhatsApp and LINE both support encrypted chats but all the encryption keys are stored on your phone, so you can only have one phone working at a time and desktop access is actually routed through it.

We (https://phnx.im/about) are building something new (https://air.ms). The website doesn’t yet mention self-hosting and federation, but we’d like to get there as well. Beyond that, our focus is on combining good UX with state-of-the-art security. It might not float everybody’s boat, but it should satisfy the list above.

We are in an early phase right now, where we test the product with a limited number of people, hence the invitation-only approach. We intend to drop that towards the end of the year if all goes well.

We helped co-author MLS, and we also contribute to the MIMI IETF working group. We’d like Air to be as standards-based as possible.

We are also curious to learn about specific problems that folks think have not been solved yet in the space.

You‘re describing Wire. One could quibble about the FOSS part but it is open source (gplv3 or agpl). It’s used by a bunch of European governments and agencies, as well as American agencies, has regular security reviews and thanks to MLS, supports groups with more than 2k clients. Self hosting is a bit of a pain, but people are doing it.

Give it a try

Maybe Delta Chat?

UX feels less polished yet snappier than Element-Matrix and the project seems pretty active.

https://delta.chat/

That’s Matrix. Matrix has spent too much time chasing Discord, with spaces, and group video chat, and email with federation. And too much time chasing Slack with threads. But everything you mentioned is core Matrix chat and works great on every client.

Chatto is what I am starting to lean into. Still early in development, but self-hosted version is available and the dev has been responsive and nice to chat to.

I'm sure you've tried or at least considered it, but you didn't explicitly mention it so: XMPP? The MUC extension has no problem with large groups (after a certain point you have to disable presence advertisement and reflections and whatnot, but that's way north of 100)

XMPP has several ways of doing e2ee, the most popular being OMEMO.

The challenge will be finding clients that supports OMEMO for MUCs (multi user chats) on each platform. They exist on desktop, at the very least.

XMPP

Email.

keet.io

Might be too P2P for your taste though.

Have you tried XMPP (with OMEMO)?

> Dendrite is kind of deprecated as a homeserver these days, at least it doesn't seem to be the main focus of development and most recent commits are mere dependency bumps. Years ago, when the server was set up, choosing Dendrite seemed like a good decision, because it was easier to deploy and maintain than Synapse and there was a promise for a bright future for the first 2nd generation homeserver implementation. Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.

Dendrite may or may not have been a good choice for a Matrix homeserver at the time the decision to start it was made, years ago. But the real problem, as the blog post points out, is that there is no good way to change that decision. Migrating to a new homeserver implementation is equivalent to destroying the old server and creating a new one from scratch - which also has the implication that any user whose account was on the old server loses that account and has to create a new one, because Matrix user accounts are tied to some homeserver (a bad design decision, I think). Tying system identity to someone else's server - and that server's domain name - is the cardinal sin of federated identity systems, the ActivityPub ecosystem has exactly the same problem.

This is addressed two paragraphs later:

> Years ago, when the server was set up, choosing Dendrite seemed like a good decision

> Unfortunately, migrating between Matrix homeserver implementations remains a problem with no satisfying solution, so we're kind of stuck on slowly rotting foundations.

Hi, could you describe the environment you're using it? Thank you

Element X does video calls fine. It's been ages since it was the messy beta you describe it as. In fact, it does calls better these days. There's no good reason to go with Element Classic anymore, I don't understand why they don't just drop the old thing.

All the other things are just as true if you replace "Matrix" and "Element" with "email" and "outlook"/"gmail".

If you don't think the person you're talking to understands the difference between apps and emails ("I can email outlook people from my gmail?" is a serious question these days), just don't mention it. They're not going to get into the weeds anyway.

When I tried to explain the different "servers" in Discord to some a-technical people I had the same problem and disabling invites + not bothering with explaining the server concept seems to work out a lot better. I've given up trying to explain computer things to people who don't want to understand how the things they rely on work.

Explaining to non-tech people that Matrix was email and Element was Gmail was easy to understand.

I usually recommend Element X on Android, FluffyChat if they complain too much about Element X after using it a bit, and nheko on desktop.

It is really annoying that Element X is missing so many things Element had (you can't even do /me messages, markdown headlines aren't shown properly either), but getting someone to move apps is pretty tough, so might as well get them on the new one that will hopefully get better with time.

Also I never tell people about voice or video in Matrix unless they ask, and if they do I tell them I don't use it, it's probably not great, and to just use Mumble for voice and Jitsi for video.

That's a strange conversation to have. Just compare it with email and they immediately get it

God, it reads like a slapstick comedy routine...

Element X does video chat just fine by now, doesn't it?

Element Desktop is the element desktop client (doesn't officially have sliding sync yet)

I find the bridge setup rather suboptimal, but with a complete lack of a good Pidgin alternative for the modern age, it's the best system around, whether you do it with Matrix or with XMPP.

I've hosted my own synapse since 2019, maybe even earlier. Its the same virtualized instance, all I've ever done is update it. Never had to reboot it other than due to updates.

Nothing in any logs?

as someone who wasn’t online in the IRC heydays i really wonder why we can’t just build on it, instead of inventing new protocols