MSC2781: Remove the reply fallbacks from the specification #2781
Conversation
deepbluev7
force-pushed
the
drop-the-fallbacks
branch
from
bc40dab
to
4ec0095
Compare
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
deepbluev7
force-pushed
the
drop-the-fallbacks
branch
from
4ec0095
to
6868738
Compare
turt2live
added
kind:maintenance
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
…possible) Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
There was a problem hiding this comment.
I understand the controversy but I really think that fallbacks bring more problems (especially in terms of the content getting stuck in messages not belonging to authors) than solutions to those who try to stay as simple as possible. The requirement to strip the fallbacks in replies raises the bar of implementing them to the point where half of the ecosystem chooses not to deal with that. Besides, the fallbacks are a huge HTML foot in the door where plaintext messengers have literally no chance of compliance. So yes, please, let's go with it.
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
turt2live
added
the
needs-implementation
|
Implementation: matrix-org/matrix-react-sdk#6964 |
turt2live
changed the title
mscbot
added
the
unresolved-concerns
|
fwiw, the thing that swung me on this is the t&s impact of leaking contents of deleted in replies. |
|
Overall I'm happy with this, but I think the text is a bit confusing. @turt2live and I left a bunch of comments which should help with that. @mscbot concern General clarity |
|
I think this is going in the right direction but already has appropriate concerns, and I agree with them. For future reference, some examples would make this a lot easier to read. |
|
Thank you all very much for the feedback, I'll address it in the next few days! |
| 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. |
There was a problem hiding this comment.
To add to this, Element Android actually seems to completely blank the message if the rich reply is there, but not the reply fallback (new Beeper Android and some mautrix bridges have done this for example)
It also seems a little unlikely that this will be fixed element-hq/element-android#8460
There was a problem hiding this comment.
One of my hopes with this MSC was to encourage clients to implement proper reply support. Element Android in particular has been a problem for me, since it sends invalid fallbacks in many cases. While I do agree, that it is unlikely this will actually be fixed in Element Android, considering how problematic the reply implementation in Element Android is, I don't know if that should really be a blocker on this MSC. Stripping out its current reply handling and implement this MSC is probably easier than making Element Android actually compliant with the current specification for replies (from before this MSC).
This also addresses several review comments from clokep and Travis.
|
@deepbluev7 Thanks for your effort on clarifying and improving this MSC. I think it is much easier to read now and clearer what the proposed changes are! 🎉 @mscbot resolve General clarity |
| 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) |
There was a problem hiding this comment.
... and therefore relies on the reply fallback? So is the same as Element Android? or different?
There was a problem hiding this comment.
When that was written, yes. Although I didn't investigate more since I don't own any iOS device. But it seems Element iOS might have some support now based on element-hq/element-ios#6155 ?
Thanks dbkr, richvdh and clokep! Co-authored-by: David Baker <dbkr@users.noreply.github.com> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
|
||
| ## Proposal | ||
|
|
||
| Remove the [rich reply fallback from the |
There was a problem hiding this comment.
All of those examples are from a time before the deprecation policy was enacted in Matrix 1.1, fwiw. This MSC introduces a technically breaking change to clients, which necessitates deprecation first at a minimum. The spec instructs clients which do support rich replies on how to handle the fallback (strip it), and implies that the module is optional. By removing the fallback, we're saying that clients must support rich replies in order to maintain conversation context - something which is currently optional (and not even a SHOULD optional).
The MSC addresses the context piece a bit, but doesn't address the breaking change. As such, this needs to go through deprecation first to manage the breaking change, then removal at least 1 version later as per the policy. This does add additional overhead - feedback regarding that is best placed in a dedicated MSC which aims to change the deprecation policy.
|
@mscbot resolve Mention intentional mentions |
Co-authored-by: Travis Ralston <travpc@gmail.com> Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Since I hit another fallback bug today, I thought I should finally propose this. Let's see, how this goes.
Rendered
Implementations:
See also:
fixes matrix-org/matrix-spec#368
fixes matrix-org/matrix-spec#350 ?
Signed-off-by: Nicolas Werner nicolas.werner@hotmail.de
FCP tickyboxes