taler-docs

commit 75830b96f52d3ee1cd236dff2239e7ab8a1d7cab
parent 3efd020941198b37bd8e0ff3cb226d2a4909cce3
Author: Christian Grothoff <christian@grothoff.org>
Date:   Fri, 16 Apr 2021 12:53:28 +0200

revise backup flow

Diffstat:
M
design-documents/006-anastasis-ux.rst
 | 
25
+++++++++++++++++++------
M
design-documents/013-peer-to-peer-payments.rst
 | 
8
++++----

2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/design-documents/006-anastasis-ux.rst b/design-documents/006-anastasis-ux.rst
@@ -38,28 +38,41 @@ Setup Steps
            shape = rectangle;
        ];
        select_auth [
-           label = "Select\nAuthentication Methods\n\nProvide\nAuthentication Data";
+           label = "Select\nAuthentication Methods";
+           shape = rectangle;
+       ];
+       provide_auth [
+           label = "Provide\nAuthentication Data";
            shape = rectangle;
        ];
        select_providers [
            label = "Select\nService Providers";
            shape = rectangle;
        ];
-       threshold [
-           label = "Define\nRecovery Threshold";
+       review_policy [
+           label = "Review Recovery Policy";
+           shape = rectangle;
+       ];
+       edit_policy [
+           label = "Edit Recovery Policy";
            shape = rectangle;
        ];
        pay [
-           label = "Payment";
+           label = "Confirm Payment";
            shape = oval;
        ];
        settings -> backup_is_setup;
        backup_is_setup -> provide_id [label="Yes: Setup Recovery"];
        backup_is_setup -> settings [label="No"];
        provide_id -> select_auth;
+       select_auth -> provide_auth;
+       provide_auth -> select_auth;
        select_auth -> select_providers;
-       select_providers -> threshold;
-       threshold -> pay;
+       select_providers -> select_auth;
+       select_providers -> review_policy;
+       review_policy -> edit_policy;
+       edit_policy -> review_policy;
+       review_policy -> pay;
    }
 
 Entry point: Settings
diff --git a/design-documents/013-peer-to-peer-payments.rst b/design-documents/013-peer-to-peer-payments.rst
@@ -48,10 +48,10 @@ Requirements
 * If a payment would partially succeed, i.e. because the payer inadvertedly
   used some double-spent coins and some valid coins, this must fail before the
   uni-directional communication and be correctable payer-side.
-* The usual properties of Taler (everything auditable, high-performance
-  in terms of CPU, bandwidth, latency, storage requirements, and the
-  ability to levy fees on every operation that is costly for the exchange)
-  need to be preserved.
+* The usual properties of Taler (everything auditable, unlinkability,
+  high-performance in terms of CPU, bandwidth, latency, storage
+  requirements, and the ability to levy fees on every operation that
+  is costly for the exchange) need to be preserved.