mirror of
https://github.com/ArcticFoxes-net/Synapse-Ubuntu-ZFS
synced 2024-09-19 22:24:42 -04:00
69 lines
3.3 KiB
YAML
69 lines
3.3 KiB
YAML
|
# 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
|
||
|
|
|
||
|
|
# 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
|