Cody on Nostr: I’m writing my own Nostr client. (Not entirely from scratch. There seem to be ...
I’m writing my own Nostr client. (Not entirely from scratch. There seem to be pretty nice libraries out there in TS and Rust!)
But I found 2 annoying characteristics of the relay protocol:
The “notice” message isn’t tied to any particular request or subscription. But some relays use it as a way to give error messages.
Ex: I found one relay would answer my search subscription with a notice “error: slow down”. Then it never resolves the original request. (Despite IIRC the NIP saying that you should always close a subscription.)
So now I need to add special cases to handle that relay/message. And probably a timeout for subscriptions. Which you can’t do in the general case. But I guess if you don’t get an event or an EOSE within some time you can assume the subscription failed to start?
But how do I know when I’ve “slowed down” enough? Why wouldn’t the relay just throttle its responses to me if it wants me to go slower? 😣
OTOH I guess you have to do this kind of defensive programming for any protocol. But would be nice if there were a standard way to handle cases like this.
#nostrdev
But I found 2 annoying characteristics of the relay protocol:
The “notice” message isn’t tied to any particular request or subscription. But some relays use it as a way to give error messages.
Ex: I found one relay would answer my search subscription with a notice “error: slow down”. Then it never resolves the original request. (Despite IIRC the NIP saying that you should always close a subscription.)
So now I need to add special cases to handle that relay/message. And probably a timeout for subscriptions. Which you can’t do in the general case. But I guess if you don’t get an event or an EOSE within some time you can assume the subscription failed to start?
But how do I know when I’ve “slowed down” enough? Why wouldn’t the relay just throttle its responses to me if it wants me to go slower? 😣
OTOH I guess you have to do this kind of defensive programming for any protocol. But would be nice if there were a standard way to handle cases like this.
#nostrdev