Rate limiting spec ambiguous

[danielniccoli]

The specs state for every API endpoint if it is rate-limited or not. Example:

https://matrix.org/docs/spec/client_server/latest#post-matrix-client-r0-register

But later in the specs it is stated that ...

Homeservers SHOULD implement rate limiting to reduce the risk of being overloaded. If a request is refused due to rate limiting, it should return a standard error response of the form.
https://matrix.org/docs/spec/client_server/latest#rate-limiting

Does 12 override the specs of the endpoints that are not rate-limited? Or is rate-limiting in itself just a recommendation?

[turt2live]

Rate limiting is just a recommendation. Some endpoints are intentionally not rate limited, but we've also missed defining rate limiting on a few.

[richvdh]

honestly it seems odd to me for the spec to take a position on what should be rate-limited or not. That's pretty much an implementation decision.

The spec might want to give advice on endpoints that should have higher or lower rate limits, but putting it next to "Requires auth" like that makes it look like gospel.

[danielniccoli]

honestly it seems odd to me for the spec to take a position on what should be rate-limited or not. That's pretty much an implementation decision.

Yes, that's what I was thinking until I arrived at No.12 in the specs. Also, wouldn't it be preferrable that rat-limiting is done at the web server layer rather than the server? The way rate-limiting is documented right now also implies that rate-limiting should be done in the Matrix server-implementation.

How about changing it to:

Rate-limit recommendation: Yes|No.

or

Rate-limited: Recommended/Not recommended.

[joepie91]

Related: #320?

[reivilibre]

The spec is still not clear at all today that rate-limiting is just a recommendation; would we accept a spec text change to clarify this?

Responding to a PR (element-hq/synapse#18927) now where someone has (very reasonably) interpreted Synapse rate-limiting where the spec says 'No' as a Synapse bug...