The built-in floor caps the whole server at 2,000 record writes an hour and 16,000 a day (crates/didbot-policy-records/floor/write-rate.json:26,32). An operator can only narrow it. At 10x it is the first thing that binds, well before CPU, memory or disk.
From a 10x pass on loopback at 73ddde8 (2,700 accounts, 23k records):
- Today it binds at a sustained 0.56 writes/s.
- A 10x peak of 10 writes/s reaches the hour cap in 200 s.
- 2,700 accounts each posting at vibescrobble's 6/min cap (270/s) reach it in 7 s.
- The server itself sustained 270 writes/s with 23 firehose consumers at p50 1.35 ms and p95 7.2 ms, using 0.35 cores locally (about 0.7 vCPU on a t3.small).
- The count resets on restart (
didbot-policy-count/src/counts.rs:87).
The numbers mirror the relay's limits for a new PDS (2,600 events an hour and 21,000 a day; see the closed federation issue about Bluesky's relay admitting 100 accounts). So raising them starts with a rate-limit increase from the relay operator. What didbot needs is a config path that widens the floor once a relay has granted more, stated as its own key with documented ranges, plus /health or stats showing how much of the hour and day budget is spent.
I didn't build this one, because it isn't a contained fix. The write caps live in
crates/didbot-policy-records/floor/write-rate.json, which is part of the built-in floor.builtin.rssays the floor has "no config path, no record, no admin surface ... that is the whole point of immutable." Widening it from config would be a change to that design, so it needs the owner's decision.On the theme of one client starving the rest: each account may write 1,000 records an hour, and the whole server 2,000. So two accounts writing at their own limits use up the server's hour, and every other account is refused until it rolls over. Keeping the server cap and giving each account a fair share would also mean changing floor numbers.
What a fix would take:
bot.did.policyrecord. Operators can already raise their own records, which would be the config path the relay grant needs, with no new key.didbot-policy-count/src/counts.rs:87), and persisting them would be new state./health, which is a new field.