Tobi Lütke x Ilya Grigorik: Building the Universal Commerce Protocol

It is an attempt to turn imprecise English language into not machine-runnable code, but something that is more precise than just words. I think one way to think about the protocol versus direct integration one-to-one client server is this idea of the cathedral and the bazaar. What's so interesting about protocol creation is the people who create protocols have to understand the problem better than anyone else.

Hello, everyone. This is another Context episode. And this time I'm here with Ilya Grigorik. And we are going to talk about why protocols are such an important thing that engineers talk about. And in fact, I think if you do our job right, you are going to, I mean, have a much stronger appreciation for the protocols that run the modern world that underpin the world of engineering and sort of what makes a protocol, what makes them good, and why it's a thing that when you probably find yourself at some place, even if you're not in engineering and you buy drinks for engineers and get them onto their most philosophical self and into the topics of internet history, you will at some point hear about protocols. And then next time you'll have hopefully something interesting to contribute to those conversations.

Ilya, you have worked on a lot of important protocols of the internet in your career. Obviously, the largest one of those is the W3C, the internet body that specifies what web browsers are allowed to do. HTML is one of those protocols, I suppose, I guess. HTTP is definitely the thing that makes all web browsers work, which is something you have worked on. And most recently on UCP, which we talk a lot about because it's enabling the agentic world. And so, welcome.

Let's quickly start with HTTP. Tell us a bit about that protocol, the origin of it.

Yeah.

It's not.

But that came later, right? But then you forward evolved that. And what happened was there's this Cambrian explosion of people building stuff because they said, hey, this is cool. There's something here. So then somebody comes along and says, you know, it'd be cool if you could fetch an image. But how do we differentiate that? And so headers come to existence. And headers, one of the key decisions at the time was it's an open protocol. So there was no central governing body. Tim did not sit there and approve every proposal for every header that said, this is how you do it. Instead, it was community of server builders. And then there's a growing community of client builders who just said, look, we're just going to try stuff. We're going to throw some stuff at the wall. Hey, Apache server, if you add this header, and I will add this listener on the other side, then the two of us can negotiate, and now we can speak images. And look, ta-da, right? And this is the genesis of the internet as we know it. There's this Cambrian explosion of experimentation, and it's lawless. People are just doing stuff, and they're experimenting. And then after the fact, smart people come together and say, look, we've tried five different variants of how to negotiate an image. Let's just agree on a convention. And that becomes the IETF lore and you have these like RFCs that get put out. But note that it is not by consent or approval of somebody. Tim was never in that way.

A request for comments. Even that's kind of like prosaic in a way, right?

It's not like a law.

It is our best attempt. Well, maybe not best. That it is an attempt to turn imprecise English language into not machine-runnable code, but something that is more precise than just words, such that somebody on the other side could implement it in a more respectful way. Which, by the way, is also what the legal language is.

Right. Into the mono repo, so to speak, at least in the common law area of the world. And so it's like you make a request for comments because you want to make a change or you want to make an enhancement or you want to specify something that already works, which is actually also an interesting, like very often an RFC is happening for something that's almost backwards facing documenting about something that someone has already tried.

You sent your request saying you would accept compressed version of a content.

So this is fascinating. And then, of course, HTTP evolved a lot, and it's gotten a lot better since with HTTP 2 and 3 and so on. You worked on 2, I think, and 3. Foundations are free, which is very, very good nerd credit. Very nice work. I think what's so interesting about it, though, is like some people listen to this and they're like, well, that sounds not exactly like engineering. This sounds very ad hoc, right? And very like engineering as opposed to, you know, you have blueprints. You build a bridge in a world where gravity doesn't change. You figure out what the tolerances are and then you build on tolerances. And if you, within the margins of the tolerances, you can decide to optimize for cost or optimize for beauty or, you know, just like, you know, the Golden Gate Bridge and the random bridge over the local river all like work on the same principle, but like different decisions were made based on the envelope of a project. So there are some variants in there, but no fundamental, almost market-like price-finding. And this really is messy. For instance, I think HTTP famously misspelled the word "referrer" in it. And that's just in the spec. Did we ever actually fix this?

