Skip to content

MSC4169: Backwards-compatible redaction sending using /send #4169

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 8 commits into
base: main
Choose a base branch
from
Open

MSC4169: Backwards-compatible redaction sending using /send #4169

wants to merge 8 commits into from

Conversation

tulir
Copy link
Member

@tulir tulir commented Jul 7, 2024 •
edited by turt2live
Loading

@tulir tulir added proposal A matrix spec change proposal client-server Client-Server API needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. kind:maintenance MSC which clarifies/updates existing spec labels Jul 7, 2024
@tulir tulir mentioned this pull request Sep 8, 2025
Merged
3 tasks
@tulir tulir removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Sep 8, 2025
@tulir tulir marked this pull request as ready for review September 8, 2025 15:59
turt2live
turt2live approved these changes Sep 8, 2025
View reviewed changes
Copy link
Member

@turt2live turt2live left a comment

Choose a reason for hiding this comment

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

generally lgtm

@tulir
Undeprecate /redact
94ec653 
Signed-off-by: Tulir Asokan <[email protected]>
@tulir
Copy link
Member Author

tulir commented Sep 9, 2025 •
edited by KitsuneRal
Loading

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 Sep 9, 2025

Probably no reason to delay this, it's very straightforward

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Sep 9, 2025 •
edited by KitsuneRal
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 Sep 9, 2025
@github-project-automation github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Sep 9, 2025
@tulir tulir moved this from Tracking for review to Ready for FCP ticks in Spec Core Team Workflow Sep 9, 2025
@turt2live turt2live added the 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. label Sep 9, 2025
anoadragon453
anoadragon453 reviewed Sep 9, 2025
View reviewed changes
proposals/4169-send-redact-backwards-compatibility.md
Comment on lines +5 to +6
The `/redact` endpoint is also forwards-compatible because it works in all room
versions. However, `/send` was not made backwards-compatible. This means that
Copy link
Member

Choose a reason for hiding this comment

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

I don't see MSC2174 specifically calling out either /redact or /send. Was this an issue with server implementation?

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 there was any issue with /redact, but servers did obviously have to make changes to the endpoint in room v11 even though the MSC didn't call it out explicitly.

proposals/4169-send-redact-backwards-compatibility.md Outdated
Additionally, [MSC4140] currently only defines delaying events for `/send`.
While it could be extended to support `/redact` for self-destructing messages,
the MSC can also work as-is if `/send` supported redactions in all room
versions.
Copy link
Member

Choose a reason for hiding this comment

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

I feel like you're circling the use case you're trying to support without explicitly saying it.

I think this could be better expressed as "This inconsistency makes it difficult to implement features such as self-destructing messages (utilising MSC4140's delayed events functionality, which is only implemented for /send). As clients cannot reliably use /send to send redactions across all room versions while supporting older clients."

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 original reason why I wrote this MSC in 2024 was actually abstracting event sending in a client SDK without special-casing redactions, MSC4140 just brought it up again and was harder to work around

Copy link
Member Author

Choose a reason for hiding this comment

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

Have reworded that paragraph

KitsuneRal
KitsuneRal reviewed Sep 9, 2025
View reviewed changes
@tulir tulir requested a review from anoadragon453 September 11, 2025 15:05
reivilibre pushed a commit to element-hq/synapse that referenced this pull request Sep 22, 2025
@SpiritCroc @tulir
Implement MSC4169: backwards-compatible redaction sending for rooms <…
83aca3f 
… v11 using the /send endpoint (#18898)

Implement
[MSC4169](matrix-org/matrix-spec-proposals#4169)

While there is a dedicated API endpoint for redactions, being able to
send redactions using the normal send endpoint is useful when using
[MSC4140](matrix-org/matrix-spec-proposals#4140)
for sending delayed redactions to replicate expiring messages. Currently
this would only work on rooms >= v11 but fail with an internal server
error on older room versions when setting the `redacts` field in the
content, since older rooms would require that field to be outside of
`content`. We can address this by copying it over if necessary.

Relevant spec at
https://spec.matrix.org/v1.8/rooms/v11/#moving-the-redacts-property-of-mroomredaction-events-to-a-content-property

---------

Co-authored-by: Tulir Asokan <[email protected]>
@turt2live turt2live removed the 00-weekly-pings Tracking for weekly pings in the SCT office. 00 to make it first in the labels list. label Sep 30, 2025
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this pull request Oct 8, 2025
chat/matrix-synapse: Update to 1.139.0
762c0cd 
# Synapse 1.139.0 (2025-09-30)

## Features

- Add experimental support for [MSC4308: Thread Subscriptions extension to Sliding Sync](matrix-org/matrix-spec-proposals#4308) when [MSC4306: Thread Subscriptions](matrix-org/matrix-spec-proposals#4306) and [MSC4186: Simplified Sliding Sync](matrix-org/matrix-spec-proposals#4186) are enabled. ([\#18695](element-hq/synapse#18695))
- Update push rules for experimental [MSC4306: Thread Subscriptions](matrix-org/matrix-spec-proposals#4306) to follow a newer draft. ([\#18846](element-hq/synapse#18846))
- Add `get_media_upload_limits_for_user` and `on_media_upload_limit_exceeded` module API callbacks to the media repository. ([\#18848](element-hq/synapse#18848))
- Support [MSC4169](matrix-org/matrix-spec-proposals#4169) for backwards-compatible redaction sending using the `/send` endpoint. Contributed by @SpiritCroc @ Beeper. ([\#18898](element-hq/synapse#18898))
- Add an in-memory cache to `_get_e2e_cross_signing_signatures_for_devices` to reduce DB load. ([\#18899](element-hq/synapse#18899))
- Update [MSC4190](matrix-org/matrix-spec-proposals#4190) support to return correct errors and allow appservices to reset cross-signing keys without user-interactive authentication. Contributed by @tulir @ Beeper. ([\#18946](element-hq/synapse#18946))

## Deprecations and Removals

- Remove obsolete and experimental `/sync/e2ee` endpoint. ([\#18583](element-hq/synapse#18583))

# Synapse 1.138.0 (2025-09-09)

## Features

- Support for the stable endpoint and scopes of [MSC3861](matrix-org/matrix-spec-proposals#3861) & co. ([\#18549](element-hq/synapse#18549))
itsoyou pushed a commit to famedly/synapse that referenced this pull request Oct 13, 2025
@SpiritCroc @tulir @itsoyou
Implement MSC4169: backwards-compatible redaction sending for rooms <…
3fd5cd8 
… v11 using the /send endpoint (#18898)

Implement
[MSC4169](matrix-org/matrix-spec-proposals#4169)

While there is a dedicated API endpoint for redactions, being able to
send redactions using the normal send endpoint is useful when using
[MSC4140](matrix-org/matrix-spec-proposals#4140)
for sending delayed redactions to replicate expiring messages. Currently
this would only work on rooms >= v11 but fail with an internal server
error on older room versions when setting the `redacts` field in the
content, since older rooms would require that field to be outside of
`content`. We can address this by copying it over if necessary.

Relevant spec at
https://spec.matrix.org/v1.8/rooms/v11/#moving-the-redacts-property-of-mroomredaction-events-to-a-content-property

---------

Co-authored-by: Tulir Asokan <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@turt2live turt2live turt2live approved these changes

@KitsuneRal KitsuneRal KitsuneRal left review comments

@clokep clokep clokep approved these changes

@anoadragon453 anoadragon453 Awaiting requested review from anoadragon453

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.

6 participants

@tulir @mscbot @clokep @turt2live @anoadragon453 @KitsuneRal