3.2 KiB
MSC3989: Redact origin property on events
The current redaction algorithm keeps the
top-level origin property on events during redaction, however, as of this writing, the only use within the
spec of origin as a top-level event property is a malformed example of event format. The property has no
significant meaning in modern room versions.
Within the ecosystem, it's clear that we'd prefer the property to disappear, and have tried to do so in the past. The malformed examples are even known to us.
What's not clear, and mentioned in a comment,
is whether the origin property is actually used. There do not appear to be any auth rules or similar
which would use the property, however it'd hardly be the first time that the spec was wrong about an
ancient room version like v1. What is clear is that Synapse, where this question would be asked,
wants to drop support for the property and has
taken steps towards that mission by fixing bugs
in the area. In a quick audit
of the Synapse codebase during implementation of this MSC, the origin property appears unused.
Given the above context, this proposal removes the origin property from the redaction algorithm
in a future room version, leaving it as-is for existing versions (not that an MSC can change the behaviour
of an already-stable room version anyways).
Some other properties are additionally useless in modern room versions, however they are already adapted by MSC2176.
Proposal
In a future room version, the origin property is removed from the list of event keys which are
kept during redaction. Note that this requires a new room version because changing the redaction
algorithm changes how event IDs are calculated,
as they are reference hashes
which redact the event during calculation.
Potential issues
No major concerns.
Alternatives
No significant alternatives.
Security considerations
No major concerns.
Unstable prefix
While this MSC is not considered stable, implementations should use org.matrix.msc3989 as the room
version identifier, using v10 as a base.
Dependencies
No blocking dependencies.
This MSC would partner well with the following MSCs, however: