W3C Interview: Coil on Interledger Protocol and Web Monetization

In June I had the pleasure of speaking with Coil CEO Stefan Thomas about the Interledger Protocol (ILP), and Coil's vision of using it to support "Web Monetization," essentially bringing micropayments to the Web as an alternative to advertising and subscriptions.

Ian Jacobs (W3C): Do you think of yourself as a "payments guy"?

Stefan Thomas (Coil): Interesting that you should say that. I think of myself first as an open source guy. Payments have been my focus for the past nine years, but from the perspective of applying open source and open standards to payments.

Ian: What problem did you perceive needed to be solved that led you to apply open source to payments?

Stefan: I used to work at a Web agency in London. I remember one of the big problems we had was how to pay freelancers all over the world. It seemed very silly to me that something that is essentially just moving bits and bytes should be so difficult. Why is it so hard to decrement my balance in London and increment someone else's balance in Pakistan? That shouldn't be so hard. When I found out about Bitcoin, that was the first time it felt like somebody was trying to solve this problem in an open source way. So I jumped on that bandwagon, but quickly learned how little we knew about payments, and how much more there is to it. So I spent the next eight years learning and getting up to speed.

Ian: I am also new to payments. When I started I also thought it would mostly be about counters. People in the payments industry laughed at me and said, "It's not simple. It's about distributing liability, and fraud mitigation" and things like that. I was quickly humbled. Once you moved past bits and bytes, what stood out as making payments hard or complex?

Stefan: I would push back on that: I think payments themselves are simple. There are nuances, but I would not call these complexities. At the end of the day, the core is just moving balances up and down. But there are a lot of ways to build payments systems that seem reasonable, but are the wrong way to do it. For example, when we first got into it we thought the faster you can move the money, the better. As it turns out, there are some pretty good reasons why you may want money to move more slowly. If you have a million dollars moving one way and a million dollars moving the other way, you can do that almost for free because those transactions cancel out. Money is fungible and you can net the flows. But you can only do that if there is a settlement period. And so real-time payments turn out to be more expensive than non-real-time payments, and oftentimes that's not worth it.

Ian: That sounds like an engineering or business optimization more than something to address a social need like reducing fraud or managing chargebacks. How do you build support for those features into a payments system?

Stefan: I think that payments were treated for a long time was as this one thing with many aspects to it. With the Interledger Protocol (ILP) we've tried to be much more deliberate with where one layer starts and one layer ends, and the responsibilities of each layer. Our approach is very much inspired by the TCP/IP stack and the Web platform and other successful standards that have had to tackle very multi-faceted problem areas.

Ian: Could you describe how that layered vision for payments has evolved over the years?

Stefan: My initial hypothesis was based on thinking that the reason payments are expensive and they suck is that there are middlemen, and the middlemen take a large cut or are doing a poor job. That was definitely challenged once I spent more time working with people from Mastercard, Visa, and so on. They are really good at their jobs, and it's not like I can point at those systems and say, "You're using an outdated this or that." These are well-architected, and battle-tested systems. And on the flip side, with Bitcoin, we eliminated middlemen, but as soon as the network started to get popular, the transaction fees went up anyway. We thought the transaction fees are only there because the middlemen are so greedy. But with Bitcoin there are no middlemen, so why would the transaction fees go up?

Ian: Why did they go up?

Stefan: To understand why something is expensive you have to ask, "compared to what?" We wondered why it was expensive to send money around compared to sending data around the Internet, which is cheap. I don’t think it is because there are middlemen; I think it’s because payment systems aren’t forced to compete in the same way data networks are.

Stefan: If you want to make Bitcoin more efficient, you have to change it. To change it you have to get everyone already using it to change the software they are running. This makes every change to the system a huge political process and a huge lift. Now compare that to the Internet. If I want to run a faster version of WiFi all I need to do is buy a router that supports it, and a device that works with it, and I can still be connected to the Internet. Inter-networking means each network can run differently and they can still connect to one another. Each network can use different technology in order to meet different use cases. Ethernet is an efficient, ubiquitous network standard, but if I want to get Internet access on an airplane, an Ethernet cable dangling from the plane just wouldn’t work. Better to use a satellite network. Or, if I want to get Internet to a hundred devices in a stadium, I might use WiFi. To have Internet in a rural area, I might put up cell towers. All the complexities of moving the data around are confined to the lower layer, and yet everything still interoperates through the Internet layer. That's what really drives down the cost. If I am an inefficient Internet Service Provider, people will go elsewhere since there are lots of people offering the same service: access to this shared network. Bitcoin is still just a network, not an internetwork. That's how we realized we needed to create something like Interledger.

