On 8. Sep 2021, at 03:21, Jacob Bachmeyer <jcb62281@gmail.com> wrote:
Schanzenbach, Martin wrote:
I think use cases such as "soft binding" of pocket change to certain
products/services could still make sense.
Eg. 10% for candy, 20% for games etc.
Even that would be quite difficult to consolidate properly for businesses.
This type of "budgeting aid" could be implemented entirely client-side and
transparently with respect to the Taler protocols. Users configure their wallets to set
certain amounts aside for certain categories and indicate the category to associate with
each transaction. The wallet rejects the transaction (and offers access to revise the
user's budget to permit the transaction) if the funds allotted to that category would be
insufficient within the user's budget.
No other entity need even be able to see the user's categories or budget outline; the
"restriction" is entirely in the user's wallet and can be effectively overridden if the
user so chooses. Businesses would receive only the standard tokens, with no indication that token
X was budgeted for use with them. The "soft binding" use case is entirely client-side,
requiring only some additional metadata to preserve the budgeting information when synchronizing
wallets.
I think I would agree with you. I did not put time into finding those examples,
I just wanted to illustrate a use case which is not as highly regulated as age
restrictions.
The problem with age restriction is that it will happen if you agree with it or
not, because it is regulated. So if the Taler technology does not support it,
merchants will have to implement it in another way.
As a user, you will not be able to "opt out" just because Taler does not
support this feature for its transactions, and merchants (this is my assumption) will not
be fully compliant by relying on the proposed incarnation of the feature.
Mostly because the restricted goods and the legal age for them are defined by
the state and its laws.
If you advocate from the perspective of a libertarian society, I fully agree
with you that this feature is unnecessary and if at all should be implemented
client-side.