Limits API

[erkinalp]

Not all users are as lucky as matrix.org to have variable scaling.

Corresponds to Matrix feature request https://github.com/matrix-org/matrix-doc/issues/3018 and MSCs matrix-org/matrix-spec-proposals#3021, matrix-org/matrix-spec-proposals#3053, matrix-org/matrix-spec-proposals#3059.

[erikjohnston]

Hi, this isn't really that actionable on our side until the MSCs land, so I'm going to close this for now. If there are things that you think can be done here without a spec change then feel free to open a new issue 🙂

[erkinalp]

@Sorunome said that x-per-user does not need an MSC:

how / why?
soru can see x-per-users be helpful in commercial aspects, but not users-per-x
conveniently, x-per-users is an implmentation detail
x-per-user is an implementation detail and shouldn't need an msc

Therefore matrix-org/matrix-spec-proposals#3021 can be said to be actionable even now, because it only affects a particular server and not server-to-server communication (both room and session limits only concern the homeserver of said user). We can use the org.matrix.limits prefix as the unstable prefix if it is OK for you. That also applies to "per-user per-server" part of matrix-org/matrix-spec-proposals#3059. Those MSCs arose out of the need to standardise the interfaces of fanout and rate limiting to allow clients to query the remaining limits and fail gracefully. However matrix-org/matrix-spec-proposals#3053 and "per-user per-room" part of matrix-org/matrix-spec-proposals#3059 need standardisation as those features bring changes in state resolution and event authorisation.