Send-payment-request returns too early

[eorituz]

Problem Definition

I wrote a small M2M paywall demo and figured out that the send payment request

curl -i -X POST http://localhost:5001/api/v1/payments/0x0f114A1E9Db192502E7856309cc899952b3db1ED/0x61C808D82A3Ac53231750daDc13c777b59310bD9 -H 'Content-Type: application/json' --data-raw '{"amount": "42"}'

a payer sends to its Raiden client returns before the payee can see the successful payment in his payment history.

curl localhost:5001/api/v1/payments

This behavior is a huge UX problem for any M2M use case since the payer doesn't know when he is able to access the paywalled content. (Accessing the paywalled content is ofc only possible as soon as the payee learned about the successful payment.)

Solution

Do not return a "send payment request" before the payee reported a successful state change.

[Dominik1999]

Thanks for that issue. Nice to have real user feedback. In this distributed system the perspective of the finalization of the payment is not the same for those two parties atm. Let's see how we can fix that for M2M use cases.

[eorituz]

@Dominik1999 I understand that the sending of an additional message like "I updated my state with our recent transaction" costs latency but maybe we could add a flag --send-process-confirmation.

When using raiden in M2M payments the overall latency using raiden with such a flag would decrease since I had to build in a sleep to overcome the imperfect information.

[eorituz]

This Problem is linked to an old issue https://github.com/raiden-network/raiden/issues/2523 where we decided to not target this problem. The reasoning is basically "that's the way a decentralized system works".

[konradkonrad]

A solution is probably payment receipts

[karlb]

Since we are asking the target anyway, couldn't we block on that request until the payment succeeds? Something like GET /api/(version)/payments/(token_address)/(partner_address)/(payment_id)?wait_for_success=5