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