re.: downloading the same events from multiple relays, this is pretty much the same issue as the one I was describing.
In NIP-01 there is specified a REQ message that contains a JSON object. This object specifies #e, #p, since and until. since and until are great, because since means the opposite of until. But there is no opposite of #e and #p. What is needed are properties that mean:
not-#e: do not give me any of the listed event ids
not-#p: do not give me any events that contain the listed pubkeys
Then the client notes, for each relay it connects to, when it last issued a REQ message, call that t. Any subsequent REQ it sends to that relay will have since:t .
Next, the client will go through its list of relays one at a time, not all at the same time. In order to prevent a situation where any one relay could perform a denial of service on the client, the client can specify a minimum time for relays to respond in and remove relays from the list or put them at the end if they respond too slowly.
The first REQ will have an empty not-#e list. Then for subsequent REQs on later relays in the list, all the event ids retrieved from previous REQs are added to the not-#e list. This ensures that duplicate events are not retrieved from different relays.
In addition we can specify a not-#p on all the REQs containing the pubkeys that the user has specified they are not interested in (blocked, etc). This does the optimization I talked about before.
Once the client has performed this batch of REQs it updates the times t for each relay, so future REQ batches will contain the new since value.
This should ensure that, for requested events:
1. the client only gets newer events
2. the client does not get duplicate events
3. the client does not get events they know they won't be interested in and have to discard
I don't know if new properties can be added to the object and be compliant with the specification NIP-01. If not then a new message type would have to be added that replaces REQ, e.g. "REQ2", in a new NIP, to add the new filter properties.
Next we have the problem of asynchronous events (events issued by the relay after the EOSE message).
During REQ processing, it might be necessary to inform a relay that no new asynchronous events should be sent until the client specifically requests that it is ready for asynchronous events. Otherwise we might still get a duplicate event while the client is processing results from other relays later in the list.
Then we have to specify a new message type sent from the client to the relay, let's call this SEEN. When the client receives an asynchronous event from any relay it is connected to, it immediately sends a SEEN message to all the other relays it is connected to with the event id. That way the other relays know not to send asynchronous events with that id. There may still be a small amount of duplication due to time windows in processing, but it should reduce duplication by a large amount.
What do you think?
