Community Call - February 9, 2022

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:00Z2022-02-09T17:00:00Z

Meet joining info
Video call link:
Or dial: ‪(GB) +44 20 3956 1581‬ PIN: ‪476 812 309‬#
More phone numbers:

Add to Google Calendar

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.

Just curious - what is the planned cadence for these calls going forward?

For example, I noticed there wasn’t a call on Feb 2.

The cadence has changed this year. The calls are going to be once a month, on the second Wednesday of the month.

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)


  • 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

Are there any thoughts on this before our call?

The recording for the community call has been uploaded to:

The debate item is open until the March Community Call, if you’re looking for more context, notes are in the open-payments repository.