Hi @Yuki Kishimoto , cc @Awiteb 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:

GitHub

nostr/sdk/src/pool/mod.rs at 17470cb551e9e359d0a7cde7ef5e1564627c8f91 · nostrdevkit/nostr

Rust implementation of the nostr protocol, high-level client library, Nostr Wallet Connect and more. - nostrdevkit/nostr

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