diff --git a/etc/matrix-synapse/conf.d/retention.yaml b/etc/matrix-synapse/conf.d/retention.yaml
index a9c99bb..ae10feb 100644
--- a/etc/matrix-synapse/conf.d/retention.yaml
+++ b/etc/matrix-synapse/conf.d/retention.yaml
@@ -1,69 +1,6 @@
-# Message retention policy at the server level.
-#
-# Room admins and mods can define a retention period for their rooms using the
-# 'm.room.retention' state event, and server admins can cap this period by setting
-# the 'allowed_lifetime_min' and 'allowed_lifetime_max' config options.
-#
-# If this feature is enabled, Synapse will regularly look for and purge events
-# which are older than the room's maximum retention period. Synapse will also
-# filter events received over federation so that events that should have been
-# purged are ignored and not stored again.
-#
 retention:
-  # The message retention policies feature is disabled by default. Uncomment the
-  # following line to enable it.
-  #
-  enabled: true
+  enabled: false
 
-  # Default retention policy. If set, Synapse will apply it to rooms that lack the
-  # 'm.room.retention' state event. Currently, the value of 'min_lifetime' doesn't
-  # matter much because Synapse doesn't take it into account yet.
-  #
-  default_policy:
-    min_lifetime: 1d
-    max_lifetime: 1y
-
-  # Retention policy limits. If set, and the state of a room contains a
-  # 'm.room.retention' event in its state which contains a 'min_lifetime' or a
-  # 'max_lifetime' that's out of these bounds, Synapse will cap the room's policy
-  # to these limits when running purge jobs.
-  #
-  allowed_lifetime_min: 1d
-  allowed_lifetime_max: 1y
-
-  # Server admins can define the settings of the background jobs purging the
-  # events which lifetime has expired under the 'purge_jobs' section.
-  #
-  # If no configuration is provided, a single job will be set up to delete expired
-  # events in every room daily.
-  #
-  # Each job's configuration defines which range of message lifetimes the job
-  # takes care of. For example, if 'shortest_max_lifetime' is '2d' and
-  # 'longest_max_lifetime' is '3d', the job will handle purging expired events in
-  # rooms whose state defines a 'max_lifetime' that's both higher than 2 days, and
-  # lower than or equal to 3 days. Both the minimum and the maximum value of a
-  # range are optional, e.g. a job with no 'shortest_max_lifetime' and a
-  # 'longest_max_lifetime' of '3d' will handle every room with a retention policy
-  # which 'max_lifetime' is lower than or equal to three days.
-  #
-  # The rationale for this per-job configuration is that some rooms might have a
-  # retention policy with a low 'max_lifetime', where history needs to be purged
-  # of outdated messages on a more frequent basis than for the rest of the rooms
-  # (e.g. every 12h), but not want that purge to be performed by a job that's
-  # iterating over every room it knows, which could be heavy on the server.
-  #
-  # If any purge job is configured, it is strongly recommended to have at least
-  # a single job with neither 'shortest_max_lifetime' nor 'longest_max_lifetime'
-  # set, or one job without 'shortest_max_lifetime' and one job without
-  # 'longest_max_lifetime' set. Otherwise some rooms might be ignored, even if
-  # 'allowed_lifetime_min' and 'allowed_lifetime_max' are set, because capping a
-  # room's policy to these values is done after the policies are retrieved from
-  # Synapse's database (which is done using the range specified in a purge job's
-  # configuration).
-  #
-  purge_jobs:
-  #  - longest_max_lifetime: 3d
-  #    interval: 12h
-  #  - shortest_max_lifetime: 3d
-  #    interval: 1d
-    - interval: 1d
\ No newline at end of file
+redaction_retention_period: 30d
+user_ips_max_age: 60d
+delete_stale_devices_after: 120d