ArcticFoxes-net/Synapse-Ubuntu-ZFS
1
0
Fork 0
mirror of https://github.com/ArcticFoxes-net/Synapse-Ubuntu-ZFS synced 2024-11-12 13:51:33 -05:00
Code

Update retention.yaml

Browse Source 
Signed-off-by: Tommy <contact@tommytran.io>
This commit is contained in:
Tommy 2023-08-31 15:24:52 -07:00 committed by GitHub
parent f8495a5c11
commit 4b603d1628
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 4 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
etc/matrix-synapse/conf.d/retention.yaml
View File

@ -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: retention:
# The message retention policies feature is disabled by default. Uncomment the enabled: false
# following line to enable it.
#
enabled: true
# Default retention policy. If set, Synapse will apply it to rooms that lack the redaction_retention_period: 30d
# 'm.room.retention' state event. Currently, the value of 'min_lifetime' doesn't user_ips_max_age: 60d
# matter much because Synapse doesn't take it into account yet. delete_stale_devices_after: 120d
#
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