> > last stable version at https://lists.cpunks.org/pipermail/cypherpunks/2022-July/102291.html
next step might be to change flushing so the index can be accumulated > during writes or mini flushes, so as to be able to limit the total size of > an index per flush if needed, without issue. > maybe this means retaining a working index as class data, and changing the approach for updating it so that it doesn't really solely on expanding the last entry but rather updates the whole thing probably important to optimize away the approach of reiterating all leaves > every flush. would greatly limit write speed on older stores, and be much > harder to comprehend when it is old. > basically this could mean adding state and/or methods to internodes so things like their path and depth don't need to be fully recalculated >
