The cost of an ordinary scroll
The relay banned its own operator
A nos.lol operator traces a traffic ban back to their own phone. The ensuing discussion asks how much work a client makes a relay do.
The suspicious address belonged to the person running the service. Posting as someone, a nos.lol operator recounts: Last week I banned my own phone from my own relay (nos.lol).
They had been reading global feeds in YakiHonne web and Coracle over a mobile connection.
The operator describes a limit of 200 subscription-request messages per IP address every 10 seconds, backed by a script that bans persistent excess. The flagged connection had sent 283 requests over the cap and reconnected seventy-five times in an hour. In this account, ordinary reading looked enough like a flood to trip the protection.
The follow-up was an AI-assisted inspection of client code. It points to differences in how applications combine requests, reuse cached events and retry subscriptions after a connection drops. Those findings are the operator’s review, not a controlled comparison conducted by this paper.
In the thread, Kieran responds that queries should go through the cache, repeated requests should carry a time filter, and most requests are inexpensive. That introduces a useful distinction: a cap that counts messages and an assessment of the work each message causes are measuring different things.
The operator’s central complaint is that a refusal from a relay does not always change a client’s sending pattern. A reconnection that immediately repeats the same requests can bring the problem back with it. Their warning to readers is practical: client behaviour can result in a temporary ban even when the person holding the phone is simply reading.
The ban is described as happening last week. The account and replies were posted in today’s reading window; they do not establish a performance ranking for every client version.