Yeah, so I'm pretty sure in a thousand years or a hundred years, the official spelling of referrer will at some point just flip. I think every dictionary already accepts it the way it's written in the HTTP standard as not wrong, at least, because it's so commonly used. But it's just like someone misspelled it, I suppose, at some point.

Yeah, and so the consequence, like again, really, really nerdy topic here, but then the consequences of this are basically the world we all live in. Everyone here at Shopify has the job which I think hopefully we love and appreciate because of these messy protocol creation exercises early in the 70s, 80s, 90s. Because at some point in 2004, I could just take a like a random computer connected to the internet and I could respond to port 80 and hopefully to 443 as well to just launch a piece of software that I wrote but nothing else than just like listen to these two ports on the internet and if a request arrived that asked for the snow devil or any of the files and paths there it sent back e-commerce website and it had in it like a checkout which...

Exactly. And it just like, you know, like to computer there is no such thing as Snowdevil or a checkout, but like that doesn't matter. Like no one had to pre-plan the fact that e-commerce might happen in HTTP. In fact, they tried and then we didn't sort of with Listen, I suppose, with 402 status code. But anyway, that's a different topic. So this is sort of, and then protocols are really all around us. Like, obviously, computers talk to each other over DNS, which is a protocol, and then obviously they package everything into container-like packets in something called TCP IP, which is the reason why anything on the internet even works. In a very real way, although it might be just on the margins of a protocol and you can pick on which side it's lying. But like Liquid feels like a protocol because it's a way for designers to state the online store they would like to be responded with when someone comes asking for it. And a couple of rules related to what products to show and so on. And those are provided to Shopify, the software, and then Shopify uses its current best way of turning this into a real online store and sending it back. And that's basically what Shopify has been doing for those 20 years that's existed. There's a couple of protocols that are really important and why it's fun to talk about them is, you know, HTTP is a little bit special because it's somehow finagled its way to the browser bar and therefore we actually are aware of it. But really, when a protocol truly works, it's invisible. The only protocols that people know about are the ones that are really wrong in important ways, and therefore everyone's complaining about them, or they will never have heard of them because they didn't get adopted. And so one of the aspects of protocols is that they allow a lot of different people to openly collaborate. I think that's one of the just absolute... I think that needs to be true for a protocol to be successful.

That's right. People query their own data in Shopify with ShopifyQL, which is a language protocol. The amazing thing is this has existed for a very long time. We've had ShopifyQL for, I think, over 10 years, maybe actually much longer, I think, 15 maybe. And nothing about how ShopifyQL is executed is the same. Right. Like the same query works. You can still ask for your orders based on the weekday, but we can take the same packet that you stated and now execute them in a completely, like everything about the way shop is deployed, it's on different data centers, it's scaled to the entire world. It's like all these kinds of things. So I think this is what protocols also enable, that there can be progress. Protocols don't calcify progress in the same way that a lot of, you know, just like monolithic software does. Let's talk about the, like, let's fast forward to today. I think one way to think about the protocol versus direct integration one-to-one client server is this idea of like the cathedral and the bazaar, and which seems always super appropriate thing to talk about for us in commerce.

Yes.

Yes, exactly. And then right beside it is the bazaar, and the bazaar has a very different, you look far and wide and you go, oh my God, there's so much variety here. There's so much-

And chaos. And crazy.

Right. Some of it you can barter, some of it you need stable coins for. Some of it you need fiat currency. Some of the world delivery. The list goes on and on and on.

Yeah. Right? It is just kind of controlled chaos. It's not even the same bazaar even like three hours later. Right? Like it's like it's completely changes based on...

Exactly. So it's, you know, it's absolutely, it's chaotic. It doesn't look impressive. You look up and see nothing. You open my ear. In fact, it's intimidating probably the first time you walk up to it. It's like, how do you even make sense? No one knows. Like you ask someone, hey, where can I find these goods? They have like no idea because again, tomorrow the whole thing is going to be different depending on when someone shows up where. So now the fun challenge. So it's not easy, but kind of obvious how you build a protocol for the cathedral. Because, well, by definition, it's a blueprint, right? How do you build a protocol for the bazaar? That is the hard problem. And this is why I brought an expert onto the show.

