Editor’s note: With Web 3 the center of a lively debate, it’s worth revisiting the following post, originally published in 2014 and now a seminal piece in the crypto canon, by Gavin Wood, a co-founder of Ethereum who went on to found the Web3 Foundation and create Polkadot and Kusama.

As we move into the future, we find increasing need for a zero-trust interaction system.

Even pre-Snowden, we had realized that entrusting our information to arbitrary entities on the internet was fraught with danger. However, post-Snowden the argument plainly falls in the hands of those who believe that large organizations and governments routinely attempt to stretch and overstep their authority. Thus we realize that entrusting our information to organizations in general is a fundamentally broken model. The chance of an organization not meddling with our data is merely the effort required minus its expected gains. Given that companies tend to have income models that require they know as much about people as possible, the realist will realize that the potential for covert misuse is difficult to overestimate.

The protocols and technologies on the web, and even at large the internet, served as a great technology preview. The workhorses of SMTP, FTP, HTTP(S), PHP, HTML and Javascript each helped contribute to the sort of rich cloud-based applications we see today such as Google’s Drive, Facebook and Twitter, not to mention the countless other applications ranging through games, shopping, banking and dating. However, going into the future, much of these protocols and technologies will have to be re-engineered according to our new understandings of the interaction between society and technology.

Web 3.0, or as might be termed the “post-Snowden” web, is a re-imagination of the sorts of things we already use the web for, but with a fundamentally different model for the interactions between parties. Information that we assume to be public, we publish. Information we assume to be agreed upon, we place on a consensus ledger. Information that we assume to be private, we keep secret and never reveal. Communication always takes place over encrypted channels and only with pseudonymous identities as endpoints; never with anything traceable (such as IP addresses).

In short, we engineer the system to mathematically enforce our prior assumptions, since no government or organization can reasonably be trusted.

There are four components to the post-Snowden web: static content publication, dynamic messages, trustless transactions and an integrated user interface.

Publication

The first, we already have much of: a decentralized, encrypted information publication system. All this does is take a short intrinsic address of some information (a hash, if we’re being technical) and return, after some time, the information itself. New information can be submitted to it. Once downloaded, we can be guaranteed it’s the right information since the address is intrinsic to it. This static publication system accounts for much of HTTP(S)’s job and all that of FTP. There are already many implementations of this technology, but the easiest to cite is that of BitTorrent. Every time you click on a magnet link of BitTorrent, all you’re really doing is telling your client to download the data whose intrinsic address (hash) is equal to it.

In Web 3.0, this portion of the technology is used to publish and download any (potentially large) static portion of information that we are happy to share. We are able, just as with BitTorrent, to incentivize others to maintain and share this information; however, combined with other portions of Web 3.0, we can make this more efficient and precise. Because an incentive framework is intrinsic to the protocol, we become (at this level, anyway) DDoS-proof by design. How’s that for a bonus?

Messaging

The second portion of Web 3.0 is an identity-based pseudonymous low-level messaging system. This is used for communicating between people on the network. It uses strong cryptography in order to make a number of guarantees about the messages; they can be encrypted with an identity’s public key in order to guarantee only that identity can decode it. They can be signed by the sender’s private key to guarantee that it does indeed come from the sender and provide the receiver with a secure receipt of communication. A shared secret can provide the opportunity to communicate securely, including between groups, without the necessity of proof of receipt.

Since each of these provides ultimate message logistics, the use of transmission-protocol level addresses becomes needless; addresses, once comprised of a user or port and an IP address, now become merely a hash.

Messages would have a time-to-live, allowing the disambiguation between publication messages that one may wish to be “alive” for as long as possible to guarantee as many identities see it and instant signaling messages that wish to be transmitted as quickly as possible across the network. Thus the dichotomy of latency and longevity is traded.

Actual physical routing would be carried out through a game-theoretic adaptive network system. Each peer attempts to maximize their value to other peers in the assertion that the other peers are valuable to them for the incoming information. A peer whose information is not valuable would be disconnected and their slot taken with a connection to some other, perhaps unknown (or perhaps second-degree), peer. In order that a peer be more useful, messages with some specific attributes would be requested (a sender address or topic, for example – both unencrypted – beginning with a particular bit string).

In Web 3.0, this portion allows peers to communicate, update and self-organize in real time, publishing information whose precedence does not need to be intrinsically trusted or later referred. In the traditional web, this is much of the information that travels over HTTP in AJAX style implementations.

Consensus

