Comment by Arathorn | Hacker News Reader

Comment by Arathorn | Hacker News Reader

Parent Full thread

Matrix clients should be super easy to write - e.g. https://news.ycombinator.com/item?id=20948530

Servers are definitely harder - it's probably similar complexity to writing a git implementation (given it's basically doing the same operation: synchronising DAGs of commits between replicas of a chat room).

In terms of it being a rapidly moving target: from memory we've never broken backwards compatibility on Matrix since day 1 back in 2014. "Matrix 2.0" is not a breaking change; it's just adding some new APIs to change performance to be O(1) rather than O(N) (and switching to OIDC for auth and native VoIP for multiparty).

So, overall, I'd say it makes things easier: both Matrix client & server authors will no longer have to mess around implementing custom auth (which was a huge burden to get right), but be able to use existing mature OIDC implementations. Meanwhile, the new sync API should be as easy as the old one (although we haven't really done a like for like comparison yet, given we've been obsessing about driving the new sync API as efficiently as possible)

> Matrix clients should be super easy to write - e.g. https://news.ycombinator.com/item?id=20948530

The script in your follow-up github link is still missing escapes of tokens and room id (which can both be arbitrary strings according to the specs) btw. And you should add 500/502/503 error handling, these happen fairly often on non-tiny accounts in my experience, even outside matrix.org

> from memory we've never broken backwards compatibility on Matrix

* https://spec.matrix.org/v1.5/changelog/ has a handful of "Breaking changes" sections since 2021

* https://matrix.org/docs/spec/client_server/r0.6.0.html#chang... , https://matrix.org/docs/spec/client_server/r0.5.0.html#chang... , etc. have a few more before 2021

* Removing reply fallbacks (recommended by MSC3676 and already implemented by at least some clients) causes other clients to miss notifications

> "Matrix 2.0" is not a breaking change Was there really no better name for the talk?

I must acknowledge I was very spooked by the 2.0 in there

Semver does not apply to everything, and definitely not to end products aimed at consumers.

Except that Matrix is a protocol, and the end products using it may like to know that v2.0 (which says "I'm breaking backward compatibility") is actually not breaking backward compatibility.

I don't see the end-to-end encryption there. Nor any of the other tablestakes features.

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?

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

> 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?

Reply on news.ycombinator.com