Interesting ✍️

Reply to this note

Please Login to reply.

Discussion

yeah, ordering of the processes in the protocol is critical

you have to first send

OK,false,auth-required for reqs

and for event publish it's

CLOSED,auth-required

and then after that you send AUTH with the challenge

then you drop the message processing, and the client must repeat the action after authing, otherwise they get another round of the same

i saw blastr type servers were pushing events to my relay over and over again so i added a feature where if they try to publish three events in a row and don't auth any attempts to send events for 10 minutes is ignored. then if they continue after the ban period, it goes to 20 minutes, and so on, so after 11 times they are banned for a whole day

i think the reason why clients are so shit at it is because they don't have any understanding of queue processing and retries, or very little, and it's just too much for their little aNoNyMoUs braindamaged pea brains to understand they need to auth and then send the event again (or request).

i actually at one point was adding a "pending event" for a socket previously, so that the moment they auth the event was processed but that's not how the protocol works, and probably should be how it works, for the sake of the gumbies in client dev.

this is a hard problem to solve correctly, i think applesauce gives you the best primitives to get it right https://hzrd149.github.io/applesauce/relays/relays.html#authentication

it definitely works, as does whatever #jumble uses, and the #coracle library also works. probably NDK doesn't work consistently, or at least it didn't used to.

it was really hard implementing auth on a relay because of how poorly clients implement it

yep NDK doesn't handle this well. it has a lot of other problems too.