The lead · Relay infrastructure
A Relay Learns to Say No
After repeated outages at nos.lol, its operator reports that a small change inside the relay held back millions of junk read requests.
The restart was becoming part of the problem. In an account posted Tuesday, the nos.lol operator writing as someone described a relay repeatedly brought down by connection floods and machine chatter. Each restart sent legitimate users rushing back alongside the attackers. The gaps between failures shrank until the service was dying in about a minute.
Firewalls bought time. Around 580 bots were identified and blocked, the operator said, but fresh addresses kept appearing. Shared VPN exits complicated the response: blocking one address could take innocent users with it. Meanwhile, a single spam-filter process became a queue that other workers could not get past.
The reported turning point was roughly fifty lines of request rate limiting inside the relay, applied per address and globally. Excess read requests were refused before reaching its internals. The operator said the relay had rejected over 12 million junk requests and run for 20 hours 50 minutes without a restart at the time of the dispatch.
Requests over the limit are refused before they touch the relay's internals, so the jam has nothing to feed on.
— someone, the operator’s account
The follow-up question reaches beyond attackers. In a later note, someone asked what normal relay use should look like as agents and applications begin treating Nostr as storage, a rendezvous point, or a message bus. The posted threshold was 200 read requests in ten seconds. An open relay still has somebody paying for the door.
The follow-up on client behaviour · Figures are the operator’s reported readings.
