Meeting minutes
I was late to join. are we scribing here or somewhere else?
<Uchi> here, please
Web Monetization API
events triggered when monetization payment is received, or when the link element is loaded
<Uchi> Alex: replaced <meta> tag with <link> tag for in the new Web monetization spec
Alex: properties cover what amount and currency the payment was
… URL to the wallet to verify the incoming payment, or a receipt string for Interledger
… shipped test implementation for Coil extension, new versions to support these new features, but backward compatible
… work is in wicg/webmonetization github
… have received some feedback, but would like more feedback and see potential browser implementation
… a mobile browser native implementation (Puma), but desktop browsers just have browser extensions at the moment
… adoption on websites growing, up to 0.02% of sites in a crawl (web almanac)
… easy to make payment within one bank, or within banks that have a system to talk to each other. across different banks, there is high overhead (a human has to approve)
… small, continuous payments is infeasible
… credit card networks also not effective for this, especially for receiving small payments
… Interledger proposes a way to represent money in any type of account
… modeled on TCP/IP, but losing money is not as acceptable as losing packets
… 'ledger' is anything that stores transactions of value, but not intended to mean the crypto use of that term
… your Starbucks loyalty card is one of the largest ledgers in the world :)
… packetizes payments, but doesn't care about the currency or scale
… no minimum transaction size
David: are there implementation roadblocks to adopting ILP? because of the binary protocol, or not based on some existing system
Alex: working on application-layer protocol, Open Payments, REST APIs, so that you don't have to understand the binary/networking protocol
David: some networks only allow HTTP traffic. wouldn't want to SSH tunnel to get around barriers in a hotel network
Alex: Interledger protocol has to have a lot of options to work with so many different ledgers. but that makes it complex, need Web Monetization to be something simpler
… want to see how Web Monetization can happen in browsers
McCool: could this be integrated with WebSockets?
Alex: can be run over websockets, but requires converting into binary format
McCool: connections to verifiable credentials/did?
Alex: addressing -- URLs feel natural for that
… every ledger will have different requirements for identity and credentials
David: counterparties are always known. if you're willing to pay, you are identifier to your payment provider, and that information is confirmed?
… you don't need to establish the payer's identity at the moment of the page load
Alex: but privacy protection, the receiver does not know who the sender is
Alex: Coil decreases rate of streaming payments so that payments continue and don't run out
Alex: trust the browser to break up the funds and send it to the right parties that the user wants
<Zakim> npdoty, you wanted to comment on streaming vs other kinds of transactions
<Ian> npdoty: Can this be used for non-time-based activity?
<Ian> Alex: Yes
<Ian> ...it's designed for both streaming and chunks
<Ian> npdoty: Is this intended to replace PR API / PH ?
<Ian> Alex: It's a complement.
<Ian> npdoty: I can see some activities gated on payment "You can't get this until I have confirmed receipt of money"?
<Ian> Alex: You get a receipt so you can verify a payment
<Ian> ...you still have to do work to verify the payment depending on what's in the payment
<Ian> ...I think pages will use both payment handlers and Micropayments depending on size of payments
<Ian> ...a byproduct of using ILP is currency conversion
<Ian> ..when value hops to a network that can do the currency conversion, the amount can be deposited in one currency and then sent out in another currency.
<Ian> ...networks are incentivized to keep conversion fees low (competition with other networks)
Steven: (from Google Chrome payments team) how should web monetization providers integrate with the browser?
Alex: extensions might be a way to do that. configuration of a payment provider could be done with a payment extension
… if I'm a provider for this user, this is how I would want payments to work
Steven: dangers of browser extensions. if there's a malicious payment provider that convinces a user to install an extension, could that malicious provider then track the user's online activity?
Alex: envision a different kind of extension, like themes. the payment provider shouldn't have access to the page, leave it to the browser to packetize the money and distribute it
… wouldn't want to give up the privacy aspect, even for legitimate providers
alex: responsibility of the browser to let the user decide how much payment goes where
… payment provider has lost the ability to track where the payment has gone
smcgruer: the question is whether the browser wants to maintain the complex configuration of how the user wants to distribute funds
smcgruer: for tips or soft/hard paywalls, how can the page specify a minimum amount of money necessary for this?
… the page has some content in the page saying "this needs a dollar" and the user clicks it
alex: uses HTML to visibly represent that it needs a dollar
… and then user interacts with the extension, to give a dollar with the site that I'm currently on
Ian: what's the UX to get to the extension when the user clicks a button in the HTML that they want to pay
Alex: no communication between the page and the extension, because it would break the privacy requirements
Ian: a payment handler for web monetization could have the browser help create a modal when you click a button in the page
Alex: think it should be more user-initiated. if you want a direct transaction, you could use Payment Handler
smcgruer: often content creators will give a thank you in response to tips, not exactly payment for content
alex: API is simplified in order to provide a lot of use cases, but Coil just handles the streaming use case. would like to see more providers that explore multiple use cases
Karl: for enterprise cases, or a media network, or a celebrity
… brands that want to fund sponsored posts
… not just the individual user, but how does this work for organizations getting millions or billions of views?
alex: haven't thought much about that
Alex: at mozfest, Coil gave out a large sum, and then individuals could monetize, give tips for their favorite sessions
… not sure how that would work for Beyoncé. turning off monetization for a little while, and then making it private after the first X views
@@@: for small publishers and bloggers, how easy would it be for them to monetize their content?
… what is your feeling for the future, 5 years?
alex: as a small publisher, I make money on a computer jokes website
… don't have a lot of time to work on gated content, just drop the meta tag on my page
… Coil has maybe just 5,000 monetization users, but still made £30 last year
alex: user adoption necessary for it to make progress
… allowing anyone to become their own monetization provider could make a big difference
… testing with Firefox was extremely useful for the spec/design process
… Grant for the Web tests of people using the functionality has also explored genuine use cases, more than just a single document
… revenue sharing is important, and unlikely to ever be a fair split
… in the next year, we want more monetization providers, and test it out in a browser
Alex: currently a CG, but would love to see a WG if there's support
… Friday session at 12:30 at TPAC
likely hybrid attendance/support
[continued conversation of different use cases, or splitting monetization, but scribe isn't keeping up]
smcgruer: what about iframes?
alex: currently an even split of iframes that support monetization, but the top-level page can determine whether iframes are allowed
… you as the page creator decide what gets monetized
smcgruer: can't fund this directly right now, but Chromium is open source and would like to see proposals and implementations
alex: have funding to support it, but need someone with the experience and expertise in the browsers
… see how it would work if it *were* in the browser, even if it's not immediately going to end up in Chrome
smcgruer: interesting question is how much the browser is responsible for or how they handle it
alex: could have a web monetization server for browsers to call out to, but would be a big piece of infrastructure
karl: excited, all in about implementation. can start with simple use cases and then take it to talent. young creators use the Web so much. monetization should attract attention the way that NFTs did
… for artists to be able to say to people on the Web, this is how you can be part of our art or community
… talent who are streaming tons of views, but not getting the monetization
… collegiate sports as well
… should be simple enough for easy adoption, by the small site and by the consumer
… could donate on a fraction of the monetization for a special event, etc.
… a way to add another layer of revenue to their existing models
… proof of concepts to try out with a publisher or with talent
alex: talking with lots of publishers in the news space, like when newspapers buy articles from other journalism organizations
… could have payments split automatically between the nytimes and the smaller org