this doesn't happen with #realy auth implementation, i'd be almost certain there's something wrong with your implementation as well
my relay needed changes to enable full public read with selective auth required, it edits the filters to remove the stuff that is not allowed without auth and then returns the result and then sends a CLOSED auth-required and this works on coracle and nostrudel as well as jumble... jumble was fine with how realy was doing it but the others were not because they were getting stuck because they have queries that mix DMs with allowed event kinds and the socket was waiting for them
so i just filter it out, then tell the client to auth after giving back what results it can, and it doesn't stall the whole socket, just blocks reading
what happens often also is once a client auths to publish an event that socket is unlocked and doesn't go through this pathway
this is why i have been saying for a while now, a few months maybe, that the design of nostr using sockets for everything makes it a lot harder to reason about, and the auth spec does not make it clear that authorization is a PER SOCKET thing, that is, it is a state, the socket is not authed, or it is, there is no "authed for some request" semantics and that confuses a lot of people, and the spec is not clear about it
auth is the bread and butter of the internet... without it there is not accounts or the ability to monetize anything, seems like y'all are starting to finally grasp this, but you still don't seem to be quite there
IMO, we could just deprecate nip-42 and just put the nip-98 auth
but then we also have the problem of how do we tell the client for what reason they need to auth? that`s what part of nip-11 is about, an api capabilities/requirements, and auth is one of the main infos that is needed for this, but the way they are expressed in the nip-11 doc is not clear, it's a mess, and partly that is because there isn't a formal notion of API method in nostr, which is part of the reason why there is so many interop problems around auth
just go look at openapi documentation section on authentication, it's extensive, and that's because you basically can't run a service on the internet unless you charge people and you can't have the payers get special treatment without having auth to identify them
Thread collapsed
I think you may have misunderstood. The issue we encountered was caused by a bug in the sdk
yes, incorrect handling of auth by the client library
there is several libraries i'm familiar with now, applesauce from the dev of #nostrudel, the #coracle libraries (also used in #flotilla and #welshman) there is #NDK which is the one Pablo and idk who else is working on, used on highlighter and olas, and there is also fiatjaf's nostr-tools which is being used by njump, and probably others i am not familiar with
fortunately most of them now are taking getting auth right seriously, so i'm pleased to hear you found and will soon squash another bug
The more people use it, the fewer bugs there will be 🫡
[x] if they report the bugs and the developer is responsive
your focus on squashing bugs before adding features is The Way :trademark:
Thread collapsed
Thread collapsed
Thread collapsed
Thread collapsed
