Encrypted iCloud/GDrive Backup using Photon SDK

[tanx]

Is your feature request related to a problem? Please describe.

Thank you for your amazing work to make ecash easy to use. If I may make a feature request to make backup easier. Perhaps an encrypted iCloud/GDrive backup might be an alternative to the seed back proposed in #140. I've worked on Photon SDK during my Spiral grant and it has a react-native library to enable a seedless backup UX. The user just needs to remember a four digit PIN (which you're already using to unlock the wallet). Documentation and a preview video of the UX can be found here:
https://docs.photonsdk.org/

Describe the solution you'd like

The is a react-native library and client code example can be found here:
https://github.com/photon-sdk/photon-lib#key-backup

The user just enters a four digit PIN upon wallet setup and their private key material (and any JSON formatted meta data) is encrypted on their device and the backup is uploaded to their iCloud/GDrive account (which is already setup on their respective OS). So no need to create a new account. When the user wants to restore their ecash on a new device, they just enter the four digit PIN.

The 256 bit encryption key is stored on photon-keyserver (which the eNuts can run its own version of):
https://github.com/photon-sdk/photon-keyserver

There is also a development keyserver to play around with here:
https://docs.photonsdk.org/key-server-api

I'm not familiar of how stateful a Cashu wallet is. But if it is stateful, another option could be to use would be the Lightning Channel State backup api:
https://github.com/photon-sdk/photon-lib#lightning-channel-state-backup

Curious to hear your thoughts. Thanks :)

[KKA11010]

Thank you for your feature request and for your kind words about the app.

While your proposal is theoretically feasible, it does raise a few concerns:

• The backup would need to be updated after each transaction, which would require a network request. These requests can potentially fail, and updating the backup at certain intervals might result in outdated backups.
• Some users, myself included, prefer not to rely on additional third-party services.
• Users are already placing their trust in the mint provider, which offers its own backup solution and it's generally more efficient and less confusing to stick with one solution rather than implementing multiple approaches.

The seed backup option currently seems to be the most effective. It allows the app to handle everything locally, only requiring the mint for fund restoration.

As for the Lightning channel backup, it's not a viable option in this case. The wallet only manages a token database and doesn't interact with Lightning channel states. All Lightning-related operations are managed by the mints.

I appreciate your suggestions and the resources you've shared. I'm always open to new ideas that can improve the UX.

[tanx]

Got it. Thanks for your detailed feedback. It makes sense to use the mint as much as possible to persist state and rely only on a seed for client side encryption.

I‘m aware all lightning state is handled by the mint. But safe ecash backup seems to have similar in-order requirements as channel state backup. The VSS project is also worth mentioning in this regard. It is used for non-custodial lightning wallets to store channel state. It offers several SQL backend options. So perhaps something a mint could integrate on the same host: https://github.com/lightningdevkit/vss-server

[KKA11010]

@callebtc @gandlafbtc @BilligsterUser @misovan Any thoughts on this? What do you think about giving the user the option to choose between seed or encrypted iCloud/GDrive backup?

[callebtc]

@callebtc @gandlafbtc @BilligsterUser @misovan Any thoughts on this? What do you think about giving the user the option to choose between seed or encrypted iCloud/GDrive backup?

I like this very much but I feel like I would give the user both options: store their entire balance after each tx, and also store their seed phrase in cloud backup as well.

[tanx]

Thanks for the feedback @callebtc. Happy to provide code review and answer any questions if you decide to use photon for cloud backups. This threat model document helped other devs that used the lib and may be helpful to further the discussion around trade-offs: https://github.com/photon-sdk/photon-lib/blob/master/threat-model.md

[BilligsterUser]

Thank you 🙏

[tanx]

I would give the user both options: store their entire balance after each tx, and also store their seed phrase in cloud backup as well.

Also to clarify... photon should only be used to backup the private key that is used to encrypt tx/ecash data. That private key would be static while the ecash data changes with each tx. I'm not familiar of how ecash data is currently backed up in eNuts. The last time I tested eNuts there was only an option to copy a "Cashu token from mints and proofs which becomes invalid after new transactions". Perhaps @G8XSU, @moneyball can provide guidance as to whether Spiral's VSS project is a good fit here.

[G8XSU]

VSS can serve the purpose of primary storage in this case.
Vss is built as a generic purpose storage solution which can either be self-hosted or client can use one of the 3p providers or mint-hosted.

The backup would need to be updated after each transaction, which would require a network request. These requests can potentially fail, and updating the backup at certain intervals might result in outdated backups.

This is exact use-case for Vss in case of lightning state storage.

Overall Vss is just a Client-side encrypted KVStore with optional versioning support.

In near future, versioning support will be used to add multi-device support. I think this can be very useful for cashu-wallet.

Afaiu, integration would involve implementing SimpleKeyValueStore and SecureStore for VSS.

Vss-client is currently written in rust, we can discuss the approach for language/bindings support if you are interested.
Let me know if you have further questions.

[tanx]

Thanks for the info @G8XSU!

Vss-client is currently written in rust, we can discuss the approach for language/bindings support if you are interested.
Let me know if you have further questions.

I guess this is what Mutiny uses in their rust/wasm PWA? I suspect a pure TypeScript/JavaScript port of vss-client would be the simplest path to integrate in eNuts as react-native's JavaScriptCore runtime doesn't support wasm. A react-native module that calls vss-client ObjectiveC/Kotlin language bindings might be another path. But in my experience language bindings for react-native modules are usually more work than a pure JS rewrite, especially if the lib in question only calls HTTP/REST apis and doesn't need native OS apis. Not sure if I'm underestimating vss-client's complexity though.