Skip to content

MSC4326: Device masquerading for appservices #4326

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

MSC4326: Device masquerading for appservices #4326

wants to merge 1 commit into from
+116 −0

Conversation

turt2live
Copy link
Member

@turt2live turt2live commented Aug 12, 2025 •
edited
Loading

Rendered

Disclosure: I am Director of Standards Development at The Matrix.org Foundation C.I.C., Matrix Spec Core Team (SCT) member, employed by Element, and operate the t2bot.io service. This proposal is written and published with my role as a member of the SCT.

SCT Stuff:

MSC checklist

FCP tickyboxes

@turt2live turt2live changed the title MSC: Device masquerading for appservices MSC4326: Device masquerading for appservices Aug 12, 2025
@turt2live
Copy link
Member Author

turt2live commented Aug 12, 2025 •
edited
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.

@turt2live turt2live marked this pull request as ready for review August 12, 2025 04:06
@turt2live turt2live added proposal A matrix spec change proposal application services kind:core MSC which is critical to the protocol's success needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Aug 12, 2025
turt2live
turt2live commented Aug 12, 2025
View reviewed changes
proposals/4326-appservice-device-masquerading.md
Copy link
Member Author

@turt2live turt2live Aug 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

Implementation requirements are met through MSC3202, specifically this bit of Synapse and the listed appservice/bot usage.

@turt2live turt2live removed the needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. label Aug 12, 2025
@turt2live
Copy link
Member Author

As this is effectively blocking #4190 - let's get this through the process.

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Aug 12, 2025 •
edited
Loading

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

Concerns:

  • inexplicable error code choice

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 Aug 12, 2025
@github-project-automation github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Aug 12, 2025
@turt2live turt2live moved this from Tracking for review to Ready for FCP ticks in Spec Core Team Workflow Aug 12, 2025
This was referenced Aug 12, 2025
Open
Open
richvdh
richvdh reviewed Aug 26, 2025
View reviewed changes
proposals/4326-appservice-device-masquerading.md
and "last seen timestamp" for the device, though for some endpoints it may mean interacting with the
device specifically (such as when uploading one-time keys).

If the `device_id` does not already exist on the `user_id`, the server returns a `400 M_EXCLUSIVE`
Copy link
Member

Choose a reason for hiding this comment

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

why M_EXCLUSIVE, of all things?

@richvdh
Copy link
Member

richvdh commented Sep 2, 2025

Maybe not the biggest problem in the world, but to make clear why this hasn't received my tick:

@mscbot concern inexplicable error code choice

@mscbot mscbot added the unresolved-concerns This proposal has at least one outstanding concern label Sep 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@richvdh richvdh richvdh left review comments

Assignees
No one assigned
Labels
application services disposition-merge kind:core MSC which is critical to the protocol's success 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. unresolved-concerns This proposal has at least one outstanding concern
Projects
Spec Core Team Workflow
Status: Ready for FCP ticks
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@turt2live @mscbot @richvdh