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