Re: [Taler] feedback requested: 002-wallet-exchange-management

[Torsten Grote]

On 2020-04-13 15:13, Florian Dold wrote:
>>> If the user reviews a new exchange during withdrawal but then does
>>> not decide to use it, will this exchange be permanent?
>> I'd say yes.
> Hmm.  I really don't like the idea of being able to add some information
> that's prominently visible in a way that can't be deleted.

Why can't it be deleted? If I entered or selected a previously unknown
exchange, that's probably because I want to use it. If I don't want to
use it anymore, should there not be away to remove it from the list, if
it doesn't hold any of my coins?

>> Ideally, we can work without partial results.
> I'm not sure, and that's why I included the option to do a partial query
> ;-)  Depending on the hardware of the user and the number of
> denomination that the exchange offers, it might have noticeable latency
> to verify all signatures we need to verify before the user can accept
> the withdrawal operation.
> 
> If a client of wallet-core (e.g. the Android UI) doesn't need the faster
> partial information, it can always pass this in the query.

Android wallets are probably the ones with the least computing power. I
think it is fine that adding a new exchange takes some time. You don't
do it that often and it hopefully doesn't take several minutes, right?
If it takes more than a few seconds, one could also show various stages
in the UI to keep the user entertained.

If using the partial feature what is the advantage on the UI side? Is it
just that the user can see the next screen faster and then has to wait
after that?

> Some exchange management view might want to allow the user to view the
> accepted ToS and then the current ToS, and maybe even show a diff!  For
> that we need to know these details.

True, but since this is a new feature that isn't planned at the moment,
could we add those later when we add the feature?

> We are doing normalization (and it *used* to be documented, but I have
> to admit I can't currently find any documentation about it other than
> the wallet's source code).

Haha ok. So I can count on wallet-core normalizing the user inputs.

> Interesting point.  I guess by "trust", we mean "don't show a big
> warning the next time this exchange is selected for withdrawal".  Maybe
> trust is not the right word?  Any better suggestion?

I am not sure how this is supposed to work, but my guess is that the
wallet comes with auditors for the jurisdictions Taler works in and that
exchanges operating in these jurisdictions will need to be audited, so
they they will be "trusted" by default, right?

> If I "untrust" an exchange, it means I don't want it to be selected by
> default (even if it's the last exchange I used), and that I have to
> check some box again that I trust this exchange the next time I use it
> for withdrawal.

Maybe there could be a "use this exchange for withdrawals" checkbox
somewhere without talking about trust?

> I think directly trusted exchanges should be the exceptional case, but
> if we don't allow it, other deployments (university, festival, ...) of
> Taler would always be 2nd class citizens with this wallet.

Would these other deployments be using the same official currency like
the audited ones?

>> I saw public keys included in some responses. What's the use-case for
>> the wallet here or could we leave those out? In general, there seems to
>> be a tendency in the APIs I've seen to include as much information as
>> possible. I'd do it the other way around and add as little as possible,
>> only what is expected to be needed in the UI layer and add more later,
>> if needed.
> It definitely needs to be displayed as a way to verify that this is
> really the exchange the user wants to use, in case they enter it
> manually via an URL.

Is there already information about how users are expected to do that?

A taler Uri should probably come with the public key. Not sure that we
should support manually entering an exchange in that case. Humans aren't
good at reliably comparing long strings, so there would need to be some
QR code verification. But if you do that you might as well use the QR
code to add the exchange *with* the public key.

Or we trust DNS and TLS to sufficiently guarantee that the added
exchange is the correct one? Maybe not.

Kind Regards,
Torsten