continued partial outages. i found the culprits again and have redirected traffic around the bottleneck relays (hint, it has to do with my opensource auth proxy and pokey, i need to harden this more somehow) unfortunately the client side fixes dont seem to be working,, or old versions, maybe its tor i duno.
Discussion
please check out https://realy.lol auth library
i NEVER have problems with auth on realy, i think out of all the paid relays i use, wine, land, and yours, that mine NEVER fails to auth on either coracle or nostrudel, ever. ever ever.
i mean, ok, idk how to assess what is going on with your auth thing but maybe poking around at realy you might figure out why your auth sprocket is broken
i didn't think that maybe there was some bigger issue at play but maybe
https://github.com/mleku/realy/blob/dev/auth/nip42.go
will help
thx man, i will. im just tryin to get it to survive for a bit and will instrument it more soon. there are some agressive clients out there and weekends are when they all come out to play 😅
yeah, clients can be super stupid
the main thing is to look at where the code is actually doing things... this auth code is basically forked from the fiatjaf/mattn relayer, and i didn't change any of those auth parts, so track all the places where the auth verification function is used and you'll see when it should be
https://github.com/mleku/realy/blob/dev/realy/handlers.go#L138 this is where auth is required for an EVENT
https://github.com/mleku/realy/blob/dev/realy/handlers.go#L391 for COUNT
here i do special handling to permit filters that match on "directory" kinds https://github.com/mleku/realy/blob/dev/realy/handlers.go#L138
that is a special feature i have made that strips filters of all but a list of kinds (user metadata, follow, mute, relay lists, and some others i forget) https://github.com/mleku/realy/blob/dev/realy/handlers.go#L138
it processes the filter that has been stripped of non-directory kinds and then after sending back the result it sends an auth request... this is a kind of "helping the network" measure, to make a bridge between private relays, since clients are almost always configured with several if not a dozen relays it allows people to find each other even if they literally only use this one relay - if more clients implement outbox properly, now that realy automatically allows all permitted users who are able to access the relay to allow their follows as well, and they can then post their replies to the relay, and prevent the lost poast problem
the auth works pretty well, i have one bug. my problem is i dont handle when a client just sits there sending the same req over and over (pre-auth). so i need to build in the rate limiting now.. does yours do rate limits like this? the pattern is, connects once, sends thousands of reqs (which all get sent a reply of auth required)
one extra bug i noticed besides this not having limits that is.. but its a rarer case, still..
yeah, implementing limits, that's a matter of creating some kind of timer, so the thread just backs off for like a second or whatever and then answers and if it's the same shit again backs off again further and etc
It fails a lot but it could be the spam
I have thought a lot about limiting sockets per ip address
ya, i've been finding/fixing lots of bugs.. im super annoyed w ubuntu rn (the host os) it doesnt have compatible journal with debian AND it uses snap 😭. seemed fine for a while, till it wasnt.
yeah, i'm not experienced with the pros and cons of this stuff because i only have like one or two things running
there is rate limit ability in there somewhere
you could make it just quit giving the same thing after a while maybe, why waste the bandwidth
ya, its all good, i can add a backoff for this case fairly ez. possibly some other things maybe ill do here while im in the code, like supporting dynamic limits/notice payments.
give me a hollar if my stuff is causing issues
its not lnbits this time.. i dont think, but thanks 😁
on further investigaton, this was not pokey at all, or the auth layer 👀👀👀
thanks to nostr:nprofile1qqsxg45ph8gx0vdrvtzta6xal7v86frx6jvstsnvhrlvtehmwwh4epqpzamhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6tcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz9nhwden5te0v4jx2m3wdehhxarj9ekxzmny9ua2vh28 for being so responsive it helps with all the debugging and client/relay symbiosis 🌊🐳🐳🐳