MSC4335: M_USER_LIMIT_EXCEEDED error code

[hughns]

Rendered

Implementations:

• Server:
  • Synapse: Support for experimental MSC4335 error code for media upload limits element-hq/synapse#18876
• Client:
  • Element Web: Support for experimental MSC4335 M_USER_LIMIT_EXCEEDED error code element-hq/element-web#30738

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

And like this for a hard limit:

---

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

---

SCT Stuff:

MSC checklist

FCP tickyboxes

[ara4n]

@mscbot fcp merge

[mscbot]

Team member @mscbot 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

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.

[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.

[turt2live]

@mscbot concern Checklist not complete/started

(any SCT member can resolve this)

[hughns]

I have added an alternative of using server side translations here instead of info_uri, soft_limit and increase_uri.

I think this would actually provide a better UX overall, albeit at the expense of complexity for the homeserver operator and error payload size.

I would welcome input on this.

[Johennes]

Could the server not use specific wording in error field of the current standard error response, too?

E.g.:

{
  "errcode": "M_USER_LIMIT_EXCEEDED",
  "error": "You have reached your daily upload limit. More information on the usage limits that apply to your account is available <a href=\"https://matrix.org/homeserver/pricing/#usage-limits\">here</a>. You can upgrade to a Premium account to increase the limits <a href=\"https://account.matrix.org/account?action=org.matrix.plan_management\">here</a>.",
  ..
}

From a quick check the only restriction on error that I could find in the spec is that it's human readable.

The error string will be a human-readable error message, usually a sentence explaining what went wrong.

[t3chguy]

Clients shouldn't show a non-i18n'd error field though because it may not match the user's language requirements, so clients end up having to use only errcode and mapping those to translations themselves

[Johennes]

Ah. Ok, that makes sense, thanks.