Web Commerce Interest Group

<dezell> I'm not seeing the Webex activated yet, however

<scribe> Meeting: Web Commerce Interest Group

<scribe> Scribe: Ian

ILP update

[Evan Schwartz presents slides]

evan: Interoperable streaming payments
... interop is biggest payment problem
... PR API helps where there is a match; but there might not be a match (due to regional networks not having global scale)
... so today to make a payment you need to be on the same network
... and the flip side is to accept payments you need to be part of many networks
... payment networks are disconnected, so you need to connect them, by forwarding data across independent networks
... analogous to IP
... internetworking for money
... ILP CG at W3C. About 300 contributors
... ILP is designed to be use case agnostic
... so good to have lots of different players involved
... there are strong parallels with Internet architecture
... the "ledger layer": blockchains, banks, mobile money, digital wallets, cash
... the "ILP" layer: forwarding packets of money across the ledgers
... transport layer: IPR, PSK, Stream
... application layer: SPSP, HTTP-ILP, Paytorrent
... ILP design is so similar we are now basically copying QUIC

Basic model: Connectors route data across networks

scribe: they generate revenue from spreads
... payments can be sent across any number of hops
... the core of ILP is the CORE and PACKET AND ADDRESS forms
... and ILP packet has a destination address and other fields
... how is ILP being used today?
... Ripple is using a version of this technology to connect banks and other customers
... we are also working with Gates Foundation on Mojaloop
... interop is a key financial inclusion challenge
... that has been developed and they are working on pilots in various countries
... we are also trying to set up an open ILP network that connects cryptocurrencies

<Zakim> manu, you wanted to ask how ILP contributors are wrapping ILP into their products? What does the adoption pathway look like? What's in PoCs, Pilots, and production? Can you run ILP

manu: What does the adoption pathway look like for contributors?
... what would our company need to do to put ILP in front of our customers?

evan: The easiest way to start would be to connect through a cryptocurrency (XRP, ether, some bitcoin one)
... you would integrate SPSP

Manu: How much of this could be run on QUIC?

Evan: This is not using QUIC itself
... what this means is that ILP packets are limited in terms of data and money they carry
... like IP (max transmission unit depends on network)
... we needed something that does much of what QUIC does to multiplex streams of data/money
... I am reusing QUIC as a model

Manu: Why would you not build it on top of QUIC?

Evan: The actual communication protocol between peers is out of scope for ILP
... so each of the links can use whatever protocol it wants. Today we are using Web Sockets but that's not the most efficient one one might use
... we've considered QUIC or other approached like dedicated fiber links

Manu: You are focused on message formats?

Evan: Yes, the ILP packet does not depend on the network layer

Demos

"Connector dashboard" is connected to the live ILP network

scribe: individual connectors use routing tables

[Demo shows Payment Pointers for payment targets]

"moneyd" is a local connector that gives programs on my machine access to ILP

scribe: demo shows a web site that accepts ILP payments
... payment happening for photos and also streaming video
... streaming payments
... you can pay small amounts during interactions
... because payments are clunky, we try to bundle interactions ...but streaming payments could allow other models

"payment bandwidth": payment connectors might want to limit money you pay or receive at a given amount of time

scribe: could be measured, say, in dollars/second

<manu> Ian: I hear you saying: "A video is a series of photos"... what's the interest of streaming payments for product that costs more than a few dollars?

Evan: Originally we thought ILP should be for both big and small payments, but when you DESIGN for both, complexities arise
... the qualities you want for sending $10M are different from $.1
... for large amounts, it doesn't matter how much time is required, but focus is on risk
... for small amounts, time because much more important
... so we focused ILP design on transferring small amounts, much like the internet
... like Internet: you want to share large files, but IP only does small packets
... this lets routers optimize for large volumes of small packets
... so to send lots of money through ILP you send lots of packets

<Zakim> manu, you wanted to note that ILP sounds like it requires people to change their payment behavior, which is a big cultural change... what uses of ILP require no changes to the way

manu: This seems like a big cultural shift
... what are advantages to ILP that are not consumer-facing?
... e.g., our wallet allows you to pay anywhere whatever account type you have
... how compelling is streaming compared to connecting to diverse payment networks?

Evan: Good segue.
... internetworking is from anyone to anyone else
... because Internet made facilitation of payments so competitive, the costs plummeted
... at the same time, because it was so cheap, internet opened up new services; we imagine the same for ILP
... example 1: signup-less services
... on the internet you can't really get services without sign-up...ILP allows more anonymous services

<manu> Ian: Guest checkout exists, there are some ways I am not signing up but I'm identifiable.

