Amber caches our data, but maybe we should be caching kind0 profiles as well? Does Amethyst always refetch upon starting? Makes sense for kind1's but profiles change way less frequently
Login to reply
Replies (5)
Kind 0 should be cached for easy and fast lookup. I'm starting to think I want nostrdb for Amethyst. The only complaint I have for nostrdb for #Notedeck is that so many profiles are old and show old names or old profiles. It's not refreshing and checking for changes.
That's one of the main problems why I didn't focused on a DB yet. We need to figure out how to delete things from the DB and rotate information very quickly. Otherwise, a simple amethyst session will get to 10 GBs of disk usage quite fast..
Just throwing something out there, maybe there are multiple valid ways to cache events. I think kind 1's have a lower priority to be cached, as they have a pretty short half life
but kind 0 and other events could have different options like refreshing on a timed schedule, or even request at viewing. Like you keep the same kind0 until you want to view the user's profile, so you'll fetch again for the profile view.
Yeah, that is definitely true. I am currently reorganizing our cache for the 100,000 WoT score events the app needs to download to make each lifecycle kind-based if root and attached to other events if not a root kind, like comments, reactions, etc. so, when the cache removes the root event, all the others get deleted, including the WOT events in memory. Then it's all about getting the same thing in disk
Also, I need to find a way to do string interning in disk. Because copying 64-byte IDs and pubkeys everywhere is not a good idea.