Stefan Thomas slides (PDF version)
AdrianHB: Ideas on streaming and monetization
stefan: Today I'll chat about web
monetization and ILP
... Biggest problem today with payments is lack of
interop
... especially if you are a global company accepting payments
from a lot of different systems
... Payment Request API solves the UX problem through
matching
... but PR API does not address the underlying interop
issues
[AdrianHB indicates slides should be available after the call]
scribe: ILP intends to bridge
different payment systems
... ILP was invented at Ripple; development happening in W3C
community; more than 390 contributors; lots of contributions
from lots of different types of players
... ILP takes inspiration from the architecture of the
internet
[Slides that show analogies between Internet stack and ILP stack]
scribe: IP doesn't change
frequently and shouldn't have; high cost (e.g., move to
IPV6)
... in the ILP stack, the Ledger layer (blockchains, banks,
mobile money, digital wallets) is like the underlying network
protocols (e.g., bluetooth, wifi, etc.)
... the ILP protocol aligns with IP
... the transport layer in ILP (IPR, PSK, Stream) encodes
frequently used functionality
... the Stream protocol does many of the things that TCP does,
such as retransmitting packets, reordering packets, etc.
... and then you have different application layer
protocols...e.g., generic HTTP equivalent would be SPSP
... continuing with the analogy: an IP packet has an address,
an ILP packet has a (global) address
... ILP "amount" is local to a given hop; it can change as it
goes over the network.
... the ILP network layer relates to settlement
... the ledgers maintain state
[How ILP works]
stefan: A connector forwards ILP
packets from one party to another
... the parties can have balances in different ledgers
... rather than making a transaction for each packet, it's
usually a net settlement
... this allows you to use relatively slow ledgers
... you can exchange lots of packets and eventually aggregate
them into a single transaction
... ILP packets can be settled on any ledger or even with
cash
... so you don't say "ILP supports ledger X" it's rather that
two parties choose how to settle with one another, and ILP
integration is how you make a payment on a given ledger
type
... there may be multiple hops to connect two end parties
... b2p-inspired routing protocol
... one issue is incentives, so ILP supports model where either
everyone is paid or nobody is
... ILP addresses this with two-phase execution
... phase one is "prepare"; packets forwarded and hold placed
on money
... only the receiver can trigger the second phase, where the
hash moves in reverse order back to the sender
... this means failure is not rewarded in phase one
... and failure is punished in phase two
... this addresses the trust problem, and allows connectors
that may not be "bank level trustworthy) but can participate in
the ecosystem
[Streaming payments]
scribe: the Stream protocol can
stream both data and money
... it has several good features, e.g., you can have a single
connection but within that multiple streawms
... you can send money on a stream
... you could make a request on one stream and send money on
another
... in our design choice, we focus on small packets of
information. Large amounts are built from smaller packets
... Stream inspired by QUIC
... on the Internet, large files are split into smaller
packets
... those packets are roughly the same size, and can be
reasoned about in the same way, whether part of a small file,
large file, video stream, etc.
... we call this "penny switching" (compared to "packet
switching)
[Applications]
- Merchant checkout demo
scribe: payment streams to
merchant
... in our demo, the backend drops packets randomly and changes
exchange rates randomly
... but Stream can still handle those conditions
IJ: What are you paying from and to here?
Stefan: Both parties using
5bells.
... the settlement might happen later, so the user experience
would not change if the parties were using different settlement
approaches
- Micropayments
scribe: fixed costs can make some
types of payments unviable
... but fixed cost low with ILP so we can more easily do small
transactions
<AdrianHB> ... we started to think about the use cases for micropayments
<AdrianHB> ... the internet economy is incomplete. It's a "Barter Economy". There is no way for me to pay for services as I use them
stefan: On the internet, we have
user some way to provide value back to the site, e.g., ads,
surveys, bundling content
... all of these "hacks" (of matching value propositions) haver
issues
... some examples: (1) dominance of marketplaces...a few large
portals
... the reason is that a lock of these workarounds work a lot
better at scale
... the internet protocol is good at making it cheap to publish
information, but there has not been a protocol to make
monetization cheaper
... often the data you are providing is the value to the
service
... back to the "double coincidence" problem: some people are
fine sharing data, others are not
... ads create a terrible user experience
... users increasingly using ad-blockers or opting out of
ads
... the ultimate solution to the barter problem was MONEY
[Demo: Streaming micropayments for content]
scribe: demo is of a blog ...
without ads
... the blog uses "Web Monetization"
... you put a meta tag in your content that is a payment
pointer: where you can receive payment
... the payment pointer is an address for (ILP) payments
... so my browser streams money to the site
... in the case of Coil (the company) our customers pay a flat
rate.
... Coil sends money to the blog
... but user can change providers (e.g., not Coil)
... and you don't have lock-in
stefan: One motivating use case
for ILP was around smart contracts
... we think of ILP as a fundamental primitive for moving
money
... we can built application protocols on it that move money
under a variety of scenarios (rules, triggers, etc.)
... e.g., there is a proposal for making subscription
payments...add-on to SPSP
... describes how a merchant might do recurring payments, and
how the user authorizes recurring payments
dezell: Another topic this group has covered is digital offers
stefan: We recently created a forum on interledger.org; would be interesting to post the use case there.
<Zakim> rouslan, you wanted to ask whether the concepts of streaming payments and interledger are separable.
rouslan: Thanks for the clear presentation
I have a question about the architecture. Are streaming payments inseparable from ILP?
scribe: or could other types of
networks provide streaming payments?
... suppose a newspaper wanted to introduce an ad-free
experience
... what would incentive them to go through streaming rather
than subscription?
... can someone get a streaming payment through something other
than ILP?
stefan: A key piece of Web
Monetization is that it is taking place in real time
... for subscriptions or bundles, you would probably use web
payments
... it could be an ILP payment or credit card payment or
whatever
... streaming payment good for "real time" or "optional"
payments
... or automated payments
... there might be a benefit to paying a large amount instantly
rather than small payments over time
<Zakim> danyao, you wanted to ask about new connectors
danyao: My question is about how
to get more connectors into the network
... what's the incentive, and what do you need to do to become
one?
stefan: The incentive is like
being an ISP...you provide connectivity for a fee
... early adopters may have central role as the network grows
(as has been observed in other scenarios of scale-free
networks)
... there's also a role for community members to run connectors
... those who are enthusiastic!
... that's also similar to how the early internet evolved
danyao: In the stable state, the
primary revenue of a connector comes from connector fee?
... does that suggest it will be commoditized due to
competition?
stefan: Depends on the type of
connector. E.g., today's wallets (*Pay) may have a special role
since user facing and sticky
... might also find some payment networks...they could become a
country's de facto value service
... depends on each market
... then you have "backbone" / wholesalers...most likely b2b
rather than end users
... more likely to be commoditized (like ISPs) but economics
depend on scale
... finally you have the merchant side, still b2b (e.g., like
acquirers today, e.g., Stripe)
... the economics will depend on local market conditions how
competitive it is
IJ: What is most likely use case? E.g., I get video through Netflix .... is this a leveler for other types of content providers?
Stefan: That's what I spend most
time thinking about. It's not really super-dependent on the
medium (audio, video, app, etc.)
... what's more important is who is the user and can we get
enough content providers to make it worthwhile for the
user
... the challenge is providing enough value to the user so they
sign up
... ultimately there will be a race between open solutions and
proprietary solutions
29 April
AdrianHB: My presentation will
focus on the latter part of Stefan's presentation
... Also will talk about more specifics about browser
functionality