4 ms·

> 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

> 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.

Arathorn 4y ago
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
- preseinger 4y ago
  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/message_retention_policies.md 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.
  - Arathorn 4y ago
    > > 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.
    - Freie_Messenger 4y ago
      Here are a few tips to reduce resource consumption (german): https://www.freie-messenger.de/en/sys_matrix/#eigener-server https://www.freie-messenger.de/en/sys_matrix/#eigener-server
    - preseinger 4y ago
      > 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.
quaintdev 4y ago
> 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.

Arathorn 4y ago

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

preseinger 4y ago
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/message_retention_policies.md 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.
- Arathorn 4y ago
  > > 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.
  - Freie_Messenger 4y ago
    Here are a few tips to reduce resource consumption (german): https://www.freie-messenger.de/en/sys_matrix/#eigener-server https://www.freie-messenger.de/en/sys_matrix/#eigener-server
  - preseinger 4y ago
    > 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.

quaintdev 4y ago

> 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.