Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Does this depend on sliding sync and their standalone authz server like Element X does?

I'd love to use Element X, but Element abandoned the form of SSO my community depends on, and I don't really have an appetite to spend 12 hours of my free time standing up sliding sync, a separate auth server, migrating my users to the separate auth server, spending hours explaining to everyone that their credentials live in some other place now, and then migrating my custom server admin software to use OpenID connect. Oh well.



> I don't really have an appetite to spend 12 hours of my free time standing up sliding sync

This has been built into synapse now for months, maybe a year. Does not require a second sliding-sync component anymore.


That's great!

What about Matrix Authentication Service? That's still a separate piece of software that requires PostgreSQL (as opposed to SQLite like my Synapse instance uses) and has no clear migration path for those of us using our own SSO solution (SAML, CAS, maybe your own OIDC provider like Keycloak...), right?

I don't want to run Dex and complicate the stack further, either.

I think 12 hours to migrate is probably optimistic even with built-in sliding sync, actually...


> What about Matrix Authentication Service?

Still its own thing which I have not deployed on my homeserver.

> as opposed to the SQLite like my Synapse instance uses

I've done this for testing but they really don't recommend it for production. It's had a history of being broken: https://github.com/element-hq/synapse/issues/18325


I've lucked out and haven't had any issues like that on my tiny home server.

I wish it were easier to be a Synapse admin! It seems like all server updates are focused on scaling matrix.org and the little guys that provide network diversity are not really being considered a priority.


We're actively trying to fix that - we're finally launching an official Web admin interface as FOSS (AGPL) for Synapse in the next day or two (it was meant to ship today in fact, but got blocked on a debate on how to distribute the containers).

Meanwhile you can see me trying to improve diskspace for Synapse by ~100x here:https://www.youtube.com/watch?v=D5zAgVYBuGk&t=1851s - admittedly motivated by matrix.org, but it would improve disk storage immeasurably for everyone.

Then, https://element.io/server-suite/community is built to be a really simple FOSS distro (albeit for k8s) which provides Matrix Auth Service, Synapse, Element Web, Element Call and (in a few days) Element Admin all in one package for self-hosters.

And if you hate k8s, then there's always the trivial docker-compose thing I did for the same stack at https://github.com/element-hq/element-docker-demo.

We have very much not forgotten the self-hosters - not least because Element tries to make money by selling the enterprise distro for enterprisey self-hosters at https://element.io/server-suite/pro. The rule of thumb is that stuff which privileges the end-user goes FOSS, and the stuff which privileges the enterprise over the end-user goes Pro{prietary,fessional}.


> I wish it were easier to be a Synapse admin! It seems like all server updates are focused on scaling matrix.org and the little guys that provide network diversity are not really being considered a priority.

Matrix is a product of venture capital and the growth at all cost culture, the absurd price to play (reqs to federate with the canonical matrix.org server) made it clear from the get go. If you have your users managed externally, you could probably have a shot at setting-up an XMPP server alongside Synapse, for a tenth of the hassle and resources consumption, and see for yourself if that's an acceptable plan B.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: