-
Notifications
You must be signed in to change notification settings - Fork 379
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 <nicolas.werner@hotmail.de>
4ec0095
to
6868738
Compare
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.
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 <nicolas.werner@hotmail.de>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
Implementation: matrix-org/matrix-react-sdk#6964 |
@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 |
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.
some very minor editorial points, and a question.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... and therefore relies on the reply fallback? So is the same as Element Android? or different?
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.
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.
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 <travpc@gmail.com> Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de>
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 <nicolas.werner@hotmail.de> * Add a note about dropping the html requirement Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Add an unstable prefix for removed fallbacks. Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Add a section about fallbacks not being properly specified. Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Add appendix about which clients do not support replies (and why, if possible) Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Correct weechat status Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Add another alternative Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Document a few more issues with fallbacks Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Update client status, remove proposal for edits and try to turn down the language a bit Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Remove mistaken reference to the Qt renderer Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Try to make motivation a bit clearer in the proposal Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * How do anchors work? Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Drop reference to issues with edit fallbacks Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Typos Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Address review comments Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * 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 <nicolas.werner@hotmail.de> * Implementation traps Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Add dates to client status list Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * Mention pushrules proposal in the alternatives section Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> * 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 <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> * Apply suggestions from code review Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * Update proposals/2781-down-with-the-fallbacks.md Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: Travis Ralston <travpc@gmail.com> Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> * Simplify wording around invalid html and potential issues Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> --------- Signed-off-by: Nicolas Werner <nicolas.werner@hotmail.de> Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> Co-authored-by: David Baker <dbkr@users.noreply.github.com> Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com> Co-authored-by: Travis Ralston <travpc@gmail.com> Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
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