Skip to content

MSC4142: Remove unintentional intentional mentions in replies #4142

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

MSC4142: Remove unintentional intentional mentions in replies #4142

wants to merge 2 commits into from
+51 −0

Conversation

tulir
Copy link
Member

@tulir tulir commented May 9, 2024 •
edited by turt2live
Loading

Rendered

Implementations:

This MSC was inspired by an unintentional mention chain in Matrix HQ

image

SCT stuff:

MSC checklist

FCP tickyboxes

@tulir
Proposal for removing unintentional intentional mentions in replies
4516c6e 
Signed-off-by: Tulir Asokan <tulir@maunium.net>
@tulir tulir added proposal A matrix spec change proposal kind:maintenance MSC which clarifies/updates existing spec labels May 9, 2024
@tulir
Copy link
Member Author

tulir commented May 9, 2024

Discussion about the issue on the original MSC: #3952 (comment)

@tulir
Explicitly specify that clients can add more mentions
8bf8bf3 
Signed-off-by: Tulir Asokan <tulir@maunium.net>
clokep
clokep reviewed May 9, 2024
View reviewed changes
turt2live
turt2live reviewed May 10, 2024
View reviewed changes
proposals/4142-fix-reply-intentional-mentions.md
Copy link
Member

@turt2live turt2live May 10, 2024 •
edited by tulir
Loading

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

The Element product team has approved the change now

Copy link
Member Author

Choose a reason for hiding this comment

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

I don't think anyone has complained about the lack of unexpected mentions in the past few months

@turt2live turt2live added the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label May 10, 2024
@tulir tulir mentioned this pull request May 11, 2024
Closed
@deepbluev7 deepbluev7 mentioned this pull request May 13, 2024
Merged
@jmartinesp jmartinesp mentioned this pull request Jul 10, 2024
Closed
@tulir tulir mentioned this pull request Sep 11, 2024
Closed
@tulir tulir mentioned this pull request Oct 16, 2024
Merged
@pixlwave pixlwave mentioned this pull request Nov 26, 2024
Open
@tulir tulir added client-server Client-Server API and removed needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Jun 13, 2025
@tulir
Copy link
Member Author

tulir commented Jun 13, 2025

MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands.

SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable.

Checklist:

  • Are appropriate implementation(s)
    specified in the MSC’s PR description?
  • Are all MSCs that this MSC depends on already accepted?
  • For each new endpoint that is introduced:
    • Have authentication requirements been specified?
    • Have rate-limiting requirements been specified?
    • Have guest access requirements been specified?
    • Are error responses specified?
      • Does each error case have a specified errcode (e.g. M_FORBIDDEN) and HTTP status code?
        • If a new errcode is introduced, is it clear that it is new?
  • Will the MSC require a new room version, and if so, has that been made clear?
    • Is the reason for a new room version clearly stated? For example,
      modifying the set of redacted fields changes how event IDs are calculated,
      thus requiring a new room version.
  • Are backwards-compatibility concerns appropriately addressed?
  • Are the endpoint conventions honoured?
    • Do HTTP endpoints use_underscores_like_this?
    • Will the endpoint return unbounded data? If so, has pagination been considered?
    • If the endpoint utilises pagination, is it consistent with
      the appendices?
  • An introduction exists and clearly outlines the problem being solved.
    Ideally, the first paragraph should be understandable by a non-technical audience.
  • All outstanding threads are resolved
    • All feedback is incorporated into the proposal text itself, either as a fix or noted as an alternative
  • While the exact sections do not need to be present,
    the details implied by the proposal template are covered. Namely:
    • Introduction
    • Proposal text
    • Potential issues
    • Alternatives
    • Dependencies
  • Stable identifiers are used throughout the proposal, except for the unstable prefix section
    • Unstable prefixes consider the awkward accepted-but-not-merged state
    • Chosen unstable prefixes do not pollute any global namespace (use “org.matrix.mscXXXX”, not “org.matrix”).
  • Changes have applicable Sign Off from all authors/editors/contributors
  • There is a dedicated "Security Considerations" section which detail
    any possible attacks/vulnerabilities this proposal may introduce, even if this is "None.".
    See RFC3552 for things to think about,
    but in particular pay attention to the OWASP Top Ten.

@tulir
Copy link
Member Author

tulir commented Jun 13, 2025

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Jun 13, 2025 •
edited by richvdh
Loading

Team member @tulir has proposed to merge this. The next step is review by the rest of the tagged people:

Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for information about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Jun 13, 2025
@github-project-automation github-project-automation bot moved this to Needs idea feedback / initial review in Spec Core Team Workflow Jun 16, 2025
@turt2live turt2live moved this from Needs idea feedback / initial review to Ready for FCP ticks in Spec Core Team Workflow Jun 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@clokep clokep clokep left review comments

@turt2live turt2live turt2live approved these changes

Assignees
No one assigned
Labels
client-server Client-Server API disposition-merge kind:maintenance MSC which clarifies/updates existing spec proposal A matrix spec change proposal proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period.
Projects
Spec Core Team Workflow
Status: Ready for FCP ticks
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@tulir @mscbot @clokep @turt2live