Fix relay sub/unsub before connection is established #73
Conversation
…ses independent, let sub/unsub happen before connection was estabilished
|
This implementation also doesn't send REQ if the subscription was cancelled before connection was established |
|
I added a bug fix for unsubscribing (the code was still trying to send a CLOSE request in connecting state) |
| @@ -12,7 +12,7 @@ export type Relay = { | |||
| close: () => Promise<void> | |||
| sub: (filters: Filter[], opts?: SubscriptionOptions) => Sub | |||
| publish: (event: Event) => Pub | |||
| on: (type: RelayEvent, cb: any) => void | |||
| on: (type: RelayEvent, cb: (event: Event)=>void) => void | |||
There was a problem hiding this comment.
This is not correct because it doesn't apply when the event received is a connect, disconnect or notice.
|
Instead of just guarding these things under |
Sure, we can do that, though I'm planning to do a RelayPool and smarter Relay (with auto reconnection, looking at timeouts) where the reconnecting and error handling is done by the Relay itself. I though it would be better to put it into nostr-tools as I see that there are many RelayPool implementations already. I wanted to ask you if there's a better way to reach you (4 days is a bit too long for answer on your plans for nostr-tools). Is there another official way? (I wrote DM on nostr as well). I wrote a caching storage layer using IndexDB, that is independent of frameworks (only depends on nostr-tools and dexie.js, but I'm not against dropping dexie.js / adding other db backends). It's closed source because it's not ready yet, but it will be open source. I also wrote a Svelte client on top of the caching storage layer, but I make sure that it can be used by other clients as well that have access to JavaScript. |
|
You can talk to me on the https://t.me/nostr_protocol channel (I am not using Nostr DMs these days) but please don't demand attention or quick responses. I feel like you didn't understand my request above. This is not related to relay pool. There is even no relay pool implementations here anymore (I've removed the one that existed). Publish your libraries and clients and talk about them on Telegram and Nostr and Twitter and see if people use them. |
|
Sounds great, I added that Telegram channel (maybe it should be on the home page as an alternative contact). I understood the request, I just wrote about the RelayPool because I believe that handling connect / disconnect / reconnection logic should be done by the Relay class when we're building abstractions over it. The current Relay implementation is a leaky abstraction that is a great code example, but using it didn't make my code shorter when I added connection handling logic to it that was independent of subscription logic. It's OK to have different opinions about it, I accept yours, thanks for your answer. |
|
I created and published a separate relay pool library on top of nostr-tools, as you don't want it to be part of nostr-tools. https://github.com/adamritter/nostr-relaypool-ts It would be great to link to it from this repo, as they work well together (having a link to every project that uses nostr-tools would be great actually) |
No description provided.