Vitor Pamplona on Nostr: Hey jb55 are you using all the negentropy options that are coded in strfry to sync ...
Hey
jb55 (npub1xts…kk5s) are you using all the negentropy options that are coded in strfry to sync with relays?
I wonder if we can simplify their Nostr Extension to help other relays **and clients** implement a range-based set reconciliation over whatever event data structure they already operate on.
For instance, imagine a new stateless relay operation where clients can request hashes of ID sets grouped by week (`created_at` on GMT). A client could easily sort the events it received from that relay, group them by week, hash their IDs as well, and then compare with the results from the relay to know which weeks it needs to download from the server again.
Something like this:
REQ:
```
[
"WEEKLY-HASHES",
<subscription ID string>,
<nostr filter>,
]
```
Response
```
[
"WEEKLY-HASH",
<subscription ID string>,
<week>,
<hash>
]
```
A simple interface like this would allow the app to check if the past is still fully synced without having to download everything again just to be sure.
It's not the most optimal way. But it might just be simple enough that any relay and client can implement it effectively.
Published at
2023-10-13 15:30:49Event JSON
{
"id": "7fc401d44949a588a5524764d347f66ff997d5f2f9cb227f4407b43f492db316",
"pubkey": "460c25e682fda7832b52d1f22d3d22b3176d972f60dcdc3212ed8c92ef85065c",
"created_at": 1697211049,
"kind": 1,
"tags": [
[
"p",
"32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245"
]
],
"content": "Hey nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s are you using all the negentropy options that are coded in strfry to sync with relays? \n\nI wonder if we can simplify their Nostr Extension to help other relays **and clients** implement a range-based set reconciliation over whatever event data structure they already operate on. \n\nFor instance, imagine a new stateless relay operation where clients can request hashes of ID sets grouped by week (`created_at` on GMT). A client could easily sort the events it received from that relay, group them by week, hash their IDs as well, and then compare with the results from the relay to know which weeks it needs to download from the server again. \n\nSomething like this: \n\nREQ: \n```\n[\n \"WEEKLY-HASHES\",\n \u003csubscription ID string\u003e,\n \u003cnostr filter\u003e,\n]\n```\n\nResponse\n```\n[\n \"WEEKLY-HASH\",\n \u003csubscription ID string\u003e,\n \u003cweek\u003e,\n \u003chash\u003e\n]\n```\n\nA simple interface like this would allow the app to check if the past is still fully synced without having to download everything again just to be sure. \n\nIt's not the most optimal way. But it might just be simple enough that any relay and client can implement it effectively.",
"sig": "49882d521b23481ba08fb451d745dd7dc9f2624dc9472f3b19a1a987b93a720214b286ed28b563accebd280e8fe7e20d2581003df8b6a533b8b3d3c39b05ba46"
}