Hi nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e...

reya

npub1zfss807aer0j26mwp2la0ume0jqde3823rmu97ra6sgyyg956e0s6xw445

hex

c98b072db3c27e862704710e73db11b01f8c8ea309ab4d4dae49ce030f92fd3b

nevent

nevent1qqsvnzc89keuyl5xyuz8zrnnmvgmq8uv363sn26dfkhynnsrp7f06wcprpmhxue69uhhyetvv9ujuem4d36kwatvw5hx6mm9qgspycgrhlwu3he9ddhq407h7duheqxucn4g3a7zlp7agyzzyz6dvhc0kh760

Kind-1 (TextNote)

2026-05-20T01:34:16Z

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

原始 JSON

{
  "kind": 1,
  "id": "c98b072db3c27e862704710e73db11b01f8c8ea309ab4d4dae49ce030f92fd3b",
  "pubkey": "126103bfddc8df256b6e0abfd7f3797c80dcc4ea88f7c2f87dd4104220b4d65f",
  "created_at": 1779240856,
  "tags": [
    [
      "t",
      "l864"
    ],
    [
      "p",
      "68d81165918100b7da43fc28f7d1fc12554466e1115886b9e7bb326f65ec4272"
    ],
    [
      "p",
      "00000001505e7e48927046e9bbaa728b1f3b511227e2200c578d6e6bb0c77eb9"
    ]
  ],
  "content": "Hi nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet , cc nostr:npub1qqqqqq2stely3ynsgm5mh2nj3v0nk5gjyl3zqrzh34hxhvx806usxmln03 \nI wonder, can you add an option (new feature) to enable this kind of behavior for the Pool stream_events API?\n\nDetail:\n\n- 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.)\n\n- This behavior leads to very poor Gossip performance, users usually wait too long for the results because of the multi step stream_events calls\n\n- 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\n\nProposal:\n- stream_events will have an option to return early when the first result is received, without waiting for all relays\n- When gossip is enabled, stream_events will always return early\n- When returning early, other relays will automatically unsubscribe",
  "sig": "25e9080d6786e08f1537bbeb34ec291fffee3a5a9069afedc18cee6113b707f5e6885171b04fa423ce9eec4053913e457a4418250580cea0eded3a613d96bbaa"
}