Meeting minutes
[slide 2]
[slide 3]
[slide 4]
[slide 5]
[slide 6]
[slide 8]
[slide 9]
[slide 10]
[slide 11]
[slide 12]
[slide 13]
[slide 14]
[slide 16]
[slide 17]
[slide 18]
Rick: I'm Rick Byers, engineer director, my team includes payment request
… when we designed payment handler, this included spurring innovation for payments
… there are a few integrations today, but not lots
… I know the web monetization model of streaming doesn't work with payment handler
… but the new one-time payment, I would love to know if payment handler wouldn't work for this
… we haven't had anyone doing that as scale yet
Uchi: we tried the ability to send tips to web monetized web sites
… will have to look more at that to know if it's using payment handler
… it works by sending a user-defind amount tip that gets sent to the interledger endpoint
… it can be sent in any currency
… what I'm really keen to talk about how we can work together to see how web monetization can work with payment handler
… our head of engineering for the interledger foundation is here
Alex: the current version of the spec has been developed in the CG
… we haven't looked at how it could work with payment handler
… we've been focusing on crystalizing the changes Uchi mentioned
… I feel we should be done with that work just after TPAC
… this whole web monetization provider scheme works on micropayments
… where the user can afford a few cents to read a blog post or watch a video
… PaymentHandler isn't really great for micropayments
… whereas Interledger Protocol is built for it
… when we're looking at tipping with bigger payments, Payment Handler is a better candidate for that
Rick: to what extent is the installation of a web extension is a barrier? esp one that can read any web site?
… has an extension be good enough on desktop?
Uchi: it's still very early, so users are willing to install the extension to experiment
… but we want to get to a stage where web monetization is built-in in browsers
… and the user can sign up to their payment providers from their browser
… with the goal that the payment provider can't know which web sites is being visited, how much is spent on it, etc
Rick: so, not a major barrier yet, but want to avoid that
… I want to make sure the right extensibility hooks are available in chrome to allow that innovation
Alex: one of the limitations it the granularity of permissions for Web extensions in chrome
… we've built the extension to be as privacy-preserving as possible, but we need to ask very broad permissions in Chrome
… (better situation in Firefox)
Rick: if you think that matters to your user base and would help with adoption, I would be happy to help submitting a feature request to the extensions team
… esp if the firefox system has a better system
Uchi: let's follow up on this
Richard: you've mentioned that a few cents is not a lot for people in countries with high income levels
… I'm concerned with the inverse situation where micropayments would be required to access a lot of content
… this could lock out lots of people in poorer countries
… who couldn't afford to pay for the content anymore
… it would help if it was possible to make it cheaper depending on the countries the user is based in
… can that be addressed within the privacy constraints you operate?
Uchi: I agree we want to build a Web anyone can afford the content they enjoy without locking people out
… the current subscription model for Coil Web Monetization is $5/month - how that gets split across the different sites: the 1st hour on a site is 36c; once I've reached ~$4.x, smaller payments are sent to web payments creators
… I don't have to pay additional money to keep enjoying Web monetization
… it's one model from one provider
… the idea that additional providers could come together to provide different services with different models
… e.g. adapted to different localities
… $5/month can be a lot for some countries, but there is room for additional providers to build other types of subscriptions
… while still allowing people to enjoy web monetized content
… it's still early, and we're encouraging innovation in this space
Richard: thanks - I still worry whether this means an end user would need to contract with many web monetization providers
Uchi: this is being discussed in the Web Monetization repo, under the "multi-pass" name
<Ian> [Note also there are more sessions on Web Monetization and Interledger this week]
Alex: the new spec thinks of Web Monetization as a feature of the browser
… different providers can offer different models
… all of those use cases could be enabled by different providers without having to change the spec
Andrzej: do you consider storing/providing user data in some way, even as an option that a user have to turn on in their config, so I, as a game developer, can recognize it was John who played my game for 5 hours instead of a random paying user? I could use his avatar in a game, or put his details on a leaderboard, and interact more, instead of having no idea who visits my games (considering all the privacy concerns) [from the chat]
Uchi: providing additional value based on the amount payed for a game
… we don't want to store any data at all
… instead of building data storage in the web monetization spec, we expect each app to store data in the browser
alex: if you wanted to do it right now with Coil, every time you get a progress event which you can use to keep track
… Coil is making lots of efforts to not get any visibility on this
… as a developer, you could use fingerprinting - not saying you should
… you can keep track of how much payment streaming has happened
Andrzej: I agree with the privacy concerns; but from a game dev point of view wanting a patreon-like community,
… allowing to customize the experience for / reward frequent users would be good
… probably more a request for Coil than the protocol
uchi: a follow up on this might be to create a task on the WICG repo, where I'll bring on Ben, Adrian, Marcos to discuss how this could be done
: Web Monetization issues on the WICG repo
Uchi: Dietrich commented on the payment request API in the chat
Ian: we've been chatting about opportunities to open up the safari ecosystem
… we've had meetings with other payment providers for cross-browser payment apps
… Apple has heard the input from these providers but haven't changed their take on opening up the payment request ecosystem
… I'm open to other ideas on how to change the situation
Uchi: reading from the chat, question form DKA: "have you talked about the environmental impacts of the distributed ledger ecosystem? "
… we haven't discussed that topic
… interledger and web monetization isn't restricted to distributed ledgers or specific currencies
… the interledger protocol is built like TCP/IP - any currency, any ledger, banks, payment providers can become settlement engines and nodes and connect to interledger
… despite its name, interledger is not limited to distributed ledger systems
Alex: "ledger" is associated wtih crypto nowadays, but it's a more general accounting term
… interledger connects two ledgers (incl a regular bank account)
… this can includes distributed ledgers, but the protocol is currency agnostic
… designed to accept any currency and convert it to any other supported currency
… there is nothing tied to crypto
DKA: I knew some of that already; I'm a Web Monetization content provider with my personal blog
… in practice, if you want to use this system, you have to use a crypto wallet today
Alex: the network wallet can accept 96 currencies
… I'm receiving money from Web MOnetization via Monzo (?)
… we would like to get more nodes in the network, incl from banks, directly from the interledger wallet
… we need them to provide additional payment pointers
DKA: thanks, that helps answer my question