Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Manu Sporney: W3C – Making Payments a Web Standard

Episode Date: February 15, 2016

A typical online transaction today isn’t very different from how it was done 25 years ago at the dawn of the Internet. In fact, online payments haven’t changed much at all. When we want to pay for something online, we copy very sensitive credit card information into a form on a website and trust that website to capture it securely and make proper use of it. If this seems like an old and antiquated way to pay, that’s because it is, and it costs billions of dollars per year in security and fraud prevention. The World Wide Web Consortium wants to standardize the way we pay online, making it more secure, and hopefully a better experience for users. is a computer scientists and Standards Lead at the W3C. We talk about some of the core problems with dealing with credentials on the web and making online payments. Specifically, we discuss the Web Payments Working Group (WPWG), and their efforts to bring banks, payments providers and browser manufacturers together to converge around a standard set APIs to make for a better and more secure payment experience for all users. Topics covered in this episode: Manu’s interest in Bitcoin and blockchains His role in building the JSON-LD standard What is the W3C, what are it’s roles and how does it operate The level of interaction between the Bitcoin community and the W3C The fundamental problems of dematerialised payments online What it means to standardize payments online The Interledger Payments Community Group Manu’s company Digital Bazaar Episode links: Web Payments at the W3C Digital Bazaar This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/118

This is Epicenter Bitcoin, episode 120 with guest Manu Sporni. This episode of Epicenter Bitcoin is brought you by hi.com. Protect yourself against hackers and safeguard your identity online for the first class VPN. Go to high.combe slash epicenter and sign up for a free account today. Hi, welcome to Epicenter Bitcoin. The show Edge talks about the technologies, projects, and people driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kuchew.

I'm Meher Roy. Today we have a very interesting conversation lined up for you with Manu Sporny. He's a founder and CEO of Digital Bazaar and a chairman for the web payments, credentials and JSON LD community groups at the Worldwide Web Consortium, that's W3C. He spends most of his time driving the creation of open standards and open technology that will integrate linked data, open identity and payments into the core architecture of the web. So before we start, Manu, we'd like to know. know a bit more about your background and how you got interested in web standards in the first

place? Sure. Hey, thanks for having me today. My background is as a computer scientist, so I have a computer science degree. I've always been very interested in primarily computer graphics, but also decentralized systems. So I first got interested in decentralized systems, building things like render farms and server farms like that. And then later, right in my senior year of college, ended up launching my first startup. And we basically ported Linux to the PlayStation too and did a whole bunch of audio player for Linux and game development. on Linux on the PlayStation 2. And shortly thereafter, we launched one of the first online music stores,

but on the PlayStation 2, and that kind of moved us in the direction of figuring out if there was a better way for artists to be paid, a more fair way for digital content to be distributed over decentralized networks, and for those payments to be made over those decentralized networks. And for those payments to be made over those decentralized networks. So that's when we launched our current company.

So this is my third company. This company's focus, DigitalBazaar's focus, is basically figuring out a way for humankind to monetize the stuff that they do more fluidly. So, you know, our ideal world is people effectively do what they naturally want to do, right? They work on the things that they love. And as a side effect of them working on those things, there is a value dissemination structure behind it. Like they get paid basically when they sit down at a computer and write code or they get paid whenever they start writing music and sending it out to the web and making money off of it is this really fluid thing. It's not like it's today where you sit down, you write some music and there's this hard stop and then you have to go look for a public. and then there's a hard stop wait, and then you have to wait for your music to be distributed.

And ultimately, we'd like people to have a more direct control over how they're paid, when they're paid, things of that nature. So that's kind of where my interest in decentralized systems, decentralized payments, and decentralized identity came from. And, well, that's interesting because we also sort of create content that we'd like to get paid for. And we don't have direct payment from our listeners. Of course, we do have some tips, but most of our revenue comes from advertisers. So monetizing content is a topic that I had never really been concerned about up until we started episode after two years ago.

And it is a topic that does occupy my mind quite a bit, even though we don't really make any money personally from a percent of it, but just trying to pay bills and pay for the team and everything. And so what are your interests like, do you have any interests in Bitcoin and blockchain specifically? Is that something? Oh, absolutely. Yeah, absolutely. I mean, you know, there's a deep interest there. we talk quite a bit with folks in the Bitcoin and blockchain community. And, you know, honestly, like, the blockchain is, you know, I'm thrilled that so many people

are talking about this stuff that people in the 80s and 90s were talking about, right? So, I mean, like, this is like, you know, it wraps fantastic things together, like, you know, decentralized systems wrap with peer-to-peer networks and, you know, some deep, deep, cryptography, like you combine all those things together, and that's like, that's fantastic stuff. Like, that's world-changing stuff. And it's nice to see that Bitcoin finally got that conversation into the public, because this is a conversation that has been going on in the cypherpunk world, the, you know, crypto world since the 80s and the 90s. So, yeah, a very, very deep interest and deep engagement with the Bitcoin community.

So let's first start with understanding what the W3C is. Personally, I'm new to the software world myself, and Bitcoin got me in this path. So I've always heard about the W3C, but I couldn't really describe how it works and what are the past successes. So could you go into what W3C tries to do, how it does it and what has. have been successes. Sure. So to answer your last question first, the W3C standardized the web. So if you're using the web, you have them to thank for doing that. Really, you know, Sir Tim Berners-Lee is the person that did a lot of the, him and Robert Kellow, did a lot of the initial work on the idea

behind the web. But it wasn't long before they had to start standardizing things. So you got interoperability. And so Sir Timberus Lee helped found the World Wide Web Consortium back in the early 90s. And that's where, you know, the initial version of like HTTP happened. That's where HTML happened. You know, you've got SVG, CSS. Anything that you use to build the web was standardized at the W3C many, many, many years ago. So the W3C, the W3C. has grown since then. I mean, it started out as just like this handful of, you know, people and companies. But it has grown to around 400 member companies and every large technology company you can think of is a part of W3C, Google, Microsoft, Facebook, U.S. Federal Reserve, Bloomberg,

like they're, you know, the list goes on and on, 400 plus members. And basically, these members decide what the next generation web and Internet is going to look like. like. So there are really two bodies that do standardization around internet and the web. The Internet Engineering Task Force, IETF, works on protocol level stuff. That's like the base layer communication stuff. And then the W3C works on like the higher level application stuff like HTML5 and CSS3 and a variety of other technologies like that. So anyone that uses the web, all of us right now, you're on a web page, like listening to this, or you use a web page to download it. The W3C is the organization that figures out how that technology is

going to work and how we're going to get massive interoperability around those technologies. Right. I think most people don't realize the important role that the W3C has made in just making the web just usable. I mean, I remember being a teenager and right. writing web pages and creating web pages back in the late 90s and having to write, you know, this is the era, the era during which you had to specify which browser your web page would work on and that just kept going, you know, into the mid 2000s up until sometime in like late, you know, late 2000s things started to, started to coagulate and becomes a lot more standardized.

And that was sort of a nightmare era. Even though there was a W3C, there was still a lot of problems with standards that you just seem to have really smoothed out these last couple of years. Well, that's good that it looks like that from the outside. It's still rough going, you know? I'm not doing as much web development as I was, but I remember doing web development back in the days of IE6. And it was really a pain. It's gotten a lot better. Yeah, absolutely.

It's gotten a lot better. So can you walk us through? I have a rough idea, but it's always great to have a refresher of the process through which the W3C standardizes, you know, a technology, something like HTML5, for example. Sure. HML5 is a pretty complex one. Let me just speak generically. So typically you have all the W3C members, and W3C is kind of.

constantly keeping an eye out for new technologies that might need to be standardized. So there are these groups called community groups at the W3C. I think there's something like 800 of them. Like there's an insane number of them. And each one deals with something, you know, different. Like one of them deals with like pointer events. Another one deals with like, you know, credentials. Another one deals with web payments.

Another one deals with crypto ledgers, like blockchain like stuff. Another one's working on interledger. So you have all these community groups, and they're super experimental, but there are a bunch of people that are kind of saying, hey, there's some interesting technical stuff happening in this area. Let's keep an eye on it and figure out if there's something we can standardize around it.

There are other people that are saying, look, this problem exists today. Like, let's look at Canvas, the Canvas element in HTML. And so let's get together and propose a solution and get it in the browser as quickly as possible, because, for example, like video game developers are having a really hard time deploying games on the web. And if we want the web to be this ubiquitous thing,

we need to support them, right? So you get a community group together. You work on the technology. And that usually lasts. Some of these things have been incubating for, like, four years. Some of them incubate for, like, six months in launch, right? So the first stage is incubation. Next stage is to convince the W3C membership

that they should spend their effort in trying to standardize this, right? And so you have to go around and basically talk to organizations like Google and Microsoft and Facebook and Twitter and get them to agree that they're going to back, you know, the standardization around this work, that they're going to say, hey, you know what, this is important to us. So we will send a couple of engineers into a working group to work on this stuff. So that's kind of like the chartering process. So step one is experiment.

and incubate. Step two is charter the work to happen and get bind from the membership. And then step three is basically do the work. Sit down in a working group. You've got, you know, the best minds from all the top technology companies in the world sitting in there, trying to figure out the one way that we're going to implement this stuff in the browser or, you know, on the Internet in general. And then that's like, you know, an all-out technical brawl slug fest for like two to four years. And, you know, after everyone emerges all bruised and bloodied, you have like a technical standard.

You have an international standard. Like at the end of that, you have HTML5 or you have CSS3 or you have XML, right? So each one of those things went through that process. And it can be as quick as two years to get through the process, which sounds. really long, but it's really not. Like, you have to get 50 companies to agree on the one way to do thing. That's one way to do things. That's really hard. But some of them, like, you know, HTML5 dragged out for like, some people, you know, would assert that it dragged out for like 12 years, right? So it's, that's the general process. It's incubate and then launch the official work

and then do the technical work and get the standard done. that it's funny because when you look at us like when you look at HTML5 or when look at XML or any of these standards after they've come out of that process you just look at them and you think of course that of course that's how you should do it you know it seems so obvious and what seems sort of funny as well is that you know a lot of what you mentioned there is with that that period during which everybody's trying to agree on the standard it looks a lot like what's happening in Bitcoin It does echo that that same sort of process that the Bitcoin community is going through right now regarding block size and such things only maybe with less, which is less standardized and where there's less formality.

Right. There's less structure and legal framework around it. That's right. Yeah. I mean, so a lot of people don't, you know, we're. a number of us in the standards world who have been at ITF and W3C for a long time and have gone through like all the painful, painful work to just set up a process where people can come together and agree on something, right? And you don't have like five people running the show and, you know,

50 people just sitting back and you're saying, stop, please, and having absolutely no power to do anything. Like, we've seen that happen at ITF and we've seen that happen at W3C and Oasis and there are all these standardization bodies that went through this. And we're watching the same thing kind of like play out in the Bitcoin world. And many of us are like going in and going like, please, please, like follow some of the models that have been tried and true. Like we, we know how to at least set up the infrastructure where people can get together and make consensus decisions, you know, peacefully without having to do, you know, things like forking the blockchain and things of that nature. But I think, you know, part of it is that the Bitcoin community is fairly young and inexperienced

in that realm. And that's like not a bad thing. Like a lot of people think I'm kind of like, you know, saying, oh, they're, you know, they're not doing it right. But their benefits for getting kind of a fresh approach, like something that might come out of the BIPs and the way Bitcoin community is doing this stuff is a new. process around agreeing on technology. But I'm fairly skeptical that that's what's going to come out. I think what's going to come out of it is like you're going to end up taking bits and pieces of ITF and W3C and maybe there's a new standardization body for Bitcoin or Bitcoin decides to start standardizing at ITF and W3C. You know, it's hard to, it's hard to say. None of these

consensus on really hard technical, technical systems that span the globe, like global technical systems, none of them are without their warts, right? So like W3C almost really screwed up HTML5. In fact, they didn't work on HTML5. They worked on XHtml 2 for like five or six years. They worked on the wrong thing, right? I remember that. And the browser manufacturers basically broke off of W3C and were basically, and basically said, you're not solving the problems that web developers have. We have to listen to web developers. So we're going to go off.

We're going to break off into this group called the WhatWG. And we're going to develop HTML5 there. And so the spec editor for HTML5 basically was like, I'm going to rewrite the whole thing from scratch. I'm going to go over here. Once you guys come to your senses, come and let us know. Until then, we're going to start shipping new product and browsers. And that's when, like, you started seeing some of these new HTML5 features happening.

So even a community as, like, you know, in Internet timescales, as old as the W3C or the IETF, even an organization like that has problems where community, you know, the community splits for some reason. But ultimately, HTML5 was brought back into the W3C. You got buying from all these other companies, not just the browser manufacturers. And it worked out. But those types of struggles are the same types of struggles we're seeing in the Bitcoin community these days. And it's frustrating to see, like, other folks go through it and, you know, trying. And, you know, we go out and we try to help, but it's, you know, it's not, I don't think the Bitcoin community is ready yet to engage on a broader scale, right?

