Re: [Taler] wallet exchange management

[Florian Dold]

Hi Torsten,

thanks for your constructive comments.  I think we still have some
different ideas about how the exchange list management should work
conceptually.

I thought when we select a different exchange for withdrawal, it doesn't
necessarily get added permanently to the list of known exchanges.  This
is why it's called "query" and not "add".  It'll get added either by
setting it as "trusted" or by accepting a withdrawal.

> Should we maybe list all exchanges we have available for the currency in
> question and if one can't be used disable selection in the UI along with
> a reason?

Yes, the updated API will reflect that (hopefully).

>> Otherwise, the wallet would end up showing exchanges that we've only
>> queried and looked at, but never done anything else with.
>
> Is this a bad thing? Would we ever query exchanges without user
> interaction and thus fill up the exchange list with lots of exchanges
> unknown to the user?

Hmm.  At least one such source of new exchanges would be the one
suggested by the bank.

But I see your point that we may not have to worry about this list
expanding too much, especially if we rank them by recency.

> Would the earliest coin expiration of interest in that list as well?

Good point, but I think this should be part of the "reasonable-ness"
criteria struct.

Otherwise, I agree with all the "type errors" (boolean vs string, list)
you pointed out ;-)

- Florian


On 4/9/20 1:29 AM, Torsten Grote wrote:
> On 2020-04-08 09:32, Florian Dold wrote:
>> As an optimization, the "queryExchangeInfo" API should be able to return
>> information about the exchange that is not 100% complete (regarding
>> verified denominations and wire info).
> 
> I don't know how long downloading /keys and verification takes, but if
> possible, I would like to avoid having to deal with partial information.
> Ideally, I provide a baseUrl to add a new exchange and only get the
> result when adding the exchange was successful.
> 
>>  So the request would be
>>
>> interface QueryExchangeInfoRequest {
>>   // If given, return error description if the exchange is
>>   // not compatible with this withdrawal operation.
>>   talerWithdrawUri?: string;
> 
> Do we need this? Can't we just add a new exchange and if this exchange
> can't be used for whatever the user wants to perform afterwards, we deal
> with it the way we need to deal with these things anyway?
> 
> Why is it called QueryExchangeInfoRequest? Don't we want to add a new
> exchange here?
> 
>> interface QueryExchangeInfoResponse {
>>   auditingState: ExchangeAuditingState;
> 
> This should probably be a list as there can be more than one auditor, right?
> 
>> Here's an interesting error case:  What if the exchange and wallet
>> disagree about the auditorBaseUrl and/or auditorName for the same
>> auditorPub?  Will this inconsistency be reported?  Will we just use the
>> auditor public key and ignore the rest?
> 
> I still consider myself rather new to Taler and miss a lot of
> information, but this sounds like we should reject a new exchange if it
> presents inconsistent auditor information.
> 
> Side question: shouldn't auditor information be signed with the
> auditor's private key that corresponds to auditorPub? This wouldn't
> prevent inconsistent information, but at least we know that the auditor
> is to blame for them.
> 
>> By "active" I mean that this exchange should show up in the list of
>> choices when doing a withdrawal.  Otherwise, every exchange the wallet
>> ever used will be in this list.
> 
> Should we maybe list all exchanges we have available for the currency in
> question and if one can't be used disable selection in the UI along with
> a reason?
> 
>> Ah "default exchange", again something else that we are implicitly
>> mentioning, but that's not part of any API yet.
> 
> When doing "getWithdrawDetailsForUri" without a "selectedExchange", it
> could just use the default one.
> 
> However, when we other a dedicated exchange management UI, it *might* be
> useful to see which is default and change the default there.
> 
>> Otherwise, the wallet would end up showing exchanges that we've only
>> queried and looked at, but never done anything else with.
> 
> Is this a bad thing? Would we ever query exchanges without user
> interaction and thus fill up the exchange list with lots of exchanges
> unknown to the user?
> 
>> interface ExchangeListRequest {
>>   // Used to decide compatiblity
>>   talerWithdrawUri: string;
>> }
> 
> Should we also support listing *all* exchanges we have, for an eventual
> management UI?
> 
>> interface ExchangeListRespose {
>>   exchanges: {
>>     exchangeBaseUrl: string;
>>     // Incompatible exchanges are also returned,
>>     // as otherwise users might wonder why their expected
>>     // exchange is not there.
>>     compatibility: "compatible" |
>>       "incompatible-version" | "incompatible-wire";
>>     trustedDirectly: string;
> 
> What string do we expect 'trustedDirectly' to have? Or is this a boolean?
> 
>>     recommendedByBank: boolean;
> 
> I guess this works only when we specify a talerWithdrawUri.
> 
>>     // The "reasonable-ness" of the exchange's fees, in context
>>     // of the withdrawn amount.
>>     // Only provided if available (if we've already queried
>>     // and checked this exchange before).
>>     feeStructureSummary: FeeStructureSummary | undefined;
>>   }[];
>> }
> 
> We could leave this out for now until we find a fee summary solution. Or
> could this be a simple boolean indicating whether the exchange has a
> sane fee structure or not?
> 
> Would the earliest coin expiration of interest in that list as well?
> 
> Kind Regards,
> Torsten
>