Oddbean new post about | logout
 Here is the problem with relays. You can DoS a basic relay implementation (if it has no rate-limiting) from a single laptop like this:

cat /dev/urandom | websocat wss://somerelay.xyz

Here is the problem with Outbox Model. A user can make another user's client connect to any relay, and that relay can do the exact same thing just in the other direction, because websockets are bidirectional. Therefore a single relay can DoS a client.

Therefore rate-limiting of websocket messages are needed on both the relay AND the client.

I'm not saying we shouldn't do it, or that outbox isn't the answer to all our problems. It is. But it creates a new set of fun problems that programmers will have to think about and mitigate. 
 Can we apply WoT to relays? 
 Yes actually, that's an interesting idea. Although the tradeoff is that you further emphasize a few central relays, which is the very thing outbox model aims to fix. You will want rate liming either way on both relay and client. 
 Seems a good idea to apply scores on relays 
 how about you don't follow people who will DoS your client  
 Very interesting. Yes, I think rate limiting on both sides is necessary.

This is an excellent fuzzing method.

I tried running chorus and hitting it with this attack from a local process.  For about 100,000 bytes (in 0.031 seconds) chorus handles and prints all the errors, generally being JSON parse errors.  Then a bug is hit and I get a thread panic (chorus main thread continues, only that one connection is dropped)

Also chorus has mechanisms to drop connections and block IPs based on too many errors coming in, but for some reason these didn't work against this.

This is Sunday I wasn't going to do dev work today, but this is too interesting. 
 Hah, fixed both of those already. Easy fixes.

Gossip will need more work though.