Note to reviewer
The goal here is to simplify and standardize storage as prep for cross-platform / app integration. So, we isolate and store wallet info that does not change in a smaller JSON wallet object. This is intended for secure storage. The android adapter puts this there.
We keep everything else out of this. It's in sqlite in android, still indexedDb for web.
The plan is, going forward, "everything else" will be migrated to a standardized sqlite, optimized for loading speed and performance.
The diff is regrettably enormous. However, changing the storage is not possible to do in an isolated and contained way. Typescript and extensive integration tests confirm expected behavior. I have also tested the migration on the extension and web. Android does not migrate, need to wipe and then test.
Focus on wallets/useWallet.ts and wallets/index.ts which is where the main changes are. Everything else is cascading from this, i.e. we no longer deal with the paths map to get addresses, we now have sk and pk and address just available in the wallet.
Longer Notes
Storage refactor before the android app launches.
The current spaghetti implementation of "keep the private keys in secure storage" for android is too insane (we take a wallet object, pull out the private keys, throw everything else into sqlite, then recombine them every time we access them).
It needs to be simpler so that we can easily extend and add cache features for performance.
Refactor wallets to store only bare-minimum wallet data. Stuff that will never be a problem in ambiguously limited storage environments like android's Preferences. In this way, the secure storage stuff is always sequested, and we only write to it when we
- create a wallet
- delete a wallet
- rename a wallet
The sqlite storage can be more easily used for more frequent write write operations, like caching utxos, token data, or tx history.
For now, this means we are not storing wallet state at all. We always get it on wallet activation. With chronik, that is not really a problem. It takes <1s and we are already locking the UI until utxos sync anyway. I don't notice a performance impact in this diff.
Going forward, when we have ecash-wallet and auto-updating utxo sets, we will again cache utxos. But utxos should not be in encrypted storage. Will be more thoughtful about how we cache and use sqlite when we get there.
We will end up totally losing the wallet state and replacing it with ecash-wallet and some cache optimizations in sqlite. For now, we just lose storing the wallet state, but preserve the same interface in Cashtab state.