I see a cons of current gossip method is the client is trying connect inbox/outbox relays before query event

// Add outbox relays
for url in broken_down.outbox_urls.into_iter() {
    if self.add_outbox_relay(&url).await? {
        self.connect_relay(url).await?;
    }
}

// Add inbox relays
for url in broken_down.inbox_urls.into_iter() {
    if self.add_inbox_relay(&url).await? {
        self.connect_relay(url).await?;
    }
}

If relay have some errors, client will try reconnect, the fetch events will become very slow. I wonder if when this issue is resolved (gossip storage and relays rank/score implemented). Will this problem be solved too?

If relay have some errors, client will try reconnect, the fetch events will become very slow.

Yes, this is true but after few attempts the SDK will start skipping unresponsive relays (this in general, not only for gossip). This require some secs so if the relay was just added it will not be skipped.

I wonder if when this issue is resolved (gossip storage and relays rank/score implemented). Will this problem be solved too?

Yeah, partially. I still have to study the best way to implement it. Using a relay score I can ignore the unresponsive relays but for new ones the issue could still persist (if the relays are new, never saw before).

I wonder is there a way to clear the gossip graph?, I want after user update their NIP65 or NIP17 relays, the gossip graph will be refresh to use their latest relay list or mark their public key outdated, then gossip graph will use latest info.

I think will be nice if we have a command to force refresh gossip graph for certain public key like this

client.gossip_invalidate(public_key)

I wonder is there a way to clear the gossip graph?, I want after user update their NIP65 or NIP17 relays, the gossip graph will be refresh to use their latest relay list or mark their public key outdated, then gossip graph will use latest info.

I think will be nice if we have a command to force refresh gossip graph for certain public key like this

client.gossip_invalidate(public_key)

What if the gossip data were updated automatically when sending or receiving a NIP17/NIP65 relay list event?
So, would be enough to send a REQ asking for the relay list of the public keys to update the gossip data (i.e., an auto-closing or long-lived subscription).

I fear it will take too much concurrent subscriptions, some relays have limit max subscriptions per users.

Or we can do same approach like automatic_authentication, when receive NIP17 or NIP65 events from pool, gossip graph for event's author will be updated.

I fear it will take too much concurrent subscriptions, some relays have limit max subscriptions per users.

If you "invalidate" the public key, a REQ will still be sent to relays, to update the relay lists.

I think it will be fine if it is auto-closing

I think it will be fine if it is auto-closing

Yeah, currently is auto-closing.

Or we can do same approach like automatic_authentication, when receive NIP17 or NIP65 events from pool, gossip graph for event's author will be updated.

Yes, I was thinking to this. If gossip is enabled and an event with kind 10002 or 10050 is received, the gossip data is updated.