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
• TravisR - Implementation not sufficient - doesn't appear to be tested in practice, or validates that existing clients handle the new error code appropriately

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.

[turt2live]

@mscbot resolve Checklist not complete/started
@mscbot concern TravisR - Implementation not sufficient - doesn't appear to be tested in practice, or validates that existing clients handle the new error code appropriately

[anoadragon453]

Should we just include increase_uri if the limit can be increased, otherwise omit it?

[clokep]

Do you mean not have the soft_limit flag?

[anoadragon453]

Suggested change

	As such, I think this message would be confusing to users the interim whilst clients updated their implementations and
	As such, I think this message would be confusing to users in the interim whilst clients updated their implementations and

[anoadragon453]

It also prevents homeservers for implementing new limits without writing an MSC (the next alternative also speaks to this).

However, it would solve the translation problem without the homeserver needing to define every translation.

[uhoreg]

nit: since clients sometimes show the error to the user, I think

Suggested change

	"error": "User has exceeded their storage quota of 10GB",
	"error": "You have exceeded your storage quota of 10GB",

would look better. (same below)