A full-fledged incentivization for Store (and potentially other light protocols) may involve multiple round trips. For instance, a client may first query a price from the server, and then submit an actual query along with a proof of payment. We need to consider what happens if the network connection is disrupted in the middle of the protocol.
Copying a relevant comment by @chaitanyaprem from the PR discussion:
A does historyRequestQuery(Q1) to B
B offers a price
A makes payment and sends proof of payment to B
Before B responds with actual data for the query, A looses network connection.
A reconnects after sometime and wants to request server again for Q1 along with proof-of-payment. I could not see this scenario getting addressed by the simpler protocol laid out and hence was suggesting that we should include the option of indicating proof-of-payment in the historyRequestQuery itself.
But now that i think about it, this may lead to complexities. e.g consider another scenario
A does historyRequestQuery (Q1) to B for time t1 to t2(now)
B offers a price
A makes payment and sends proof of payment to B
Before B responds with actual data for the query, A looses network connection.
Now after sometime when A comes back the historyRequestQuery would be from time t1 to t3(now) where t3>t2.
One solution for this is : B has to indicate to A that it is responding with only data from t1 to t2 and ask for further proof of payment (by specfying the price).
Now i see that this is complicating the price aspect of the protocol.
A full-fledged incentivization for Store (and potentially other light protocols) may involve multiple round trips. For instance, a client may first query a price from the server, and then submit an actual query along with a proof of payment. We need to consider what happens if the network connection is disrupted in the middle of the protocol.
Copying a relevant comment by @chaitanyaprem from the PR discussion: