Hi nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet , cc nostr:npub1qqqqqq2stely3ynsgm5mh2nj3v0nk5gjyl3zqrzh34hxhvx806usxmln03
I...
Hi nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet , cc nostr:npub1qqqqqq2stely3ynsgm5mh2nj3v0nk5gjyl3zqrzh34hxhvx806usxmln03
I wonder, can you add an option (new feature) to enable this kind of behavior for the Pool stream_events API?
Detail:
- With the current behavior, stream_events API connects to all relays, then waits for the result of each relay, then collects and processes (de-dups, forwards, etc.)
- This behavior leads to very poor Gossip performance, users usually wait too long for the results because of the multi step stream_events calls
- When a user calls stream_events with a Filter X, the SDK breaks down the filter, then fetches the NIP-65 relay list (with stream_events), then connects to those relays, then fetches events by Filter X again. The problem is the SDK waits for all relays to complete, as described here: https://github.com/rust-nostr/nostr/blob/17470cb551e9e359d0a7cde7ef5e1564627c8f91/sdk/src/pool/mod.rs#L864
Proposal:
- stream_events will have an option to return early when the first result is received, without waiting for all relays
- When gossip is enabled, stream_events will always return early
- When returning early, other relays will automatically unsubscribe
