Re: [Taler] Taler Android UX

[Christian Grothoff]

On 4/9/20 8:02 PM, Torsten Grote wrote:
> On 2020-04-07 14:40, Christian Grothoff wrote:
>>> [exchange selection]
>> First time: - bank trigger (QR code, link on Bank-site) => Exchange 
>> selection => Tos => ...
> 
> If there's a trustworthy exchange to pre-select, doing this might be
> easier for users than being forced through exchange selection for their
> first-time withdrawal. We could still show an onboarding dialog making
> people aware of the possibility to change the exchange, but maybe only
> for their second withdrawal?

That sounds a bit too much like a dark pattern for really strongly
forcing people onto our pre-selected exchange. Sure, having an
audited/trusted exchange default pre-selected in that dialog can make
sense so that the user only has to click on 'next'. But skipping it
entirely and immediately going ToS without even giving a hint that there
could be another choice seems fishy.

>> The /keys response of the exchange includes four fees for each 
>> denomination.
> 
> Thanks! I now found it in the exchange info JSON I get from wallet-core
> and implemented a simple page showing the fee structure of the current
> exchange. A screenshot is attached.

Well, we should definitively hide the rounding loss if it is zero. Other
than that, the screen shot already wonderfully demonstrates that this is
clearly too much information -- especially if we imagine a user
withdrawing an amount with a more diverse set of denominations being
used ;-). Anyway, the screenshot nicely shows the kind of complexity
we'd want to _hide_.

>> Well, 'big warning' may be an understatement (we could make it a 
>> protocol violation and refuse to deal with the exchange).
> 
> If that's possible. Sure.

It's our design, we can force it. It could just also be a very bad idea
to do so (it reduces possibilities for competition on fee structures).

>> But the real question is what those 'ground rules' should *be* (to
>> improve UX while maintaining sufficient flexibility).
> 
> It would maybe help to understand the fee structure better.
> 
> So there's a withdraw fee per coin which adds up to a total withdraw
> fee. Then, there can be a rounding loss if we can't satisfy the
> withdrawal with the available coins. Couldn't we offer the user to
> withdraw a bit more in this case to avoid this loss?

That'd imply the exchange taking a loss. However, the rounding loss is
largely theoretical: if the exchange offers denominations that are at or
below the smallest unit you can wire-transfer (like 1 cent), the
rounding loss will always be zero and can be ignored/hidden. But an
exchange could also only offer say 50 cent coins as the smallest unit,
and then it would become "substantial". Hence again we must have it, at
least as long as we don't have some harsh constraints on the offered
denomination structure. And given that for example there are EURO-zone
countries with 1cent and 2cent pieces, and others with only 5 cent
pieces, I think that flexibility of defining the smallest denomination
should carry over to electronic cash.

> Then each coin also has fees for deposit, refresh/change and refund. The
> last one is clear. Not sure when the first fee is due. Is this for
> payments?

Yes, when you make a payment (deposit) at a merchant, that deposit fee
is deducted from the amount the merchant receives.

> Refresh is needed when a payment can't be made with the
> available coins.

Refresh can be for change, but also when coins expire, or when
transactions are aborted due to network failures. So not just for
getting change, but _mostly_.

> I don't yet understand why these operations incur different technical
> costs for an exchange operator and thus need to separate. I also don't
> understand why the fees need to be per coin. Ideally, the UI and cost
> structures can be understood by users without knowing about coins.

A refresh is a two round-trip operation involving about 10x the number
of expensive cryptographic operations and storage compared to withdraw
or deposit. Withdraw is signing, which is cryptographically more
expensive than verifying (deposit). Refund involves only EdDSA-signature
verification, the others are RSA and EdDSA. Refund results in the
deposit fee being waved, but requires additional DB storage during
processing.

Refresh fees could also be used by central banks to create effectively a
negative interest rate on e-cash (Woergelgeld).

Finally, from a business perspective, one can either go for a model of
"cost-based fees" (i.e. I charge proportional to costs), or like Credit
cards to hiding the cost structure: deposit fees _can_ be explicitly
covered by merchants, while the others are always _visible_ to the
consumer. So an exchange operator COULD decide to only charge deposit
fees to make the consumer never see any fees explicitly. However, then
malicious consumers could do (pointless)
withdraw-refresh-refresh-refresh-refresh and basically try to "bankrupt"
the exchange operator that way.

In summary: the costs are sometimes substantially different (bandwidth,
computation and storage), and it is also conceivable that an exchange or
central bank may set fees for marketing or policy reasons that do not
even match the costs.

> Then there's wire fees per year. Are these always per year or are the
> timespans flexible? For which operation are those fees charged?

Wire fees are charged per wire transfer. The merchant(s) specify how
often they want to be paid (hourly, daily, weekly, every 42h, whatever),
and that's how often the aggregation wire fee will be charged.

Closing fees are ONLY charged to customers that create a reserve (wire
money to the exchange) but then never withdraw the coins.

Both should largely correspond to the wire transfer costs of the
underlying banking system.

>>> Btw. it looks like the WebExtensions wallet and the exchange let 
>>> you withdraw KUDOS without needing to accept the ToS. IMHO both 
>>> should enforce that.
>> Of course. The problem is that we are (still) lacking man-power for 
>> the WebExtensions wallet.
> 
> Sure, but is the WebExtensions wallet silently accepting the ToS for the
> user? If not, IMHO the exchange should enforce that ToS were accepted
> before accepting a withdrawal.

I suspect the WebExtensions wallet isn't even ToS-aware at all at this
point. Also the exchange can't "enforce" this, because it doesn't get
anything when the user accepts the ToS. The system design says the
exchange must offer it, and wallets MUST collect the 'acceptance' from
the customer before proceeding. Naturally, this being Free Software, we
can't enforce that. But I think that may actually be even *technically*
beneficial, especially for payments for Internet of sh*T (IoT) applications.


Happy hacking!

-Christian

signature.asc
Description: OpenPGP digital signature