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

[Torsten Grote]

On 2020-04-09 06:16, Florian Dold wrote:
> Please have a look: 
> https://docs.taler.net/design-documents/002-wallet-exchange-management.html

Thanks a lot for writing this up. It helps a lot to have a document
summarizing the outcome of a long email thread.

> An exchange might only be known the wallet temporarily.

typo?

Aprt from that I am not sure we need temporary exchanges and thus
garbage collection at all.

> During the withdrawal process, the bank can also suggest an exchange.
> Unless the exchange is already known to the wallet, this exchange
> will be added non-permanently to the wallet.

Could we only add the exchange if the user actually selects it? Or do we
need to query it first to offer it as an option in exchange selection?

Or could we also list it, but display it differently and only query it
once the user decided to try what the bank suggested?

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

> interface QueryExchangeInfoRequest {
>   ...
>   // If true, the query already returns a result even if
>   // /wire and denomination signatures weren't processed yet
>   partial: boolean;

If think I had said this somewhere else before:
Ideally, we can work without partial results.

What happens if a QueryExchangeInfoRequest fails, because the user made
a typo in the baseUrl for example?

> interface QueryExchangeInfoResponse {
>   ...
>   currentTosVersion: string;
>   acceptedTosVersion: string;

What's the reasoning here? Could we not simply have an tosAccepted
boolean and if it is false, we need to accept?

Depending on the outcome of the balance discussion, we might want to
include the current balance hold by an exchange in the list response.

Are base URLs normalized somehow? I guess these would all be different
exchanges?

* http://exchange.example.org
* https://exchange.example.org
* https://exchange.example.org/
* https://exchange.example.org/#foo

Regarding manually setting trust, I think this is something to be
avoided if at all possible as most users are not in a position to
properly judge if an exchange can be trusted or not. It only opens a up
a big attack vector.

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.

> SetExchangeTosAccepted

We should probably add a version field here to clarify which version of
the ToS the user had accepted. Sure, wallet-core could just use the
latest one, but what if that has changed since the user requested the ToS?

I hope the feedback is useful.

Kind Regards,
Torsten