I think we've mentioned it on the show before that there would be some benefit to the Bitcoin protocol being part of the W3C or ITF. Do you have any thoughts on that? Is that something that would be advisable or desirable for Bitcoin? Is it near to be another standardizing body in your opinion? So, you know, I'm trying to, let's remove all the political charge from the question. question, right? So maybe it's not the W3C that's the right place, maybe it's not ITF, but there is a need for some place where people can get together and make decisions on the protocol. There is currently, you know, there's really only one software base for Bitcoin, right? Let me compare and contrast. So the web and the internet have

many, many, many different clients. There's not just one HTTP client or two HTTP clients. There are hundreds of them. And the reason there are hundreds of them is because there are standards, they're documents that actually say this is exactly what the protocol is. If you don't do X, Y, and Z in this order, you're violating the protocol. You can choose to do that, but you're not going to be able to interoperate with the 100 other HTTP clients out there, right? Bitcoin doesn't have the same thing going on right now. There are bits and pieces that are written down here and there, but there's kind of still the code base and the five core maintainers.

The W3C and ITF discovered many, many years ago in the late 80s and early 90s that it's really dangerous to have. It doesn't matter how awesome the five people that are at the core of the thing are. that is dangerous, right? Because that means that there's a centralization of power in decision making. And so the idea that you have a set of protocols that are written down and you have hundreds of implementers of those protocols, that is the only thing that I know of these days

that actually gets the right technical solutions technical and political solutions implemented. So maybe Bitcoin goes into W3C, maybe they go in the ITF, maybe the Bitcoin Foundation or Bitcoin whatever creates their own standard-setting organization. But I think the end result has to be the Bitcoin Protocol or whatever it ends up turning into is clearly documented. There's a clear set of test suites around it.

and there are 50 implementers of clients for Bitcoin, right? That's where you want to go. I think getting there is still questionable. I would imagine, like, if I had to take a shot at it, I would say the ITF is the best place for Bitcoin to go to standardize. But, you know, that's not, I don't know if that's really going to happen anytime soon. Personally, I suspect the Bitcoin community wouldn't want to go. down a path like that. Like you feel the need for governance, but then you also somehow want to

have the anarchy also. There are two ways to approach that statement, right? One of them is like the political direction and the other one is the technical direction. So the technical answer for that is pretty easy. Like build extensibility into the core of the protocol. You can have technical anarchy if you do that, right? So you say, you know, these are the ways that the Bitcoin protocol can be extended. or you come up with some kind of generalized extensibility mechanism, and go for it. Like, look at the web, right?

No one's telling anyone how to build a website. People are just sitting down and writing code and building websites, right? It's total anarchy when it gets to that point, right? But getting a webpage from point A to point B, we need to have some amount of standardization around that because we want everyone on the planet to be able to go to your site and get that page, right? But what's on that page and how your JavaScript executes?

Totally up to you. Right? So you can have the whole, you can build a really chaotic anarchist system on top of a solid foundation, a solid communication foundation, right? And that's really the point. Like you don't want to standardize too much. You want to standardize enough so that there's interoperability, but not, so much that you kill off innovation.

And that's a really hard kind of balance to mean. Now, going at that statement from a political direction, there's a lot of drama in Bitcoin, right? There's a lot of politics being played in Bitcoin. And I tend to be fairly disinterested in that stuff. I'm more focused on the technical stuff and ensuring that people can innovate and innovate on top of the technical platform. But having an infrastructure that tamps down on the drama and the politics

and gets people to focus on the technology is really useful, right? So I think the W3 and the ITF are fairly good at that. They're fairly good at, I mean, there's always politics. Anytime that there's a lot of money involved, there's going to be politics. but setting up an infrastructure where you can effectively tamp down the politics and the politics and the drama that's kind of plaguing the Bitcoin community, in my opinion, at this point. Having an infrastructure where you can do that is super helpful, right?

Let's take a short break and talk about hide.me. Have you ever tried watching streaming TV from abroad? If you have, you've probably been greeted with an annoying error message written by some idiot lawyer telling you that you have no rights and you can't watch this program from outside the country. This used to happen to Sebastian all the time when he was in lonely France trying to watch his favorite moose hockey game in Canada and you wouldn't believe how angry he got. That's where most of his gray hair comes from. With hide.m.me, this painful phase of my life is now over. When I want to watch American television or my favorite moose hockey game from Europe, I just changed my IP

address and nobody ever knows where I came from. And with gigabit connections, I have zero lag. me a try with their free plan. Their free plan includes two gigabytes of data at unthuddled bandwidth. You can use any of their free exit nodes, which are in Amsterdam, in Singapore, and in Montreal, and you can sign up for that at height of me slash epicenter. Now, if you use URL, and if you decide to go premium down the line, it's going to get you 35% off. And the premium plan gives you a lot. It gives you unlimited data. You can use as much as you want. You can connect up to five devices.

So your whole household fits on the plan. And you can use any of their exit nodes all over the world. And they've got like 30 of them. And of course, you can pay with Bitcoin. So give it a try. We would like to thank HaTotMe for their support of WebSend and Bitcoin. For this podcast, we are going to walk through two of the topics that you are involved in in W3C and I've thought about quite a lot. And for our listeners, Manu has a really nice

website where he writes blogs about many two topics like credentials on the web and payments on the web. And he has written like very detailed analyses of all of the different projects that have come before trying to solve credentials on the web and what was missing with them and why they didn't succeed. Since the Bitcoin community is also so interested in the problem of identity, we thought it would be nice to invite Manu and walk through his experiences, we're getting credentials on the web. So the first question then is,

what is the core problem with credentials on the web, and why hasn't it been solved for, I don't know, 20 years? Sure. So let's see. I think the core problem, there are many, many problems. So let's talk about identity on the web. Every time this thing kind of comes up, the problem gets bigger and bigger and bigger until we're talking about fixing identity on the web.

And the problem with identity on the web is it means very different things to very different people. It means something different to governments. It means something different to individuals. it means something different to corporations. So what you end up with at the end is trying to solve this massive, massive problem, and you make almost no, there's no traction on doing it. So the work at the W3C, and let me underscore that this is experimental work right now, there is an official task force looking at verifiable claims and credentials on the web.

