[Arathorn]

It looks like i've done a bad job at explaining this, so i'll try to clarify:

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.

[traspler]

After re-reading and reading many other comments in various posts I think I have misunderstood it partly. So the workers part has been overhauled in Rust for Synapse Pro. Is this a complete re-implementation of Synapse so the big deployments with Synapse Pro will not run anything from the normal Synapse or is this only part of the whole stack and the Pro deployments will also run most of the normal Synapse?

[jdenning]

But it seems like this move incentivizes you to not improve the open source server, at least such that the open source server is always inferior to the pro version.

If someone makes a new, more performant, open-source server, and it touches your bottom line then you're strongly motivated to "embrace, extend, extinguish".

The thing is, we've all heard this before, and it always ends up the same. I hope you prove me wrong, but I wouldn't bet on it.

[Arathorn]

> But it seems like this move incentivizes you to not improve the open source server, at least such that the open source server is always inferior to the pro version.

The idea is that we absolutely improve FOSS synapse in all ways - other than supporting enormous deployments. For instance we continue to land perf improvements to FOSS synapse and make average sized servers as snappy as conceivably possible. And all features land in FOSS synapse, etc. If we don’t it would harm the public Matrix network and we obviously don’t want that.

> If someone makes a new, more performant, open-source server, and it touches your bottom line then you're strongly motivated to "embrace, extend, extinguish".

Rather than EEE, I’d expect us to simply compete with that server - adding more features, better perf, better commercial support, etc. For Matrix’s sake, I hope that we end up in that situation tbh.

> The thing is, we've all heard this before, and it always ends up the same. I hope you prove me wrong, but I wouldn't bet on it.

I think the difference is that typically folks doing this are being greedy to grow a profitable (or could-be-profitable) company as aggressively as possible. Whereas here the motive is simply to pay for our FOSS dev and get to breakeven and be able to sustainably grow Matrix for the benefit of the whole network. If in the end a bit of proprietary software is the necessary evil to get there, sobeit.

Of course this could change in future, eg if mgt changed, but that’s true of anything. But the intention is categorically not to EEE (and on the Matrix Foundation side, the governance and spec process is set up to stop Element from being able to EEE even if it wanted to).