target a subset of pool relays for subscriptions and report on which relays have events

[DanConwayDev]

Describe the enhancement

1. target subscriptions to a subset of relays in a pool
2. record which relays returned events and provide method to query this

Use case

1. Use of the orthodox / gossip model
2. Increase privacy by reducing the queries sent to each relay
3. Refining relays being sent queries based on likelihood they will have a given message

Additional context
I'm very much interested in your thoughts on this generally and how you would approach it. I'm also happy to contribute towards a PR.

[yukibtc]

Hi, currently it's possible to subscribe only to specific relays:

let relay = client.relay("wss://relay.example.com").await?;
relay.subscribe(filters, wait).await?; // This use the default internal ID (the pool use a different internal ID)
// OR
relay.subscribe_with_internal_id(InternalSubscriptionId::Custom("my_custom_id".to_string()), filters, wait).await?;

But yes, I can try to add a method to do this automatically, specifying a list of relays.

---

record which relays returned events and provide method to query this

Regarding this, I suppose that it's needed a DB. I tried to implement it times ago but it's difficult to generalize it. I'm thinking a way to implement again a DB to store all the received events and allow the user to query from it without messing up the code. Probably using nostrdb.
Anyway, it's currently possible to know what relay sent an event by listening for notifications (but you have to record the events by yourself for now):

client
    .handle_notifications(|notification| async {
        if let RelayPoolNotification::Message(url, message) = notification {
            // handle message
        }
        Ok(false) // Set to true to exit from the loop
})
.await?;

[DanConwayDev]

But yes, I can try to add a method to do this automatically, specifying a list of relays.

Thanks! That sounds ideal.

I suppose that it's needed a DB.

Perhaps my use of the word query is misleading. I can see a need for a full event cache stored in a database but this requirement is way more simplistic. What about adding a events_on_relays: Arc<Mutex<Vec<(& EventId, Vec<&Url>)>>>, property to RelayPoolTask, coupled with a recently_seen_on_relays(&EventId) -> Vec<Url>?

[yukibtc]

Ah, yeah, I already store in RAM the seen event ids in the RelayPoolTask (Arc<Mutex<VecDeque<EventId>>>). I can try to upgrade that field and store also urls.
To avoid to increase too much the RAM storing also the relays URLs for every ID, probably it's better to add something like RelayId that will be a unique (incremental) usize for every relay.
The RelayId can be used then to get the relay URL.

What do you think?

[DanConwayDev]

Yes that sounds good, or potentially for cleaner lifetime management use a reference to a Url.

[yukibtc]

Hey, it's not possible to send, get or request events (or messages) to/from specific relays.

Get events from specific relays:

client.get_events_from(["wss://relay1.com", "wss://other.relay"], ...).await?;

Send event to specific relays:

client.send_event_to(["wss://relay1.com", "wss://other.relay"], ...).await?;

To know where an event was seen:

let database = client.database();
let urls = database.event_seen_on_relays(event_id).await?;

[yukibtc]

The database.event_seen_on_relays method is already available in v0.27. The other changes are available in master branch and will be included in v0.28