And what we're focusing on is a fairly small, we're trying to focus on a pretty small scope. So we're basically saying it is really hard for people to do things like show their driver's license on the web. It's really hard for people to prove that they're over the age of 21 or prove that they have a passport or prove that they graduated from a particular school to prove that they have a certain skill set, all super difficult things to do. do online. And what we end up falling back to is just self-reported information. So if you go and you look at LinkedIn, you look at someone's LinkedIn profile, you have no idea if they actually did those things, right? It's just people self-asserting a bunch of information. So the verifiable claims and the credentials work at the W3C are focusing on how do you send someone a digitally signed claim that was issued to you by some organization,

like the Department of Motor Vehicles, in a way that can be trusted, right, in a way that can't be forged, and it kind of lives with you. It's user-centric, meaning like, you are in control of those credentials. So think about this analogy. Like, you have a wallet and you have a bunch of pieces of paper

stuffed in there. And it so happens that when you pull out one of those pieces of paper and wave it in front of someone, all of a sudden they can trust that you're licensed to drive or that you're over a certain age, right? You can't do that on the web very easily, right? I could, you know, we're in video chat right now. I could pull out my driver's license and show it to you, but you have no idea if I just like photocopied that thing on a high quality printer or not, right?

So what you actually need is a digitally signed claim from the Department of Motor Vehicles saying that I am licensed to drive, right? So that's the problem we're focusing on how, you know, what does that credential look like? Can we make that credential format the same for health care and finance and government and all these different organizations, you know, all these different market verticals? And then what does the protocol for exchanging that look like? How do you issue a credential? How do you give the credential over to someone and then where do they store it? Do they store it on their mobile phone in a cloud somewhere?

How do we make that thing privacy enhancing? And then when they go to a place that actually wants them to use that credential, how do we then prove that, or how does that organization ask for that credential? Give me your driver's license. What's the technical equivalent of that on the Internet and the web? So that's in a nutshell, that's what the credentials work and the verifiable claims work at the World Wide Web Consortium are trying to tackle. They're trying to see, should we start a standardization initiative around this?

If so, what kind of technology are we going to use for it? So, Manu, I'd like to ask that, isn't there's a problem that is nearing a solution? For example, I've seen in the Bitcoin community these companies, like, I forgot the name of the best one of them, but it's really good, their service. They basically have a way by which I can display my identity over my webcam. and they have a way of detecting frauds over the webcam. So basically if I display my driving license, it works for IDs of 180 countries. And if I'm displaying a fraud, then the server on the other side will know it's a fraud. And basically any company could integrate with this solution.

So for example, Facebook could integrate with their solution and Facebook could know that, yeah, I have a driver's license and it's just. genuine, and then they could sign the statement that they have verified this claim. So isn't this something that could be solved through machine learning and these techniques? Do we really need something at the core of the web to solve it, or is it attackable through machine learning? Let me, there are three points that you made there that I thought were interesting. The first one is there exists a company that can do this, right?

and if everyone were to just use that company, then the problem would be solved, right? So that is fundamentally anti-web and anti-internet. There shouldn't be just one company with the capability of doing that. There should be a thousand companies with the capability of doing that. Because if you have one or five companies doing that, they're going to own that market and charge terrible rates to their customers, right? We want an interoperable standard. So, you know, I tend to be fairly, whenever somebody says there is a company that can already do this out there.

The first question is, how many competitors can there be to that one company, right? And how hard it is, how hard is it for those people to compete with the company? If it takes $10 million to get to the point that that company is at, then that is not a good technology for, you know, it's just, you don't have competition in the marketplace, right? And that's primarily what the web and the internet, you know, the ITF wants. You have Google and Microsoft and, you know, Apple involved. None of them are going to cede that as a solution to that problem to a single company, right? So that was the first point that you made that I thought was interesting.

So, you know, the W3C and most of the folks, most of the W3C member companies keep an eye out for companies like that, ones that are solving hard problems like that, but tend to be fairly skeptical of the solution unless they can actually see exactly how it works in running code. Because it turns out that a lot of those companies that are making those claims, I mean, they're like, I don't know, hundreds of identity verification, identity proofing companies. that have that solution, but you dig into the technology on a good chunk of them, and it turns out that they're providing a whole bunch of false positives, as in like they say they actually checked a lot of that information, but it turns out that it's really easy to fake it. And for the ones that do actually have a good solution,

that good solution is never going to be ubiquitous and universal, unless they have an enormous jump on the market, or the large companies like Google and Facebook and Apple are willing to seed that market to them. It's too small for them to care about, right? Okay, so that was the first thing. Like, yes, companies like that exist. They're not really interesting at web scale or Internet scale unless they have a big jump on the market like Adobe did with, you know, PDF or, Skype did with calls and communication, right? There are always those unicorns out there, but, you know, by and large, they do not make for good

internet and web standards. Okay, so that's the first part. The second part was like, you know, we have machine learning, we have all these other technologies, couldn't we just apply that to the problem? And I think the simple answer to that is not everyone has access. to those technologies. So think about a community college that wants proof that you went to high school before they admit you into the community college.

That organization is not a technology organization. They know absolutely nothing about machine learning. And if who they divvy that work out to, the identity proofing work out too, if that person, you know, if that organization has a corner on the market and they're charging, you know, $15 per identity check, then that's an enormous amount of money to that community college. If there was a competitive market instead, then all of a sudden that community college can bother with doing background checks and checking to see if the digital signature on that person's credential checks out. They can do that for like pennies on the dollar instead of paying the like

$15 to $30 they pay now. Okay. And so, well, I think we can all agree that having a sort of centralized solution that, you know, is, that is IP that's owned by a company is probably not a good, a good fit for a web standard. Although, you know, PDF and Skype are some exceptions to that, as you mentioned. But, you know, there's some protocols out there. I mean, we've had on the show one name. We've also had recently a gentleman, which I forgot his name. His name escapes me right now who's working on the identified protocol. And the identified protocol does something really, really interesting where anybody can create an identity for himself or multiple identities. And then the identity is corroborated by a web of trust. So essentially, you know, other people come and sort of say that what you're saying is true. And that could be, you know, your friends saying that you are who you say you are, that you work here, that you've worked here in the past, or it could be like the DMV saying that, yes, of course, your driver's license is

valid. What do you think of this kind of system? Do you think this is a good way to solve the problem of identity online? So I'm not deeply familiar with the protocol and the technology, so I can't say definitively one way or the other. Right, but you're familiar with the concept of Web of Trust, right? Web of Trust, yeah. So let's talk about Web of Trust.

