https://github.com/nostr-protocol/nips/pull/1494/commits/8790dabc29a046ca1515154763525cf4a3964eba this?
i don't see anything about a query that returns only a list of event IDs in that
https://github.com/nostr-protocol/nips/pull/1494/commits/8790dabc29a046ca1515154763525cf4a3964eba this?
i don't see anything about a query that returns only a list of event IDs in that
That's exactly what Negentropy syncing (nip77) does. You send a filter just like in nip01 and get back the list of id's you don't have that mat h this filter. It's using a special binary protocol to make this size optimized
how does it know what you have tho?
1. In the beginning the server sends you a list of fingerprints of id ranges.
2. You check if your local fingerprints for the same ranges match.
3. When they match, you say that part matches; when they don't match, you look inside the range to see what you have.
4. If you have few ids or none for that range, you send the ids you have -- then the server will send back the ids it has; if you have way too many ids inside that range, you split the range into multiple ranges and send a fingerprint of each.
5. Repeat the process for all ranges until have narrowed them enough for you to get a list of the ids you don't have from the server -- as well as the ids you have that the server doesn't.
Something like that, I may have gotten details wrong.
that sounds right but this range thing is a very fuzzy concept in 2^256 finite field