Hacker News Reader

Comment by walrus01 | Hacker News Reader

> Rocket.Chat is basically selfhosted slack.

What would this accomplish that self hosting synapse doesn't?

It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or not federate.

https://github.com/matrix-org/synapse

I have one setup where the synapse daemon lives on a VM that's only accessible in company internal RFC1918 IP space so you can only connect to it if your laptop or other device is also on a split tunnel VPN.

Of course you could run it with a public IP as well.

View on HN

> What would this accomplish that self hosting synapse doesn't?

It would have all your messages in it if you've been using it for years.

You may prefer the UI.

It may be more efficient (synapse gets a lot of bad press for being heavyweight).

You may partner with a company that already has one system, while you use the other, and would like to chat with each other without either of you changing out your infrastructure.

> It's totally possible to self host the official matrix 'synapse' daemon for self hosted slack-like functionality within an organization, and use the official 'element' client or any other compliant matrix protocol client. If it's for something like company slack-like functionality you can choose to federate or not federate.

Having attempted to do exactly this recently, let me assure you that while it may be technically possible, it is practically infeasible.

Almost everything in Matrix, at multiple layer of abstraction, is built on the presumption of federation: federated events, federated authn/authz, etc. Try to turn federation off, and you're in a no-man's land of untested and unpredictable behaviors. Want to turn off federation _and_ make E2EE obligatory? Good luck! Even if you manage to get Synapse configured to work that way, you'll be delighted to discover that retention rules don't apply to encrypted events.

Synapse, by the way, is a real resource hog. It used an order of magnitude more resources than any other service in my entire infrastructure _at idle_ with no users and no federation. I would have loved to use one of the alternative server implementations, but none of them supported both E2EE and SSO.

Matrix is a dead-end.

What? Almost every statement here is wrong. There are tonnes of unfederated Matrix servers out there, and E2EE and SSO is completely orthogonal to federation. History retention does apply to encrypted events. And Synapse only tends to use lots of resources when federated into large public rooms (these days). I’m terrified at what must have gone wrong such that you ended up drawing these conclusions :s

I'm conveying my personal experience with the software.

> There are tonnes of unfederated Matrix servers out there,

No way to know for sure, but it certainly isn't a well-supported configuration.

> History retention does apply to encrypted events.

> Note that message retention policies don't apply to state events.

https://github.com/matrix-org/synapse/blob/develop/docs/mess...

> And Synapse only tends to use lots of resources when federated into large public rooms (these days)

Synapse used 30-50% of 1 CPU and ~1GB memory at idle with 1 room and 0 connected clients.

> > There are tonnes of unfederated Matrix servers out there,

> No way to know for sure, but it certainly isn't a well-supported configuration

It really is. By default we develop against unfederated servers (synapse running on localhost). Of the synapses we host at EMS probably 30% are unfederated. It is completely supported.

> Note that message retention policies don't apply to state events

Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

> Synapse used 30-50% of 1 CPU and ~1GB memory at idle with 1 room and 0 connected clients.

Then something was going really weirdly wrong. It should idle at <1% cpu and ~150MB RAM on an unfederated server with one room and zero clients.

Very strange.

Here are a few tips to reduce resource consumption (german): https://www.freie-messenger.de/en/sys_matrix/#eigener-server

> Correct. State events are key/value data associated with a room - eg who’s in it, what it’s called, whether it’s encrypted. obviously you can’t expire them after N days otherwise the structure of the room would disintegrate. It has nothing to do with E2EE messages.

E2EE-encrypted message are persisted by Synapse as state events.

Or, maybe more precisely, if I set a message retention policy of X days, rows in event tables associated with E2EE-encrypted rooms, which are created when messages are sent to that room, and which are older than X days, are not removed.

> it is practically infeasible.

> Try to turn federation off, and you're in a no-man's land of untested and unpredictable behaviors.

This is wrong. I have been using non federated server for over a year and I hardly faced any issue.

Reply on news.ycombinator.com