So Web of Trust has been around for a really long time since the 90s, right? PGP was the first kind of web of trust, and it didn't scale really well because of key management issues. Identify might be really interesting because, you know, depending on how they do it, having other people vouch for you is a powerful thing. But if you look at these web of trust, I'm a deep believer in web of trust. Like I wish that's the way stuff worked. I think you could get rid of a lot of middlemen if you did that. The problem with web of trust is that it's very difficult to determine who's a liar and who's not.

So if your web of trust ends up kind of devolving into you delegating who you trust to a larger organization and them delegating it up to a larger organization and you effectively end up with a certificate authority model that we have right now. Right. So we, we, now that's not to say that inevitably you end up in the certificate authority model because the CA model is a terrible trust model, right? I mean, we've got, you know, if you look at your browser and you look at all the CAs that you trust, there's this giant laundry list of them, including the U.S. and China CAs. So the U.S. on a regular basis signs things saying that, yeah, of course we're a Chinese website and the Chinese government on a fairly regular basis. certificates saying, yeah, of course, with the U.S. government, right? Or we're a U.S. base, you know, you're really talking to Google, trust us, right? So, like, the CA model's broken. The Web of Trust model doesn't really scale very well. The final solution is probably somewhere in the middle, like you choose which organizations you trust, but there has to be some amount of delegation of responsibility. So it's somewhere in the middle between the two extremes,

you know, pure web of trust and pure CA model. But I mean, I think, you know, they're on the right path, right? So the idea that you can have multiple identities, great idea. Everyone should be able to have multiple identities, one for your home life, one for your work life, all that kind of stuff. Should other people be able to make non-reputable statements about you that you or a good person or you have a certain credit score. Yeah, absolutely. That's definitely something that we need to do. Should you be in control of those digital credentials so that you only expose the digital credentials that you want to to the organizations and people that you want to? Yeah, absolutely, right? You need to be in control of the ecosystem. It doesn't need to be locked into some

kind of service provider that's going to hold you hostage, right, so that you can't leave. All of these are really good. It's a good model. The question is, how do you hit scale with it? So you can hit scale with it by being a really, really, really successful open source project like Linux, right? Or OpenStack. You can hit scale by just cornering the market before anyone knows what's going on, right? like Skype and, you know, Adobe with Flash and, you know, a PDF.

Or you can try to slug it out in the standardization route and try to get all these big companies to agree on a standard way of doing something. So that's also, you know, a potential. It does seem like a pretty, like a fairly big challenge. since you wrote an really interesting article on your blog where you go through most of the

major identity credential systems that have come and gone since the dawn of the internet and now we have these new systems coming out and in any case most of them some of them are good at certain things and while they fail at other things

and there's really there seems to be a problem just hitting all of the all of the sort of requirements. requirements for a good identity system? You asked a question, what about all these solutions that have existed before these identity solutions like SAML and Open ID Connect and Open ID10 and log in with Google and log in with

Facebook? So I think those were trying to address a single sign-on problem and they were thinking about verifiable claims and identity as kind of the secondary thing. And so, you know, they're good at what they were designed to do. They were never designed to exchange verifiable claims and prove someone's identity online. That was not the primary goal. The other thing that was not a primary goal was this concept that you would control your identity, right? Your identity was portable.

Your credentials were portable. You have to look at, like, you know, who put together, Open ID Connect. it was effectively Microsoft, Facebook, and Google. Do they want you leaving their networks? Of course not. So because of the organizations involved, the end result ends up looking a certain way, and it's not very user-centric in the end.

Today's magic word is standard. S-T-A-N-D-R-D. Head over to less-stock Bitcoin.com to sign in, Enter the magic word and claim your part of the listener award. So the other thing like Manu you have really been interested in is is somehow having a standard way on the web to send and receive payments and to standardize the payment experience for everybody in the web. Can you give us a vision for what a standardized payment experience for everybody really means

and how is it different from the experience today? What's really missing out here? The web payments work at the W3C started around five years ago, right? So it started in a community group, and we were trying to convince the W3C and the ITF that we should try and standardize the way values exchanged over the Internet. So this was pre-Bitcoin, like by... This was actually, it started before that, but this was pretty, this pre-Bitcoin, right?

And we were basically saying, we need to figure out a way, you know, paying for things online is not only a pain, but it is also rife with fraud, right? You know, if you think about making a payment online, it's kind of ridiculous from a security standpoint. You go to a website that you've never been to before. They ask you for your credit card number. you pull out a piece of plastic from your wallet, you type in your credit card number along with everything that is needed to process that credit card without it being present, and then you hit send,

right? And then you pray that it's not, that the credit cards, that you didn't just send it to someone that was going to steal it, steal your credit card. So that's the first thing that happens. The second thing is like the site that you just uploaded your credit card number two, you have no idea what their security practices are, right? And if when we found, as we found out in the Target and the P.F. Chang's, you know, break in and the Home Depot break in. Like, even the major, major retailers have no idea how to protect those numbers. Because quite honestly, there is no good way to protect those numbers, right? There are secrets that if you get that secret, it is a password into your bank account.

Anyone can use that number to pull, you know, a good chunk of money out of your account. So we were looking at this problem on the web and we were like, there's got to be. a better way to do this, right? I mean, we have really strong crypto these days. We know how to, you know, pass around tokens for payments. What if we routed payments not over these old networks, but over the core of the web and the internet? And what if we made it possible for you to pay in any currency or any, you know, over any payment network? And we built that ability into the web, right? There's no reason why you shouldn't be able to go to a store, click pay, see a total, and hit, yes, I want to buy that thing, and you not transmit your credit card numbers. There's no reason why you shouldn't

be able to pick Bitcoin as a potential payment mechanism or U.S. dollars or euro or your credit card. Like all of these things should be possibilities. It's just not built into the core of the web. So what we did is we started on a five-year journey to try and convince the W3C and banks and financial industry and technologists that we should standardize the way payments are made online. So that was kind of the genesis of that work. And it took years to convince these organizations that we should try and standardize payments on the web. How is it possible that it took 25 years to get to even just discussing it? I'm curious, like, did the invention of Bitcoin have anything to do with sort of getting that ball moving or sort of giving people inside maybe the W3C or the industry that

payments, instantaneous payments were possible and there were other ways to think about how we were paying online? So, you know, I think Bitcoin helped us. convince people that there were other ways to pay other than just Visa and MasterCard and cash, and that it is possible to have a purely digital currency and settle within minutes, if not seconds, over the web and the internet. That's what Bitcoin did. As far as convincing them to start the work, no, not really.

