[tptacek]

The story of the Matrix project is about the closest thing you could find to a total vindication of Moxie's original take about federation. Federation delayed the convergence of Matrix to E2E-by-default by (as I recall?†) years, and will drastically complicate their response to the Nebuchadnezzar results, which were themselves in part a complication of decentralization and loose coupling.

You can coherently argue that decentralization is an important, or even necessary, goal for private communications. I won't agree, but I can productively hear that argument out. But I don't think you can cite Matrix as the counter to Moxie's point; with respect to Matrix, the more appropriate assessment of Moxie's federation argument might be "prophetic".

I will never sound like it, but I'm in Matrix's corner. I see clearly where they fit into the ecosystem. The world where Matrix replaces Discourse, Slack, IRC, and Telegram is a better world.

I do not see Matrix replacing Signal, or whatever post-Signal project is carrying forward their ideals 20 years from now.

† A Matrix project person will be sure to correct me on this, and I call it out in part to be candid that I'm not certain about the specific duration.

[Arathorn]

ironically, i agree with much with this: Matrix began in May 2014; we started E2EE in Feb 2015 and turned it on by default in May 2020. Centralised systems are way simpler and easier to reason about and present a smaller attack surface.

Is decentralisation worth it despite that? In my opinion, categorically yes. Just as the internet is better than a corporate WAN, and the internet should live forever, unlike the likes of AOL.

https://matrix.org/blog/2020/01/02/on-privacy-versus-freedom was my attempt to articulate this.

[tptacek]

I would hope there's not much irony here at all. Signal has different priorities than Matrix. I'm sure the Signal project would like to think it can eventually grow to replace Slack, and I don't see that happening either.

[Arathorn]

The only irony was that you were expecting to be corrected, and instead I largely agreed.

[tptacek]

I don't think so! Also: we're waiting for y'all to be ready for the SCW podcast. So you have me over a barrel! I have to be nice to lure you.

[Arathorn]

I wouldn't waste time trying to be nice; I'll turn up whatever if you'll have me. Cryptographically constrained room membership in Matrix is still stuck behind consolidating on matrix-rust-sdk for E2EE, so we only have to address & audit it in one place - and progress has also been impacted by funding challenges (https://matrix.org/blog/2022/12/25/the-matrix-holiday-update... etc). So you might have to wait a while longer.

[simfree]

Signal without SMS support is a poorer performing version of Element to me. There is little practical difference between Signal and most other popular messaging apps that implements end to end encryption.

Compare Element and Signal Desktop startup times, Element is nearly instantaneous, while Signal takes significant time to even open. Both are using the same software stack on desktop, Electron with SQLite.

[3np]

When you get up to the thousands of rooms and tens of millions of messages (bridging and integrations will do that to you), Element Desktop Linux performance degrades severely and will regularly lose connection requiring restarts. And good luck getting out of that scenario or splitting up/archiving the account or groups of the rooms in a digestible format...

We've had Matrix in an org I'm in for a few years now and this has become a meme now.

[Arathorn]

Fixing this has been the primary focus of the core Matrix team over the last year - we revealed the end result at FOSDEM a few weeks ago, and it literally improves performance to be better than Telegram/Discord/Slack or anything else we've benchmarked against: https://youtu.be/eUPJ9zFV5IE?t=566

If you're feeling adventurous, try develop.element.io and enable Sliding Sync in Labs, and you should get instant login, sync, and orders of magnitude better performance (but it is definitely beta). You may need to run your own SS proxy, for which we published a guide yesterday: https://youtu.be/25wkV2ZCSsM

[3np]

Thanks for the follow-up.

Unfortunately, those are all orthogonal: you are referring to server and client-server-sync performance. I'm referring to opening and navigating the client UI, and these issues are as present when offline and no homeserver communication and syncing is involved.

The developments you mention are all important, great, and exciting but from what I've seen so far the UI performance issues are unaddressed. We had users try to report these issues on GH historically but they tended to get dismissed as "can't reproduce on my mac" or left unattended.

[Arathorn]

for the sake of completeness: they aren’t orthogonal. the reason that element web can take tens of seconds to launch is not just because it’s syncing with the server, but because it is loading hundreds of MB of json from indexeddb. Sliding Sync fundamentally changes that; in fact the sliding sync impl I pointed you at doesn’t persist any local state in indexeddb between launches (element web has never supported launching offline, fwiw). Therefore time to launch and load the UI is immeasurably improved.