otherwise, you should also ignore filters that are not specific (just since/until) for counting last access
blocking them imo is a bad idea, but if they misbehave that makes sense
otherwise, you should also ignore filters that are not specific (just since/until) for counting last access
blocking them imo is a bad idea, but if they misbehave that makes sense
yeah, i think i'll just add an access counter and then the sort order will be by last accessed AND least accessed, and this will remove the LRU bias, the GC will sort the oldest ones first and then sort those by the least accessed
stuff that might be better to keep will also tend to have higher access counts so it can be shuffled upwards away from the low water mark
this is for later work, anyhow, but as we have discussed the idea of making relays into caches for a bigger event store would require capping the storage use of the caches, evicting the least valuable data in the cache
relay operators could then run independent cache relays as part of their service offering and subscribe to the big store and save on managing their relay's syncing with the broader network (their relays would push to the store when they store and pull when they process requests, refreshing entries that may have found their way down to the end of the list)