Skip to content
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

MSC4142: Remove unintentional intentional mentions in replies #4142

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
51 changes: 51 additions & 0 deletions proposals/4142-fix-reply-intentional-mentions.md
Copy link
Member

@turt2live turt2live May 10, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actively used by users to demonstrate desired behaviour

Not entirely sure what that means 🤔 The PR opening comment has an example of the currently specced behavior being undesired, and I think it's relatively obvious that mentioning the user you're replying to is desired

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Notifications have always been a pretty controversial area to be within. Where some folks consider it a bug, others don't.

That requirement is mostly to say it needs opinion from Product-centered folks.

Original file line number Diff line number Diff line change
@@ -0,0 +1,51 @@
# MSC4142: Remove unintentional intentional mentions in replies

Currently, the reply spec has a section called [Mentioning the replied to user](https://spec.matrix.org/v1.10/client-server-api/#mentioning-the-replied-to-user)
which says

> In order to notify users of the reply, it may be desirable to include the
> sender of the replied to event and any users mentioned in that event. See
> [user and room mentions](https://spec.matrix.org/v1.10/client-server-api/#user-and-room-mentions)
> for additional information.

The "*any users mentioned in that event*" part is particularly problematic, as
it effectively means all mentions will be propagated forever through a reply
chain, causing lots of unintentional pings.
clokep marked this conversation as resolved.
Show resolved Hide resolved

The propagation was originally added to preserve the old reply fallback mention
behavior where explicit mentions in the replied-to message were be copied to
the reply fallback and therefore caused pings. However, the current spec copies
far more than just explicit pings from the replied-to message. Additionally, no
other chat application that I know of propagates mentions like that.

## Proposal
The proposed fix is to stop propagating mentions entirely. The `m.mentions`
object of replies should only contain explicit mentions in the new message,
plus the sender of the replied-to message. The mentions in the replied-to
message are ignored.

Clients are still free to add other mentions to the list as they see fit. For
example, a client could offer a button to mention all users in a reply chain.
This proposal simply changes the default behavior recommended in the spec.

## Potential issues
Users who have already got used to the new behavior may be surprised when they
don't get mentioned by reply chains.

## Alternatives
### Split `m.mentions`
To preserve the old reply fallback behavior, `m.mentions` could be split into
"explicit" and "implicit", so that replies copy explicit mentions into the
implicit list. Future replies would then only copy new explicit pings and
wouldn't cause an infinite chain.

Since other chat applications don't copy pings at all, having a weird feature
like that doesn't seem worth the additional complexity.

## Security considerations
This proposal doesn't touch anything security-sensitive.

## Unstable prefix
Not applicable, this proposal only changes how the existing `m.mentions` object
is filled for replies.