And the reason was because no one from the Bitcoin community came with us to the W3C, to make a case for it. And still, to this day, there is, like, not a single Bitcoin company that's deeply involved in the work, which is frustrating because we want them to be there. Like, we really, really want the Bitcoin community to engage, but for a variety of reasons they're not. And, you know, I shouldn't say we and them, there are a number of people in the group that are deep, deep believers in Bitcoin.

You know, I'm one of the spec editors for the web payments community group specs, and I made it a point to put Bitcoin in there as a payment mechanism, right? But there are people that are saying, rip it out. We don't have any Bitcoin company that's asking for us to do that. And until they join and they say that they want to be a part of this work, we shouldn't put it in there. So, like, that's one of the fights that's kind of happening right now. But going back to your original question, why did it take so long? I think there are two, there's really, there are two reasons why it took so long. The first is like we tried this in 1999 and failed miserably. Like there was this, like, I don't remember, I don't know if you remember, but there was this, you know, idea of like pepper coin and micropayments back in 98 and 99. And the W3C started this initiative to try and make micropayments and paying for content work in the late 90s. And a bunch of academics got involved.

No one from industry got involved. And it just melted down. Nothing happened as a result of it, right? And so W3C basically said, usually when you try something at W3C and it fails miserably, they're like, okay, we'll come and revisit this in, you know, five to ten years. Right. So you have to wait five to ten years to try again.

we started trying in around 2008, 2007-2008, meaning I would go to Sybos and talk about the web payments initiative. It was just a lot of just going to conferences and talking to people and saying, hey, wouldn't it be great if we had a standard for payments on the web and getting buy-in? And eventually we got enough momentum, like Bloomberg joined and the U.S. Federal Reserve joined, And at that point, like, W3C started taking us seriously. And then once we had a workshop, we got a number of banks, you know, involved. And then, you know, Microsoft and Google and Apple started showing up to the meetings. And after that, we had, you know, a decent bit of momentum.

So the first reason was there was a really bad failure in 2000, and we didn't feel like we could do anything for a while. The second reason, which I think is way more interesting, is that it was really hard for us to even have the discussion with developers that they had any part to play in this. Because payments is something the banks do. It's not something that I as a web developer, it's not something that I as a web developer do. Payments is something that the banks do. and because of that, I have no power to change anything, right? So Bitcoin changed that conversation. You know, it was, you know, for two years prior, you know, we'd go into a group and we'd be like, okay, who wants to join us?

No hands would go up. And we were like, this would change the way people exchange value over the web. It would make it so that people could work on the things that they love and get, you know, get rewarded for it just through the web. It would be this nice flow of like value exchange. isn't that a future all of you believe in? And everyone would be like, yeah. And then we'd say, okay, come and help us build this future. And they'd be like, I don't know if I know enough about payments to really do anything about it.

And, you know, it took a lot of explaining. Like, we would have to sit down with developers and basically say, you realize that payments is just adding, you know, subtracting a number from one database column and adding it to the other database column, it's really no more complicated than that, right? Well, I mean, I would, yeah, sure, but then you need to have consensus over, that's what Byzantine fault tolerance solves.

Right. Well, true, right? It solves it in a decentralized way, right? But there are centralized ways that you could solve this problem before Bitcoin. There's no reason, like, you know, for this web payment stuff to start, you didn't need Bitcoin, right?

It's great that Bitcoin's here. We definitely want to use it as part of the next generation solution. But it's the mental model that a lot of web developers had. I have no part to play in the way value is moved around the world. And I think what happened with Bitcoin changed that dynamic a bit. We definitely saw a very sharp uptick in people joining the Web Payments Community Group after all the Bitcoin stuff was going on. So the second thing was just a mindset thing.

Developers didn't think they had any part to play. Now they know that they do. And so it's much easier to get something off the ground when that mindset has been changed. So now from the mindset that developers have nothing to do with payments, we have come to this set where we have everything to do with payments and there are just too many different alternatives. So we have like cryptocurrencies, then we have like cryptocurrencies, something like Ripple. Then we have interledger, which is, which if our listeners don't know about, is Ripple's new

project where they figure out a way by which you can move value across two crypto ledgers in a peer-to-peer fashion. And then you have now these, for lack of a better word, these bank-grade blockchains, which is like bank sharing a blockchain. So we have a lot of different ideas in our community. ones do you find interesting from the perspective of the worldwide web consortium? I mean, all of them, right? All of them have some pretty interesting ideas that, I mean, yeah, all of them, all of them are interesting because all of them have some really interesting

concepts that the other ideas don't, right? And standardization is fundamentally picking the best ideas from a bunch of different solutions and trying to make them stick together in some kind of cohesive way. Sometimes it works out. Sometimes it doesn't. The other thing about standardization is you're trying to generalize the solution so that if you had a general solution, a bunch of different technologies based off of blockchain or based off of decentralized ledgers could kind of spring forth from that work.

So, yeah, I mean, all of them are interesting in their own way. The interledger work is being incubated at the W3C. It's a community group at the W3C. The bank blockchains thing is kind of frustrating because there's already a bunch of people working in public around it. And I think the banks see just about everything as like a competitive advantage. And if they own it, they own the competitive advantage. right? But banks are also not technology companies. They don't understand that there is, well, I shouldn't say this. They understand that having common infrastructure is important, but they want to

own as much of the infrastructure as possible because it's a competitive advantage, right? One of the things that a banker said to me once that has really stuck with me was that, you know, fraud's not an issue for us, the bank, right? Because all those costs are effectively pushed on to the customer. There's some countries where that's not allowed, but by and large, those costs are pushed on to the customer, right? So, you know, what's our competitive advantage? Our competitive advantage is saying that it is safer to use a visa card that we issue because we will look out for fraudulent activity because we have the best fraud detection programs in the world. That's our competitive advantage. It is not a competitive advantage to remove all the fraud in the

system because if we were to do that, then we'd be back to square one competing on a level playing field with all the other banks in the world, and we absolutely don't want that to happen, right? Yeah, I mean, like, this is kind of one of the interesting features of bank, like one of the interesting properties of bank rate blockchains that by definition, it seems to be a system where even if a lot of banks were to come on a single platform, none of them, would have a competitive advantage over another one if they were on the same platform. So if like the three of us represent different banks and we are on the same platform, then we basically lose all sorts of market differentiability and competitive advantages over each other.

So that's kind of different about the bank rate blockchain, isn't it? So there's not just one bank. That's true. So yes, you're absolutely right. But I think there's nuance there that you didn't quite capture. So I don't think many of the banks want to all jump onto a bank blockchain. So there are problems that banks face that blockchain can solve. So for example, you've got a big multinational bank that goes in and buys a bunch of banks in another country.

