MSC3676: Transitioning away from reply fallbacks (#3676)
* MSC3676: Transitioning away from reply fallbacks * msc number * md fails * typoe * Update proposals/3676-transitioning-away-from-reply-fallbacks.md Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> * incorporate feedback * consolidate justification Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>pull/977/head
Matthew Hodgson
3 years ago
committed by
GitHub
parent
dd32431b85
commit
2cd2a7122c
@ -0,0 +1,89 @@
|
|||||||
|
# MSC3676: Transitioning away from reply fallbacks.
|
||||||
|
|
||||||
|
## Problem
|
||||||
|
|
||||||
|
As per [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781)
|
||||||
|
(Remove reply fallbacks), the current reply fallback implementation is very
|
||||||
|
problematic:
|
||||||
|
* Its quotes leak history which may not be visible to the user
|
||||||
|
* The quoted sections may trigger unexpected notifications
|
||||||
|
* `<mx-reply/>` tags are hard and dangerous to manipulate, and have caused
|
||||||
|
multiple vulnerabilities in clients
|
||||||
|
* They don't localise.
|
||||||
|
|
||||||
|
[MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781) proposes
|
||||||
|
removing them entirely. However, this triggers a relatively large cascade of
|
||||||
|
additional dependent work:
|
||||||
|
* Some users rely on their mxid existing in fallbacks to notified when
|
||||||
|
someone replies to their messages. So we'd need to create and implement
|
||||||
|
new push rules to recreate this feature ([MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664)).
|
||||||
|
* The push rules are even more complicated than expected for this, because
|
||||||
|
they also would need to stop replies which are used as fallback for
|
||||||
|
threads (as per [MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440))
|
||||||
|
from firing notifications.
|
||||||
|
* In the absence of fallbacks, in order to render replies simple clients will
|
||||||
|
now have to parse `m.in_reply_to` objects and fish around for the missing
|
||||||
|
events (or ask the server to bundle the replies, which is not yet a
|
||||||
|
thing).
|
||||||
|
|
||||||
|
Meanwhile, [MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440)
|
||||||
|
(Threads) uses replies as a fallback representation for threads (which is
|
||||||
|
very desirable to support clients while the threads transition is happening,
|
||||||
|
or to support simpler clients which support replies but not threads).
|
||||||
|
However, currently `m.in_reply_to` is only allowed on `m.room.message` events
|
||||||
|
of msgtype `m.text`, which means it cannot currently be used as a fallback
|
||||||
|
for arbitrary threaded events.
|
||||||
|
|
||||||
|
## Proposal
|
||||||
|
|
||||||
|
As a transitional step towards removing reply fallbacks entirely, instead: we
|
||||||
|
make reply fallbacks best effort. Specifically:
|
||||||
|
|
||||||
|
* `m.in_reply_to` is relaxed to apply to any event type
|
||||||
|
* In practice only `m.room.message` events with msgtype `m.text` or similar
|
||||||
|
(`m.emote`, `m.notice`) would be able to express reply fallbacks (using the
|
||||||
|
`m.body`, `format` and `formatted_body` fields).
|
||||||
|
* Thread events using replies as a fallback representation for threads should
|
||||||
|
not include a textual reply fallback at all (and so avoid threaded messages
|
||||||
|
triggering notifications). The same would apply for any other usage which uses
|
||||||
|
replies as a fallback.
|
||||||
|
|
||||||
|
This means that we can still use reply fallbacks for notification purposes
|
||||||
|
until that is properly fixed by [MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781)
|
||||||
|
and [MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) - decoupling this
|
||||||
|
additional work from landing threads in
|
||||||
|
[MSC3440](https://github.com/matrix-org/matrix-doc/pull/3440).
|
||||||
|
Replying to a message with an attachment won't trigger a notification, but
|
||||||
|
this is no worse than the behaviour today.
|
||||||
|
|
||||||
|
## Alternatives
|
||||||
|
|
||||||
|
We could remove fallbacks entirely and do all the subsequent work needed to
|
||||||
|
support that ([MSC2781](https://github.com/matrix-org/matrix-doc/pull/2781),
|
||||||
|
[MSC3664](https://github.com/matrix-org/matrix-doc/pull/3664) and whatever
|
||||||
|
MSC handles thread+fallback notification interaction). However,
|
||||||
|
we believe that adding threads to Matrix is (much) higher priority and
|
||||||
|
value for Matrix than cleaning up edge cases around reply fallbacks, and
|
||||||
|
given the two can be decoupled, they should be. The importance of threads is
|
||||||
|
based on the fact that we're seeing Matrix repeatedly fail to be selected as
|
||||||
|
a collaboration technology thanks to other alternatives supporting
|
||||||
|
Slack-style threads.
|
||||||
|
|
||||||
|
We could not use `m.in_reply_to` as a fallback for clients which don't
|
||||||
|
understand `m.thread`, but this would result in an unnecessarily
|
||||||
|
terrible fallback for older/transitional/WIP/simple clients.
|
||||||
|
|
||||||
|
## Security
|
||||||
|
|
||||||
|
By temporarily keeping reply fallbacks around on a best effort basis, we're
|
||||||
|
still vulnerable to their security risks. Client implementors should read
|
||||||
|
the [security issues highlighted in MSC2781](https://github.com/deepbluev7/matrix-doc/blob/drop-the-fallbacks/proposals/2781-down-with-the-fallbacks.md#appendix-b-issues-with-the-current-fallbacks)
|
||||||
|
if implementing reply fallbacks.
|
||||||
|
|
||||||
|
## Unstable prefix
|
||||||
|
|
||||||
|
None needed.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
|
||||||
|
None. (MSC3440 will depend on this, however)
|
||||||
Loading…
Reference in New Issue