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

[Florian Dold]

On 4/14/20 10:58 PM, Torsten Grote wrote:
> 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?

True, at least when we didn't do anything with the exchange (don't have
coins from it), we should offer deletion directly.  I got confused with
some other discussion where somebody mentioned we shouldn't have a
"delete" button for exchanges.

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

It's always good if we can do some expensive work while the user is busy
with something else, such as reading the fees / structure summary for
the exchange or even look at the ToS.

IMHO we should not underestimate how lower (perceived or real) latency
leads to a better user experience.

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

You're thinking about just the Android UI as a client, but we have to
include everything that the integration test is interested in as well
(and the WebExtension wallet)!

I want one API for wallet-core that I can test well, and I want to have
the same API for all clients *and* all implementations.  Otherwise we'll
have

* android API for wallet-core in JS
* integration test API for wallet-core in JS
* android API for wallet-core in Kotlin
* integration test API for wallet-core in Kotlin
* ... in Swift
* ...

And that's obviously bad.

Testing whether the wallet picks up changes in the exchange's current
ToS is indeed something I want to have in the integration test.

> 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?
They'll be indirectly trusted when audited by a trusted auditor, that's
why the other flag is called trustedDirectly!

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

Yes, I think "trust" is a bit overloaded.  But we again have to
distinguish between what we use internally, and what user-facing
vocabulary we use.

You're making a good point that we might want to avoid "trust" in the
user-facing vocabulary.

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

They could.  Nobody prevents you from setting up your own little "EUR"
exchange, but of course merchants very likely won't accept payments via
this exchange, as they trust it neither directly or indirectly via an
auditor!

We can certainly discourage using a common currency name though!  Not
sure how far we should go with this.  We could even say that an auditor
trusted by the wallet can audit a currency "strictly" / "excusively", so
as long as the BAFIN auditor audits EUR, the wallet will reject all
exchanges that are not audited by BAFIN.

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

As you've suggested yourself, probably there will be some QR code for
this in the future.  That could/should include both the base URL and the
master public key.

But users adding their own exchange manually is quite an uncommon use
case, so actual verification by the user would happen very rarely.

Even for the "festival deployment", the exchange recommended by the
festival money ATM would usually be used.

- Florian