|
| 1 | +# MSC4169: Backwards-compatible redaction sending using `/send` |
| 2 | +[MSC2174] moved the `redacts` key from the top level to inside `content` for `v11` and later room versions. It |
| 3 | +also defined forwards- and backwards-compatibility for receiving by defining |
| 4 | +that servers will copy the key to both locations when serving events to clients, regardless of room version. |
| 5 | +The `/redact` endpoint is also forwards-compatible because it works in all room |
| 6 | +versions. However, `/send` was not made backwards-compatible. This means that |
| 7 | +clients can't switch to using `/send` unless they keep track of room versions. |
| 8 | + |
| 9 | +The inability to use `/send` in all room versions makes it more difficult for |
| 10 | +clients to abstract event sending without special-casing redactions and to |
| 11 | +implement features such as self-destructing messages (utilising [MSC4140]'s |
| 12 | +delayed events functionality, which is only implemented for `/send`). |
| 13 | + |
| 14 | +[MSC4140]: https://github.com/matrix-org/matrix-spec-proposals/pull/4140 |
| 15 | +[MSC2174]: https://github.com/matrix-org/matrix-spec-proposals/pull/2174 |
| 16 | + |
| 17 | +## Proposal |
| 18 | +The proposed solution is to have the server move the `redacts` key from the |
| 19 | +content to the top level of the event when `/send/m.room.redaction` is called |
| 20 | +in a pre-v11 room. |
| 21 | + |
| 22 | +## Potential issues |
| 23 | +Servers that don't support this MSC may behave unexpectedly if a client tries |
| 24 | +to redact using `/send` in an old room. Synapse currently throws an assertion |
| 25 | +error (which turns into HTTP 500) when trying to redact with /send in a pre-v11 |
| 26 | +room, which shouldn't cause any issues other than the request failing. Clients |
| 27 | +can avoid issues by confirming server support using `/versions` first. |
| 28 | + |
| 29 | +## Alternatives |
| 30 | +### Client-side switching |
| 31 | +Clients could remember room versions themselves and adjust the endpoint based |
| 32 | +on that. This works fine for thick clients which cache data locally anyway, but |
| 33 | +does not work for things like bots which have minimal local state. |
| 34 | + |
| 35 | +### Just use `/redact` |
| 36 | +`/redact` works fine for all room versions. We could discourage using `/send` |
| 37 | +for redactions and prefer `/redact` instead. However, this would require more |
| 38 | +special-casing for various things that send events, like MSC4140. It is |
| 39 | +preferable to reduce unnecessary special-casing by allowing `/send` in all room |
| 40 | +versions. |
| 41 | + |
| 42 | +### Deprecate `/redact` |
| 43 | +In addition to allowing `/send`, we could encourage everyone to switch over by |
| 44 | +formally deprecating `/redact`. However, there are some other sugar APIs like |
| 45 | +`/ban` which do nothing `/state` can't, so `/redact` is also kept fully |
| 46 | +supported for now. A future MSC may choose to deprecate it. |
| 47 | + |
| 48 | +## Security considerations |
| 49 | +This allows clients to send arbitrary content in pre-v11 redaction events. |
| 50 | +It shouldn't cause any security issues, as it's already possible in v11+ rooms |
| 51 | +or with a modified server. |
| 52 | + |
| 53 | +## Unstable prefix |
| 54 | +The endpoint itself has no unstable prefix as it can already be used to send |
| 55 | +redactions in v11+ rooms. Support for the transformation in old room versions |
| 56 | +can be detected using the `com.beeper.msc4169` unstable feature flag in the |
| 57 | +`/versions` response. The feature flag should continue to be advertised after |
| 58 | +the MSC is accepted until the server advertises support for the stable spec |
| 59 | +release that includes this MSC. |
| 60 | + |
| 61 | +## Dependencies |
| 62 | +None. |
0 commit comments