MSC4335: M_USER_LIMIT_EXCEEDED error code

[hughns]

Rendered

---

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.

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 Element Web 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:

Customisation of clients for matrix.org homeserver

The Matrix.org Foundation has discussed with Element Creations Limited the possibility of having Element clients show a custom message when the M_USER_LIMIT_EXCEEDED error is received from the matrix.org homeserver. Element have agreed to this in principle.

If this MSC is accepted then the Foundation intends to request that other client developers consider implementing a similar customisation for the matrix.org homeserver. The purpose of this is to support the funding of the matrix.org homeserver.

Whilst the exact design/form of this in Element is to be decided, the following illustrates the level of customisation that is anticipated. (For example, it might appear as feedback within the timeline instead of a modal)

In the case of a Free user encountering a limit that can be increased by upgrading to Premium:

For a hard limit:

---

SCT Stuff:

MSC checklist

FCP tickyboxes

[ara4n]

@mscbot fcp merge

[mscbot]

Team member @mscbot has proposed to None 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
• how can clients programmatically discern between a soft limit and a payment required limit if both are setup on a homeserver?

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]

The bot isn't aware that FCP is paused when a concern is raised during the countdown. This still has 4 days of FCP to go once the concern is cleared.

[richvdh]

Ahem:

https://spec.matrix.org/proposals/#process:

a member of the Spec Core Team can raise a concern and block FCP from completing. This will not reset or pause the 5 day FCP timer

[turt2live]

The rest of that quote feels relevant:

... but FCP will not conclude until all concerns have been resolved.

so there's 0 days left, but it's still in FCP.

See also: matrix-org/mscbot-python#3 (also note that the process on spec.matrix.org is full of lies in many places, but here it looks accurate enough).

[KitsuneRal]

@mscbot resolve how can clients programmatically discern between a soft limit and a payment required limit if both are setup on a homeserver?

[turt2live]

we'll fix the spell check later

[hughns]

Spec PR: matrix-org/matrix-spec#2315

[turt2live]

Merged 🎉