4 ms·

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

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.

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.