That's right. The bazaar has parameters. They are enforced in very different ways in different places. But you obviously can't go and just make one stand that fills the entire market. Presumably, you can't use force to avoid having competitors. And there are rules. They are just organic in a way, like how they were established. And they eventually become culture of a place. Right. And some of those are operational in how you deploy it. And some of the, as you said, are the protocols. How do you negotiate those differences? And the hard part of this is understanding of what is your responsibility. Good protocols know their boundaries, right? Because they know how to layer themselves to build on top, so they're not trying to reach too far up or too far down. And they established this abstraction where they're satisfied that intersection of here's what one side of the market is willing to offer, here's what the other side of the market is willing to implement, and then how to facilitate that exchange in the middle. And so that then, again, literally a market emerges and sees if there's price finding. Figure out like again all these kind of things happen but like it's really the reason why it's such a fun metaphor is because I think people know that both of those things work and even though you would imagine there is a better solution like they usually like people have a bias towards there being the one true solution for everything but usually they often even the extremes of the spectrum actually are both perfectly viable. And so Shopify obviously is a company that's like very bazaar. If Shopify would be, it would be so fun to see Shopify as like an actual bazaar, like visualized with a crazy variety of shops and the crazy amount of commerce and crazy amount of ideas and the crazy amount of people that are coming to all these stores. There's like Alo Yoga next to the hardware shop next to like, it's just like, it would be absolutely mad and it would be wonderful. And so every one of those businesses is really uniquely their own. Specifically, you know, often people think that there's like small businesses are like simple and then big businesses are complex. Very often actually this winds up being wrong. Maybe they're both, they're just both complex or sometimes they're really, really big ones. It can actually be quite simple.

You have to prove yourself worthy.

Up wielding. This is not like, this is a holy object, right? So like, you know, you can't even believe how much my kids got into this because they very literally grinded this aim trainer just to be able to purchase a mouse for like $70, which is like, and like, this is so fun, right? And so all of this. Now we have all of this going on Shopify and now the internet is transitioning to agentic commerce. This has been your project that you've been working on, frankly, day and night, with very many long phone calls and all sorts of wrangling of basically the industry at this point, the Universal Commerce Protocol, the UCP. UCP is essentially retain the variety of the bazaar, but in such a way that it's not Shopify having to set up the boundary conditions for the bazaar anymore. And so talk about your experience of UCP, which is essentially the hardest protocol anyone can imagine making because it is.

Discount engines and customizations.

Different discounts stacking.

Yeah, you collect a couple of information, you click a button, you provide a credit card or login, and then money is transferred, and what else could possibly be happening, right?

Or is it just claiming?

This is Quebec. Quebec has its own stuff.

Yes. So a lot of that complexity is absorbed. Some of them, there's buildings in the United States where the shipping costs and taxes change depending on which loading dock of that building something goes out of.

Yeah, and they have their own cathedrals and bazaars by themselves. Like lots of people want to do this centrally because it's easier for trust. Everyone wants to create their own central repository of registered agents, right?

Therefore, you now have to do it.

Yeah, yeah. It's like a kid's summer camp registration of Shopify. And like at some point in checkout, it needs to ask like, hey, does Tommy have any peanut allergies or something like this? And like, that is not something like, you know, on Shopify, like they have an extension and then it asks this and it's being collected or it's gating the checkout if this is not there because it's required. Like if you would build a checkout protocol naively or would ask people to just like build a API integration, they would never add to their, like to TikTok, to like peanut allergy dialogue, right? That's not what TikTok engineers will work on, right?

So I think this is your idea was like to, you know, what's so interesting about protocol creation is the people who create protocols have to understand the problem really at an atomic level, probably better than any, like this is my favorite thing about engineering, is that it really requires you to at some point understand the problem probably better than anyone else. Like at least for a fleeting, maybe it's 10 minutes, but for 10 minutes, you understand this problem better than any practitioner if you want to crack the code on finding exactly the right way to do something. And the discipline of what makes engineers really good are the people who can do this quickly and repeatedly, who would just have a way of looking themselves into a problem matter. So I think this was another one of those moments where really in an agentic world, we need the concept of an escalation to a human. And sometimes these escalations can be dealt with directly by an agent if it just happens to have all the information. Sometimes it needs to be able to ask a person. And this, I think, was the biggest unlock in this protocol, which I think gave us a confidence that it's actually possible to make.

