<dezell> I'm not seeing the Webex activated yet, however
<scribe> Meeting: Web Commerce Interest Group
<scribe> Scribe: Ian
[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
"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)
IJ: We are still working on dates; we will take to email