Skip to content

MSC4335: M_USER_LIMIT_EXCEEDED error code #4335

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

MSC4335: M_USER_LIMIT_EXCEEDED error code #4335

wants to merge 10 commits into from
+188 −0

Conversation

hughns
Copy link
Member

@hughns hughns commented Aug 29, 2025 •
edited by tulir
Loading

Rendered

Implementations:

In the prototype implementation when this error code is encountered for a file upload, it is rendered as follows for a soft limit:

image

And like this for a hard limit:

image

I am employed by Element to write this MSC on behalf of the Matrix Foundation for use on the matrix.org homeserver.

SCT Stuff:

MSC checklist

FCP tickyboxes

@hughns hughns changed the title MSCXXXX: M_USER_LIMIT_EXCEEDED error code MSC4335: M_USER_LIMIT_EXCEEDED error code Aug 29, 2025
This was referenced Aug 29, 2025
Draft
Open
@turt2live turt2live added proposal A matrix spec change proposal client-server Client-Server API kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. labels Aug 29, 2025
t3chguy
t3chguy reviewed Aug 30, 2025
View reviewed changes
@hughns hughns requested a review from erikjohnston September 8, 2025 10:45
@hughns hughns marked this pull request as ready for review September 24, 2025 17:07
Johennes
Johennes reviewed Sep 25, 2025
View reviewed changes
@Johennes Johennes mentioned this pull request Oct 6, 2025
Open
3 tasks
@hughns hughns mentioned this pull request Oct 10, 2025
Draft
5 tasks
@ara4n
Copy link
Member

ara4n commented Oct 10, 2025

@mscbot fcp merge

@mscbot
Copy link
Collaborator

mscbot commented Oct 10, 2025 •
edited
Loading

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

Concerns:

  • Checklist not complete/started

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 Oct 10, 2025
clokep
clokep reviewed Oct 10, 2025
View reviewed changes
proposals/4335-user-limit-exceeded.md
Comment on lines +86 to +90
This error code does not specify the exact nature of the limit that was exceeded, which could
potentially lead to ambiguity. However, this is consistent with other Matrix error codes that
rely on the human-readable `error` field to provide specific details. Instead the `info_uri`
provides a way for the homeserver to apply arbitrary limits without the client having to understand
every type in advance.
Copy link
Member

Choose a reason for hiding this comment

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

Should we include a type field that gets passed to info_uri as a query parameter or something?

Copy link
Member

Choose a reason for hiding this comment

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

Why not just encode the necessary information in info_uri straight away on the server side?

Copy link
Member Author

Choose a reason for hiding this comment

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

Why not just encode the necessary information in info_uri straight away on the server side?

Exactly. The intention is that the URIs are opaque and the homeserver may choose to put a type or similar field in there.

I've attempted to clarify this in 4dd453b.

Copy link
Member

Choose a reason for hiding this comment

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

Why not just encode the necessary information in info_uri straight away on the server side?

Well I assume you want to tell people what limit they've passed, would each of those be a separate info_uri? Feels like it ties your homeserver implementation tightly to whatever is at those URIs.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not understanding how just saying they're "opaque" resolves this. This makes it very tied to particular homeserver implementations.

Copy link
Member Author

Choose a reason for hiding this comment

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

That’s the point. It is tied to the homeserver.

Why is that a concern?

@tulir
Copy link
Member

tulir commented Oct 10, 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.

Johennes
Johennes reviewed Oct 13, 2025
View reviewed changes
@github-project-automation github-project-automation bot moved this to Tracking for review in Spec Core Team Workflow Oct 14, 2025
@turt2live
Copy link
Member

@mscbot concern Checklist not complete/started

(any SCT member can resolve this)

@mscbot mscbot added the unresolved-concerns This proposal has at least one outstanding concern label Oct 14, 2025
@turt2live turt2live moved this from Tracking for review to Ready for FCP ticks in Spec Core Team Workflow Oct 14, 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

@t3chguy t3chguy t3chguy left review comments

@KitsuneRal KitsuneRal KitsuneRal left review comments

@erikjohnston erikjohnston Awaiting requested review from erikjohnston

+1 more reviewer

@Johennes Johennes Johennes left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

client-server Client-Server API disposition-merge kind:maintenance MSC which clarifies/updates existing spec needs-implementation This MSC does not have a qualifying implementation for the SCT to review. The MSC cannot enter FCP. 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.

9 participants

@hughns @ara4n @mscbot @tulir @turt2live @clokep @Johennes @t3chguy @KitsuneRal