That's right. Yeah, like taking, I mean, obviously this is not discovery of a completely new idea, but it is often just a penny drop moment when say, "Hey, this thing that we've been doing over years of ad hoc is actually, if we move it to become a primitive and allow it to be utilized for all problems of this particular shape in the concept of a checkout, then the complexity just melts away in a very real way. Suddenly we can actually take all the checkouts that all our customers have so carefully configured, like the final mouse example, an agent can be trying to buy one of those mice when they're available. And the escalation is, well, you have not, like your user account on this website does not have the right tags. So therefore you have not done this thing yet. Do you want to tell your human about this or do you want to send them a link to the tool? Or do you, you know, how would you like to go about this? Maybe another way to look at it is an agent's kind of like progressive enhancement, right? So where you had to do everything manually before. Now you can delegate some portion of your commerce needs to an agent. And over time, one would hope that the agent can do progressively more and more. But you've built it in such a way that it fails open. It says, this is how far I got you. Here you go. As opposed to closed mechanism where you just said, this is one particular shape of commerce that you can do, and otherwise you cannot proceed.

I'll double up on a positive, which is it is not preordained or obvious that Agentic Commerce would be net positive to buyers or merchants if it's not done right. The bar is not, can an agent complete a transaction? Of course it can. That's a trivial example to drive through. In those cases, it just takes over your browser and pretends it's you.

Exactly. And it happens in the browser. And if it doesn't survive the next platform shift and the next platform shift kind of removes the ability for these kind of special, like differentiation, then I think your point is a very, very good one that it's not automatically positive. Like we would lose a huge amount of distinction of businesses. And I think this distinction is important. Again, there are a lot of businesses that sell mice. I'm excited about one, other people should be excited about others. And it's distinction of products and people exploring the space, sometimes by innovating on the products and sometimes by innovating on community and all these kind of things, is exactly what makes the bazaar interesting. Because otherwise you end up having just rows and rows of newly built suburbia and it does not look like a bazaar right like and there's a place for it but it just like you know there's like a vibrancy that is just like lost in that point the bazaar can also wither right because many businesses just opt out they see the shape of commerce that the first set of agents were proposing and they said okay maybe i'll try it because i'm curious but then they actually see the orders roll through and they realize all the things they lost in the process and they just opt out. So the bazaar closes.

I guess one to end protocols still. I may maybe it's not.

Yeah, I think you're right. I think that's a better way to put it. And yeah, but it's the hardest thing to do is to create a protocol, make it something that can be open and then convince people that it's the one that we should coalesce. And maybe the last bit is the hardest.

Yes. And yeah, so I think protocol design, abstraction design, like making the ones that everyone just like, this works perfectly and I don't have to think about it, is actually the highest form of software engineering specifically. It is the building the Golden Gate Bridge of our industry, like TCP certainly is, HTTP. Like, where the file API is opposite. In the same way that Rails transformed how to build a web app. Like, Rails is a protocol.

Yes, true. And then at a certain point, I'm like, oh, wait a second. I think I understand the pattern. What if I just type this and it ran? And it was like an epiphany moment of like, now I understand the dialect.

Right, right. And it wasn't without fault, but once you crack it and once you understand it, you're just that much more effective, right? Because it abstracted a lot of the complexity of I don't have to write SQL, I can just do this thing, right? Fine, buy something. It's a piece of magic. I think this is a perfect place to end with really fun conversation and again, amazing work on pioneering UCP, couldn't have done it without you. And yeah, like it's a fascinating, underexplored topic. Protocols are very important at Shopify. I think we celebrate them because we deem them to be the highest form of a craft. And I think it's exciting to go into this completely new platform shift with Agentic Commerce in a way that we can bring the unvarnished vision of our merchants to this new platform without having to, I don't know, just go for a decade of negotiations. It's really, really, really, really. This could have gone, if you would rerun this simulation here a thousand times, I really don't think in many of those. This is not the dominant outcome.

Capitalism, the best part. Yes, very good. Thank you very much, Ilya. Thanks for joining me.