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

Reply to this note

Please Login to reply.

Discussion

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

Oh, yes, the range is based on the created_at timestamps.

this is why i think a query type that only returns the event IDs would be useful as a building block for more sophisticated sync protocols, especially if it was using more compact binary data, or at least base64