MSC to remove prev_content from the essential keys list
parent
1c5ec68cd0
commit
743eeca27a
@ -0,0 +1,64 @@
|
||||
# Remove prev_content from the essential keys list
|
||||
|
||||
Matrix supports the concept of event redaction. The ability to redact rather
|
||||
than delete is necessary because some events e.g. membership events are
|
||||
essential to the protocol and _cannot_ be deleted. Therefore we do not delete
|
||||
events outright and instead redact them. This involves removing all keys from
|
||||
an event that are not required by the protocol. The stripped down event is
|
||||
thereafter returned anytime a client or remote server requests it.
|
||||
|
||||
|
||||
## Proposal
|
||||
|
||||
[The redaction algorithm](https://matrix.org/docs/spec/client_server/r0.4.0.html#redactions)
|
||||
defines which keys must be retained through a redaction. Currently it lists
|
||||
```prev_content``` as a key to retain, though in practice there is no need to
|
||||
do so at the protocol level.
|
||||
|
||||
The proposal is simply to remove ```prev_content``` from the essential keys
|
||||
list.
|
||||
|
||||
Note: the inclusion of ```prev_content``` in the essential keys list was
|
||||
unintentional and should be considered a spec bug. Synapse (and other server
|
||||
implementations) have not implemented the bug and already omit
|
||||
```prev_content``` from redacted events.
|
||||
|
||||
|
||||
## Tradeoffs
|
||||
|
||||
When sending events over federation the events are [hashed and
|
||||
signed](https://matrix.org/docs/spec/server_server/unstable.html#adding-hashes-and-signatures-to-outgoing-events),
|
||||
this involves operating not only on the original event but also the redacted
|
||||
form of the event. The redacted hash and redacted signed event are necessary if
|
||||
the event is ever redacted in future. As a result, any change of the essential
|
||||
keys list must be managed carefully. If disparate servers implement different
|
||||
versions of the redaction algorithm (for a given event) attempts to send the
|
||||
event over federation will fail.
|
||||
|
||||
We _could_ manage this change via room versioning and create a new room
|
||||
version that implements this MSC. However, because the federation already
|
||||
omits the ```prev_content``` key by convention, implementing this MSC only in
|
||||
the new room version would mean that the entire existing federation would not
|
||||
be spec compliant.
|
||||
|
||||
As a result it seems pragmatic to have the spec reflect reality, acknowledge
|
||||
that the spec and federation have deviated and instead update the spec
|
||||
retrospectively to describe the de-facto redaction algorithm.
|
||||
|
||||
## Potential issues
|
||||
|
||||
It is theoretically possible that a closed federation could exist whose servers
|
||||
do follow the spec as is. This MSC would render those servers uncompliant with
|
||||
the spec. On balance this seems unlikely and in the worst case those
|
||||
implementors could add the change to a subsequent room version, eventually
|
||||
reaching spec consistency as older room versions are deprecated.
|
||||
|
||||
## Security considerations
|
||||
|
||||
I am unaware of any security issues related to this proposal, but can certainly
|
||||
see issues with a precedent that the federation deviates from the spec.
|
||||
|
||||
## Conclusions
|
||||
Removing ```prev_content``` is pragmatic response to the current situation. It
|
||||
alligns the federation and the spec, and does so in a way that removes
|
||||
unecessary overhead.
|
Loading…
Reference in New Issue