MSC4142: Remove unintentional intentional mentions in replies

[tulir]

Rendered

Implementations:

• Implement MSC4142: Remove unintentional intentional mentions in replies element-hq/element-web#28209 (removed mention propagating from existing replied-to mention code)
• Nheko-Reborn/nheko@cf373c0 (added mention of replied-to user without mention propagating)

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

---

SCT stuff:

MSC checklist

FCP tickyboxes

[tulir]

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

[turt2live]

Implementation requirements:

• Client code for the feature - Implement MSC4142: Remove unintentional intentional mentions in replies matrix-react-sdk#12511
• Actively used by users to demonstrate desired behaviour

[tulir]

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

[turt2live]

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.

[tulir]

The Element product team has approved the change now

[tulir]

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

[tulir]

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]

@mscbot fcp merge

[mscbot]

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

• @clokep
• @dbkr
• @uhoreg
• @turt2live
• @ara4n
• @anoadragon453
• @richvdh
• @tulir
• @erikjohnston
• @KitsuneRal

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]

🔔 This is now entering its final comment period, as per the review above. 🔔

[mscbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

[Johennes]

Spec PR: matrix-org/matrix-spec#2210

[clokep]

Merged! 🎉