[bazizbaziz]

> When a value is retrieved via its key, IronDB... > Looks up that key in every store. > Counts each unique, returned value. > Determines the most commonly returned value as the 'correct' value. > Returns this most common correct value > Then IronDB self heals: if any store(s) returned a value different than the determined correct value, or no value at all, the correct value is rewritten to that store. In this way, consensus, reliability, and redundancy is maintained.

I'm not sure any of these properties are ensured the way anyone would want. Why do this? What are the failure modes this protects against? If only one of the backing stores is active when a result is written, and then the others later become active with no data, is blank data returned for the prior result? It seems like recording timestamps would fix this problem nicely on a single system and make this thing overall quite reliable.

[grun]

Cookies are frequently cleared by users, and the other datastores -- IndexedDB, LocalStorage, and SessionStorage -- can be unceremoniously purged by the browser under storage pressure.

See my other comment, here: https://news.ycombinator.com/item?id=18297177

I'll explicate this in the documentation. Thank you for your feedback, bazizbaziz.

[bazizbaziz]

Thanks for the response! FWIW I'm overall really interested in this, as I maintain an application that uses localStorage to keep very important data while the app is offline until it can be uploaded.

I recently tested localForage [0] to see if it could be more reliable and get around storage limitations of localStorage. Unfortunately, LocalForage has a very annoying problem where it picks a single storage backend to use, but the one it chooses can switch on page reloads (yes, even on the same device/browser.) and this switching causes data loss as keys stored in the other backends are unaccessible. I'm very interested to see if IronDB can help here! Thanks for working on this.

[0] https://github.com/localForage/localForage

[grun]

Wonderful.

Don't hesitate to let me know if there's anything else I can help with, bazizbaziz.

[franciscrick1]

What if users don't want you taking control of their computer?

[bildung]

> Why do this? What are the failure modes this protects against?

I have a use case for this: I've written what is basically a crud web app for a non-profit. That's an offline app (appcache) and right now uses localstorage for keeping data offline in the browser while in the field. That is pretty brittle as is, but dedicated application installations didn't fit the budget. The app is used in the field by volunteers all over the country. With volunteers fluctuating and many people being privacy conscious, it happens regularly that they change Firefox preferences to delete cookies etc. on shutdown, and now newer Firefoxes deprecating localstorage, potentially resulting in data loss.

Something like IronDB would actually help me.

[grun]

Awesome.

If you find any bugs, or have any ideas to improve IronDB, don't hesitate to let me know.