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 <[email protected]>
deepbluev7
force-pushed
the
drop-the-fallbacks
branch
from
4ec0095
to
6868738
Compare
turt2live
added
kind:maintenance
Signed-off-by: Nicolas Werner <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
…possible) Signed-off-by: Nicolas Werner <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
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 <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
turt2live
added
the
needs-implementation
|
Implementation: matrix-org/matrix-react-sdk#6964 |
turt2live
changed the title
|
@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 <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]> Co-authored-by: Patrick Cloke <[email protected]>
Co-authored-by: Richard van der Hoff <[email protected]>
Co-authored-by: Patrick Cloke <[email protected]>
|
|
||
| ## 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 <[email protected]> Co-authored-by: Andrew Morgan <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
|
I'm still concerned about the jump to removal here, but not enough to prevent this MSC from moving forwards: @mscbot resolve We must deprecate before removal I have unticked my box though to get broader alignment from the remaining SCT members on this. |
mscbot
removed
the
unresolved-concerns
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
final-comment-period
|
Implementation: officialdakari/Extera |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
mscbot
added
finished-final-comment-period
and removed
disposition-merge
final-comment-period
turt2live
dismissed
their stale review
review is not considered blocking for FCP
turt2live
added
spec-pr-missing
* MSC2781: Down with the fallbacks Signed-off-by: Nicolas Werner <[email protected]> * Add a note about dropping the html requirement Signed-off-by: Nicolas Werner <[email protected]> * Add an unstable prefix for removed fallbacks. Signed-off-by: Nicolas Werner <[email protected]> * Add a section about fallbacks not being properly specified. Signed-off-by: Nicolas Werner <[email protected]> * Add appendix about which clients do not support replies (and why, if possible) Signed-off-by: Nicolas Werner <[email protected]> * Correct weechat status Signed-off-by: Nicolas Werner <[email protected]> * Add another alternative Signed-off-by: Nicolas Werner <[email protected]> * Document a few more issues with fallbacks Signed-off-by: Nicolas Werner <[email protected]> * Update client status, remove proposal for edits and try to turn down the language a bit Signed-off-by: Nicolas Werner <[email protected]> * Remove mistaken reference to the Qt renderer Signed-off-by: Nicolas Werner <[email protected]> * Try to make motivation a bit clearer in the proposal Signed-off-by: Nicolas Werner <[email protected]> * How do anchors work? Signed-off-by: Nicolas Werner <[email protected]> * Drop reference to issues with edit fallbacks Signed-off-by: Nicolas Werner <[email protected]> * Typos Signed-off-by: Nicolas Werner <[email protected]> * Address review comments Signed-off-by: Nicolas Werner <[email protected]> * 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 <[email protected]> * Implementation traps Signed-off-by: Nicolas Werner <[email protected]> * Apply suggestions from code review Co-authored-by: Richard van der Hoff <[email protected]> * Add dates to client status list Signed-off-by: Nicolas Werner <[email protected]> * Mention pushrules proposal in the alternatives section Signed-off-by: Nicolas Werner <[email protected]> * Update proposal to 2024 This also addresses several review comments from clokep and Travis. * Be explicit about removal * Apply suggestions from code review Thanks dbkr, richvdh and clokep! Co-authored-by: David Baker <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]> Co-authored-by: Patrick Cloke <[email protected]> * Apply suggestions from code review Co-authored-by: Richard van der Hoff <[email protected]> * Update proposals/2781-down-with-the-fallbacks.md Co-authored-by: Patrick Cloke <[email protected]> * Apply suggestions from code review Co-authored-by: Travis Ralston <[email protected]> Co-authored-by: Andrew Morgan <[email protected]> * Simplify wording around invalid html and potential issues Signed-off-by: Nicolas Werner <[email protected]> --------- Signed-off-by: Nicolas Werner <[email protected]> Co-authored-by: Richard van der Hoff <[email protected]> Co-authored-by: David Baker <[email protected]> Co-authored-by: Patrick Cloke <[email protected]> Co-authored-by: Travis Ralston <[email protected]> Co-authored-by: Andrew Morgan <[email protected]>
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 [email protected]
FCP tickyboxes