Well, if you want end-to-end encryption, then obviously that's going to be hard to write from scratch(!) - especially if you want it to be secure. However, we make it trivial to get up and running by piping your client through a proxy like Pantalaimon (https://github.com/matrix-org/pantalaimon/) which takes your normal traffic and makes it E2EE.

Not sure which "any of the other tablestakes features" you have in mind... obviously if you want loads of features, then you're going to have to write a whole bunch of code to implement them in your client, or build on an existing SDK like matrix-bot-sdk, matrix-rust-sdk, matrix-js-sdk etc. Not sure that's a disadvantage of Matrix though(!)

I recall the selling point of Matrix being security. (Otherwise, we could just use IRC.)

The conventional IETF-ish Internet ideal of open standards is to have a specification that is implementable.

When the selling point is security, insecure implementations don't help us.

Suggesting an off-the-shelf proxy kludge doesn't clearly answer how implementable it is.

Sounds like you're saying that the protocol (with necessary security) is hard to implement. Do the new changes affect that one way or the other?

> When the selling point is security, insecure implementations don't help us.

I'm not sure using a proxy is my preferred solution either, but if you're worried about insecure implementations doesn't it make a ton of sense to separate the E2EE implementation from the rest of the client implementation?

My ideal when using an experimental Matrix client if I don't know the developers involved would be for their experimental code to be quarantined away from the encryption code. That way I don't have to worry so much about whether their implementation is insecure, I know they're just using something off-the-shelf.

Whether the proxy in specific is the best way to do that, :shrug:, but my instinct is that pushing messages through some kind of separate encryption/decryption handler that can be verified on its own and reused by multiple clients isn't a bad idea. That approach seems like good security practice to me. Am I missing something?

Modern XMPP+OMEMO has a stronger security story and isn't controlled by a single corporation with a CEO who can't help but get involved in every HN thread about his product, and there are multiple working clients for every platform, which is something Matrix can barely claim

Of course "Arathorn" would say it's easy to implement a client for the protocol he controls unilaterally, it's in his interest to get you locked in!

There is one cross platform client for matrix and it drives the features: element

I say this from a place of current experience, as I run a server and use element and fluffy chat, each of which has its own issues. If it's so easy, where are the others? Why is there only one third party home server available that is only partially implemented? XMPP offers at least three to choose from. Now /that/ is a real protocol

There is zero benefit for choosing matrix over XMPP