mleku @mleku - 17h
fun fact about what has happened with my relay's database utilization after siccing it on around 11000 users follow lists is the database blew up from around 90mb to 400mb this will be because of follow lists of course, and #realy currently is not actually deleting these and any of the "directory event" kinds old versions... i may need to create a custom GC feature that works even if full GC is not enabled to prune off the oldest versions after the most recent 10 or so, because this is a pretty awful waste of space lol it's the sort of big impact issue that might even warrant building a special handling of these events by creating an npub index and using monotonic serial numbers for each npub (and hashtag) to encode the necessary event ordering in a super compact form it's on my mind, anyway, has been for some time, but probably just pruning out excess old versions will fix me at this point i can probably even just shoehorn this feature into a special handling clause in the event save code that finds all of the copies and sorts them by timestamp and keeps the most recent 10 versions and deletes the old ones (and tombstones them)
mleku @mleku - 15h
#realy only needs to store like 11-110k of these events for a typical deployment that i have in mind (100-1000 users) but it sure as fuck is a lot of data storage required definitely penciling in firmly that in future the follow events are going to get special space-saving treatment even just changing them to storing the npubs as raw binary will halve the storage required
also, no, this bloating was from about 11000 users follow lists, resulting from the follows of ~100 follows, and in fact at this point only about half of those users events have been spidered out of the nostrwebs mmm i like that #nostrwebs