What's the fastest way to send money from one of the banks to the other banks? in some cases, it's using the same consumer-grade wire transfer than any other technology that the banks have inside because they can't integrate. So if that bank instead had a unified blockchain that was just internal to the bank, they could do instantaneous settlement and clearing between all the banks that they have in the world. And it's private. Nobody has to know what they're doing behind the scenes, but this private blockchain

run just by that bank for that bank would enable all their bank branches to sink almost instantaneously, which they can't do today. So that's one example where these private blockchains are an interesting thing. I mean, the other thing is, of course, like, this is something that could be incredibly disruptive to the banks. So they want to throw a bunch of money onto it, learn as much as they can, and then own the technology, if at all. possible. What would a, so I know we're very early in the, in the process of getting to a web payment standard. I think the first workshop was just a few months ago, right?

Two years ago, actually. The first workshop was two years ago. And then the working group, the official working group, interest group, sorry, was created three months later. And then the first working group, which actually creates technical standards. started last September. So it works well underway. Right. Okay. If we do arrive at a standard, how long do you think that can take? If HTML5 took 12 years, what in your opinion is the time frame needed in order to get all these banks and financial actors and browser manufacturers and all of the parties involved to come to a standard. So our charter is for two years. If we don't get it done by two years, they will shut us down. So that kind of lights the fire under everybody to get this stuff going. So just to just to be clear, the W3C membership doesn't like this stuff the last multiple years. They want it,

they want it done yesterday, right? So and there are certain things that are required to get it done as quickly as possible. One of them is to have the browser manufacturers involvement, so making sure you've got Google Chrome and Firefox and Edge and Opera backing you. That's important. We have every single one of the major browser manufacturers in the Web Payments Working Group. They're engaged. The other thing, of course, is making sure that you have ecosystems that are going to deploy this stuff once they're there. You know, Apple's involved in the group. They have Apple Pay. They have the iTunes store. You know, there's a pretty large economic ecosystem there.

Google kind of has the same thing going on with Android pay and, you know, their payment mechanisms and their, you know, browser tie-ins. So there's a forcing function here for the financial institutions, the banks and, you know, major organizations like that. And the forcing function is basically like, if Apple and Apple and, you know, if Apple and. Google adopt this technology before you do, or if they start running with it and you don't, where do you think that's going to put you? Right. And I think, you know, the banks understand that, and I don't think they have, they don't, they want this stuff to succeed. They want payments to become something where they can differentiate themselves on, like online payments to be something that they can differentiate themselves on. They want online payments to be something that

brings their customers in front of them. Because, I mean, the banks are like, when you swipe your card, you don't see your bank's brand image anywhere today, right? Whereas when you go to make an online payment, you might see a, you know, your payment page, say, you know, this payment being made via your USAA account or your Wells Fargo account or your Bank of New York account, right? So it's an advertising thing for the banks. They get to get in front of their customers.

Because they are, I mean, the banks are there, you know, analyzing if you should be, you know, if you are committing fraudulent activity or not, meaning like the banks are there to catch fraudulent activity. They're always there working behind the scenes to make sure that your money is not being stolen from your account. So it would be nice, at least they see it as, it would. would be nice if our customers were reminded that we're looking out for them. Right. Okay. And with regards to the work that's been done so far, what are the sort of big

areas that seem, are there areas that seem to be converging? What are people sort of coming towards or coagulating towards in terms of what the standard could look like? Sure. So, you know, there are two kind of specifications right now. Like this changes for month to month. It's fairly chaotic in the group right now because we're three months in and we're trying to figure out. We're trying to get a first public working draft out by March of this year, meaning like we're going to rough out what this thing looks like and put it out for public input by March, April, May of this year. Right now, it looks like there are two web APIs and and an HTTP API.

So the web APIs are things that are going to be implemented in the browser. And there's a high level one and a low level one. The high level one has to do with checkout flow. Like when you go to checkout at a website that you've never been to, what do they almost always need from you? They almost always need a shipping address.

They almost always need some kind of payment token or something saying that you're going to pay for something. And there are the things they might want to collect like loyalty card coupons, you know, that kind of stuff. So one of them is looking like a high-level checkout API. So you go to a site, you click pay. It says these are the items that you're buying, like Chrome takes over and says,

these are the items that you're buying. This is how much they cost. Which shipping address do you want to use? I want to use my home shipping address. And then after that it says, okay, the total is like $20 or $20. euro, and at that point you click pay, and then the payment happens, right? So that's the high level flow. The low level flow has more to do with just initiating a payment request. So let's say that

you're on a site, they don't really need to collect shipping address or any coupons or anything like that. They're just like, give us five bucks, right? So that's, you know, you click the pay button, it says this site is asking if you can pay them $5. You can pay with, you can pay with, you can pay, Visa MasterCard and Bitcoin, which one do you want to pay with? You know, click on Bitcoin or whatever. And then you click pay and the payments made, right? And the merchant has proof that the payment was made and all that kind of stuff. So right now, that's what the browser experience looks like.

There's a bunch of HTTP APIs that could be used for machine-to-machine communication. So let's say that you wanted to write some software that made your monthly electricity payments automatically. So you could, through like a program, fetch an invoice from your electric company and then pay that invoice programmatically. Right? No, you just have an agent, a smart agent doing payments behind the scenes for you.

So that might run at your bank, or it might be a piece of software that you write yourself. Right. So that's what the HTTP API looks. like, and of course we're trying to like harmonize this stuff with the international financial networks like Swift and ISO 222. So there's a messaging component to it. So in general, that's what the work looks like. It's like core messaging. What does the payment protocol look like over HTTP? And then what does the payment protocol look like when executed through the web browser?

This is fascinating because I work in e-commerce. I've worked in e-commerce for the last almost a decade. And checkout flow is just one of those things that people spend so much time working on the U.S., making sure it's optimized, making sure people are going to not mess up on the fields or whatever. And with this year, just completely removing all those barriers and making it part of the browser and a unified experience that is essentially no longer the responsibility of the company or the brand that has the e-commerce site, but the browser. So I think that's a good thing because browsers, that sort of interface, software interface

is probably going to be a lot cleaner and a lot better than something that you would find on a website. I mean, people are going to use to it. They're always used to the same type, same interface. But on the other hand, it does, you know, there is a bit of marketing that's always involved in a checkout process. You know, like, do you want to add this to your card or like upselling things like that? Right. There may be some, there may be some, obviously in terms of best practices that will sort of shift things.

