From 2cd2a7122cd8778c83f94db81621b6833093a9e3 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 2 Feb 2022 14:59:18 +0000 Subject: [PATCH] MSC3676: Transitioning away from reply fallbacks (#3676) * MSC3676: Transitioning away from reply fallbacks * msc number * md fails * typoe * Update proposals/3676-transitioning-away-from-reply-fallbacks.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * incorporate feedback * consolidate justification Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- ...transitioning-away-from-reply-fallbacks.md | 89 +++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 proposals/3676-transitioning-away-from-reply-fallbacks.md diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md new file mode 100644 index 00000000..3754e259 --- /dev/null +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -0,0 +1,89 @@ +# MSC3676: Transitioning away from reply fallbacks. + +## Problem + +As per [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781) +(Remove reply fallbacks), the current reply fallback implementation is very +problematic: + * Its quotes leak history which may not be visible to the user + * The quoted sections may trigger unexpected notifications + * `` tags are hard and dangerous to manipulate, and have caused + multiple vulnerabilities in clients + * They don't localise. + +[MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781) proposes +removing them entirely. However, this triggers a relatively large cascade of +additional dependent work: + * Some users rely on their mxid existing in fallbacks to notified when + someone replies to their messages. So we'd need to create and implement + new push rules to recreate this feature ([MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664)). + * The push rules are even more complicated than expected for this, because + they also would need to stop replies which are used as fallback for + threads (as per [MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440)) + from firing notifications. + * In the absence of fallbacks, in order to render replies simple clients will + now have to parse `m.in_reply_to` objects and fish around for the missing + events (or ask the server to bundle the replies, which is not yet a + thing). + +Meanwhile, [MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440) +(Threads) uses replies as a fallback representation for threads (which is +very desirable to support clients while the threads transition is happening, +or to support simpler clients which support replies but not threads). +However, currently `m.in_reply_to` is only allowed on `m.room.message` events +of msgtype `m.text`, which means it cannot currently be used as a fallback +for arbitrary threaded events. + +## Proposal + +As a transitional step towards removing reply fallbacks entirely, instead: we +make reply fallbacks best effort. Specifically: + + * `m.in_reply_to` is relaxed to apply to any event type + * In practice only `m.room.message` events with msgtype `m.text` or similar + (`m.emote`, `m.notice`) would be able to express reply fallbacks (using the + `m.body`, `format` and `formatted_body` fields). + * Thread events using replies as a fallback representation for threads should + not include a textual reply fallback at all (and so avoid threaded messages + triggering notifications). The same would apply for any other usage which uses + replies as a fallback. + +This means that we can still use reply fallbacks for notification purposes +until that is properly fixed by [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781) +and [MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) - decoupling this +additional work from landing threads in +[MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440). +Replying to a message with an attachment won't trigger a notification, but +this is no worse than the behaviour today. + +## Alternatives + +We could remove fallbacks entirely and do all the subsequent work needed to +support that ([MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781), +[MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) and whatever +MSC handles thread+fallback notification interaction). However, +we believe that adding threads to Matrix is (much) higher priority and +value for Matrix than cleaning up edge cases around reply fallbacks, and +given the two can be decoupled, they should be. The importance of threads is +based on the fact that we're seeing Matrix repeatedly fail to be selected as +a collaboration technology thanks to other alternatives supporting +Slack-style threads. + +We could not use `m.in_reply_to` as a fallback for clients which don't +understand `m.thread`, but this would result in an unnecessarily +terrible fallback for older/transitional/WIP/simple clients. + +## Security + +By temporarily keeping reply fallbacks around on a best effort basis, we're +still vulnerable to their security risks. Client implementors should read +the [security issues highlighted in MSC2781](https://github.com/deepbluev7/matrix-doc/blob/drop-the-fallbacks/proposals/2781-down-with-the-fallbacks.md#appendix-b-issues-with-the-current-fallbacks) +if implementing reply fallbacks. + +## Unstable prefix + +None needed. + +## Dependencies + +None. (MSC3440 will depend on this, however)