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)
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
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.
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(!)
> 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
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)