Web3: the hope of protocols over platforms

In the beginning there were protocols…

Instead of writing over web3 again, I want to write about Web1: the 90s. At that time I used something called Communicator. You can think of it as a suite of Internet clients and applications. It had Navigator, a web browser, of course, but also an email messenger, a news client, and even a push system. It was a great example of how the early web worked: multiple protocols for different purposes. You may remember FTP, SMTP, Gopher and Archie, as well as XMPP and much, much more.

The nice thing about these protocols is that they made the computer you were using irrelevant. They abstract the underlying operating system and hardware. Likewise, these protocols embraced the Unix philosophy and only focused on one thing to get it right: file sharing, email sending, push notifications and so on.

Then HTTP and HTML won

The most “abstract” of these protocols was HTTP. Although it was originally designed for transferring hypertext documents, it soon became apparent that it was good at transferring just about any kind of file. Similarly, HTML was pretty quick to see the emergence of JavaScript as a way to make static documents more dynamic. The web stack was (and still is largely):

1. Request to download HTML, JavaScript and CSS files over HTTP.

2. The browser “runs” these to display them as beautiful websites and applications.

This meant that other, more specialized protocols could simply become applications on top of HTTP and HTML. If you’re using Gmail and sending an email to someone else using Gmail, you’re probably not using POP, SMTP, or IMAP, just HTTP and HTML. FTP and XMPP are now known as Megaupload and WhatsApp, for better or worse.

What might surprise you is how hacky HTTP and HTML are. After all, the HTTP specification uses Refer instead of ‘referrer’, which would be the proper English term, and despite all efforts, HTML could never meet the XML requirements. Do you see the irony? HTML and HTTP, both of which were poorly designed compared to others more academic protocols and formats, eventually took over the entire stack.

Their simplicity and versatility is what made HTTP, HTML, and JavaScript so powerful by being applied anywhere and for anything.

402: Reserved for later use

Still, the HTTP specification had some interesting features, including HTTP status codes, to tell the customers how to behave with the files it has downloaded. It contains mechanisms to redirect users when resources have changed, or to indicate that the user cannot access them, or that they are not available now. You must have heard of the infamous 404!

There are dozens of states, including 402, that servers should use to indicate when payment is required. It turns out that the specification for this is still Reserved for future use.

That means that all websites and applications (including those that replaced the protocols) that used HTTP and HTML had to figure out for themselves how to monetize and that’s how we got to banner ads and the attention economy.

Soon, some of these websites and applications realized that they needed to get bigger in order to be more profitable. They realized that the more data they collected, the more attention they attracted, the more lock-in they had, the more profitable they could become (not just more revenue!). That is how platforms wedged in the middle of the internet.

the platforms

To keep lock-in, platforms _privatized_ protocols and applied their own terms of service to them: this is how Facebook works now _possess_ the social chart or Google tried (trying?) to force its own syndication format, called AMP, on publishers. In Web2, the permissionless internet of protocols was replaced by endless intermediates and gatekeepers in the form of platforms.

Will Web3 Make Us Reinvent Protocols?

The current state of the internet is… disappointing. The governance of our collective brain is being challenged by all kinds of governments, users are becoming increasingly frustrated with the behavior of these platforms and the internet is increasingly controlled by a shrinking number of companies (or individuals like Mark and Elon).

In the long list of Internet protocols, a fairly recent protocol is steadily gaining popularity and fame: Bitcoin. Don’t roll your eyes yet. Bitcoin is a protocol for money. It lets people transfer coins in a completely permissionless and decentralized way, just like HTTP lets them transfer documents. To understand why Bitcoin represents a new hope for a protocol-driven internet, we need to think about what blockchains are.

So, what are blockchains good for?

Bitcoin is a distributed ledger. When it comes to ledgers, it’s a bad one, and worse than most other ledgers in just about every aspect except one: the ability to get people to agree on what everyone’s balance sheet is, without central authority. Bitcoin shows us that blockchains are consensus machines: they are systems that make it possible for us all _agree_ on things, even if we disagree on something else, and even if we try to lie to others.

Meetings are nice, but what do we really agree on? In software, there are actually two kinds of things: data, often referred to as a “state,” and algorithms. Bitcoin asks us to agree on ledger balances: Julien owns 15.4, Hannah owns 1337, and Giselle owns 42. That’s good, but not very useful outside of that use of the ledger.

In fact, a blockchain may also ask to agree on processes. These process agreements are often smart contracts. They are pieces of code that operate in ways that cannot be changed, beyond what the code actually encodes. If all a contract does is the sum of 2 numbers, then the sum of 2 numbers is returned, and no one will ever be able to change that program, without ending the entire blockchain.

Maybe you see where I’m going: these smart contracts, or collectively agreed processes, are in fact protocols. They are ways of codifying actor behavior in a way that no actor can arbitrarily change how things work at everyone’s expense (unless it’s codified that way, of course).

Dead Code vs Smart Contracts

But there is one more thing. Usually protocols are “dead code”. They are specifications, written in English, with much MUST and MUST, but despite everyone’s best efforts, the translation from English (the lingua franca!) to actual computer code is subject to interpretation and many things can get lost in the translation. In smart contracts, the protocols are basically run code. There is no need to interpret English, and maybe even no need for a detailed specification because the protocol is the smart contract.

It goes even further. Usually, the governance around the dead code protocols is quite limited. A small number of large companies spend several million dollars annually to sit at the table of the IETF, W3C and other governing bodies. Despite many good intentions, it is quite opaque and full of politics: I’ll give you your DRM if you agree to my HTTP2. As a result, things go slow and will sometimes go in directions that don’t serve small indie developers or internet users in general.

Again, blockchains offer us an interesting opportunity, because the governance of a protocol is in fact a protocol too! Furthermore, there is a special type of smart contract, called a DAOcan provide a pretty good alternative to the typical ‘chamber’ board that has happened until now.

And now?

First, it’s early.

Then, look after.

And only then, let’s experiment in ways that let us slowly deconstruct platforms, replacing some of the key primitives they own with open protocols collectively owned and controlled by their own communities.

For example, the identity primitive is a very important one. Almost every website and platform needs to identify its users. Emails and passwords were the norm, but passwords are bad, and users are asking to (re)create identities on each single website is just too painful. So we moved into the worlds of OpenId and OAuth. These are useful ways to reduce the security risks that passwords posed, but they also moved us from a self-sovereign world (I own my email address and password) to a world where we delegated our identities to Google and Facebook, which … is not ideal .

The cryptocurrency primitives of public/private key cryptography bring us back to a world where we can have a globally shared identity, with no password AND without hoping that the platforms will continue to provide one for us. Login with Ethereum is an attempt in that direction.

Of course I believe that another primitive core that has appeared on the internet is the concept of: membership. Whether it’s your paid access to the New York Times, the fact that you follow me on Twitter, or that Discord role, it’s all memberships. Since they are everywhere, I think memberships should be normalized so that they behave same.

The platforms will always have a role. They will provide distribution, management, differentiated user interfaces and other capabilities. But protocols will never act as gatekeepers, as they cannot remove someone from the network without removing themselves from that network. Despite its best efforts, Apple will never be able to remove Safari from iOS to fully master the “application” experience on their phones. However, they can (and should!) compete for the best experience, speed, connectivity or battery life!

Julien Genestoux is the founder of Unlock.