feat: Pay before Persist experiment #1373
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Towards #1331
Related #1251
Problem
In theory, we can Pay a request before persisting it in the Request Network protocol.
In other words, we create a Request in memory without persisting it. Then, we prompt the end user to send payment against that request. Finally, we persist the request - so that it may serve as a receipt for the payment.
However, the existing SDK functions assume that the request is persisted immediately after being created.
Motivation
This shortens the critical path for a user making a payment. This is especially desirable for payment apps - in which a payer wants to buy something. The workflow is driven by the payer instead of the payee, so why make them wait for the request to be persisted before allowing them to send a payment?
Changes
Why were these variables/functions chosen?
I traced the RequestNetwork.createRequest() and the RequestLogic.acceptRequest() functions and changed all the internal variables/functions
private
=>public
.Considerations
Rather than implementing this new logic, this PR only changes several
private
functions and variables to bepublic
, thus empowering external contributors to experiment with the "Pay before Persist" workflow. The expectation is that once these experiments are complete, we either:or