Re: [Taler] replay and merchant backend/frontend protocol

[Christian Grothoff]

Well, in any case we need to very clearly define what the backend has to
store.  Right now, the merchantdb only stores hashes of the contracts
that have been paid, and never stores _anything_ just for the /contract
requests.

What you suggest now will make /contract requests significantly more
expensive, as even unpaid contracts will require a database transaction.
 If we store
 h_contract -> contract or
 h_contract -> (contract, frontend_data)
is almost irrelevant here.  For me, the real issue is that the merchant
frontend can no longer assume that /contract requests are virtually free
(we can probably do 10k EdDSA signatures/s, but only way fewer
transactional DB commits/s).

But, you are right in that "somebody" has to do it, and it's probably
better done once in the backend than in each frontend.

On 01/25/2016 11:23 PM, Florian Dold wrote:
> On second thought, it might be cleaner to have the extra information
> that is only needed by the merchant frontent in the wrapper around the
> contract (e.g. as a "frontend_data" field).  This extra field then
> shouldn't ever be sent to the customer.
> 
> Implementation-wise it's almost the same though, the info is just
> outside the contract and not inside.
> 
> - Florian
> 
> On 01/25/2016 11:15 PM, Florian Dold wrote:
>> Hi!
>>
>> if my understanding is correct, there is currently a deficit in the
>> backend/frontend protocol.
>>
>> The information we get from /backend/pay is not sufficient to restore
>> the client's session state, since the response is empty on success.
>>
>> For example in the donation shop demo, the missing information would be
>> the payment amount and the payment receiver ("taler", "tor", "gnunet").
>>
>> Of course there are other possibilities to get this information, but for
>> our case it seems very convenient to just have the whole contract as a
>> response to /backend/pay in the frontend.
>>
>> For both our demos, the information that the frontend needs from the
>> backend can be assembled from the contract (and if not, there should be
>> an "extra" field in the contract for the merchant to store
>> machine-readable, small pieces of information).
>>
>> Now you could argue that always returning the full contract on
>> /backend/pay is overhead, but consider that we're talking about loopback
>> here in practice, and that it would make the implementation quite easy.
>>
>> Thoughts?
>>
>> Christian or Marcello:  Any volunteers to implement this in the backend,
>> while I hack on the wallet and the shop frontend?
>>
>> - Florian
>>
>

signature.asc
Description: OpenPGP digital signature