From 686873831917b7a4132bbd1d8ec056b5da979664 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 18 Sep 2020 23:44:23 +0200 Subject: [PATCH 01/27] MSC2781: Down with the fallbacks Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 151 ++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 proposals/2781-down-with-the-fallbacks.md diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md new file mode 100644 index 00000000000..2d8f844c54c --- /dev/null +++ b/proposals/2781-down-with-the-fallbacks.md @@ -0,0 +1,151 @@ +# MSC2781: Deprecate fallbacks in the specification + +Currently replies require clients to send and parse a fallback representation of +the replied to message. Something similar is planned for edits. While at least +in theory fallbacks should make it simpler to start supporting replies in a new +client, they actually introduce a lot of complexity and implementation issues +and block a few valuable features. This MSC proposes to deprecate and eventually +remove those fallbacks. It is an alternative to +[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), which intends to +double down on fallbacks. + +### Issues with the current fallbacks + +#### Stripping the fallback + +To reply to a reply, a client needs to strip the existing fallback of the first +reply. Otherwise replies will just infinitely nest replies. [While the spec doesn't necessarily require that](https://github.com/matrix-org/matrix-doc/issues/1541), +not doing so risks running into the event size limit, but more importantly, it +just leads to a bad experience for clients actually relying on the fallback. + +Stripping the fallback sadly is not trivial. Most clients did that wrong at some +point. At the point of writing this, FluffyChat seems to fail stripping the +fallback, while Riot/Element did fail to do so in the past, when `` +tags were not evenly matched. Since clients can send arbitrary byte sequences, +every client needs to basically parse untrusted input and sanitize it. A normal +html parser will fail stripping a `` sequence in +some cases. If you use a regex to strip the fallback, you may be able to be +attacked using regex DOS attacks (although that is somewhat mitigated by the +maximum event size). In the end there are quite a few edge cases, that are not +covered in the existing specification, since it doesn't specify the exact rules +to strip a fallback at all. + +Stripping the fallback from body is even more complicated, since there is no way +to distinguish a quote from a reply reliably. + +#### Creating a new fallback + +To create a new fallback, a client needs to add untrusted html to its own +events. This is an easy attack vector to inject your own content into someone +elses reply. While this can be prevented with enough care, since Riot basically +had to fix this issue twice, it can be expected that other clients can also be +affected by this. + +#### Requirement of html for replies + +The spec requires rich replies to have a fallback using html: + +> Rich replies MUST have a format of org.matrix.custom.html and therefore a formatted_body alongside the body and appropriate msgtype. + +This means you can't reply using only a `body` and you can't reply with an +image, since those don't have a `formatted_body` property currently. This means +a text only client, that doesn't want to display html, still needs to support +html anyway and that new features are blocked, because of fallbacks. + +This is also an issue with edits, where the combination of edit fallback and +reply fallback is somewhat interesting: You need to send a fallback, since the +event is still a reply, but you can't send a reply relation, since this is an +edit. So for clients relying on the edit fallback, you send a broken reply +fallback, that doesn't get stripped, even when the client supports rich replies. + +#### Replies leak history + +A reply includes the `body` of another event. This means a reply to an event can +leak data to users, that joined this room at a later point, but shouldn't be +able to see the event because of visibility rules or encryption. While this +isn't a big issue, there is still an issue about it: https://github.com/matrix-org/matrix-doc/issues/1654 + +Replies are also sometimes localized. In those cases they leak the users +language selection for their client, which may be personal information. + +#### Low value of fallbacks + +The above issues would be somewhat acceptable, if reply fallbacks would provide +some value to clients. Generally they don't though. The Qt html renderer breaks +on `` tags, so you need to strip them anyway to render replies. +Bridges usually try to bridge to native replies, so they need to strip the reply +part (https://github.com/matrix-org/matrix-doc/issues/1541). Even the IRC bridge +seems to send a custom fallback, because the default fallback is not that +welcome to the IRC crowd. + +Clients that actually use the fallback (original Riot/Android for example) tend +to do so for quite some while, because the fallbacks are "good enough", but in +the end that provides a worse experience for everyone involved. For example you +couldn't see what image was replied to for the longest time. Just "X replied to +an image with: I like this one" is not valuable, when 3 images were sent. + +Only replies to actual text messages have a somewhat reasonable fallback. The +other ones do not provide any more value than a plain "this is a reply" tag, +unless the client also already supports event links. + +## Proposal + +Deprecate the rich reply fallback. Clients should stop sending them and should +consider treating `` parts as either something to be unconditionally +stripped or as something to be escaped as invalid html. In the future the +fallback should be removed from the spec completely with only a note left, that +it may exist in old events. + +Furthermore, no fallback should be used for edits, since just adding an asterisk +before the same message does not provide much value to users and it complicates +the implementation of edits for no tangible benefit. + +The fallback for more niche features, like in room verification can stay, since +that feature is actually somewhat hard to implement and some clients may never +support encryption. + +As a result of this, you would be able to reply with an image or edit a video. +New clients would also be able to implement edits and replies more easily, as +they can sidestep a lot of pitfalls. + +## Potential issues + +Obviously you can't remove the fallback from old events. As such clients would +still need to do something with them in the near future. I'd say just not +handling them in a special way should be okay after some unspecified period of +time. + +Clients not implementing rich replies or edits may show some slightly more +confusing messages to users as well. I'd argue though that in most cases, the +reply is close enough to the replied to message, that you would be able to guess +the correct context. Replies would also be somewhat easier to implement and +worst case, a client could very easily implement a little "this is a reply" +marker to at least mark replies visually. + +Same applies to edits. If 2 very similar messages appear after one another, +someone new to online messaging would assume, this is a correction to the +previous message. That may even be more obvious to them than if the message was +prefixed with a `*`, since that has been confusing to users in the past. Since +edits would now look exactly like a normal message, they would also be +considerably easier to implement, since you jus need to replace the former +message now, similar to a redaction, and not merge `content` and `new_content`. + +## Alternatives + +[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589): This adds the +reply text as an addional key. While this solves the parsing issues, it +doesn't address the other issues with fallbacks. + +One could also just stick with the current fallbacks and make all clients pay +the cost for a small number of clients actually benefitting from them. + +## Security considerations + +Removing the fallback from the spec may lead to issues, when clients experience +the fallback in old events. This should not add any security issues the +client didn't already have from interpreting untrusted html, though. In all +other cases this should **reduce** security issues. + +## Unstable prefix + +Seems unnecessary, since this only removes stuff. From 8d8b38dc35ccbd8deedde020908ecb59b6b75cd6 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Sat, 19 Sep 2020 00:35:19 +0200 Subject: [PATCH 02/27] Add a note about dropping the html requirement Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 2d8f844c54c..00cf2efb9be 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -94,7 +94,8 @@ Deprecate the rich reply fallback. Clients should stop sending them and should consider treating `` parts as either something to be unconditionally stripped or as something to be escaped as invalid html. In the future the fallback should be removed from the spec completely with only a note left, that -it may exist in old events. +it may exist in old events. Clients may send replies without a formatted_body +now. Furthermore, no fallback should be used for edits, since just adding an asterisk before the same message does not provide much value to users and it complicates From 94cffdcd98050a443ec2c8a21c2c4ad1aaa77790 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Sat, 19 Sep 2020 00:43:02 +0200 Subject: [PATCH 03/27] Add an unstable prefix for removed fallbacks. Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 00cf2efb9be..b06b1576faa 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -149,4 +149,6 @@ other cases this should **reduce** security issues. ## Unstable prefix -Seems unnecessary, since this only removes stuff. +Clients should use the prefix `im.nheko.msc2781.` for all their event types, if +they implement this MSC in a publicly available release or events may otherwise +bleed into public rooms. From 18a2732b95138269341081c88baa644dd69b4ca2 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Sat, 19 Sep 2020 01:21:38 +0200 Subject: [PATCH 04/27] Add a section about fallbacks not being properly specified. Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index b06b1576faa..b085ce3baed 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -58,6 +58,18 @@ event is still a reply, but you can't send a reply relation, since this is an edit. So for clients relying on the edit fallback, you send a broken reply fallback, that doesn't get stripped, even when the client supports rich replies. +#### Format is somewhat badly specified + +Further complicating the stripping and creation portion of fallbacks is, that +they are somewhat badly specified. While the fallback and html use are required, +the spec only says how a fallback "should" look, not how it "must" look. In +practice there are various variations of the fallback floating around, where the +tame ones are just localized, but others are just straight up missing suggested +links or tags. + +Basically a client can't rely on the fallback being present currently or it +folllowing any kind of shape or form. + #### Replies leak history A reply includes the `body` of another event. This means a reply to an event can From 8e7c44b51f35295569bab130e539d586a6f86800 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Thu, 1 Oct 2020 21:49:10 +0200 Subject: [PATCH 05/27] Add appendix about which clients do not support replies (and why, if possible) Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 28 ++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index b085ce3baed..baef9ea3262 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -140,7 +140,7 @@ someone new to online messaging would assume, this is a correction to the previous message. That may even be more obvious to them than if the message was prefixed with a `*`, since that has been confusing to users in the past. Since edits would now look exactly like a normal message, they would also be -considerably easier to implement, since you jus need to replace the former +considerably easier to implement, since you just need to replace the former message now, similar to a redaction, and not merge `content` and `new_content`. ## Alternatives @@ -159,6 +159,32 @@ the fallback in old events. This should not add any security issues the client didn't already have from interpreting untrusted html, though. In all other cases this should **reduce** security issues. +## Appendix A: Clients not supporting rich replies + +Of the 18 clients listed in the [matrix client matrix](https://matrix.org/client-matrix) +10 are listed as not supporting replies: + +- weechat-matrix: Actually has an [implementation](https://github.com/poljar/weechat-matrix/issues/86) although it may be [broken](https://github.com/poljar/weechat-matrix/issues/233). +- Quaternion: [Blocked because of fallbacks](https://github.com/quotient-im/libQuotient/issues/245). +- matrixcli: [Doesn't support formatted messages](https://github.com/ahmedsaadxyzz/matrixcli/issues/10). +- Ditto Chat: [Doesn't support replying?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/83), but [does some special stuff for rendering?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/8) +- Mirage: Supports rich replies, but has [doesn't strip the fallback correctly](https://github.com/mirukana/mirage/issues/89) and uses the fallback to render them. +- Fractal: [Unsupported](https://gitlab.gnome.org/GNOME/fractal/-/issues/194). Has some reports, that the fallback doesn't look nice though. +- Nio: [Unsupported](https://github.com/niochat/nio/issues/85). +- Pattle: Client is not being developed anymore. +- Seaglass: Doesn't support rich replies, but is [unhappy with how the fallback looks](https://github.com/neilalexander/seaglass/issues/51)? +- Miitrix: Somewhat unlikely to support it, I guess? +- matrix-commander: No idea. + +So in summary, half of the listed clients don't support replies. At least one +client doesn't support it because of the fallback (Quaternion). 3 of the command +line clients probably won't support replies, since they don't support formatted +messages and replies require html support for at least sending. Fractal and Nio +don't seem to use html for rendering either. It would be interesting to hear the +opionion of the developers of those clients, if dropping the fallback would +negatively impact them or if they would be fine with implementing proper +replies. + ## Unstable prefix Clients should use the prefix `im.nheko.msc2781.` for all their event types, if From ff76870aa7683193a11681c354d5e78284722099 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Thu, 1 Oct 2020 22:57:48 +0200 Subject: [PATCH 06/27] Correct weechat status Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index baef9ea3262..79c79d021a2 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -164,7 +164,7 @@ other cases this should **reduce** security issues. Of the 18 clients listed in the [matrix client matrix](https://matrix.org/client-matrix) 10 are listed as not supporting replies: -- weechat-matrix: Actually has an [implementation](https://github.com/poljar/weechat-matrix/issues/86) although it may be [broken](https://github.com/poljar/weechat-matrix/issues/233). +- weechat-matrix: Actually has an [implementation](https://github.com/poljar/weechat-matrix/issues/86) to send replies although it may be [broken](https://github.com/poljar/weechat-matrix/issues/233). Doesn't render rich replies. Hard to implement because of the single socket implementation, but may be easier in the Rust version. - Quaternion: [Blocked because of fallbacks](https://github.com/quotient-im/libQuotient/issues/245). - matrixcli: [Doesn't support formatted messages](https://github.com/ahmedsaadxyzz/matrixcli/issues/10). - Ditto Chat: [Doesn't support replying?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/83), but [does some special stuff for rendering?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/8) From 74dc8d87779074fa1453754af7c058a622fc49be Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Mon, 10 May 2021 22:25:27 +0200 Subject: [PATCH 07/27] Add another alternative Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 79c79d021a2..1d7d2785188 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -152,6 +152,14 @@ doesn't address the other issues with fallbacks. One could also just stick with the current fallbacks and make all clients pay the cost for a small number of clients actually benefitting from them. +Lastly one could introduce an alternative relation type for replies without +fallback and deprecate the current relation type (since it does not fit the new +format for relations anyway). We could specify, that the server is supposed to +send the replied_to event in unsigned to the client, so that clients just need +to stitch those two events together, but don't need to fetch the replied_to +event from the server. It would make replies slightly harder to implement for +clients, but it would be simpler than what this MSC proposes. + ## Security considerations Removing the fallback from the spec may lead to issues, when clients experience From c8e437734aa2bb1c7b73a7effe8f3d72b4f3f3d9 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Mon, 10 May 2021 22:42:25 +0200 Subject: [PATCH 08/27] Document a few more issues with fallbacks Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 1d7d2785188..10aad09df98 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -100,6 +100,26 @@ Only replies to actual text messages have a somewhat reasonable fallback. The other ones do not provide any more value than a plain "this is a reply" tag, unless the client also already supports event links. +#### Fallback discussion blocks new features + +On any proposal that wants to enable replies to other events or replies with +other events, the discussion around "how to handle the fallback" happens. Any +such MSC needs to specify, how the fallback should look like and the events need +to support the `formatted_body` field. This blocks a lot of improvements, that +could be done to replies as a whole. Often commentors even ask for the issues +with fallbacks to be fixed on that MSC. + +#### Localization + +Since the fallback is added as normal text into the message, it needs to be +localized for the receiving party to understand it. This however proves to be a +challenge, since users may switch languages freely in a room and it is not easy +to guess, which language was used in a short message. One could also use the +client's language, but that leaks the user's localization settings, which can be a +privacy concern and the other party may not speak that language. Alternatively a +client can just send english fallbacks, but that significantly worsens the +experience for casual users in non-english speaking countries. + ## Proposal Deprecate the rich reply fallback. Clients should stop sending them and should From 7caeb628b8fd2ac3399eb14c41168063aae7ff45 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:08:23 +0100 Subject: [PATCH 09/27] Update client status, remove proposal for edits and try to turn down the language a bit Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 295 ++++++++++++---------- 1 file changed, 159 insertions(+), 136 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 10aad09df98..6006d354075 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -1,4 +1,4 @@ -# MSC2781: Deprecate fallbacks in the specification +# MSC2781: Remove reply fallbacks from the specification Currently replies require clients to send and parse a fallback representation of the replied to message. Something similar is planned for edits. While at least @@ -9,31 +9,140 @@ remove those fallbacks. It is an alternative to [MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), which intends to double down on fallbacks. -### Issues with the current fallbacks +## Proposal + +Remove the rich reply fallback from the specification. Clients should stop +sending them and should consider treating `` parts as either something +to be unconditionally stripped or as something to be escaped as invalid html. +Clients may send replies without a formatted_body now using arbitrary message +events (not state events). + +As a result of this, you would be able to reply with an image. New clients +would also be able to implement edits and replies more easily, as they can +sidestep a lot of pitfalls. + +An extended motivation is provided at [the end of this document](Appendix-B:-Issues-with-the-current-fallbacks). + +There are similar benefit for not adding a fallback to edits. This proposal +focuses on replies for simplicity, but encourages +[MSC2676](https://github.com/matrix-org/matrix-doc/pull/2676) to drop the edit +fallback or remove it [when moving to extensible +events](https://github.com/matrix-org/matrix-doc/pull/3644). + +## Potential issues + +Obviously you can't remove the fallback from old events. As such clients would +still need to do something with them in the near future. I'd say just not +handling them in a special way should be okay after some unspecified period of +time. + +Clients not implementing rich replies or edits may show some slightly more +confusing messages to users as well. I'd argue though that in most cases, the +reply is close enough to the replied to message, that you would be able to guess +the correct context. Replies would also be somewhat easier to implement and +worst case, a client could very easily implement a little "this is a reply" +marker to at least mark replies visually. + +Same applies to edits. If 2 very similar messages appear after one another, +someone new to online messaging would assume, this is a correction to the +previous message. That may even be more obvious to them than if the message was +prefixed with a `*`, since that has been confusing to users in the past. Since +edits would now look exactly like a normal message, they would also be +considerably easier to implement, since you just need to replace the former +message now, similar to a redaction, and not merge `content` and `new_content`. + +## Alternatives + +[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589): This adds the +reply text as an addional key. While this solves the parsing issues, it +doesn't address the other issues with fallbacks. + +One could also just stick with the current fallbacks and make all clients pay +the cost for a small number of clients actually benefitting from them. + +Lastly one could introduce an alternative relation type for replies without +fallback and deprecate the current relation type (since it does not fit the new +format for relations anyway). We could specify, that the server is supposed to +send the replied_to event in unsigned to the client, so that clients just need +to stitch those two events together, but don't need to fetch the replied_to +event from the server. It would make replies slightly harder to implement for +clients, but it would be simpler than what this MSC proposes. + +## Security considerations + +Removing the fallback from the spec may lead to issues, when clients experience +the fallback in old events. This should not add any security issues the +client didn't already have from interpreting untrusted html, though. In all +other cases this should **reduce** security issues. + +## Appendix A: Clients not supporting rich replies + +Of the 23 clients listed in the [matrix client matrix](https://matrix.org/clients-matrix) +16 are listed as not supporting replies: + +- Element Android: Relies on the reply fallback. +- Element iOS: [Does not support rich replies](https://github.com/vector-im/element-ios/issues/3517) +- weechat-matrix: Actually has an [implementation](https://github.com/poljar/weechat-matrix/issues/86) to send replies although it seems to be [broken](https://github.com/poljar/weechat-matrix/issues/233). Doesn't render rich replies. Hard to implement because of the single socket implementation, but may be easier in the Rust version. +- Quaternion: [Blocked because of fallbacks](https://github.com/quotient-im/libQuotient/issues/245). +- matrixcli: [Doesn't support formatted messages](https://github.com/ahmedsaadxyzz/matrixcli/issues/10). +- Ditto Chat: [Seems to rely on the fallback](https://gitlab.com/ditto-chat/ditto/-/blob/main/mobile/scenes/chat/components/Html.tsx#L38) +- Mirage: Supports rich replies, but [doesn't strip the fallback correctly](https://github.com/mirukana/mirage/issues/89) and uses the fallback to render them. +- Nio: [Unsupported](https://github.com/niochat/nio/issues/85). +- Pattle: Client is not being developed anymore. +- Seaglass: Doesn't support rich replies, but is [unhappy with how the fallback looks](https://github.com/neilalexander/seaglass/issues/51)? +- Miitrix: Somewhat unlikely to support it, I guess? +- matrix-commander: No idea, but doesn't look like it. +- gotktrix: [Seems to rely on the reply fallback](https://github.com/diamondburned/gotktrix/blob/5f2783d633560421746a82aab71d4f7421e4b99c/internal/app/messageview/message/mcontent/text/html.go#L437) +- Hydrogen: [Seems to use the reply fallback](https://github.com/vector-im/hydrogen-web/blob/c3177b06bf9f760aac2bfd5039342422b7ec8bb4/doc/impl-thoughts/PENDING_REPLIES.md) +- kazv: Doesn't seem to support replies at all +- Syphon: [Uses the reply fallback in body](https://github.com/syphon-org/syphon/blob/fa44c5abe37bdd256a9cb61cbc8552e0e539cdce/lib/views/widgets/messages/message.dart#L368) + +So in summary, 3/4 of the listed clients don't support replies. At least one +client doesn't support it because of the fallback (Quaternion). 3 of the command +line clients probably won't support replies, since they don't support formatted +messages and replies require html support for at least sending. + +Only one client implemented rich replies in the last 1.5 years. Other clients +are either new in my list or didn't change their reply rendering. I would +appreciate to hear, why those client developers decided not to support rich +reply rendering and if dropping the reply fallback would be an issue for them. + +Changes from 1.5 years ago: + +- Fractal: [Seems to support replies now!](https://gitlab.gnome.org/GNOME/fractal/-/merge_requests/941) +- Commune: Seems to support rich reply rendering and style them very nicely. +- NeoChat: [Supports rich replies](https://invent.kde.org/network/neochat/-/blob/master/src/utils.h#L21) +- Cinny: [Seems to support rich replies](https://github.com/ajbura/cinny/blob/6ff339b552e242f6233abd86768bb2373b150f77/src/app/molecules/message/Message.jsx#L111) +- gomuks: [Strips the reply fallback](https://github.com/tulir/gomuks/blob/3510d223b2d765572bf2e97222f2f55d099119f0/ui/messages/html/parser.go#L361) +- Lots of other new clients! + + +## Appendix B: Issues with the current fallbacks + +This section was moved to the back of this MSC, because it is fairly long and +exhaustive. It lists all the issues the proposal author personally experienced +with fallbacks in their client and its interactions with the ecosystem. -#### Stripping the fallback +### Stripping the fallback To reply to a reply, a client needs to strip the existing fallback of the first reply. Otherwise replies will just infinitely nest replies. [While the spec doesn't necessarily require that](https://github.com/matrix-org/matrix-doc/issues/1541), not doing so risks running into the event size limit, but more importantly, it just leads to a bad experience for clients actually relying on the fallback. -Stripping the fallback sadly is not trivial. Most clients did that wrong at some -point. At the point of writing this, FluffyChat seems to fail stripping the -fallback, while Riot/Element did fail to do so in the past, when `` -tags were not evenly matched. Since clients can send arbitrary byte sequences, -every client needs to basically parse untrusted input and sanitize it. A normal -html parser will fail stripping a `` sequence in -some cases. If you use a regex to strip the fallback, you may be able to be -attacked using regex DOS attacks (although that is somewhat mitigated by the -maximum event size). In the end there are quite a few edge cases, that are not -covered in the existing specification, since it doesn't specify the exact rules -to strip a fallback at all. +Stripping the fallback is not trivial. Multiple implementations had bugs in +their fallback stripping logic. The edge cases are not covered in the +specification in detail and some clients have interpreted them differently. +Common mistakes include: + +- Not stripping the fallback in body, which leads to a very long nested chain. +- Not dealing with mismatched `` tags, which can look like you were + impersonating someone. Stripping the fallback from body is even more complicated, since there is no way to distinguish a quote from a reply reliably. -#### Creating a new fallback +### Creating a new fallback To create a new fallback, a client needs to add untrusted html to its own events. This is an easy attack vector to inject your own content into someone @@ -41,7 +150,7 @@ elses reply. While this can be prevented with enough care, since Riot basically had to fix this issue twice, it can be expected that other clients can also be affected by this. -#### Requirement of html for replies +### Requirement of html for replies The spec requires rich replies to have a fallback using html: @@ -55,10 +164,20 @@ html anyway and that new features are blocked, because of fallbacks. This is also an issue with edits, where the combination of edit fallback and reply fallback is somewhat interesting: You need to send a fallback, since the event is still a reply, but you can't send a reply relation, since this is an -edit. So for clients relying on the edit fallback, you send a broken reply -fallback, that doesn't get stripped, even when the client supports rich replies. +edit. Currently this is solved by not sending a reply fallback in edits, so +clients can't rely on a reply fallback in all cases. + +We currently can see 2 behaviours in practice: + +Client A supports rich reply rendering, Client B does not. -#### Format is somewhat badly specified +- A sends an edit. This according to MSC2676 does not include a reply fallback. + A properly sees the edit still as a reply. B does not. +- B sends an edit but includes a reply fallback in the body. It can still see + that the message is a reply. A needs to strip the invalid reply fallback, or + it will see the reply content twice. + +### Format is unreliable Further complicating the stripping and creation portion of fallbacks is, that they are somewhat badly specified. While the fallback and html use are required, @@ -68,9 +187,10 @@ tame ones are just localized, but others are just straight up missing suggested links or tags. Basically a client can't rely on the fallback being present currently or it -folllowing any kind of shape or form. +following any kind of shape or form and stripping is done on a best effort +basis, especially for the fallback in `body`. -#### Replies leak history +### Replies leak history A reply includes the `body` of another event. This means a reply to an event can leak data to users, that joined this room at a later point, but shouldn't be @@ -80,36 +200,32 @@ isn't a big issue, there is still an issue about it: https://github.com/matrix-o Replies are also sometimes localized. In those cases they leak the users language selection for their client, which may be personal information. -#### Low value of fallbacks +### Using the unmodified fallback in clients and bridges -The above issues would be somewhat acceptable, if reply fallbacks would provide -some value to clients. Generally they don't though. The Qt html renderer breaks -on `` tags, so you need to strip them anyway to render replies. -Bridges usually try to bridge to native replies, so they need to strip the reply -part (https://github.com/matrix-org/matrix-doc/issues/1541). Even the IRC bridge +The above issues are minor, if reply fallbacks would sufficiend value to +clients. However at least the Qt html renderer breaks on `` tags, so +you need to strip them anyway to render replies. Bridges usually try to bridge +to native replies, so they need to strip the reply fallback +(https://github.com/matrix-org/matrix-doc/issues/1541). Even the IRC bridge seems to send a custom fallback, because the default fallback is not that welcome to the IRC crowd. -Clients that actually use the fallback (original Riot/Android for example) tend -to do so for quite some while, because the fallbacks are "good enough", but in -the end that provides a worse experience for everyone involved. For example you -couldn't see what image was replied to for the longest time. Just "X replied to -an image with: I like this one" is not valuable, when 3 images were sent. +Some clients do choose not to implement rich reply rendering, but the experience +tends to not be ideal, especially in cases where you reply to an image and now +the user needs to guess, what image was being replied to. -Only replies to actual text messages have a somewhat reasonable fallback. The -other ones do not provide any more value than a plain "this is a reply" tag, -unless the client also already supports event links. +As a result the fallbacks provide value to only a subset of the Matrix +ecosystem. -#### Fallback discussion blocks new features +### Fallback increase integration work with new features -On any proposal that wants to enable replies to other events or replies with -other events, the discussion around "how to handle the fallback" happens. Any -such MSC needs to specify, how the fallback should look like and the events need -to support the `formatted_body` field. This blocks a lot of improvements, that -could be done to replies as a whole. Often commentors even ask for the issues -with fallbacks to be fixed on that MSC. +- [Edits explicitly mention](https://github.com/matrix-org/matrix-doc/pull/2676) + that a reply fallback should not be sent in the `m.new_content`. +- [Extensible events](https://github.com/matrix-org/matrix-doc/pull/1767) would + need to specify how the fallback should look like. [Alternatively they could + also drop it](https://github.com/matrix-org/matrix-doc/pull/3644). -#### Localization +### Localization Since the fallback is added as normal text into the message, it needs to be localized for the receiving party to understand it. This however proves to be a @@ -120,99 +236,6 @@ privacy concern and the other party may not speak that language. Alternatively a client can just send english fallbacks, but that significantly worsens the experience for casual users in non-english speaking countries. -## Proposal - -Deprecate the rich reply fallback. Clients should stop sending them and should -consider treating `` parts as either something to be unconditionally -stripped or as something to be escaped as invalid html. In the future the -fallback should be removed from the spec completely with only a note left, that -it may exist in old events. Clients may send replies without a formatted_body -now. - -Furthermore, no fallback should be used for edits, since just adding an asterisk -before the same message does not provide much value to users and it complicates -the implementation of edits for no tangible benefit. - -The fallback for more niche features, like in room verification can stay, since -that feature is actually somewhat hard to implement and some clients may never -support encryption. - -As a result of this, you would be able to reply with an image or edit a video. -New clients would also be able to implement edits and replies more easily, as -they can sidestep a lot of pitfalls. - -## Potential issues - -Obviously you can't remove the fallback from old events. As such clients would -still need to do something with them in the near future. I'd say just not -handling them in a special way should be okay after some unspecified period of -time. - -Clients not implementing rich replies or edits may show some slightly more -confusing messages to users as well. I'd argue though that in most cases, the -reply is close enough to the replied to message, that you would be able to guess -the correct context. Replies would also be somewhat easier to implement and -worst case, a client could very easily implement a little "this is a reply" -marker to at least mark replies visually. - -Same applies to edits. If 2 very similar messages appear after one another, -someone new to online messaging would assume, this is a correction to the -previous message. That may even be more obvious to them than if the message was -prefixed with a `*`, since that has been confusing to users in the past. Since -edits would now look exactly like a normal message, they would also be -considerably easier to implement, since you just need to replace the former -message now, similar to a redaction, and not merge `content` and `new_content`. - -## Alternatives - -[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589): This adds the -reply text as an addional key. While this solves the parsing issues, it -doesn't address the other issues with fallbacks. - -One could also just stick with the current fallbacks and make all clients pay -the cost for a small number of clients actually benefitting from them. - -Lastly one could introduce an alternative relation type for replies without -fallback and deprecate the current relation type (since it does not fit the new -format for relations anyway). We could specify, that the server is supposed to -send the replied_to event in unsigned to the client, so that clients just need -to stitch those two events together, but don't need to fetch the replied_to -event from the server. It would make replies slightly harder to implement for -clients, but it would be simpler than what this MSC proposes. - -## Security considerations - -Removing the fallback from the spec may lead to issues, when clients experience -the fallback in old events. This should not add any security issues the -client didn't already have from interpreting untrusted html, though. In all -other cases this should **reduce** security issues. - -## Appendix A: Clients not supporting rich replies - -Of the 18 clients listed in the [matrix client matrix](https://matrix.org/client-matrix) -10 are listed as not supporting replies: - -- weechat-matrix: Actually has an [implementation](https://github.com/poljar/weechat-matrix/issues/86) to send replies although it may be [broken](https://github.com/poljar/weechat-matrix/issues/233). Doesn't render rich replies. Hard to implement because of the single socket implementation, but may be easier in the Rust version. -- Quaternion: [Blocked because of fallbacks](https://github.com/quotient-im/libQuotient/issues/245). -- matrixcli: [Doesn't support formatted messages](https://github.com/ahmedsaadxyzz/matrixcli/issues/10). -- Ditto Chat: [Doesn't support replying?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/83), but [does some special stuff for rendering?](https://gitlab.com/ditto-chat/ditto-mobile/-/issues/8) -- Mirage: Supports rich replies, but has [doesn't strip the fallback correctly](https://github.com/mirukana/mirage/issues/89) and uses the fallback to render them. -- Fractal: [Unsupported](https://gitlab.gnome.org/GNOME/fractal/-/issues/194). Has some reports, that the fallback doesn't look nice though. -- Nio: [Unsupported](https://github.com/niochat/nio/issues/85). -- Pattle: Client is not being developed anymore. -- Seaglass: Doesn't support rich replies, but is [unhappy with how the fallback looks](https://github.com/neilalexander/seaglass/issues/51)? -- Miitrix: Somewhat unlikely to support it, I guess? -- matrix-commander: No idea. - -So in summary, half of the listed clients don't support replies. At least one -client doesn't support it because of the fallback (Quaternion). 3 of the command -line clients probably won't support replies, since they don't support formatted -messages and replies require html support for at least sending. Fractal and Nio -don't seem to use html for rendering either. It would be interesting to hear the -opionion of the developers of those clients, if dropping the fallback would -negatively impact them or if they would be fine with implementing proper -replies. - ## Unstable prefix Clients should use the prefix `im.nheko.msc2781.` for all their event types, if From 1539dcd8ecf3e685166853f8d6cd90765b9659ed Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:12:39 +0100 Subject: [PATCH 10/27] Remove mistaken reference to the Qt renderer Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 6006d354075..0c14c412476 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -203,9 +203,8 @@ language selection for their client, which may be personal information. ### Using the unmodified fallback in clients and bridges The above issues are minor, if reply fallbacks would sufficiend value to -clients. However at least the Qt html renderer breaks on `` tags, so -you need to strip them anyway to render replies. Bridges usually try to bridge -to native replies, so they need to strip the reply fallback +clients. Bridges usually try to bridge to native replies, so they need to +strip the reply fallback (https://github.com/matrix-org/matrix-doc/issues/1541). Even the IRC bridge seems to send a custom fallback, because the default fallback is not that welcome to the IRC crowd. From 98df79dab73004cc47c76446071457b228e58d73 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:19:41 +0100 Subject: [PATCH 11/27] Try to make motivation a bit clearer in the proposal Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 0c14c412476..e115d254e90 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -19,9 +19,10 @@ events (not state events). As a result of this, you would be able to reply with an image. New clients would also be able to implement edits and replies more easily, as they can -sidestep a lot of pitfalls. +sidestep a lot of pitfalls. This should improve the look and feel of replies in +Matrix across all clients in the long term. -An extended motivation is provided at [the end of this document](Appendix-B:-Issues-with-the-current-fallbacks). +An extended motivation is provided at [the end of this document](user-content-appendix-b-issues-with-the-current-fallbacks). There are similar benefit for not adding a fallback to edits. This proposal focuses on replies for simplicity, but encourages From b05e0a2f7e4899f0689f08eebfe2bf64b99dea07 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:21:06 +0100 Subject: [PATCH 12/27] How do anchors work? Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index e115d254e90..78c5a4c8dee 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -22,7 +22,7 @@ would also be able to implement edits and replies more easily, as they can sidestep a lot of pitfalls. This should improve the look and feel of replies in Matrix across all clients in the long term. -An extended motivation is provided at [the end of this document](user-content-appendix-b-issues-with-the-current-fallbacks). +An extended motivation is provided at [the end of this document](#user-content-appendix-b-issues-with-the-current-fallbacks). There are similar benefit for not adding a fallback to edits. This proposal focuses on replies for simplicity, but encourages From 60c33c3eb4f5b8b345821a8322b22d57098b580f Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:27:53 +0100 Subject: [PATCH 13/27] Drop reference to issues with edit fallbacks Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 78c5a4c8dee..ff813f6baab 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -44,13 +44,13 @@ the correct context. Replies would also be somewhat easier to implement and worst case, a client could very easily implement a little "this is a reply" marker to at least mark replies visually. -Same applies to edits. If 2 very similar messages appear after one another, +~~Same applies to edits. If 2 very similar messages appear after one another, someone new to online messaging would assume, this is a correction to the previous message. That may even be more obvious to them than if the message was prefixed with a `*`, since that has been confusing to users in the past. Since edits would now look exactly like a normal message, they would also be considerably easier to implement, since you just need to replace the former -message now, similar to a redaction, and not merge `content` and `new_content`. +message now, similar to a redaction, and not merge `content` and `new_content`.~~ ## Alternatives From 838f0ce0996267aff80285fa1a3d008996a17027 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 14 Jan 2022 07:32:30 +0100 Subject: [PATCH 14/27] Typos Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index ff813f6baab..6de61673a38 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -24,7 +24,7 @@ Matrix across all clients in the long term. An extended motivation is provided at [the end of this document](#user-content-appendix-b-issues-with-the-current-fallbacks). -There are similar benefit for not adding a fallback to edits. This proposal +There are similar benefits to not adding a fallback to edits. This proposal focuses on replies for simplicity, but encourages [MSC2676](https://github.com/matrix-org/matrix-doc/pull/2676) to drop the edit fallback or remove it [when moving to extensible From 2380162de4496545c3043aca84cf82b61fafa63c Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Wed, 19 Jan 2022 03:22:33 +0100 Subject: [PATCH 15/27] Address review comments Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 129 ++++++++++++++-------- 1 file changed, 80 insertions(+), 49 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 6de61673a38..a7a8c5f23ca 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -5,30 +5,31 @@ the replied to message. Something similar is planned for edits. While at least in theory fallbacks should make it simpler to start supporting replies in a new client, they actually introduce a lot of complexity and implementation issues and block a few valuable features. This MSC proposes to deprecate and eventually -remove those fallbacks. It is an alternative to -[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), which intends to -double down on fallbacks. +remove those fallbacks. It was an alternative to +[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), which chose a +different representation of the reply fallback, but was ultimately closed in +favor of this proposal. ## Proposal -Remove the rich reply fallback from the specification. Clients should stop -sending them and should consider treating `` parts as either something -to be unconditionally stripped or as something to be escaped as invalid html. -Clients may send replies without a formatted_body now using arbitrary message -events (not state events). +Remove the [rich reply fallback from the +specification](https://spec.matrix.org/v1.1/client-server-api/#fallbacks-for-rich-replies). +Clients should stop sending them and should consider treating `` parts +as either something to be unconditionally stripped or as something to be escaped +as invalid html. Clients may send replies without a formatted_body now using +arbitrary message events (not state events), which is currently still disallowed +by the +[specification](https://spec.matrix.org/v1.1/client-server-api/#rich-replies). As a result of this, you would be able to reply with an image. New clients would also be able to implement edits and replies more easily, as they can -sidestep a lot of pitfalls. This should improve the look and feel of replies in -Matrix across all clients in the long term. +sidestep a lot of pitfalls. -An extended motivation is provided at [the end of this document](#user-content-appendix-b-issues-with-the-current-fallbacks). +Given clients have had enough time to implement replies completely, the +overall look & feel of replies should be unchanged or even improved by this +proposal. -There are similar benefits to not adding a fallback to edits. This proposal -focuses on replies for simplicity, but encourages -[MSC2676](https://github.com/matrix-org/matrix-doc/pull/2676) to drop the edit -fallback or remove it [when moving to extensible -events](https://github.com/matrix-org/matrix-doc/pull/3644). +An extended motivation is provided at [the end of this document](#user-content-appendix-b-issues-with-the-current-fallbacks). ## Potential issues @@ -42,15 +43,19 @@ confusing messages to users as well. I'd argue though that in most cases, the reply is close enough to the replied to message, that you would be able to guess the correct context. Replies would also be somewhat easier to implement and worst case, a client could very easily implement a little "this is a reply" -marker to at least mark replies visually. - -~~Same applies to edits. If 2 very similar messages appear after one another, -someone new to online messaging would assume, this is a correction to the -previous message. That may even be more obvious to them than if the message was -prefixed with a `*`, since that has been confusing to users in the past. Since -edits would now look exactly like a normal message, they would also be -considerably easier to implement, since you just need to replace the former -message now, similar to a redaction, and not merge `content` and `new_content`.~~ +marker to at least mark replies visually. Not having a reply fallback might also +prompt some clients to implement support for rich replies sooner. Users will now +complain about no context. Previously there was some context for replies to text +messages, which made it easy to accept the solution as good enough. However the +experience with replies to images was not acceptable. Motivating clients to +implement rich replies is a good thing in the long run and will improve the +Matrix experience overall. + +You might not get notifications anymore for replies to your messages. This was +a feature of the reply fallback, because it included the username, but users had +no control over it. A follow-up MSC will propose a push rule for related events, +which will allow users control over getting notified by replies (and other +relations) or not. ## Alternatives @@ -62,21 +67,26 @@ One could also just stick with the current fallbacks and make all clients pay the cost for a small number of clients actually benefitting from them. Lastly one could introduce an alternative relation type for replies without -fallback and deprecate the current relation type (since it does not fit the new -format for relations anyway). We could specify, that the server is supposed to -send the replied_to event in unsigned to the client, so that clients just need -to stitch those two events together, but don't need to fetch the replied_to -event from the server. It would make replies slightly harder to implement for -clients, but it would be simpler than what this MSC proposes. +fallback and deprecate the current relation type (since it does not fit the +[new format for relations](https://github.com/matrix-org/matrix-doc/pull/2674) +anyway). We could specify, that the server is supposed to send the replied_to +event in unsigned to the client, so that clients just need to stitch those two +events together, but don't need to fetch the replied_to event from the server. +It would make replies slightly harder to implement for clients, but it would be +simpler than what this MSC proposes. ## Security considerations Removing the fallback from the spec may lead to issues, when clients experience the fallback in old events. This should not add any security issues the client didn't already have from interpreting untrusted html, though. In all -other cases this should **reduce** security issues. +other cases this should **reduce** security issues (see +https://github.com/vector-im/element-web/releases/tag/v1.7.3 or the appendix for +examples). + +## Appendix A: Support for rich replies in different clients -## Appendix A: Clients not supporting rich replies +### Clients without rendering support for rich replies Of the 23 clients listed in the [matrix client matrix](https://matrix.org/clients-matrix) 16 are listed as not supporting replies: @@ -118,6 +128,20 @@ Changes from 1.5 years ago: - Lots of other new clients! +### Testresults without fallback + +So far I haven't found a client that completely breaks without the fallback. +All clients that support rendering rich replies don't break, when there is no +fallback according to my tests (at least Nheko, Element/Web, FluffyChat and +NeoChat were tested and some events without fallback are in #nheko:nheko.im and +I haven't heard of any breakage). Those clients just show the reply as normal +and otherwise seem to work completely fine as well. Element Android and Element +iOS just don't show what message was replied to. Other clients haven't been +tested by the author, but since the `content` of an event is untrusted, a client +should not break if there is no reply fallback. Otherwise this would be a +trivial abuse vector. + + ## Appendix B: Issues with the current fallbacks This section was moved to the back of this MSC, because it is fairly long and @@ -127,7 +151,8 @@ with fallbacks in their client and its interactions with the ecosystem. ### Stripping the fallback To reply to a reply, a client needs to strip the existing fallback of the first -reply. Otherwise replies will just infinitely nest replies. [While the spec doesn't necessarily require that](https://github.com/matrix-org/matrix-doc/issues/1541), +reply. Otherwise replies will just infinitely nest replies. +[While the spec doesn't necessarily require stripping the fallback in replies to replies (only for rendering)](https://spec.matrix.org/v1.1/client-server-api/#fallback-for-mtext-mnotice-and-unrecognised-message-types), not doing so risks running into the event size limit, but more importantly, it just leads to a bad experience for clients actually relying on the fallback. @@ -164,9 +189,10 @@ html anyway and that new features are blocked, because of fallbacks. This is also an issue with edits, where the combination of edit fallback and reply fallback is somewhat interesting: You need to send a fallback, since the -event is still a reply, but you can't send a reply relation, since this is an -edit. Currently this is solved by not sending a reply fallback in edits, so -clients can't rely on a reply fallback in all cases. +event is still a reply, +[but you can't send a reply relation](https://github.com/matrix-org/matrix-doc/pull/2676/files#diff-1761bdadd1caacb2503d2b2e6c572fc628c7321b0beab8d502ac249c15b2826aR113), +since this is an edit. Currently this is solved by not sending a reply fallback +in edits, so clients can't rely on a reply fallback in all cases. We currently can see 2 behaviours in practice: @@ -180,12 +206,10 @@ Client A supports rich reply rendering, Client B does not. ### Format is unreliable -Further complicating the stripping and creation portion of fallbacks is, that -they are somewhat badly specified. While the fallback and html use are required, -the spec only says how a fallback "should" look, not how it "must" look. In -practice there are various variations of the fallback floating around, where the -tame ones are just localized, but others are just straight up missing suggested -links or tags. +While the spec says how a fallback "should" look, there are variations in use +which further complicates stripping the fallback. Some variations include +localizing the fallback, missing suggested links or tags, using the body in +replies to files or images or using the display name instead of the matrix id. Basically a client can't rely on the fallback being present currently or it following any kind of shape or form and stripping is done on a best effort @@ -203,12 +227,14 @@ language selection for their client, which may be personal information. ### Using the unmodified fallback in clients and bridges -The above issues are minor, if reply fallbacks would sufficiend value to +The above issues are minor, if reply fallbacks added sufficient value to clients. Bridges usually try to bridge to native replies, so they need to strip the reply fallback (https://github.com/matrix-org/matrix-doc/issues/1541). Even the IRC bridge seems to send a custom fallback, because the default fallback is not that -welcome to the IRC crowd. +welcome to the IRC crowd, although the use cases for simple, text only bridges +is often touted as a good usecase for the fallback (sometimes even explicitly +mentioning bridging to IRC). Some clients do choose not to implement rich reply rendering, but the experience tends to not be ideal, especially in cases where you reply to an image and now @@ -221,9 +247,11 @@ ecosystem. - [Edits explicitly mention](https://github.com/matrix-org/matrix-doc/pull/2676) that a reply fallback should not be sent in the `m.new_content`. -- [Extensible events](https://github.com/matrix-org/matrix-doc/pull/1767) would - need to specify how the fallback should look like. [Alternatively they could - also drop it](https://github.com/matrix-org/matrix-doc/pull/3644). +- [Extensible events](https://github.com/matrix-org/matrix-doc/pull/1767) + require an update to the specification for fallbacks (because there is no + `body` or `formatted_body` anymore after the transition period). + [The current proposal](https://github.com/matrix-org/matrix-doc/pull/3644) + also intends to just drop the fallbacks in extensible events. ### Localization @@ -234,7 +262,10 @@ to guess, which language was used in a short message. One could also use the client's language, but that leaks the user's localization settings, which can be a privacy concern and the other party may not speak that language. Alternatively a client can just send english fallbacks, but that significantly worsens the -experience for casual users in non-english speaking countries. +experience for casual users in non-english speaking countries. The specification +currently requires them to not be translated (although some clients don't follow +that), but not sending a fallback at all completely sidesteps the need for the +spec to specify that and clients relying on an english only fallback. ## Unstable prefix From c6049993dd6143b0bc7eda001a8ff331f7bdb679 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Wed, 19 Jan 2022 05:53:54 +0100 Subject: [PATCH 16/27] More edits Move edit section to a single sentence in "interaction with other features". Spell out why the IRC example is there. Reword body stripping. Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 50 +++++++++-------------- 1 file changed, 20 insertions(+), 30 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index a7a8c5f23ca..7a0f3c6efc5 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -1,14 +1,13 @@ # MSC2781: Remove reply fallbacks from the specification -Currently replies require clients to send and parse a fallback representation of -the replied to message. Something similar is planned for edits. While at least -in theory fallbacks should make it simpler to start supporting replies in a new -client, they actually introduce a lot of complexity and implementation issues -and block a few valuable features. This MSC proposes to deprecate and eventually -remove those fallbacks. It was an alternative to -[MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), which chose a -different representation of the reply fallback, but was ultimately closed in -favor of this proposal. +Currently replies require clients to send and parse a fallback representation +of the replied to message. While at least in theory fallbacks should make it +simpler to start supporting replies in a new client, they actually introduce a +lot of complexity and implementation issues and block a few valuable features. +This MSC proposes to deprecate and eventually remove those fallbacks. It was an +alternative to [MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), +which chose a different representation of the reply fallback, but was +ultimately closed in favor of this proposal. ## Proposal @@ -165,8 +164,12 @@ Common mistakes include: - Not dealing with mismatched `` tags, which can look like you were impersonating someone. -Stripping the fallback from body is even more complicated, since there is no way -to distinguish a quote from a reply reliably. +For the `body` extra attention needs to be paid to only strip lines starting +with `>` until the first empty line. Implementations either only stripped the +first line, stripped all lines starting with `>` until the first non empty line, +that does not start with `>` or stripped only the `formatted_body`. While those +are implementation bugs, they can't happen if you don't need to strip a +fallback. ### Creating a new fallback @@ -187,23 +190,6 @@ image, since those don't have a `formatted_body` property currently. This means a text only client, that doesn't want to display html, still needs to support html anyway and that new features are blocked, because of fallbacks. -This is also an issue with edits, where the combination of edit fallback and -reply fallback is somewhat interesting: You need to send a fallback, since the -event is still a reply, -[but you can't send a reply relation](https://github.com/matrix-org/matrix-doc/pull/2676/files#diff-1761bdadd1caacb2503d2b2e6c572fc628c7321b0beab8d502ac249c15b2826aR113), -since this is an edit. Currently this is solved by not sending a reply fallback -in edits, so clients can't rely on a reply fallback in all cases. - -We currently can see 2 behaviours in practice: - -Client A supports rich reply rendering, Client B does not. - -- A sends an edit. This according to MSC2676 does not include a reply fallback. - A properly sees the edit still as a reply. B does not. -- B sends an edit but includes a reply fallback in the body. It can still see - that the message is a reply. A needs to strip the invalid reply fallback, or - it will see the reply content twice. - ### Format is unreliable While the spec says how a fallback "should" look, there are variations in use @@ -234,7 +220,8 @@ strip the reply fallback seems to send a custom fallback, because the default fallback is not that welcome to the IRC crowd, although the use cases for simple, text only bridges is often touted as a good usecase for the fallback (sometimes even explicitly -mentioning bridging to IRC). +mentioning bridging to IRC). As a result there are very few bridges, that +benefit from the fallback being present. Some clients do choose not to implement rich reply rendering, but the experience tends to not be ideal, especially in cases where you reply to an image and now @@ -246,7 +233,10 @@ ecosystem. ### Fallback increase integration work with new features - [Edits explicitly mention](https://github.com/matrix-org/matrix-doc/pull/2676) - that a reply fallback should not be sent in the `m.new_content`. + that a reply fallback should not be sent in the `m.new_content`. This causes + issues for clients relying on the fallback, because they won't show replies + once a message has been edited (see Element Android as a current example) + and similar edge cases. - [Extensible events](https://github.com/matrix-org/matrix-doc/pull/1767) require an update to the specification for fallbacks (because there is no `body` or `formatted_body` anymore after the transition period). From 2a55bc174b70a5d7f5aa3b4c398a3d82f3892785 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Wed, 19 Jan 2022 06:14:38 +0100 Subject: [PATCH 17/27] Implementation traps Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 7a0f3c6efc5..ec463ad6f60 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -193,13 +193,13 @@ html anyway and that new features are blocked, because of fallbacks. ### Format is unreliable While the spec says how a fallback "should" look, there are variations in use -which further complicates stripping the fallback. Some variations include -localizing the fallback, missing suggested links or tags, using the body in -replies to files or images or using the display name instead of the matrix id. +which further complicates stripping the fallback or are common mistakes, when +emitting the fallback. Some variations include localizing the fallback, +missing suggested links or tags, using the body in replies to files or images +or using the display name instead of the matrix id. -Basically a client can't rely on the fallback being present currently or it -following any kind of shape or form and stripping is done on a best effort -basis, especially for the fallback in `body`. +As a result the experience in clients relying on the fallback or stripping the +fallback varies depending on the sending client. ### Replies leak history @@ -208,8 +208,9 @@ leak data to users, that joined this room at a later point, but shouldn't be able to see the event because of visibility rules or encryption. While this isn't a big issue, there is still an issue about it: https://github.com/matrix-org/matrix-doc/issues/1654 -Replies are also sometimes localized. In those cases they leak the users -language selection for their client, which may be personal information. +Historically clients have also sometimes localized the fallbacks. In those cases +they leak the users language selection for their client, which may be personal +information. ### Using the unmodified fallback in clients and bridges From 892664b6d94e75f276b556c9695665dd9299ca59 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Thu, 20 Jan 2022 20:07:24 +0000 Subject: [PATCH 18/27] Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2781-down-with-the-fallbacks.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index ec463ad6f60..c625265bf6e 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -50,7 +50,7 @@ experience with replies to images was not acceptable. Motivating clients to implement rich replies is a good thing in the long run and will improve the Matrix experience overall. -You might not get notifications anymore for replies to your messages. This was +You might not get notifications any more for replies to your messages. This was a feature of the reply fallback, because it included the username, but users had no control over it. A follow-up MSC will propose a push rule for related events, which will allow users control over getting notified by replies (and other @@ -127,7 +127,7 @@ Changes from 1.5 years ago: - Lots of other new clients! -### Testresults without fallback +### Results of testing replies without fallback So far I haven't found a client that completely breaks without the fallback. All clients that support rendering rich replies don't break, when there is no @@ -231,7 +231,7 @@ the user needs to guess, what image was being replied to. As a result the fallbacks provide value to only a subset of the Matrix ecosystem. -### Fallback increase integration work with new features +### Fallbacks increase integration work with new features - [Edits explicitly mention](https://github.com/matrix-org/matrix-doc/pull/2676) that a reply fallback should not be sent in the `m.new_content`. This causes From 52fd929030a805cfb5d3a3ed9f99d7d1fd939e61 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Thu, 20 Jan 2022 21:18:14 +0100 Subject: [PATCH 19/27] Add dates to client status list Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index c625265bf6e..72fd2af1788 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -59,7 +59,7 @@ relations) or not. ## Alternatives [MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589): This adds the -reply text as an addional key. While this solves the parsing issues, it +reply text as an additional key. While this solves the parsing issues, it doesn't address the other issues with fallbacks. One could also just stick with the current fallbacks and make all clients pay @@ -88,7 +88,7 @@ examples). ### Clients without rendering support for rich replies Of the 23 clients listed in the [matrix client matrix](https://matrix.org/clients-matrix) -16 are listed as not supporting replies: +16 are listed as not supporting replies (updated January 2022): - Element Android: Relies on the reply fallback. - Element iOS: [Does not support rich replies](https://github.com/vector-im/element-ios/issues/3517) @@ -112,12 +112,13 @@ client doesn't support it because of the fallback (Quaternion). 3 of the command line clients probably won't support replies, since they don't support formatted messages and replies require html support for at least sending. -Only one client implemented rich replies in the last 1.5 years. Other clients -are either new in my list or didn't change their reply rendering. I would -appreciate to hear, why those client developers decided not to support rich -reply rendering and if dropping the reply fallback would be an issue for them. +Only one client implemented rich replies in the last 1.5 years after the +original list was done in October 2020. Other clients are either new in my list +or didn't change their reply rendering. I would appreciate to hear, why those +client developers decided not to support rich reply rendering and if dropping +the reply fallback would be an issue for them. -Changes from 1.5 years ago: +Changes from 1.5 years ago as of January 2022: - Fractal: [Seems to support replies now!](https://gitlab.gnome.org/GNOME/fractal/-/merge_requests/941) - Commune: Seems to support rich reply rendering and style them very nicely. From 6983fde5b6273c93ef5ab26906a9e9b0415f2ecc Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Fri, 21 Jan 2022 02:48:42 +0100 Subject: [PATCH 20/27] Mention pushrules proposal in the alternatives section Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 72fd2af1788..58fb9dde810 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -52,9 +52,10 @@ Matrix experience overall. You might not get notifications any more for replies to your messages. This was a feature of the reply fallback, because it included the username, but users had -no control over it. A follow-up MSC will propose a push rule for related events, -which will allow users control over getting notified by replies (and other -relations) or not. +no control over it. Notifications can be added back by an MSC like +[MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) or a similar +proposal and give the user more control over the notifications while also being +an explicit solution. ## Alternatives From 1d1885750c11e88797077342b234385452d47160 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Mon, 3 Jun 2024 00:02:44 +0200 Subject: [PATCH 21/27] Update proposal to 2024 This also addresses several review comments from clokep and Travis. --- proposals/2781-down-with-the-fallbacks.md | 108 ++++++++++++---------- 1 file changed, 61 insertions(+), 47 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 58fb9dde810..c6a6136cf4e 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -1,61 +1,72 @@ # MSC2781: Remove reply fallbacks from the specification -Currently replies require clients to send and parse a fallback representation -of the replied to message. While at least in theory fallbacks should make it -simpler to start supporting replies in a new client, they actually introduce a -lot of complexity and implementation issues and block a few valuable features. -This MSC proposes to deprecate and eventually remove those fallbacks. It was an -alternative to [MSC2589](https://github.com/matrix-org/matrix-doc/pull/2589), -which chose a different representation of the reply fallback, but was -ultimately closed in favor of this proposal. +Currently the specification suggest clients should send and strip a +[fallback representation](https://spec.matrix.org/v1.10/client-server-api/#fallbacks-for-rich-replies) +of a replied to message. The fallback representation was meant to simplify +supporting replies in a new client, but in practice they add complexity, are +often implemented incorrectly and block new features. + +This MSC proposes to deprecate and eventually remove those fallbacks. + +Some of the known issues include: +* The content of reply fallback is [untrusted](https://spec.matrix.org/v1.10/client-server-api/#stripping-the-fallback). +* Reply fallbacks may leak history. ([#368](https://github.com/matrix-org/matrix-spec/issues/368)) +* Parsing reply fallbacks can be tricky. ([#350](https://github.com/matrix-org/matrix-spec/issues/350)) +* It is unclear how to handle a reply to a reply. ([#372](https://github.com/matrix-org/matrix-spec/issues/372)) +* Localization of replies is not possible when the content is embedded into the event. +* It is not possible to fully redact an event once it is replied to, this causes both trust & safety and right to be forgotten issues. +* There are a variety of implementation bugs related to reply fallback handling. + +More details and considerations are provided in the appendices, but these are +provided for convenience and aren't necessary to understand this proposal. ## Proposal Remove the [rich reply fallback from the -specification](https://spec.matrix.org/v1.1/client-server-api/#fallbacks-for-rich-replies). +specification](https://spec.matrix.org/v1.10/client-server-api/#fallbacks-for-rich-replies). Clients should stop sending them and should consider treating `` parts as either something to be unconditionally stripped or as something to be escaped -as invalid html. Clients may send replies without a formatted_body now using -arbitrary message events (not state events), which is currently still disallowed -by the -[specification](https://spec.matrix.org/v1.1/client-server-api/#rich-replies). +as invalid html. -As a result of this, you would be able to reply with an image. New clients -would also be able to implement edits and replies more easily, as they can -sidestep a lot of pitfalls. +Clients are not required to include a fallback in a reply since version 1.3 of +the +[specification](https://spec.matrix.org/v1.10/client-server-api/#rich-replies). +For this reason the reply fallbck can be removed from the specification without +any additional deprecation period. + +An info box should be included to mention the historical use of the reply +fallback, suggesting that clients may encounter such events sent by other +clients and that clients may need to strip out such fallbacks. Given clients have had enough time to implement replies completely, the overall look & feel of replies should be unchanged or even improved by this -proposal. +proposal. Implementing replies in a client should also be a bit easier with this +change. An extended motivation is provided at [the end of this document](#user-content-appendix-b-issues-with-the-current-fallbacks). ## Potential issues -Obviously you can't remove the fallback from old events. As such clients would -still need to do something with them in the near future. I'd say just not -handling them in a special way should be okay after some unspecified period of -time. - -Clients not implementing rich replies or edits may show some slightly more -confusing messages to users as well. I'd argue though that in most cases, the -reply is close enough to the replied to message, that you would be able to guess -the correct context. Replies would also be somewhat easier to implement and -worst case, a client could very easily implement a little "this is a reply" -marker to at least mark replies visually. Not having a reply fallback might also -prompt some clients to implement support for rich replies sooner. Users will now -complain about no context. Previously there was some context for replies to text -messages, which made it easy to accept the solution as good enough. However the -experience with replies to images was not acceptable. Motivating clients to -implement rich replies is a good thing in the long run and will improve the -Matrix experience overall. - -You might not get notifications any more for replies to your messages. This was -a feature of the reply fallback, because it included the username, but users had -no control over it. Notifications can be added back by an MSC like -[MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) or a similar -proposal and give the user more control over the notifications while also being -an explicit solution. +Old events and events sent by clients implementing an older version of the +Matrix specification might still contain a reply fallback. So for at least some +period of time clients will still need to strip reply fallbacks from messages. + +Clients which don't implement rich replies or edits may see messages +without context, confusing users. However, most replies and edits are +in close proximity to the original message, making context likely to be +nearby. Clients should also have enough information in the event to +render helpful indications to users while they work on full support. + +Clients which aren't using +[intentional mentions](https://spec.matrix.org/v1.7/client-server-api/#mentioning-the-replied-to-user) +may cause some missed notifications on the receiving side. +[MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) and similar aim to +address this issue, as +[MSC4142](https://github.com/matrix-org/matrix-spec-proposals/pull/4142) tries +to improve the intentional mentions experience for replies generally. +Because intentional mentions are already part of the Matrix specification since +version 1.7, clients can be expected to implement those first, which should make +the impact on notifications minimal in practice. ## Alternatives @@ -84,6 +95,12 @@ other cases this should **reduce** security issues (see https://github.com/vector-im/element-web/releases/tag/v1.7.3 or the appendix for examples). +## Unstable prefix + +No unstable prefix should be necessary as clients aren't required to send reply +fallbacks for all messages since version 1.3 of the Matrix specification, which +changed the wording from "MUST" to "SHOULD". + ## Appendix A: Support for rich replies in different clients ### Clients without rendering support for rich replies @@ -210,6 +227,9 @@ leak data to users, that joined this room at a later point, but shouldn't be able to see the event because of visibility rules or encryption. While this isn't a big issue, there is still an issue about it: https://github.com/matrix-org/matrix-doc/issues/1654 +This history leak can also cause abusive or redacted messages to remain visible +to other room members, depending on the client implementation of replies. + Historically clients have also sometimes localized the fallbacks. In those cases they leak the users language selection for their client, which may be personal information. @@ -259,9 +279,3 @@ experience for casual users in non-english speaking countries. The specification currently requires them to not be translated (although some clients don't follow that), but not sending a fallback at all completely sidesteps the need for the spec to specify that and clients relying on an english only fallback. - -## Unstable prefix - -Clients should use the prefix `im.nheko.msc2781.` for all their event types, if -they implement this MSC in a publicly available release or events may otherwise -bleed into public rooms. From cbeb4e04753403c760876782564442c5e0331f8b Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Mon, 3 Jun 2024 00:04:53 +0200 Subject: [PATCH 22/27] Be explicit about removal --- proposals/2781-down-with-the-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index c6a6136cf4e..f526311f3d6 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -6,7 +6,7 @@ of a replied to message. The fallback representation was meant to simplify supporting replies in a new client, but in practice they add complexity, are often implemented incorrectly and block new features. -This MSC proposes to deprecate and eventually remove those fallbacks. +This MSC proposes to **remove** those fallbacks from the specification. Some of the known issues include: * The content of reply fallback is [untrusted](https://spec.matrix.org/v1.10/client-server-api/#stripping-the-fallback). From a66f24d6b3fe102d2eca612ed628a3c64c33707b Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Tue, 25 Jun 2024 17:44:14 +0000 Subject: [PATCH 23/27] Apply suggestions from code review Thanks dbkr, richvdh and clokep! Co-authored-by: David Baker Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Patrick Cloke --- proposals/2781-down-with-the-fallbacks.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index f526311f3d6..62e247017b5 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -1,6 +1,6 @@ # MSC2781: Remove reply fallbacks from the specification -Currently the specification suggest clients should send and strip a +Currently the specification suggests clients should send and strip a [fallback representation](https://spec.matrix.org/v1.10/client-server-api/#fallbacks-for-rich-replies) of a replied to message. The fallback representation was meant to simplify supporting replies in a new client, but in practice they add complexity, are @@ -14,7 +14,7 @@ Some of the known issues include: * Parsing reply fallbacks can be tricky. ([#350](https://github.com/matrix-org/matrix-spec/issues/350)) * It is unclear how to handle a reply to a reply. ([#372](https://github.com/matrix-org/matrix-spec/issues/372)) * Localization of replies is not possible when the content is embedded into the event. -* It is not possible to fully redact an event once it is replied to, this causes both trust & safety and right to be forgotten issues. +* It is not possible to fully redact an event once it is replied to. This causes both trust & safety and right to be forgotten issues. * There are a variety of implementation bugs related to reply fallback handling. More details and considerations are provided in the appendices, but these are @@ -31,7 +31,7 @@ as invalid html. Clients are not required to include a fallback in a reply since version 1.3 of the [specification](https://spec.matrix.org/v1.10/client-server-api/#rich-replies). -For this reason the reply fallbck can be removed from the specification without +For this reason the reply fallback can be removed from the specification without any additional deprecation period. An info box should be included to mention the historical use of the reply @@ -105,7 +105,7 @@ changed the wording from "MUST" to "SHOULD". ### Clients without rendering support for rich replies -Of the 23 clients listed in the [matrix client matrix](https://matrix.org/clients-matrix) +Of the 23 clients listed in the [Matrix client matrix](https://matrix.org/clients-matrix) 16 are listed as not supporting replies (updated January 2022): - Element Android: Relies on the reply fallback. From 23dd267745924b98cdc05b24f19b8411822623bd Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Tue, 25 Jun 2024 17:44:45 +0000 Subject: [PATCH 24/27] Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2781-down-with-the-fallbacks.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 62e247017b5..27468c785b7 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -61,7 +61,7 @@ Clients which aren't using [intentional mentions](https://spec.matrix.org/v1.7/client-server-api/#mentioning-the-replied-to-user) may cause some missed notifications on the receiving side. [MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) and similar aim to -address this issue, as +address this issue, and [MSC4142](https://github.com/matrix-org/matrix-spec-proposals/pull/4142) tries to improve the intentional mentions experience for replies generally. Because intentional mentions are already part of the Matrix specification since From 1ad224eef7d1010fb9457a2d446e3135c772f71b Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Tue, 25 Jun 2024 17:59:41 +0000 Subject: [PATCH 25/27] Update proposals/2781-down-with-the-fallbacks.md Co-authored-by: Patrick Cloke --- proposals/2781-down-with-the-fallbacks.md | 9 +++------ 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 27468c785b7..4018a6f44db 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -88,12 +88,9 @@ simpler than what this MSC proposes. ## Security considerations -Removing the fallback from the spec may lead to issues, when clients experience -the fallback in old events. This should not add any security issues the -client didn't already have from interpreting untrusted html, though. In all -other cases this should **reduce** security issues (see -https://github.com/vector-im/element-web/releases/tag/v1.7.3 or the appendix for -examples). +Overall this should **reduce** security issues as the handling of untrusted +HTML is simplified. For an example security issue that could be avoided, see +https://github.com/vector-im/element-web/releases/tag/v1.7.3 and the appendix. ## Unstable prefix From 2da1ac77ef6b53283bbb9b3b8d62cff9c1cf1f89 Mon Sep 17 00:00:00 2001 From: "DeepBlueV7.X" Date: Tue, 1 Oct 2024 16:48:14 +0200 Subject: [PATCH 26/27] Apply suggestions from code review Co-authored-by: Travis Ralston Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> --- proposals/2781-down-with-the-fallbacks.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 4018a6f44db..43f9fd9892b 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -14,7 +14,8 @@ Some of the known issues include: * Parsing reply fallbacks can be tricky. ([#350](https://github.com/matrix-org/matrix-spec/issues/350)) * It is unclear how to handle a reply to a reply. ([#372](https://github.com/matrix-org/matrix-spec/issues/372)) * Localization of replies is not possible when the content is embedded into the event. -* It is not possible to fully redact an event once it is replied to. This causes both trust & safety and right to be forgotten issues. +* It is not possible to fully redact an event once it is replied to. This causes issues with Trust & Safety where + spam or other removed content remains visible, and may cause issues with the GDPR Right to be Forgotten. * There are a variety of implementation bugs related to reply fallback handling. More details and considerations are provided in the appendices, but these are @@ -34,9 +35,10 @@ the For this reason the reply fallback can be removed from the specification without any additional deprecation period. -An info box should be included to mention the historical use of the reply -fallback, suggesting that clients may encounter such events sent by other -clients and that clients may need to strip out such fallbacks. +A suggestion for the spec PR: An info box could be included to mention +the historical use of the reply fallback, suggesting that clients may encounter +such events sent by other clients and that clients may need to strip out such +fallbacks. Given clients have had enough time to implement replies completely, the overall look & feel of replies should be unchanged or even improved by this From 5c9de135093f0ac3354dff35a3fd158def0248c6 Mon Sep 17 00:00:00 2001 From: Nicolas Werner Date: Tue, 1 Oct 2024 17:00:01 +0200 Subject: [PATCH 27/27] Simplify wording around invalid html and potential issues Signed-off-by: Nicolas Werner --- proposals/2781-down-with-the-fallbacks.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/proposals/2781-down-with-the-fallbacks.md b/proposals/2781-down-with-the-fallbacks.md index 43f9fd9892b..65b796f81ab 100644 --- a/proposals/2781-down-with-the-fallbacks.md +++ b/proposals/2781-down-with-the-fallbacks.md @@ -26,8 +26,7 @@ provided for convenience and aren't necessary to understand this proposal. Remove the [rich reply fallback from the specification](https://spec.matrix.org/v1.10/client-server-api/#fallbacks-for-rich-replies). Clients should stop sending them and should consider treating `` parts -as either something to be unconditionally stripped or as something to be escaped -as invalid html. +as they treat other invalid html tags. Clients are not required to include a fallback in a reply since version 1.3 of the @@ -53,11 +52,11 @@ Old events and events sent by clients implementing an older version of the Matrix specification might still contain a reply fallback. So for at least some period of time clients will still need to strip reply fallbacks from messages. -Clients which don't implement rich replies or edits may see messages -without context, confusing users. However, most replies and edits are -in close proximity to the original message, making context likely to be -nearby. Clients should also have enough information in the event to -render helpful indications to users while they work on full support. +Clients which don't implement rich replies may see messages without context, +confusing users. However, most replies are in close proximity to the original +message, making context likely to be nearby. Clients should also have enough +information in the event to render helpful indications to users while they work +on full support. Clients which aren't using [intentional mentions](https://spec.matrix.org/v1.7/client-server-api/#mentioning-the-replied-to-user)