Re: [Taler] wallet exchange management

[Torsten Grote]

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