Right. So that's what the low-level APIs is for, right? So we are absolutely sensitive to sites not wanting to give up on the whole. like checkout flow experience. So, so, you know, to address the first thing you said, like many sites, like it is not their expertise, like doing a good checkout flow, that is not their expertise. It's a waste of time for them, right? Because they have a product and they want to sell it. They don't want to build the best checkout flow, you know, on the planet. And honestly, they spend a ton of money doing it, like thousands upon thousands of dollars just doing a checkout flow.

ideally, so there are those companies. And then there are other companies that really pride themselves on their checkout flow and how they upsell people and, you know, that kind of stuff. And that's what the low-level payments API is for. Like, you can still control the entire checkout flow process if you want to. You don't have to use the high-level checkout flow API. Instead, you can roll your own checkout flow. And in the very last step, the payment step, that's when you invoke the low-level API.

to make the payment. So we're very sensitive to, I mean, there's so many different organizations that deal with value exchange, like payments, and every single one of them wants to do it in a slightly different way. So we're trying to accommodate all of them. We're trying not to be prescriptive

about the way that it's done. And this is just all about giving people options, right? There's nothing to stop a site from basically saying, we're not going to use any of this web payments crap. We're just going to go and roll our own. That's totally fine. They can do that if they want to.

But if they want to save a lot of money, make the checkout experience smooth and have the browser takeover, that's totally a possibility as well. And another thing that we've talked about on the show before, especially with protocols like Lightning Network or other initiatives like Streamium, and there's been so much talk about this, is the idea of payment channels and being able to do micropayments. and a payment channel is essentially opening up a channel where you can send payments and in exchange you'll receive something. It could be content, could be video content, like streaming, it could be Wi-Fi access,

or it could be simply just being able to access web pages like going to your favorite website and not having a paywall, but essentially just paying for every webpage like five cents or something like that. Is this something that these payment APIs would allow for? Yeah. Well, so right now in phase one, no. because we've got like two years to get this thing done, but it is definitely on the roadmap.

Like remember that, you know, one of the first companies that we founded had to deal with like streaming music over the network and people paying as they stream the music, right? So it's on-demands, payments, micropayments, payment channels, like all that kind of stuff. So we are definitely thinking about that. And we even have technical solutions for that. The question is, how long is it going to take us to get that kind of stuff built into the standard?

Now, with the HTTP API, there are ways that you can hand a subscription off, like a subscription token, off to a website. And then that website can pull payments as you use the site, right? So it's kind of like metered access. So, yeah, absolutely, that stuff's, you know, it's on the roadmap, absolutely. And of course, this doesn't address the issue of, I mean, because you're only, you're, with the standard, what you're doing is you're making a standard way in which payments are received through a browser or some sort of client interface to the web, but you're not changing the way that we make payments. And, of course, one of the problems with, say, credit cards, especially high, really high fees, you know, you're not address. that issue and you would still have sort of those high fees if you were paying, say, five cents. But we are. So here's the thing. The web payments work is payment scheme agnostic, payment network agnostic,

which means that if a merchant wants to collect payment in Bitcoin, we let, I mean, that's like, yeah, of course, you should be able to do that. If the merchant wants to be paid in like, you know, light coin or you know US dollars or they want an ACH payment to be made like the standard supports that so we're taking no position on what the best payment network is we're just leveling the playing field so if there is a better payment network that comes that that people start using that payment network can go online instantaneously right that's the goal like the payment network can go online instantaneously and as long as merchants say that they want to accept the payment, it will be built into the browser experience, right? Without anyone having to go through a

standardization process to like add Bitcoin or add Litecoin or add Ethereum, right? But you still need to have those payment networks that allow for cheap micropayments, for example. In this example, you wouldn't want to do micropayments with a credit card. That doesn't solve that problem. You would still need to have that payment network. Okay. So before we wrap up here, we're almost out of time. Can you tell us a bit about your company, Digital Bazaar, and what you guys are trying to solve? Sure. So, I mean, our company's main purpose is to change the way people exchange value over the web, right? meaning we want to see a dramatic change in the way, a dramatic positive change in the way people work

and get compensated for that work, right? We want it to be a lot more flow-based. So the way that we do this is one of the core ways that we try to do this, we're trying to build payments into the core architecture of the web because the web is a highly-concerned, connected global network. It's the biggest communication network that we've ever had. And as a result of that, if we build payments and value exchange into that network, then we can drastically change the way that

people are rewarded for the things that they do. So the way our company does that is we focus on standardizing new technology to do payments. We take it to the standardization process, and then our company provides turnkey solutions for those standards. So if somebody wants to accept web payments, that's super easy to do. If somebody wants to accept new payment mechanisms, they can just set up our software, and it just works, right? So that's, that's, that's, kind of the core of what our company does. We go in there, we help standardize the technology, and then we provide open standardized solutions for companies to purchase. It's a fairly simple business model, right? I mean, the more people that can use these open payment systems and

open payment networks, the more people that are likely to license our software and use them. Okay, well, my name of this is a really great conversation. I mean, personally, I've sort of always been fascinated with web standards and, you know, we didn't really get to talk about JSON-LD, which I, I mean, I hadn't really heard about it before. I mean, I heard about it, but I didn't really know what it was, but I just realized, like, through researching your work, what it was and thinking of perhaps implementing it in my emails that I sent up. So there's lots of fascinating topics to talk about when talking about web standards. So thanks so much for coming on. I do hope that, I mean, it is encouraging that, you know, you think that, you say that this

could take, you know, two years to come to consensus around web payment standards. It is definitely encouraging and really hope that that that goes according to plan and that we can come to some sort of a consensus about how payments should be made online. It is really one of those fundamental problems that I really think needs to be tackled and needs to be addressed. Awesome. Well, thanks so much for having me today. I really appreciate it. Well, thank you for coming on. And to our listeners, thank you for listening. We are part of the LTV Network where you can find a whole bunch of shows about Bitcoin, cryptocurrencies, blockchain, and you can find that at let's talkbenticon.com.

We release new episodes of Epicenter Bitcoin every Monday. You can find it on your favorite podcasting app or SoundCloud. You can also watch the videos live, sorry, not live, but you can watch the videos on YouTube. but YouTube.com slash epicenter Bitcoin. And of course, if you're a lawyer listener, you can always leave us an iTunes review. If you do, send us an email at show at epicenterbidcom, and we will send you one of these snazzy t-shirts.

And of course, you can always leave us a tip, and their tipping address will be in the show description. There's no web payment standards on how to do that. You just open it up with your Bitcoin client, and you can send us to it. It's that easy. So thanks so much, and we look forward to being back next week. I'm