[Top][All Lists]

[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 
+* Minimize information leaks / timing side channels (user might be able to 
+  some setting to allow more frequent backup with less potential data loss but 
+  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 
   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 
   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 
+    money from my phone wallet and vice versa.)

To stop receiving notification emails like this one, please contact

reply via email to

[Prev in Thread] Current Thread [Next in Thread]