|
| 1 | +# MSC3989: Redact `origin` property on events |
| 2 | + |
| 3 | +The [current redaction algorithm](https://spec.matrix.org/v1.6/rooms/v10/#redactions) *keeps* the |
| 4 | +top-level `origin` property on events during redaction, however, as of this writing, the only use within the |
| 5 | +spec of `origin` as a top-level event property is a malformed example of event format. The property has no |
| 6 | +significant meaning in modern room versions. |
| 7 | + |
| 8 | +Within the ecosystem, it's clear that we'd [prefer the property to disappear](https://github.com/matrix-org/matrix-spec/issues/374), |
| 9 | +and have [tried to do so](https://github.com/matrix-org/matrix-spec/pull/998) in the past. The |
| 10 | +malformed examples are even [known to us](https://github.com/matrix-org/matrix-spec/issues/1480). |
| 11 | + |
| 12 | +What's not clear, and mentioned in [a comment](https://github.com/matrix-org/matrix-spec/issues/1480#issuecomment-1495183789), |
| 13 | +is whether the `origin` property is *actually* used. There do not appear to be any auth rules or similar |
| 14 | +which would use the property, however it'd hardly be the first time that the spec was wrong about an |
| 15 | +ancient room version like v1. What is clear is that Synapse, where this question would be asked, |
| 16 | +wants to [drop support](https://github.com/matrix-org/synapse/issues/3816) for the property and has |
| 17 | +taken [steps](https://github.com/matrix-org/synapse/pull/8324) towards that mission by fixing bugs |
| 18 | +in the area. In a [quick audit](https://github.com/matrix-org/matrix-spec-proposals/pull/3989#issuecomment-1497659507) |
| 19 | +of the Synapse codebase during implementation of this MSC, the `origin` property appears unused. |
| 20 | + |
| 21 | +Given the above context, this proposal removes the `origin` property from the [redaction algorithm](https://spec.matrix.org/v1.7/rooms/v10/#redactions) |
| 22 | +in a future room version, leaving it as-is for existing versions (not that an MSC can change the behaviour |
| 23 | +of an already-stable room version anyways). |
| 24 | + |
| 25 | +Some other properties are additionally useless in modern room versions, however they are already adapted |
| 26 | +by [MSC2176](https://github.com/matrix-org/matrix-spec-proposals/pull/2176). |
| 27 | + |
| 28 | +## Proposal |
| 29 | + |
| 30 | +In a future room version, the `origin` property is *removed* from the list of *event* keys which are |
| 31 | +kept during redaction. Note that this requires a new room version because changing the redaction |
| 32 | +algorithm changes how [event IDs](https://spec.matrix.org/v1.6/rooms/v10/#event-ids) are calculated, |
| 33 | +as they are [reference hashes](https://spec.matrix.org/v1.6/server-server-api/#calculating-the-reference-hash-for-an-event) |
| 34 | +which redact the event during calculation. |
| 35 | + |
| 36 | +## Potential issues |
| 37 | + |
| 38 | +No major concerns. |
| 39 | + |
| 40 | +## Alternatives |
| 41 | + |
| 42 | +No significant alternatives. |
| 43 | + |
| 44 | +## Security considerations |
| 45 | + |
| 46 | +No major concerns. |
| 47 | + |
| 48 | +## Unstable prefix |
| 49 | + |
| 50 | +While this MSC is not considered stable, implementations should use `org.matrix.msc3989` as the room |
| 51 | +version identifier, using v10 as a base. |
| 52 | + |
| 53 | +## Dependencies |
| 54 | + |
| 55 | +No blocking dependencies. |
| 56 | + |
| 57 | +This MSC would partner well with the following MSCs, however: |
| 58 | +* [MSC2176](https://github.com/matrix-org/matrix-spec-proposals/pull/2176) |
| 59 | +* [MSC2175](https://github.com/matrix-org/matrix-spec-proposals/pull/2175) |
| 60 | +* [MSC2174](https://github.com/matrix-org/matrix-spec-proposals/pull/2174) |
| 61 | +* [MSC3821](https://github.com/matrix-org/matrix-spec-proposals/pull/3821) |
0 commit comments