diff options
| -rw-r--r-- | design-documents/009-backup.rst | 17 |
1 files changed, 14 insertions, 3 deletions
diff --git a/design-documents/009-backup.rst b/design-documents/009-backup.rst index 80393f54..1b4895ee 100644 --- a/design-documents/009-backup.rst +++ b/design-documents/009-backup.rst @@ -62,6 +62,9 @@ Supported Operations The abandoned wallet marks explicitly in its backup blob that it is abandoned. Abandoning a wallet will set the backup state to "uninitialized". * **backup**: Do a backup cycle. +* **rekey**: Change to a new wallet root secret, in case the old one has been + compromised. Only protectes future funds of the wallet from being + compromised. Requires a new payment to all configured backup providers. Backup Format @@ -92,8 +95,8 @@ Open Questions * What happens if the same Anastasis user has multiple wallets? Can Anastasis somehow support multiple "instances" per application? -Future Work -=========== +Future Work / Ideas +=================== * Incremental backups? @@ -102,6 +105,14 @@ Future Work be updated incrementally once the journal is full. * Leaks more information and is more complex. -* Real-time synchronization, either over some signaling server +* Mult-device synchronization, with synchronous communication either over some signaling server or P2P connectivity (WebRTC, etc.) + * Destroys the "wallet" metaphor, now the wallet is more like an account. + * We should first agree on the requirements from the perspective of end users + * P2P payments in Taler might also make sync less important + * Maybe only parts of the state (purchases / contracts, but not coins) should be synchronized? + * WhatsApp web model: The wallet runs only on one devices, but other devices + can connect to it as clients. (Allows my browser wallet to temporarily access + money from my phone wallet and vice versa.) + |