New Year, New Community Call format. We’re moving the Interledger community calls to be once a month, on the second Wednesday of the month.
We’ll have 4 regular update slots, from the Interledger Foundation, Rafiki, Fynbos, and Coil teams, with additional slots open for anyone that would like to share their project or a discussion item for the broader community.
The next community call will be on 2022-02-09T16:00:00Z → 2022-02-09T17:00:00Z
Please post topics you’d like to discuss here and some background context for the rest of the community.
We have slots for more regular updates on projects that build on the Interledger protocol, so please feel free to add your project to the agenda, and talk a little bit about your project.
We have another topic for the agenda as well related to a design decision for the next iteration of Open Payments. @adrianhopebailie summarized it really well, we’d like to discuss the options with the community group:
To summarise the issue:
WM payments uses SPSP which allows an anonymous request to the Payment Pointer to get STREAM credentials
We want to allow someone to write their own WM provider that connects to an OPv2 enabled account to send the WM payments
WM currently surfaces receipts at the client which allow the receiver to verify payments
If a user connects their custom WM provider to their OPv2-enabled account then the expectation is that when they visit a WM-enabled website the provider will create a new outgoing-payment from the user’s account with the PP from the website as the destination
The sending provider (e.g. Fynbos) will query the PP URL using SPSP and then open a STREAM connection to the receiving provider and start sending. Presumably during the SPSP interaction between the sending provider and the receiving provider a receipt nonce and secret are exchanged so now the sending provider is getting receipts.
The problem to solve is, the website needs to verify that it is getting payments to it’s account
Option 1: OPv2 defines way for the WM Provider to get the receipts from the sending provider and surface these via the WM API
Option 2: The WM Provider creates an incoming payment at the receiving provider and pays into that. The website is able to query the incoming payment for the received amount.
Pros and Cons
Option 1:
+ no change to the WM API in the browser
+ website can verify payments without making requests to the receiving provider (i.e. offline)
- leaking across layers (STREAM protocol stuff needs to be exposed at the OPv2 layer)
- implementing this is going to suck (exposing the received STREAM receipts via OPv2 endpoints
Option 2:
+ cleaner OPv2 API (no need to mingle STREAM protocol stuff into the API)
- receiver has to poll for received amount from incoming payment
- changes the WM API and moves WM to use OPv2 instead of SPSP
If we do go with option 2 it would make sense for us to change OPv2 to always use incoming payments. i.e. You can’t send to an account directly
All outgoing payments would need either:
An account URL and amount (send or receive)
OR
An incoming payment URL
When sender is executing an outgoing payment, if it has an account URL and amount, then it MUSt create an incoming payment at the receiver first