-
Notifications
You must be signed in to change notification settings - Fork 380
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MSC2781: Remove the reply fallbacks from the specification #2781
MSC2781: Remove the reply fallbacks from the specification #2781
Conversation
bc40dab
to
4ec0095
Compare
Signed-off-by: Nicolas Werner <[email protected]>
4ec0095
to
6868738
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the glory of the Emperor: Down with mx-reply
!
Signed-off-by: Nicolas Werner <[email protected]>
Signed-off-by: Nicolas Werner <[email protected]>
Implementation: matrix-org/matrix-react-sdk#6964 |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seemingly my github tabs got confused and submitted my review without asking the status associated with it.
Apologies for the slow review here - authenticated media has been taking up all my time.
@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. |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Implementation: officialdakari/Extera |
The final comment period, with a disposition to merge, as per the review above, is now complete. |
review is not considered blocking for FCP
* 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]>
Spec PR: matrix-org/matrix-spec#1994 |
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