Hi folks - based on the feedback here and on Mastodon, i've updated the original blog post to try to spell out that the point of Synapse Pro is not to hold back general performance work from open source Synapse, but just eliminate scaling bottlenecks for massive deployments: https://element.io/blog/scaling-to-millions-of-users-require...
We replaced Matrix's custom authentication protocol with genuine OIDC: see https://areweoidcyet.com/ and the rest of this thread for details.
Therefore, we needed a basic Matrix-aware OIDC identity provider which could ship with Synapse and other homeservers in order to auth users (and optionally delegate to fully fledged IdPs like Keycloak). So we wrote matrix-authentication-service (MAS) in Rust, which is released as FOSS: https://github.com/element-hq/matrix-authentication-service.
This is released as a separate project because: a) it's written by a different team, b) it's intended to power OIDC auth for other servers than Synapse. For instance, https://github.com/element-hq/dendrite/pull/3493 is the pull to make Dendrite support OIDC via MAS.
In future, we may end up for admin convenience also bundle it by default inside FOSS Synapse (especially given Synapse is part-Rust these days) - so that folks running `pip install matrix-synapse` magically get OIDC-based auth without having to also run a separate MAS. However, this is a while off, and even then we'll continue to support MAS as a standalone service as the primary configuration.
(N.B. none of this has anything to do with Synapse Pro, and is an example of Element continuing to pour the majority its effort into FOSS work like MAS and native OIDC in Matrix...)
Firstly, thank you for paying to support the Foundation for so long and for sticking with Matrix & Synapse.
> It's been quite a while since we've seen a new user-facing feature
I'm not sure this is true, as you say yourself in the following paragraphs. On the Element side, we shipped Element X as the much-needed rewrite of the old Element apps. On the Matrix side, Matrix 2.0 is a step change in terms of instant sync/login/launch, QR login, native-OIDC, invisible encryption, etc. From an end-user perspective, my experience of Matrix has improved unrecognisably in the last year. I can see how this might feel different if you're stuck on the old stack.
> All in all, it does not feel like the things I want, and (assuming I'm not a completely unusual case) that the community wants, are high priority for the Element team
We've tried to prioritise usability, stability and performance over everything - including features. I'm sorry if this doesn't match your needs though.
> They're spending what budget they do have on refactors like MAS, which don't seem to impact usability.
Some of the usability improvements that MAS provides are:
* 2FA and MFA (which is frankly embarrassing that we didn't have before)
* QR login (for parity with Discord/WhatsApp/Signal "just scan this QR code to login")
* Refresh tokens, so that leaked access tokens expire rapidly
* Integration with password managers
* Password reset flows which work on all clients (e.g. password reset doesn't exist on the legacy Element mobile apps)
* Huge security improvements by actually following a mature auth standard (OIDC) rather than making up our own one. We've had some near misses on the old auth system for failure modes which OIDC fixed years ago.
> They spend time and effort supporting new features which make Element X faster (Sliding Sync) but have not yet implemented all the core functionality (Spaces) so there's not much reason to move.
Spaces is already there on the SchildiChat Next fork of Element X Android. We'll add it to Element X Android later in the year - but it's been delayed as the paying customers tend not to care that much about spaces (they just want a WhatsApp clone).
> This announcement, and that RAM graph which I will never see on my own server, makes me confident in discontinuing my support.
The hope is that the $ from Synapse Pro allows us to fund FOSS Synapse dev to improve the core perf & resource usage of FOSS Synapse - which in turn will reduce the RAM usage for everyone. (But massive-scale scalability will remain paywalled for now.)
To be clear: the reason small Synapse servers are slow is NOTHING to do with the workers being written in Python rather than Rust. We will use $ from Synapse Pro to speed up Synapse (and Matrix, at the protocol level) for everyone.
> I do not feel like Matrix/Element values its community any more.
Sorry. If we didn't value the community I wouldn't be sitting on HN trying to explain why we've done this. Thanks again for supporting over the years.
There are two different performance issues here. One is the stuff that Graphene is talking about, which affects all server sizes, and we are trying to fund work on to fix in FOSS Synapse - see https://news.ycombinator.com/item?id=42752847.
Entirely separately: there are bottlenecks you hit if you try to run a 100K+ user server. Synapse Pro fixes those bottlenecks, and the idea is the $ derived from that can then fund the broader FOSS improvements, which otherwise are starved of funding.
FOSS Synapse already is a hybrid of Python and Rust, and has been for years - with Rust used for the hot paths. Synapse Pro is just pushing that a bit further for worker processes, by having the host process itself being Rust-first rather than Python-first. But the majority of the app and architecture is the same; it's just swapping out some of the python-with-rust processes for pure-Rust alternatives. I think of it a bit like using a hardware accelerator (how I envy the fact that nobody complains about the fact that hardware accelerators cost money!)
Some massive organisation (government agency, healthcare provider, network of schools etc) says: "Wow, Matrix is great, we should run our own instance rather than be dependent on Teams/Slack/Workspace. I'll put out a public tender for suppliers to provide this for us!"
Then, all the system integrators who are geared up to sell big IT projects to large organisations jump on the tender and say "Sure, we can do this for you, and we're best qualified to do so because we're an enormous trusted system integrator with loads of people in the right geography, got all the right compliance checkboxes, and we do this sort of thing all the time. It'll cost you $xM a year."
The upstream developer (Element) then reaches out to the integrators and says: "Oh hi! Are you planning to bid on this contract? If you want this to be successful, you should use our commercial offering, as then we'll be able to use that $ to keep upstream development alive".
The integrator then looks bewildered, and says: "But... we've been using your opensource distro off github and it seems fine? Why would we pay you guys anything? The additional cost will just make our bid too expensive and we won't win, or it'll kill our profit margins. Sorry, we'll go ahead without you and maintain the software ourselves if needed."
Given the main paying customers for Matrix are big organisations wanting digital sovereignty, this means the available $ disappears into the integrators rather making is way to fund the actual upstream dev - which then ends up stagnating, stalled, and completely at risk - putting all of these projects at risk. facepalm.
A variation on the problem is where the massive org decides to do the project in-house rather than via an integrator... but then still chooses to YOLO and freeride and given it'll cost less than using the commercial offering from the upstream. I can list at least 4 national governments who have taken this route.
To solve it, options include:
* The buyer could mandate that suppliers for the tender have to use the commercial offering from the upstream product rather than freeride on opensource. This is probably the easiest solution, but seems staggeringly rare - the only instance I know of who have taken this principled stand are ZenDiS in Germany (https://zendis.de) and we are very thankful for it.
* The upstream could make their commercial offering more valuable than the FOSS offering - e.g. additional domain-specific functionality: what we've done with Synapse Pro.
* The upstream could make the FOSS licensing less permissive, to force integrators to contribute back. We already did this with AGPL Synapse in 2023: https://element.io/blog/element-to-adopt-agplv3, and it has helped a bit... but in practice, we just saw a fleet of major Matrix tenders go to system integrators who then apologetically cut Element out, despite AGPL - putting Element's funding for 2025 directly at risk.
Which is why we're putting out brutal blog posts saying "Look, big organisations: if you try to freeride on FOSS your projects will fail" - and providing a quantified explanation of the value that the commercial offering provides... so that we can then take the $ and hopefully keep the primary FOSS project on the road.
Free software is just a hack of the copyright system. The point of which is to incentivize people to create works and be paid for them and after a period of time be added to the public domain. Eventually open source follows the same principle, just with source availability.
Most of that performance is nothing to do with whether workers are written in python or rust - see https://news.ycombinator.com/item?id=42752911. The hope is to fund maintenance for FOSS synapse, including core perf work, via Syn Pro stuff which makes the biggest impact for gigantic servers.
We didn’t rewrite the slow parts in Rust, we rewrote the bits which let large deployments scale (workers) in rust. Normal Synapse perf work will continue as ever, if not faster given it might have more funding. See https://news.ycombinator.com/item?id=42752911
> It seems to me like this disqualifies Matrix from consideration for "public infrastructure" IMHO.
Please don’t conflate Synapse with Matrix. Yes, if a govt has a “we must only spend money on pure open source products” policy then they won’t buy Synapse Pro. Perhaps they’ll end up scaling by running hundreds of separate smaller FOSS instances instead. Perhaps other server implementations will step up as FOSS (and probably promptly be undermined by the same freerider problem).
> It would have been better if the differentiation between the paid and free versions wasn't scaling, but some other features not critical for public use (or provided as a non-free plugin), but something that enterprises would consider useful.
> Yes, if a govt has a “we must only spend money on pure open source products” policy then they won’t buy Synapse Pro.
I imagine anything else would be quite irresponsible in a geopolitical climate where sanctions could pull the rug out on critical communications infrastructure.
If Matrix is just "yet another service (SaaS)" competing with Slack, MS Teams and the like it becomes a much less compelling argument for public infrastructure. You better have a product that is so much superior in functionality that it is worth the switching cost for customers.
> I imagine anything else would be quite irresponsible in a geopolitical climate where sanctions could pull the rug out on critical communications infrastructure.
I'm not sure I follow the logic here: Governments can self-host their own infrastructure and avoid potential sanctions without it having to be open source.
Meanwhile, empirically, all Governments continue to spend eyewatering amounts of proprietary software - whether that's from Microsoft or Adobe or Google or whoever. It's excruciating that in practice, only a miniscule proportion of that gets routed to open source - and even then, it's typically on a "we'll pay for features, but not maintenance" basis. So I'm not seeing any “we must only spend money on pure open source products” in practice; the closest is "if we're paying for something to be built, it needs to be open source" (which makes perfect sense, imo).
> If Matrix is just "yet another service (SaaS)" competing with Slack, MS Teams and the like it becomes a much less compelling argument for public infrastructure.
Matrix is an open protocol - it's not remotely "yet another SaaS". There's already a selection of different server implementations; some FOSS, some proprietary. You can switch between servers, and switch between clients. The fact that one server has added acceleration to enable successful massive-scale implementations and kept that as proprietary (for now) does not undermine the protocol - or stop govts from purchasing it, imo.
I think we may need to agree to disagree on this one tho :)
Thanks for engaging. Your comments point to a different mental model for thinking about government procurement of software. Not sure whether I'm convinced, but it's certainly food for thought.
reply