Display threads relation as replies when labs is disabled #7109
Conversation
There was a problem hiding this comment.
Hmm, I am not entirely sure we want this...? We should think a bit more about the compatibility goals of the threads project first.
At the very least, it feels disingenuous to claim it fixes element-hq/element-web#19681, as that's about metadata that could potentially be used for thread messages to display sanely in existing clients (as if they were replies) without code changes.
The PR here assumes a world where all clients must make code changes to properly parent thread messages like a reply. Maybe that's the pragmatic choice and could be the direction we end up taking, but it's something very different from element-hq/element-web#19681 (which perhaps gets closed and unfixed).
|
Yeah, I think we should land this PR but probably not say it fixes that bug since that bug is specifically about adding the reply metadata to threaded messages rather than how we display them in Element. |
|
Sorry about that, it did not really address the problem raised in the issue. I do agree with Dave, I still believe there's value in landing that PR that is aligned with what the MSC suggests to do |
We are not using m.in_reply_to for backwards compatibility as this means we would lose the ability to have quote replies within a thread, which was marked as a feature required for threads.
This is a discussion we had within the team, this is not the most fool-proof backwards compatible experience. But one that is good enough and allows us to have all the features we want in the future
This PR currently has no changelog labels, so will not be included in changelogs.
Add one of:
T-Deprecation,T-Enhancement,T-Defect,T-Taskto indicate what type of change this is plusX-Breaking-Changeif it's a breaking change.Preview: https://618bdcf0c9092839b64e1091--matrix-react-sdk.netlify.app
⚠️ Do you trust the author of this PR? Maybe this build will steal your keys or give you malware. Exercise caution. Use test accounts.