element-hq / element-hq/synapse
MSC1763: Proposal for specifying configurable message retention periods
- 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
Assessment
This issue has not been assessed yet.