@stevenroose @berkes Rate-limiting makes sense here, but need to check carefully that interactive use cases like GitNex client apps are not impacted.
@stevenroose @berkes one request per 5sec possibly a bit tight for interactive use, at the same time one spam issue comment every 5 seconds already quite a lot
@codeberg @stevenroose rate-limiting based on a combination of session (ID in headers?), IP and 'user' often works.
Where Z > X, Z > Y. And Y > X.
For rails, I always use https://github.com/jeremy/rack-ratelimit. There might be something in go, that can be integrated in gitea. Or agnostic proxy that is as flexible and tunable.
Though a proxy has no knowledge of things like 'user' or 'customer'.
@codeberg also note that typically, rate limiting for GET request can be an order of magnitute more lenient than for PUT/patch/POST/DELETE.
E.g. where you say: per IP we allow 100.000 read (GET) requests per hour, but only 100 writes (post etc ) per hour.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!