<manu> Ian: It's not clear to me if you mean a) You don't need an account (this exists on the Web), or b) you get to anonymity?

Evan: If you are ordering a product that is shipped to you, you need shipping info. But cloud hosting is not shipped; you don't need to know where I am you just need money to host my code
... you could have a hosting service that doesn't collect card and billing address but basically says "if you pay to this account, I will keep your hosting service going"

<manu> Ian: It's not that I doubt what you're saying... I'm just not certain how account-less it is? For example, I still need an ILP account.

<manu> Ian: It sort of says: If I'm able to pay via ILP, then I need an identifier.

<manu> Ian: When you phrase it that way, it is more about anonymity, again -- I realize you say there is a potential for use cases -- but there are many more services that are more sensitive, where you need to be more strongly identified.

AdrianHB: We are talking less here about ecommerce and more about digital services

<manu> Evan: This is more about digital native services... put money here and we'll deliver the service to you.

AdrianHB: ...as long as money arrives in an account, the service will be provided
... alternative to ad-based

Evan: In many cases today, models are ads or data collection
... if you could enable frictionless payments, I could pay very small amounts of money for a service
... the money might be small to me, but better than ad revenue
... a lot of people for a long time have talked about micropayments on the web...obstables have been (1) automation and (2) interop
... you don't want to manually have to click to make payments
... another use case is to replace marketplaces with P2P payments
... another use case is new tools for web and game developers
... even more out there possibilities:

- payments iwth any asset, exchanged in real time

scribe: ILP could enable real-time currency exchange
... if you quote me a price in your unit, I get a quote for how much it will cost me in my units

- salaries streamed on a per-second basis

<manu> Ian: There is a theme around compressing space and time that all technology seems to do

<manu> Ian: it would be interesting to explore other ways in which compressing salaries in time, where I'm not working in a chunky fashion, but rather a streaming one is interesting. Wondering what else fits?

Evan: Could imagine paying for gas or electricity via streaming payment
... "I will keep filling as long as you keep paying"

<Zakim> manu, you wanted to note insurance coverage payments.

IJ: You should do your own ILP beer and connect it to ILP

"ILP IPA"

dezell: How do you optimize the size of the streamed payment? Does the stream go in real time?

Evan: Yes, in real time...streams are not stored
... average speed is 1 second or less
... some of the things I'm thinking about now is how to deal with latency introduced through physical network distance
... I think we will bump up against physics
... regarding packet size optimization....
... this is one of the things that the ILP transport layer does
... it is responsible for how quickly to send and how much money to send in each packet
... one variable considered is "max packet amount" supported by a particular path
... another variable is congestion control...you don't want one app sucking up all your payment bandwidth
... it tries to send packets as quickly as possible but will back off if "too fast"

<Zakim> manu, you wanted to note insurance coverage payments.

Manu: Insurance coverage seems like a good streaming use case

Evan: We've been looking at use cases where people are looking for different business models

<AdrianHB> dezell - The major change with ILPv4 was a change in how nodes handle an ILP packet with respect to the underlying system (ledger) that the money is moved on. In ILPv4 we treat ILP packet as the equivalent of an auth in the card world. Nodes will forward packets on behalf of their peers and will then be paid for those by that peer either per packet or in batches but those settlement payments are bilateral so don't impact the speed of the payment itself

<Zakim> manu, you wanted to ask what's next for ILP

Manu: Sounds like a lot of core technology is being worked out...are you trying to finish the technology? Are you waiting for some killer use cases?

Evan: There are several threads of work:

- core ILP protocol was finalized last year

- now trying to finalize the transport layer

- finishing the application stack

- we have integrations with 3 different blockchain networks; would like to expand that

- identifying initial use cases

scribe: streaming media, news orgs, blogging platforms, etc.

<manu> Thanks for the presentation Evan! Great progress :)

<manu> Ian: Which parts go to IETF, which (if any) go to W3C? AdrianHB brought forward an ILP payment method. Not a lot of review yet. What are the priorities and time scales for WPWG?

AdrianHB: We are basically prototyping around payments apis and testing our current payment method draft
... part of the reason we've not yet pushed for review in the WPWG is that we want to have some working demos

<manu> Ian: TPAC comes to mind, there are a few ways to think of that - next big demo in Lyon? Or can we make payments in Lyon?

AdrianHB: ILP value goes up with network size
... now that ILP finalized, we are seeing network growth

<manu> Ian: If we follow the trajectory of the Internet - "fake money" is the next ILP challenge? (joke)

Next meeting

IJ: We are still working on dates; we will take to email