I totally agree with your perspective and the current state of affair regarding ux in the blockchain / web3 space is what in part motivated us to create Cedalio

I totally agree with your perspective and the current state of affair regarding ux in the blockchain / web3 space is what in part motivated us to create Cedalio. The mechanisim that we've built so far is to let the database owner be the one securing the private key because is the basic feature that needs to exist to built everything on top of and because we were first targeting developers in the web3 space, who value having this option. For use cases where the end-user is not technical or security-savy enough (99% of users probably) we are providing other options. We support authentication via Privy.io that enables users to create an account with username / password or connect their other login accounts (Google, GitHub, etc) and never have to worry about managing keys. For more info check https://docs.privy.io/guide/frontend/embedded/overview https://docs.privy.io/guide/frontend/embedded/overview. That being said we want to offer more auth providers and make life easier for users that don't want to manage their own private keys, we haven't launch access to mainnet yet. For example providing MPC wallet for end-users as well. There are other mechanisim for account recovery as well, like social recovery that could be implemented. As for your main point regarding business continuity and data leakage, our current solution allows us to recover the database because we have several backup mechanisims in place. That being said, as you pointed out, if the operation log is stored on a publicly accessible decentralized storage network and if an attacker gains access to the decryption keys then yes data will be leaked. Similar to how any application developer could get their AWS API keys leaked and a database is copied (assuming the database is not encrypted at rest). The current alterantive to this attack vector (if data ownership / portability without having to interact with Cedalio is not required) is to choose other storage solutions for the operation log. This is on our roadmap. We are also exploring encryption using lit.protocol and making the decryption access programmable which would allow us to remove access to who can decrypt the operation log and the encryption keys would be stored by the protocol not by the end-user. Therefore is a user looses their keys, we can remove that wallet from the list of wallets that can decrypt the operation log.