38
submitted 1 day ago* (last edited 1 day ago) by moonpiedumplings@programming.dev to c/opensource@lemmy.ml

So this is a pretty big deal to me (it looks recent, just put up last October). One of my big frustrations with Matrix was that they didn't offer helm charts for a kubernetes deployment, which makes it difficult for entities like nonprofits and community clubs to use it for their own purposes. Those entities need more hardware than an individual self hoster, and may want features like high availability, and kubernetes makes horizontal scaling and high availability easy.

Now, according to the site, many of these features seem to be "enterprise only" — but it's very strangely worded. I can't find anything that explicitly states these features aren't in the fully FOSS self hosted version of matrix-stack, and instead they seem to be only advertised as features of the enterprise version

My understanding of Kubernetes architecture is that it's difficult for people to not do high availability, which is why this makes me wonder.

Looking through the docs for the "enterprise version, it doesn't look like anything really stops me from doing this with the community addition.

They do claim to have rewritten synapse in rust though

Being built in Rust allows server workers to use multiple CPU cores for superior performance. It is fully Kubernetes-compatible, enabling scaling and resource allocation. By implementing shared data caches, Synapse Pro also significantly reduces RAM footprint and server costs. Compared to the community version of Synapse, it's at least 5x smaller for huge deployments.

And this part does not seem to be open source (unless it's rebranded conduit, but conduit doesn't seem to support the newer Matrix Authentication Service.)

So, it looks Matrix/Element has recently become simultaneously much more open source, but also more opaque.

you are viewing a single comment's thread
view the rest of the comments
[-] moonpiedumplings@programming.dev 1 points 11 hours ago

Hello Ananace! :)

I actually have seen your helm charts many, many times before when searching for matrix, synapse, or lemmy on Artifacthub.

An official helm chart isn't really a hard requirement to me, even if I were to use one and it were to stop getting maintained, I could continue on my own. But an official helm chart has big community benefits that are very important to me. Like, there becomes the option of paid support, which is a must have for many entities. Also, an official organization may support a wider variety of usecases than someone making helm charts for personal use.

I also ended up chatting with one of the core devs of Synapse about ways to improve regular Python Synapse for use with Kubernetes back in the ending of January, so hopefully it’ll improve in that direction when time allows

Do you know anything about the claims that they have rewritten synapse in rust?

[-] ace@lemmy.ananace.dev 1 points 3 hours ago

It's worth noting that the ESS suite Chart is absolutely not built to be community-viable, it's built for the kind of single-purpose deployments that Element offer hosting for, and it also breaks almost all Kubernetes best practices. Which is actually not wrong per-se. Element need to be able to maintain it after all, and since they don't have the Kubernetes know-how to build generic components, it makes sense to instead bundle a fully integrated solution which they are comfortable with developing and debugging.

They're definitely slowly but steadily rewriting Synapse in Rust as well, that's been an open and ongoing project for a while now. You can see that just by looking in the Rust folder in the Synapse sources.
I strongly doubt that they have the "rest" of the application rewritten internally and keeping it hostage for paid hosting though, it'd cost them too much to keep separate codebases for such a thing.

The "Synapse Pro" offering is most likely just the regular Python+Rust Synapse, but with a few additional HA components and some workers written in Rust for efficiency, just like how there's community workers written in both C# and Go for performance reasons.

this post was submitted on 30 Apr 2025
38 points (95.2% liked)

Open Source

36404 readers
181 users here now

All about open source! Feel free to ask questions, and share news, and interesting stuff!

Useful Links

Rules

Related Communities

Community icon from opensource.org, but we are not affiliated with them.

founded 5 years ago
MODERATORS