nostr.land is as far as I've seen the only relay that resumes subs if sent before auth. the auth dance with most relays is just tiresome. this is how all relays should behave. you send the req, it asks for auth, you auth, the req resumes. <3
bravo nostr:npub12262qa4uhw7u8gdwlgmntqtv7aye8vdcmvszkqwgs0zchel6mz7s6cgrkj
Replies (5)
I'm a bit thick in the head about the whole NIP-42 AUTH flow… and Haven only uses it for the private relay that most clients won't touch anyway. But I think Khatru should behave this way too, since AUTH is just something called as art of the rejection filters. If Haven or Khatru isn't behaving properly, could you please open a more detailed issue? Assuming khatru.GetAuthed(ctx) behaves correctly, then a gazillion Khatru-based relays out there will behave properly as well.
(cc nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp; also, please check your DMs)
i had added a similar feature that would retain a filter and resume it after auth was confirmed.
most clients retry requests and event publishes after getting an auth demand.
so i have left out that part but the code is still there to enable it.
it's just that if the client doesn't expect this, your relay ends up doubling up subscriptions.
i understand why semisol did this, and i tried it as well, but it's not in the spec. it's a reasonable expectation based on protocol theory but it's not in the spec.
did i mention, that it's not in the spec?
so, idk, semisol can keep doing this and i can enable it in my relay implementation with a few uncomments or something equally easy. but i don't think it is a good idea. the expectation of repeating a request or submission of event should be on the client.
the end.
Then the relay should send the auth from the get go and not wait for a sub at the very least. retaining and resuming should be the new norm that all clients expect IMO, they don't because it wasn't a thing
oh yeah, the feature was actually retaining events. i got piqued to do it after i was struggling with getting clients to actually auth correctly with #orly (formerly #realy) and i still have the code in teh codebase, and i probably could easily add to the listener to queue up filters in this way
i'm not sure yet if it's actually a good idea, but it makes sense, superficially.
There’s also the fact you can send AUTH in query parameters