The third portion of Web 3.0 is the consensus engine. Bitcoin introduced many of us to the idea of a consensus-based application. However, this was merely the first tentative step. A consensus engine is a means of agreeing some rules of interaction, in the knowledge that future interactions (or lack thereof) will automatically and irrevocably result in the enforcement exactly as specified. It is effectively an all-encompassing social contract and draws its strength from the network effect of consensus.

The fact that the effects of a renege of one agreement may be felt in all others is key to creating a strong social contract and thus reducing the chances of renege or willful ignorance. For example, the more a reputation system is isolated from a more personal social interaction system, the less effective the reputation system will be. A reputation system combined with Facebook or Twitter-like functionality would work better than one without, since users place an intrinsic value on what their friends, partners or colleagues think of them. A particularly poignant example of this is the difficult question of whether, and when, to befriend on Facebook an employer or dating partner.

Consensus engines will be used for all trustful publication and alteration of information. This will happen through a completely generalized global transaction processing system. The first workable example of this is the Ethereum project.

The traditional web does not fundamentally address consensus, instead falling back on centralized trust of authorities, such as ICANN, Verisign and Facebook, and reducing to private and government websites together with the software upon which they are built.

Front end

The fourth and final component to the Web 3.0 experience is the technology that brings this all together; the “browser” and user interface. Funnily enough, this will look fairly similar to the browser interface we already know and love. There will be the URI bar, the back button and, of course, the lion’s share will be given over to the display of the dapp (née webpage/website).

Using this consensus-based name resolution system (not unlike Namecoin in application), a URI can be reduced to the unique address of the front-end for that application (i.e. a hash). Through the information publication system, this can be expanded into a collection of files required for the front-end (e.g. an archive containing .html, .js, .css and .jpg files). This is the static portion of the dapp (-let).

It contains no dynamic content; that is instead serviced through the other communication channels. For gathering and submitting dynamic but publicly available content whose provenance needs to be absolutely determined and which must be held immutably forever (“set in stone”), such as reputation, balances and so forth, there is a Javascript-based API for interacting with the consensus engine. For gathering and submitting dynamic, potentially private content that is necessarily volatile and subject to annihilation or lack of availability, the p2p-messaging engine is used.

There will be a few superficial differences; we’ll see a move away from the traditional client-server URL model of addresses like “https://address/path”, and instead start to see new-form addresses such as “goldcoin” and “uk.gov.” Name resolution will be carried out by a consensus engine-based contract and trivially be redirected or augmented by the user. Periods would allow multiple levels of name resolution - “uk.gov”, for example, might pass the “gov” subname into the name resolver given by “uk.”

Due to the ever-transient nature of the information made available to the browser automatically and accidentally through the update of the consensus back end and the maintenance of the peer network, we’ll see background dapps or dapplets play a great role in our Web 3.0 experience. Either through always-visible Mac OS dock-like dynamic iconic infographics or dashboard-style dynamic dapplets, we’ll be kept accidentally up to date about that which we care.

After the initial synchronization process, page-loading times will reduce to zero as the static data is pre-downloaded and guaranteed up to date, and the dynamic data (delivered through the consensus engine or p2p-messaging engine) are also maintained up to date. While being synchronized, the user experience will be perfectly solid though actual information shown may be out of date (though may easily not, and can be annotated as such).

For a user of Web 3.0, all interactions will be carried out pseudonymously, securely, and for many services, trustlessly. Those that require a third party or parties, the tools will give the users and App-developers the ability to spread the trust among multiple different, possibly competing, entities, massively reducing the amount of trust one must place in the hands of any given single entity.

With the separation of APIs from front end and back ends, we’ll see additional ability to utilize differing front-end solutions able to deliver a superior user experience. Qt’s QtQuick and QML technologies could, for example, be a stand-in replacement for the HTML/CSS combination of traditional web technologies and would provide native interfaces and rich accelerated graphics with minimal syntactical overhead and on a highly effective reactive-programming paradigm.

Migration

The changeover will be gradual.

On Web 2, we’ll increasingly see sites whose back ends utilize Web 3.0-like components such as Bitcoin, BitTorrent and Namecoin. This trend will continue, and the truly Web 3.0 platform Ethereum will likely be used by sites that wish to provide transactional evidence of their content, such as voting sites and exchanges. Of course, a system is only as secure as the weakest link, and so eventually such sites will transition themselves onto a Web 3.0 browser which can provide end-to-end security and trustless interaction.

Say “hello” to Web 3.0, a secure social operating system.

Originally entitled “Dapps: What Web 3.0 Looks Like” and published April 17, 2014 on Gavin Wood’s blog, Insights Into a Modern World.

Read more:

What Jack Dorsey’s Beef With ‘Web 3′ Is Really About

What Is Web 3 and Why Is Everyone Talking About It?