From fd34ea90480dba377859182322f3fc8f41fdf9c8 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 00:15:42 +0000 Subject: [PATCH 1/7] MSC3676: Transitioning away from reply fallbacks --- ...transitioning-away-from-reply-fallbacks.md | 88 +++++++++++++++++++ 1 file changed, 88 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 00000000000..12645bf3f9f --- /dev/null +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -0,0 +1,88 @@ +# MSCxxxx: 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 would + not include a textual reply fallback at all. + +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. + +The assertion is 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. + +## 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, as per +above, this feels lower priority than the importance of adding threads to +Matrix, which would be unblocked rapidly by this MSC. + +## 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) From 0857b9d373891d9de7eacf047b422e55a868c52d Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 00:16:15 +0000 Subject: [PATCH 2/7] msc number --- proposals/3676-transitioning-away-from-reply-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index 12645bf3f9f..6be99632cf6 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -1,4 +1,4 @@ -# MSCxxxx: Transitioning away from reply fallbacks. +# MSC3676: Transitioning away from reply fallbacks. ## Problem From d7c7641c883c157b9e4324901b4f41ef32087264 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 00:18:07 +0000 Subject: [PATCH 3/7] md fails --- proposals/3676-transitioning-away-from-reply-fallbacks.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index 6be99632cf6..f6a309fe488 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -16,13 +16,11 @@ 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)). + 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. + 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 From 80e55299ac77096a52dc3a4c64e01101a39ca826 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 00:18:43 +0000 Subject: [PATCH 4/7] typoe --- proposals/3676-transitioning-away-from-reply-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index f6a309fe488..1b78c193967 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -41,7 +41,7 @@ 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.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 would not include a textual reply fallback at all. From e9aeb4c2dafad65d88545c026d053494146b4be6 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 18:00:51 +0000 Subject: [PATCH 5/7] Update proposals/3676-transitioning-away-from-reply-fallbacks.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/3676-transitioning-away-from-reply-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index 1b78c193967..1ff6310a216 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -54,7 +54,7 @@ additional work from landing threads in Replying to a message with an attachment won't trigger a notification, but this is no worse than the behaviour today. -The assertion is that adding threads to Matrix is (much) higher priority and +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 From 8a78065a06cd3fcf7ffa47238aa407907677c6b5 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 18:12:36 +0000 Subject: [PATCH 6/7] incorporate feedback --- .../3676-transitioning-away-from-reply-fallbacks.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index 1ff6310a216..08bd719590e 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -43,8 +43,10 @@ make reply fallbacks best effort. Specifically: * 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 would - not include a textual reply fallback at all. + * 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) @@ -70,6 +72,10 @@ MSC handles thread+fallback notification interaction). However, as per above, this feels lower priority than the importance of adding threads to Matrix, which would be unblocked rapidly by this MSC. +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 From d179d6f0807fd6a10499c090cac43ffaa8581b54 Mon Sep 17 00:00:00 2001 From: Matthew Hodgson Date: Wed, 26 Jan 2022 18:40:16 +0000 Subject: [PATCH 7/7] consolidate justification --- ...6-transitioning-away-from-reply-fallbacks.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/proposals/3676-transitioning-away-from-reply-fallbacks.md b/proposals/3676-transitioning-away-from-reply-fallbacks.md index 08bd719590e..3754e259720 100644 --- a/proposals/3676-transitioning-away-from-reply-fallbacks.md +++ b/proposals/3676-transitioning-away-from-reply-fallbacks.md @@ -56,21 +56,18 @@ additional work from landing threads in Replying to a message with an attachment won't trigger a notification, but this is no worse than the behaviour today. -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. - ## 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, as per -above, this feels lower priority than the importance of adding threads to -Matrix, which would be unblocked rapidly by this MSC. +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