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.

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?

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.