taler
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Taler] Technical questions for backup/sync (was: UI considerations


From: Christian Grothoff
Subject: Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)
Date: Thu, 21 May 2020 20:09:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 5/21/20 7:01 PM, Torsten Grote wrote:
> On 2020-04-27 12:10, Florian Dold wrote:
>> We've recently discussed some of the more technical details, I guess I
>> should write this up in a design doc!
> 
> The design doc is now available here:
> 
>     https://docs.taler.net/design-documents/005-wallet-backup-sync.html

Nice. I'm missing an arrow from the "Backup Settings" to "Backup
Secret": it is possible that I have a backup, and just want to review
the secret. So if a backup exists, there should be a forward transition
from the "Backup Settings" to the "Backup Secret" dialog.

> Note that there's still a list of open questions at the end.

I'm not sure if this is covered by your diagram, but I think we can have
more than one sync provider. In fact, we probably must allow this to
make the wallet state a CRDT.

> However, I added a diagram for the user flow of setting up backup.
> Feedback is very appreciated. If everybody agrees with that flow, we can
> design the UI and the wallet-core API around that.

If we just talk about backup/sync, with the small change above, I agree
with the diagram. If we add Anastasis into the mix, we'll need more. But
maybe let's take it one step at a time ;-).

> Note that I focused on the backup use-case for now as it has the higher
> priority and is complicated enough on its own. We can add sync with
> device management later.

I think sync mostly changes what we show in Backup settings. Given the
'backup secret', we should be able to add another device to the sync
group simply by 'restoring from backup' with that sync secret.

> How is restoring from backup supposed to work? Does the user just scan
> the QR code with the taler-sync:// URI or is there a dedicated place in
> the UI to hand that URI manually?

I would say both. I would show the QR code as the "Backup secret" (maybe
only if the user clicks on "show QR code"), and possibly give the option
to "print QR code" (if supported by the platform). But we should _also_
show the URI to be written down (yes, painful), and thus also should
have a way to enter URIs. But we should support users entering URIs by
hand _anyway_, even for taler://pay/-URIs. I just had the Anastasis devs
effectively have that problem: they have a taler://pay/ URI, and would
need to turn it into a QR code to pay with the F-droid wallet. So having
an "enter taler://-URI" feature for _all_ types of taler://-URIs would
make sense.

Oh, and I think it should be taler://sync/, not taler-sync://.

> What happens when the payment period expired? Does the service still
> allow to restore and requests a new payment afterwards? Just blocks new
> uploads in the meantime?

It deletes the backup. You pay for the storage for a time period. So
like X months before the payment expires, the wallet really MUST alert
the user to it and prompt for the user to extend the service duration by
paying again. We may want to even support an "auto-pay" feature for this
one.

> I imagine after a positive confirmation from the service, it will tell
> us that the latest backup is from date X and asks for confirmation of
> restore. Do we have the option to restore older backups as well?

The service only stores the latest version.

> Is restoring from backup always possible, no matter what the current
> state of the wallet?

Yes.

> Is existing state merged with the state of the
> backup?

Yes. Wallet state must be a CRDT, so we should always be able to merge.

> What happens if there's already another backup service in use?

I'd say we sync to all of them.

> Will both states get merged and propagated to each other? Are
> transaction IDs guaranteed to be unique even across multiple
> wallets/services?

They must be, otherwise we again don't have a CRDT.

My 2 cents

Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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