Ian: Interledger connects disparate payment networks. Based on your comment a moment ago, it sounds like you need competition among the networks (Bitcoin, Ripple, Ethereum, etc.) to drive down costs.

Stefan: At the end of the day, for something to be efficient it needs to be able to take advantage of advances in technology, advances in thinking, trying different approaches and using the one that works best, and being able to optimize for different use cases depending on the context. The Internet is an abstraction layer for how data moves. This allows me to code an application against TCP/IP or the application layer protocols and not have to care about what kind of network my users have. I can even support networks that haven't been invented yet without changing my application. My application is forward compatible to some WiFi standard in 20 years that I can't even conceive of. That's the power of the Internet abstraction layer. But if I want to make an app that uses payments, I have to code against a specific payment network, like PayPal's API or Bitcoin's API. If that network ever changes, my application will break. Any my app won't work if someone uses some other network my app doesn't know how to deal with. On top of all that, even if the API is the same --for example if one of my users uses the Bitcoin network and the other uses the Bitcoin Cash network-- those users can't pay each other. The Internet solves all those problems. We wanted to apply the same concepts to payments.

Ian: You make a good case for abstractions and open standards. But there are two hard problems: getting the right abstractions and convincing people to use them. How do you attack those problems?

Stefan: I would add a third problem: you don't want your abstraction layer to become outdated, otherwise you are back to the same problem as before where you need everybody to upgrade. I think to solve these problems you need to keep your abstraction layer simple. It should have as few opinionated decisions as possible and should leave as much as possible to either the application or transport layers above, or the physical layer below.

Ian: I've heard this called the "principle of least power."

Stefan: In the case of Interledger, a fundamental concept is "I'm giving you something." Interledger does not have an opinion of whether that something is coming from a balance, or is the result of a flat rate subscription (which is how Coil works). Evan Schwartz has a great blog post on all the things we took out of Interledger in the name of the simplicity principle. We ended up with just three essential parts of an Interledger packet:

• Address - where to send the money
• Amount - an integer; how many units you are sending
• Data associated with the transaction

Stefan: That would have been all we needed, but we had to solve one more problem: people tend to want to keep units of value for themselves. If I send packets of money on the open network, there's a chance that someone that money passes through will just keep it. It can be pretty subtle, like an Interledger service provider whose system is down and is thus making a lot of money because packets are coming in but not going out. That provider might be a little slower to fix the problem. So we had to deal with the incentives problem, which payment systems in general struggle with. This is the reason corresponding banking is so strict and so hard to get into: everyone in the system has to be trusted to diligently pass on the money. So to make Interledger an open system, we had to solve the incentive problem. We did that by putting all the packets on hold when you are sending them, and having a return path where the actual obligation is created. This does make each packet stateful, which has a performance penalty. Fortunately we don't need to send quite as many packets as the Internet. But solving this problem required us to add two more fields to the packet: a "condition" to securely identify the return packet and an "expiry date." It's hard to imagine what you would take away to further simplify. One decision that is somewhat opinionated is the choice of hash algorithm. After more than a year of discussion, we picked something (SHA-256) that we thought was available on many platforms, well-vetted and as future-proof as it can be and ran with it.

Ian: How do you make the business case to use Interledger?

Stefan: That question will lead us to Web Monetization. We were thinking about ILP as this great protocol we had in the lab, and we were wondering how to bring it out into the real world. To answer that question it helped to look at the early days of the Internet, and what people used it for. Most of the use cases were compelling because they were difficult or impossible to do using existing technologies, things like file sharing, newsgroups, and email. One common characteristic of these use cases was that you needed to communicate with lots of different people fairly often but with relatively small amounts of information. Applying that to money: where do you need to send small amounts of money to different people, with high frequency, ideally crossing borders? And what use cases demand an open standard? There are contexts like remittances where people don't really care that much if it's open or not. They might care about fees and speed but not really openness. For us one use case really stood out that required an open standard: today if I browse the Web there's no way to pay for a search result or an article or one second of a video. If you wanted to do that, you would need a way to send a tiny amount of money to different people, with high frequency, often across borders. So this seemed like the perfect use case. And the opportunity comes at the right time:

• People are having lots of conversations around privacy, which ties into monetization because of targeted ads.
• We are seeing increased use of ad blockers. There's not a day without some story about a site blocking ad blockers, or someone like Google no longer allowing ad blockers. It's an ongoing arms race. The reason is that the incentives of the user and the incentives of the Web site aren't really aligned that well.
• Netflix used to be the one video streaming service that everyone had and it had everything on it. Now everybody wants to run their own video streaming platform. The subscription model worked really well up to this point, but it has a big flaw. It doesn't scale well to having lots of independent providers.

Stefan: Between subscriptions and the economies of scale in the ad world, we've seen massive consolidation of the Web into fairly few platforms. A large percentage of traffic on the Web has been captured by a small number of sites: ads and subscriptions work better if you are a huge network. But a lot of people don't like that, so it felt like having a third monetization option that scales linearly instead of exponentially would be really valuable.

Ian: How do you get people to start using it?

Stefan: One of the nice things about Web Monetization is that it is pretty simple to adopt. All the Web site has to do is include a <meta> tag. All the user has to do is pick a provider (like Coil) and sign up with a credit card. It doesn't take that much for people who want to experiment with it.

Ian: What approaches are you taking to get both sides to adopt this?

Stefan: The first and most fundamental players that needed to adopt this are the wallet providers. We chose content providers with US bank accounts as our first target audience. So a few months ago we announced a partnership with Stronghold, which has capabilities to make payouts to US bank accounts. That was the first big hurdle that we got over. Now we are working to reach content creators and content platforms. We’re looking for sites that are passionate about the Web, and who are not too tied up with existing business models so they can try something different. We have found that there is a surprising appetite for this, even from companies where there is a risk of cannibalizing other revenue streams. They view it positively, and I think that is due to the urgency of the situation with those other streams. Ad block rates are high and rising. We've talked to Web sites that have ad block rates of 60%. The other day we were talking to a gaming site that has ad block rates of 80%. If you are losing out on 4/5ths of your customer base not generating any revenue whatsoever, that's a strong argument for you to try this. If you can convert even half of those users, you are doubling your revenue base. Tech-savvy users are the ones who tend to use ad blockers, so Web sites catering to those audiences tend to be hit hardest by ad blockers. I think that they will be the early adopters. These are also the folks who tend to care about the Web, and, being tech-savvy, they are more likely to be able to adopt the technology, so that aligns well.

Ian: Web Monetization supports streaming payments in small packets...

Stefan: One note on that: we made that architectural choice of payment switching using small packets not because we were interested in micropayments, but because we wanted to handle a wide range of payment sizes. Today, the companies that handle large payments are different than the ones that handle small payments, which means there are different paths for different size payments, making the routing protocol ridiculously complex. We looked to the Internet protocols for a solution: quantizing the problem by breaking large files into small packets. Also drawing from the Internet architecture, the packets don't know about each other. We've developed a higher level transport protocol called "STREAM" which introduces the concept of "data streams" and "money streams"; this is Interledger’s TCP equivalent. It handles things like resending money packets when they get lost, managing exchange rate fluctuations, and so on. On top of that you can build different application-layer protocols. This architecture comes back to my earlier point: the protocol for transferring value is simple; the complexity comes from the diversity of use cases. You can use different application protocols to meet different use cases so you don't need to complicate the underlying standards.

Ian: The streaming approach seems to lend itself to time-based content like video. But what about content like articles in a newspaper?

Stefan: Note that the rhythm of the payment is not dictated by Web Monetization. A web site tells the browser where people can pay to, but not how much to pay or how often. It's up to the browser and providers like Coil to figure out how to pay, and to give the user the best user experience. Suppose a newspaper site has articles that will unlock once you’ve paid $1. If a Coil user visits that site, we will try to make a determination: is it worth spending $1 of that user's money in order for them not to see a paywall here? Obviously, if your budget is $5 you're not going to get hundreds of dollars worth of content. Where providers like Coil will compete is on how intelligently we can spend the money and give the user the best possible experience for their money.

