No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

icub3d/decentcom#48

icub3d commented

2026-04-26 16:46:06 +00:00

Owner

Migrated from GitHub issue icub3d/decentcom#67
Original Author: @icub3d
Original Date: 2026-04-17T00:27:46Z

Feature: Rate Limiting Research and Implementation

Overview

Implement rate limiting for the REST API and WebSocket Gateway to protect server resources and prevent abuse from automated scripts and bots.

Background

As we enable first-class bot support and open server membership, the risk of API spam and resource exhaustion increases. The current implementation has no rate limiting, allowing any client to flood the server with requests or messages.

Requirements

Research rate limiting strategies (leaky bucket, token bucket, fixed window, etc.).
Evaluate in-process vs external (e.g. reverse proxy) rate limiting.
Implement rate limiting for auth endpoints (prevent brute-forcing).
Implement rate limiting for message creation and other sensitive actions.
Different rate limits for human users vs unverified bots vs verified bots.
Return standard 429 Too Many Requests responses with Retry-After headers.

Design (Open for Research)

API / Interface Changes

429 Too Many Requests status code implementation.
X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset headers.

Data Model Changes

Likely an in-memory store (e.g., using the governor crate) for tracking request counts.

Component Changes

server/src/auth/middleware.rs: Add rate limiting layer.
server/src/gateway/handler.rs: Add rate limiting to WebSocket message handling.

Task List

Research existing Rust rate limiting crates (e.g., governor, tower-rate-limit).
Create a prototype rate limiting middleware for Axum.
Document recommended external rate limiting configurations (Nginx/Caddy) for self-hosters.
Implement per-user and per-IP rate limits.

Test List

Integration test: sending 100 messages in 1 second returns 429.
Integration test: rate limit reset after the specified window.

Open Questions

Should we use Redis for rate limiting in clustered setups, or stick to in-memory for simplicity?
How do we handle rate limits for the WebSocket gateway specifically?

**Migrated from GitHub issue icub3d/decentcom#67** **Original Author:** @icub3d **Original Date:** 2026-04-17T00:27:46Z --- # Feature: Rate Limiting Research and Implementation ## Overview Implement rate limiting for the REST API and WebSocket Gateway to protect server resources and prevent abuse from automated scripts and bots. ## Background As we enable first-class bot support and open server membership, the risk of API spam and resource exhaustion increases. The current implementation has no rate limiting, allowing any client to flood the server with requests or messages. ## Requirements - [ ] Research rate limiting strategies (leaky bucket, token bucket, fixed window, etc.). - [ ] Evaluate in-process vs external (e.g. reverse proxy) rate limiting. - [ ] Implement rate limiting for auth endpoints (prevent brute-forcing). - [ ] Implement rate limiting for message creation and other sensitive actions. - [ ] Different rate limits for human users vs unverified bots vs verified bots. - [ ] Return standard 429 Too Many Requests responses with `Retry-After` headers. ## Design (Open for Research) ### API / Interface Changes - `429 Too Many Requests` status code implementation. - `X-RateLimit-Limit`, `X-RateLimit-Remaining`, `X-RateLimit-Reset` headers. ### Data Model Changes - Likely an in-memory store (e.g., using the `governor` crate) for tracking request counts. ### Component Changes - `server/src/auth/middleware.rs`: Add rate limiting layer. - `server/src/gateway/handler.rs`: Add rate limiting to WebSocket message handling. ## Task List - [ ] Research existing Rust rate limiting crates (e.g., `governor`, `tower-rate-limit`). - [ ] Create a prototype rate limiting middleware for Axum. - [ ] Document recommended external rate limiting configurations (Nginx/Caddy) for self-hosters. - [ ] Implement per-user and per-IP rate limits. ## Test List - [ ] Integration test: sending 100 messages in 1 second returns 429. - [ ] Integration test: rate limit reset after the specified window. ## Open Questions - Should we use Redis for rate limiting in clustered setups, or stick to in-memory for simplicity? - How do we handle rate limits for the WebSocket gateway specifically?

icub3d added the

status:planned

area:api

type:research

labels

Rows
Columns

Feature: API and Gateway Rate Limiting #48