|
|
|
|
|
by traspler
517 days ago
|
|
So there is the Synapse version that is required to get the big money contracts and the Synapse that is pretty inconsequential to the business except as a testing playground. - Makes it difficult to see how "Element is fully committed to community Synapse" can be true in the long run. Does this not spread the development effort & focus even thinner across these projects? And would reduced memory & cpu requirements not benefit all deployment sizes and not just nation-scale ones? It feels very much as a pivot towards a closed stack. |
|
Making worker processes go fast has most benefit to enormous deployments, as they won't run out of headroom when running lots of single-core python workers.
However, ALL deployment sizes benefit from algorithmic improvements to the protocol and its implementation - which are the cause of smaller servers being slower today.
Specifically:
* Merge conflict resolution (State resolution) is worse than O(N) complexity with the amount of state to be merged.
* Incremental room joins (https://element-hq.github.io/synapse/latest/development/syna...) were never fully finished.
* Servers burn lots of time trying to talk to dead servers: https://github.com/matrix-org/matrix-spec-proposals/pull/413...
* All Matrix traffic currently runs full-mesh - there's no concept of "thin nodes" or delegating fan-out to a larger server.
So, fixing these issues is all going into open source Synapse (and Matrix as a whole) - which should unrecognisably improve performance, whether servers are written in Python or Rust or Elixir or whatever. And the hope is that $ from Synapse Pro funds that work (assuming the gambit is successful).
Meanwhile, all features, security work, perf optimisations (apart from scalability work), experimental MSCs etc will continue to land in FOSS Synapse for the forseeable.