[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-docs] branch master updated (4dfa86c -> 12a3571)
From: |
gnunet |
Subject: |
[taler-docs] branch master updated (4dfa86c -> 12a3571) |
Date: |
Fri, 06 Nov 2020 22:15:28 +0100 |
This is an automated email from the git hooks/post-receive script.
dold pushed a change to branch master
in repository docs.
from 4dfa86c modified reducer documentation
new d5b6f10 clarify
new 12a3571 some ideas
The 2 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
design-documents/009-backup.rst | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/design-documents/009-backup.rst b/design-documents/009-backup.rst
index 7ec8be2..1b4895e 100644
--- a/design-documents/009-backup.rst
+++ b/design-documents/009-backup.rst
@@ -18,7 +18,9 @@ Requirements
their wallet's root secret safe.
* Arbitrary number of backup providers must be supported
-* Minimize information leaks / timing side channels **if** requested by the
user
+* Minimize information leaks / timing side channels (user might be able to
change
+ some setting to allow more frequent backup with less potential data loss but
more
+ leakage)
* Minimize potential to lose money or important information
* Since real-time sync is not supported yet, wallets should have a feature
where their whole content is "emptied" to another wallet, and the wallet is
@@ -60,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
@@ -90,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?
@@ -100,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.)
+
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [taler-docs] branch master updated (4dfa86c -> 12a3571),
gnunet <=