yeah, simple... just have to make the assumption thet L1 has the index and stub of all events it might find in the L2... probably have to think later about how to deal with one-hit wonders causing lag in client requests but it is a one thing... if a pruned event is fetched, then the user has to wait a little longer for the L2 to retrieve it
on the other hand, this also means that i could make an IPFS or Blossom event store cluster store for events as well, since i'm now only searching the L2 for specific events due to this
gonna need to think on it some more...
it could spawn a background query to the L2 for the same filter anyhow, and then add the events to the local store so next query will hit them, even if the indexes fell out of the headroom space the GC allows for pruned events
i think that is better... still not perfect but L2 queries are going to always cost an extra delay time anyway, and possibly the user will refresh and by that time the event will be freshly replaced in the L1
mleku / mleku ✝Ⓐ☯︎
npub1fj…mleku
2024-11-17 05:32:17
in reply to nevent1q…ce3c
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-11-17 05:32:17Event JSON
{
"id": "4f262d321f540a718fc2c88885f10a219856c6814391d5b4cb151c6e46c1a391",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1731821537,
"kind": 1,
"tags": [
[
"e",
"eef0f83ce1705c4b03b45935f0b69cf08ee9d348a25a2c761ce275d348b3a7cb",
"wss://nostr.land/",
"root"
],
[
"e",
"eef0f83ce1705c4b03b45935f0b69cf08ee9d348a25a2c761ce275d348b3a7cb",
"wss://nostr.land/",
"reply"
],
[
"client",
"noStrudel",
"31990:266815e0c9210dfa324c6cba3573b14bee49da4209a9456f9484e5106cd408a5:1686066542546"
]
],
"content": "yeah, simple... just have to make the assumption thet L1 has the index and stub of all events it might find in the L2... probably have to think later about how to deal with one-hit wonders causing lag in client requests but it is a one thing... if a pruned event is fetched, then the user has to wait a little longer for the L2 to retrieve it\n\non the other hand, this also means that i could make an IPFS or Blossom event store cluster store for events as well, since i'm now only searching the L2 for specific events due to this\n\ngonna need to think on it some more...\n\nit could spawn a background query to the L2 for the same filter anyhow, and then add the events to the local store so next query will hit them, even if the indexes fell out of the headroom space the GC allows for pruned events\n\ni think that is better... still not perfect but L2 queries are going to always cost an extra delay time anyway, and possibly the user will refresh and by that time the event will be freshly replaced in the L1",
"sig": "6bae904623499490a6b000a90d4018c1396d9e283f5f2e1d46bba0745a8727fad1af114c3ae2056b712ffec6265efd64960696756a316ca1f8824ef347b0a124"
}