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
Discussion
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.