Retention Configuration

[mononym]

Continuing the discussion from What happens in the matrix channels where there are no more users ? Where goes the messages ? #8

I want to set up a maximum retention in order to keep the memory footprint low. To do so I added the following lines to my homeserver.yaml and am now waiting to see what it will actually do [1] :

retention:
  enabled: true # enables the retention, is enough to enforce it once per day
  default_policy:
    min_lifetime: 1d
    max_lifetime: 4w
media_retention:
  local_media_lifetime: 4w
  remote_media_lifetime: 4w

My first observation is that nothing appears in the room state. I started a new conversation with a matrix.org user and no default m.room.retention appears in the room state after its creation.

• Does the other server (matrix.org) need to enable the setting as well ?
• Is this only for purging empty rooms, not about auto-deleting old messages ?

Thanks for any info on the topic.

[1] Source: https://element-hq.github.io/synapse/latest/usage/configuration/config_documentation.html#retention (link could be updated in the docs)

[andreasdueren]

@mononym Your config is actually valid, the confusion is about what it does and how to verify it, plus one gotcha that means it may silently not work at all.

What the retention: block does: it server-side purges old message history in rooms, based on lifetime settings. It has nothing to do with purging empty/abandoned rooms.

Why nothing appears in room state: that's expected. A server-level default_policy never creates m.room.retention state events, it's purely a homeserver-internal default applied when a room has no policy of its own. You'll only see an m.room.retention event if someone explicitly sets a per-room policy. So "nothing in room state" doesn't mean it isn't working.

Does matrix.org need it too? For your goal (keeping your server's disk usage down), no. Retention purges are local. Your server deletes its own copies. But note other servers keep their own copies of federated rooms; retention is not remote deletion.

The gotcha: the daily purge job only runs if retention.purge_jobs is configured. With just enabled: true and a default_policy, some Synapse versions won't schedule any purge job. Add one explicitly:

retention:
  enabled: true
  default_policy:
    min_lifetime: 1d
    max_lifetime: 4w
  purge_jobs:
    - interval: 1d

How to verify it's working: don't watch room state, watch the Synapse log for purge_history / "Purging" entries after the job interval elapses, and compare your Postgres DB size (events table) over a couple of weeks.

If what you actually want is cleaning up dead/empty rooms (rooms everyone has left), retention is the wrong tool. Use these two settings instead:

forget_rooms_on_leave: true
forgotten_room_retention_period: 28d

Rooms get auto-forgotten when users leave, and once every local user has forgotten a room, Synapse's daily background task purges it from the DB entirely. This removes abandoned rooms without touching history in rooms people are still using.

Both work fine on the Cloudron Synapse package via /app/data/configs/homeserver.yaml + app restart.

[mononym]

Thank you @andreasdueren for the solution and all the extra explanation!

Do you know how synapse handles on which server a room is stored? Are the rooms solely on the server which initiated the conversation or are they mirrored across servers? Would that not mean that a room history is potentially always available if one of the servers does not enable the retention setting?

[andreasdueren]

@mononym Yes, essentially. A federated room is not stored only on the homeserver where it was created. Each homeserver with participating users receives and stores its own copy of the room events for its local members. The originating server is not a central or authoritative host for the room.

A newly joining homeserver does not necessarily receive every historical event immediately, but it can request available history from other participating servers, subject to the room's history visibility and federation rules.

Therefore, Synapse retention is not a remote-delete mechanism. Your default_policy controls only what your own homeserver serves to clients and eventually keeps in its database. If matrix.org, or another participating homeserver, does not enforce equivalent retention, it may retain its own copy of the history. In an encrypted room that copy is ciphertext, but clients that still have the encryption keys may be able to decrypt it.

A room-level m.room.retention state event is federated and can communicate the intended policy to participating servers, but enforcement still depends on each homeserver supporting and honoring it. It should not be treated as a guarantee that every copy disappears everywhere.

Small correction to my previous reply: current Synapse versions use a default purge-job configuration when retention is enabled and no explicit purge_jobs section is provided. Adding purge_jobs is useful when you want to control the purge interval, but it is not strictly required.