Ian: Thank you for clarifying. So do you think people will use this to pay for articles or other content that is not time-based?

Stefan: There are two ways to look at articles. You know how on some sites the site gives you an estimate of how long it will take to read the article? So the article loads right away, but you assume the user will spend a certain amount of time on that page, and thus the content provider could make a certain amount of revenue. In theory, you could even have the article load paragraph by paragraph as the user is streaming funds. Or, the site could unlock the article once a certain amount has been paid, which would incentivize providers like us to pay out that amount right away so the user doesn’t have to wait.

Ian: Are there opportunities for advertisers to leverage Web Monetization?

Stefan: I think there are huge opportunities. There is a spectrum from cheap-to-produce content all the way to the most premium content (think "Avengers: Endgame"). A good place to start may be content that you don’t charge anything for but perhaps you allow people to tip you. The next level up would be content that’s currently monetized with ads, such as smaller publications and blogs. After that, there is a bit of a glass ceiling because the next step up is the subscription model. But to get to the subscription model a site needs to be a lot bigger and have a lot more premium content than your average ad-financed site. That's the gap that we think Web Monetization can fill. I think it provides an option that would be incredibly attractive for all the smaller Web sites that are trying to get into slightly more premium content.

Ian: I like that idea. Suppose I'm watching Amazon Prime and I see a movie available from Starz but I don't have a subscription. I would love to be able to push the "Watch this now" button and pay on the spot because I'm not ready to subscribe to the full service. Surely there is some way for these companies to negotiate a sweet spot.

Stefan: Walled gardens —going all the way back to AOL and Compuserve— are annoying for content providers. They have to maintain all these relationships, and different versions of their content, and they have to negotiate pricing every time. The idea of the Internet was to create an open pool where creators could provide content and services, and service providers had access to that open pool. Initially the pool was not as attractive as AOL, but eventually it became big enough to become more interesting than what any commercial provider could offer, and suddenly it became the most interesting pool. The result is that the providers that don't have the expense of having their own content and growing their own content pool suddenly do much better. That's because people start to care about "Internet access" and not the value added on top of that.

Stefan: This hasn’t happened for premium content because the open Web hasn’t had a monetization model. But the same rules apply, which is why we expect Web Monetization to catch on quickly once it reaches a certain critical mass. As soon as you can get content through Web Monetization that is similar in quality and quantity as what you can get from a subscription service like Disney+ or YouTube Premium, suddenly it becomes a very attractive alternative. A lot more of the money would go to the actual creators so more and more creators would want to offer their content on the open system. At that point, it snaps over so that if you are a provider that tries to get exclusive content and put it behind a wall, you're just spending a lot of money for not a lot of value-add compared to all the stuff that's in the open system. I think by being out there early with an open standard, we have a chance to build that out before any proprietary provider has a chance to own it.

Ian: Where can an early adopter play with Web Monetization?

Stefan: For people creating content, the simplest thing would be to get an Interledger-enabled wallet and put the Web Monetization <meta> tag on your site. If you don't have a site, then you can also post content on a Web Monetization-enabled platform: There is coil.com for articles and Cinnamon for videos. We’re also working closely with Imgur on creating a way to get paid for sharing images. Hopefully, there will be many other platforms available soon!

Stefan: For people who want to consume this content, the easiest thing is to sign up for Coil (currently available for Chrome and Firefox). If you don’t mind getting a bit technical, there is also an open source browser extension that implements Web Monetization without going through Coil.

Ian: W3C holds its big annual meeting in September: TPAC 2019. I expect between 500-600 attendees. I also expect to hear a lot about Web Monetization then. What are your goals for that meeting?

Stefan: Our goals are to introduce this technology to the broader Web community and stakeholders such as browsers, Web site developers, users, merchants —everybody who has an interest in the Web. We think this will impact a lot of different things. For example, initially we thought that Web Monetization might not be relevant for online shops because they are not selling "content." But we've found that Web Monetization might let smaller merchants compete with Amazon’s “Prime” subscription: Users who show up with Web Monetization might pay a little money to browse the store front and in exchange get free shipping. We look forward to discussing these and other interesting possibilities at the event!

Ian: Thank you for your time, Stefan, and see you at TPAC!

From time to time W3C conducts interviews of its Members; please contact me if you are interested.