element-hq / element-hq/synapse

MSC1763: Proposal for specifying configurable message retention periods

Open
#19,852 0 comments 2 reactions 0 assignees View on GitHub
T-ExperimentalFeature
Dominant language
Python
Stars
4.6k
Forks
600
Avg merge
5d 22h
Merged PRs (30d)
51

Description

Tracking issue for MSC1763: Proposal for specifying configurable message retention periods as an experimental feature in Synapse (albeit, in practice implemented as a stable feature..).

## Context

Synpase has supported aspects of MSC1763 for a long time, documented as such in https://element-hq.github.io/synapse/latest/message_retention_policies.html.

Up til this point while semantically it follows the MSC, the endpoints defined within it were not implemented nor were unretained messages conveyed to the client. The retention feature is not part of experimental_features but it's own top level config. The exception to this rule is that if `retention.enabled = True`, then `m.room.retention` events are considered valid retention policies in rooms.

## Current design in Synapse

Synapse supports both global retention policies configured in the homeserver config, and state-defined ones in rooms.

It does NOT use the unstable prefixes called out in the MSC, which is a bug to fix.

## Caveats to be aware of

This is used in production, so we should take care when changing this feature.

## How do we know when to remove this

I suspect in one of the two possible cases:

1. Implementations catch up with the spec, it is merged, and this implementation is marked as stable.
2. A different approach is considered and this feature is marked as legacy, and eventually users migrate away.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.