> The specification as-written is really, really bad
We get a pretty wide range of feedback on the spec fwiw: some people seem to really like it. Others say that it’s “really, really bad” which doesn’t exactly give us much to go on...
> Synapse is kind of... and Dendrite is stalled
We have no choice but improve Synapse currently, and while it is still quite a resource hog it’s improved by at least 3-5x over the last year. Dendrite instead has become more of an R&D project for future homeserver shapes, but it’s not entirely stalled.
> The matrix.org server causes de-facto centralisation
The server has been less than 50% of the visible network for several years now - and ironically the datacenter perf issues (unrelated to Synapse) we had over the last few months have shifted that balance further - it’s about 35% and dropping. Ideally we will turn it off entirely once we have decentralised accounts.
> lack of e2ee by default is iffy
Our main project right now is to fix this. Cross-signing is mid flight; E2E search is done; Pantalaimon (E2E compat for dumb clients) is done; remaining key distribution bugs are in flight. We’re aiming to turn it in by default in Jan.
> “I couldn’t figure out how the state resolution works”
State resolution is the main technical novelty in Matrix, and yeah - it’s hard, much like git’s merge resolution is not exactly easy either. Unfortunately it comes with the territory; if you want to have consistent room state while replicating them over a byzantine network of servers to stop hijacks and other abuse, you have a relatively hard problem to solve. We got it wrong the first time; the current version gets it right (as far as we know).
It looks like you guys are on the right path for most things, and I wish you luck!
Why do you have no choice but improve Synapse?
One of the reasons you seem to only get negative opinions along the lines of "really, really bad" is because "The way it's written is stylistically bad/unapproachable and an entirely different approach should probably be taken" is something that takes a few hours to diffuse into something useful, and not something most people really receive in a way that's productive. It takes a lot more effort to give truly constructive, workable criticism than expressing any sort of opinion, negative or positive.
> It looks like you guys are on the right path for most things, and I wish you luck!
thanks :)
> Why do you have no choice but improve Synapse?
There are quite a lot of Synapses out there right now, and Synapse's featureset is pretty mature. Given we have pretty high profile people running Synapse (e.g. all of the French government) we have no choice but to invest the time to polish it and make it more efficient and stable. In an ideal world we'd have paused on Synapse ages ago and focused purely on a next-gen server, but we can't leave Synapse users in the lurch. Dendrite will be getting some attention in the coming months though, but not as a direct Synapse-replacement, but more of a playground for more experimental stuff.
> It takes a lot more effort to give truly constructive, workable criticism than expressing any sort of opinion, negative or positive.
True. fwiw, my guess is that kaniini was trying to implement state resolution before we published the first stable Server-Server API back in Feb - where it most certainly was the weakest part of the spec (and had design flaws too, which is why we hadn't bothered speccing it in detail).
> The specification as-written is really, really bad
We get a pretty wide range of feedback on the spec fwiw: some people seem to really like it. Others say that it’s “really, really bad” which doesn’t exactly give us much to go on...
> Synapse is kind of... and Dendrite is stalled
We have no choice but improve Synapse currently, and while it is still quite a resource hog it’s improved by at least 3-5x over the last year. Dendrite instead has become more of an R&D project for future homeserver shapes, but it’s not entirely stalled.
> The matrix.org server causes de-facto centralisation
The server has been less than 50% of the visible network for several years now - and ironically the datacenter perf issues (unrelated to Synapse) we had over the last few months have shifted that balance further - it’s about 35% and dropping. Ideally we will turn it off entirely once we have decentralised accounts.
> lack of e2ee by default is iffy
Our main project right now is to fix this. Cross-signing is mid flight; E2E search is done; Pantalaimon (E2E compat for dumb clients) is done; remaining key distribution bugs are in flight. We’re aiming to turn it in by default in Jan.
> “I couldn’t figure out how the state resolution works”
State resolution is the main technical novelty in Matrix, and yeah - it’s hard, much like git’s merge resolution is not exactly easy either. Unfortunately it comes with the territory; if you want to have consistent room state while replicating them over a byzantine network of servers to stop hijacks and other abuse, you have a relatively hard problem to solve. We got it wrong the first time; the current version gets it right (as far as we know).
The spec (which is deliberately formal and terse) is https://matrix.org/docs/spec/rooms/v2
However, there are supporting documents linked from the spec to help clarify: the original spec proposal at https://github.com/matrix-org/matrix-doc/blob/erikj/state_re... and the guide at https://matrix.uhoreg.ca/stateres/reloaded.html etc
Ironically I think that state res is one of the best documented and understood bits of Matrix now (which is just as well, given how important it is).