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: Florian Dold
Subject: Re: [Taler] Technical questions for backup/sync (was: UI considerations for backup & sync)
Date: Wed, 27 May 2020 23:45:02 +0530
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 5/27/20 10:58 PM, Torsten Grote wrote:
>>> However, the QR code would also need to include the service domain
>>> and path. What happens if there's more than one sync service? Does
>>> the same page show two codes or does one code include the domain
>>> and path of each service potentially makes the code too big? Or do
>>> we need to show different codes on each service page/screen?
>> Yes, in addition to the key material we need to include the URL 
>> (taler://sync/$HOSTNAME/$KEYMATERAL). But unless 
>> you.pick.a.freakishly.bad.domain.name.com, this should still be OK
>> and the $KEYMATERAIL will be the biggest part.
> 
> Yep, however I am still thinking about the UI here. You said we could
> just show one master secret in a single place to add new devices even if
> we have multiple sync services and I wonder how that would work.

Wouldn't it suffice to import the QR code of one sync server (maybe the
one least recently used)?  If the newly joining wallet talks to this
sync server, it'll learn about the new ones anyway.

UI-wise, the newly enrolled wallet might want to synchronously check if
it can talk to the sync server.

> Three different choices could be confusing for users, not understanding
> if they need all three or just one or two out of three. But I am no UX
> expert, so we could try with three: QR, URI and mnemonic code.

By default I would just show one QR code for one sync server.

(If someone has a really freaky setup, like some backup server that's in
some private network, we could always add the option to first go to the
sync server details and then show the QR code specifically for this server.)

>>> No that part is fast, but according to the docs, in the worst case
>>> it takes 2h5min for a device to upload its state and another 2h5min
>>> for another one to get it.
>> Huh? How do you arrive at those numbers? Which "docs" are you talking
>> about?
> 
> I am talking about
> https://docs.taler.net/core/api-sync.html#synchronization-frequency
> where it says:
>> the client should attempt to synchronize at a randomized time
>> interval between 30 and 300 seconds of being started, unless it
>> already synchronized less than two hours ago already

It would be possible to temporarily increase the sync frequency on the
device showing the QR code.

- Florian



reply via email to

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