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: Wed, 27 May 2020 21:42:45 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

On 5/27/20 8:15 PM, Florian Dold wrote:
> 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.

Indeed.

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

And in fact poll at a reasonably high frequency for the join to have
been approved. We may even want to extend the sync API to enable
long-polling for this, basically a "if-modified" request where we sit on
it if there are no modifications.

>> 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.

I agree.

> (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.)

I think if someone is running their own sync server, we can assume that
they are technologically sophisticated enough that we don't need to
worry too much about their UX. ;-)

>>>> 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.

I agree. The above was for general sync 'in the background', not for
joining or interactive approval of new devices.

-Christian

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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