Web3: The hope of protocols rather than platforms

Couldn’t attend Transform 2022? Discover all the summit sessions now in our on-demand library! Look here.

In the beginning, there were protocols

Rather than writing about Web3 again, I want to write about Web1: the 90s. At that time, I was using something called Communicator. You can think of it as a suite of Internet clients and applications. Of course, it had Navigator, a web browser, but also a messenger for e-mails, a news client and even a push system. It was a good example of how the early Web worked: multiple protocols for different purposes. You may remember FTP, SMTP, Gopher and Archie, but also XMPP and many more.

The cool thing about these protocols is that they made the computer you were using useless. They abstracted away the underlying operating system and hardware. Similarly, these protocols embraced the Unix Philosophy and focused on one thing to do it well: file sharing, email forwarding, push messaging, etc.

Then HTTP and HTML won

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

1. Make download requests for HTML, JavaScript and CSS files via HTTP.

2. The browser “executes” them to render them as sophisticated 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 emailing 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 Referent instead of “referrer”, which would be the proper English term, and despite all efforts, HTML was never able to conform to XML requirements. See the irony? HTML and HTTP, both of which were poorly designed compared to other more academic protocols and formats, eventually took over the entire stack.

Their simplicity and versatility is what has made HTTP, HTML, and JavaScript so powerful in being adopted everywhere and for everything.

402: Reserved for future use

Still, the HTTP spec had a nice set of features, including HTTP status codes, to tell clients How? ‘Or’ What behave with downloaded files. It includes mechanisms to redirect users when resources have changed, or indicate that the user is not authorized to access them, or is now unavailable. You have probably heard of the famous 404!

There are dozens of statuses, including 402, that servers should use to indicate when a payment is required. Turns out the spec for this is still Reserved for future use.

This means that all websites and applications (including those that replaced the protocols) that used HTTP and HTML had to figure out how to monetize on their own and that’s how we ended up with banner ads and the attention economy.

Soon some of these websites and apps realized that in order to be more profitable, they needed to get bigger. They realized that the more data they collected, the more attention they got, the more locked in they were, the more profitable they could be (not just more revenue!). It’s like that platforms got stuck in the middle of the internet.


In order to maintain the lockdown, the platforms _privatized_ protocols and applied their own terms of service in addition: this is how Facebook _possesses_ the social graph or Google has tried (is trying?) to impose its own syndication format, called AMP, on publishers. In Web2, the permissionless Internet of protocols has been replaced by endless intermediaries and gatekeepers in the form of platforms.

Will Web3 allow us to 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 dwindling number of companies (or individuals like Mark and Elon).

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

So what are blockchains for?

Bitcoin is a distributed ledger. As far as registers go, it’s a bad register, and worse than most other registers in just about every aspect but one: its ability to get people to agree on what the balance of each, without central authority. Bitcoin shows us that blockchains are consensus machines: they are systems that allow us all _I agree_ about things, even if we don’t agree on anything else, and even if we try to lie to others.

Agreeing is fine, but what do we really agree on? In software, there are really two kinds of things: data, often called “state”, and algorithms. Bitcoin asks us to agree on ledger balances: Julien has 15.4, Hannah has 1337, and Giselle has 42. That’s fine, but not very helpful beyond this case. use of the general ledger.

In fact, a blockchain can also ask to agree on processes. These process agreements are often referred to as smart contracts. They are pieces of code that work in a way that cannot be changed, apart from what the code actually codifies. If the only thing a contract does is return the sum of 2 numbers, it will return the sum of 2 numbers, and nobody will ever be able to change this program, without putting an end to the whole blockchain.

Maybe you see where I’m coming from: these smart contracts, or collectively agreed processes, are actually protocols. They are ways to codify the behavior of actors in such a way that no actor can arbitrarily change the way things work at everyone’s expense (unless of course it’s been codified like that).

Dead code vs smart contracts

But there is one more thing. Usually protocols are “dead code”. These are specs, written in English, with lots of MUSTs and SHOULDs, but, despite everyone’s best efforts, the translation from English (the lingua franca!) to actual computer code is subject to interpretation and a lot of things. may be lost in translation. With smart contracts, protocols are, in effect, functioning coded. There is no need to interpret English, and maybe not even need a detailed specification because the protocol is the smart contract.

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

Here again, blockchains offer us an interesting opportunity, because the governance of a protocol is, in fact, a protocol too! Additionally, a special type of smart contract, called a DAO, can provide a pretty good alternative to the typical “chamber” governance that has occurred so far.

And now?

First it’s early.

So, You must beware.

And only then, let’s experiment in a way that slowly deconstructs the platforms, replacing some of the basic primitives they have with open protocols that are collectively owned and governed by their own communities.

For instance, identity primitive is very important. Almost all websites and platforms need to identify their users. Emails and passwords were the norm, but bad passwords, and asking users to (re)create identities on all single website is just too painful. So we moved on to the worlds of OpenId and OAuth. These are useful ways to reduce the security risks introduced by passwords, but they’ve also moved us from a self-sovereign world (I own my email and password) to one where we have 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, without a password AND without having to trust that platforms will keep providing one to us. Connect with Ethereum is an effort in this direction.

Of course, I believe another fundamental primitive that has emerged on the Internet is the concept of membership. Whether it’s your paid access to The New York Times, your following me on Twitter, or that role on Discord: those are all subscriptions. Since they are everywhere, I think memberships should be standardized so that they to behave the same.

The platforms go still have a role. They will provide distribution, curation, differentiated user interfaces, and other functionality. But protocols will never act as gatekeepers, as they could not cut someone off the network without cutting themselves off from said network. Despite its best efforts, Apple will never be able to remove Safari from iOS to fully control the “app” experience on its phones. However, they can (and should!) compete for the best experience, speed, connectivity, or battery life!

Julien Genestoux is the founder of Unlock.


Welcome to the VentureBeat community!

DataDecisionMakers is where experts, including data technicians, can share data insights and innovations.

If you want to learn more about cutting-edge insights and up-to-date information, best practices, and the future of data and data technology, join us at DataDecisionMakers.

You might even consider writing your own article!

Learn more about DataDecisionMakers

Source link