search

nostr-protocol / nips

Nostr Implementation Possibilities
2.4k stars 583 forks source link

nip-01: clarify response to close message. #1490

Closed kehiy closed 2 months ago

kehiy commented 2 months ago

we have to clarify how a relay can acknowledge a close request from a client. here is a draft pr on immortal which implements that. more implementation may do that which im not aware of.

staab commented 2 months ago

I don't think we need this. What does this solve? If the relay fails to close the subscription, it will keep sending events, or waste resources on its side. Neither of these really affect the client's ability to stop listening to the request.

kehiy commented 2 months ago

@staab in most of protocols (state-full) you can see we need to acknowledge about changing the state that nodes have about each other.

staab commented 2 months ago

That's not really an argument. Is there a use case this supports, or is it just busy work?

fiatjaf commented 2 months ago

This just adds unnecessary bloat.

kehiy commented 2 months ago

how a client can find out if the closing process was successful? relay changes an state related to client which affects their communication, but client can be aware of that how was it? successful or failed?

staab commented 2 months ago

how a client can find out if the closing process was successful?

Why would a client care?

kehiy commented 2 months ago

@staab to make sure a relay won't misbehave, otherwise close the connection with them in the WebSocket layer.

AsaiToshiya commented 2 months ago

I agree with @staab. I thought some relays send ["CLOSED", "sub1"], but it was just my imagination.

staab commented 2 months ago

@kehiy doing so would break all current implementations. Also, CLOSED is no guarantee that the relay isn't still misbehaving. If clients want to do that they have to analyze the behavior of the relay, not just blindly trust what it says.

kehiy commented 2 months ago

@staab @AsaiToshiya ok, makes sense.