Skip to content

Commit 116c5b9

Browse files
committed
split out media attachment clean-up to #2278
1 parent ac2f87e commit 116c5b9

File tree

1 file changed

+2
-10
lines changed

1 file changed

+2
-10
lines changed

proposals/1763-configurable-retention-periods.md

Lines changed: 2 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -256,16 +256,8 @@ up to the server implementation's configuration on whether to allow it or not,
256256
and if allowed, configure how long the backfill should persist before being
257257
purged again.
258258

259-
Media uploads must also be expired in line with the retention policy of the
260-
room. For unencrypted rooms this is easy; when the event that references a
261-
piece of content is expired, the content must be expired too - assuming the
262-
content was first uploaded in that room. (This allows for content reuse in
263-
retention-limited rooms for things like stickers).
264-
265-
For encrypted rooms, there is (currently) no alternative than have the client
266-
manually delete media content from the server as it expires its own local
267-
copies of messages. (This requires us to have actually implemented a [media
268-
deletion API](https://github.com/matrix-org/matrix-doc/issues/790) at last.)
259+
Cleaning up the media attachments of expired or redacted events has been
260+
split out into https://github.com/matrix-org/matrix-doc/issues/2278.
269261

270262
Clients and Servers are recommended to not default to setting a `max_lifetime`
271263
when creating rooms; instead users should only specify a `max_lifetime` when

0 commit comments

Comments
 (0)