Note: originally posted Wednesday, 17 April 2014 on gavofyork's blog Insights into a Modern World.

Apps: What Web 3.0 Looks Like

As we move into the future, we find increasing need for a zero-trust interaction system. Even pre-Snowden, we had realised that entrusting our information to arbitrary entities on the internet was fraught with danger. However, post-Snowden the argument plainly falls in the hand of those who believe that large organisations and governments routinely attempt to stretch and overstep their authority. Thus we realise that entrusting our information to organisations in general is a fundamentally broken model. The chance of an organisation not meddling with our data is merely the effort required minus their expected gains. Given they tend to have an income model that requires they know as much about people as possible the realist will realise that the potential for convert 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, 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 reimagination of the sorts of things that 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 that we assume to be agreed, 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 organisation 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.

The first, we already have much of: a decentralised, 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 Bit Torrent. Every time you click on a magnet link of Bit Torrent, 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 Bit Torrent, to incentivise 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 incentivisation framework is intrinsic to the protocol, we become (at this level, anyway) DDoS-proof by design. How's that for a bonus?

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 provide ultimate message logistics, the use of transmission-protocol level addresses becomes needless; addresses, where once user or port together with 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 signalling 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 an game-theoretic adaptive network system. Each peer attempts to maximise 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 (e.g. of a sender address or topic---both unencrypted---beginning with a particular bit string).

In Web 3.0 this portion allows peers to communicate, update and self-organise 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.

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 making reducing the changes of renege or wilful 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 generalised global transaction processing system the first workable example of which is the Ethereum project.

The traditional web does not fundamentally address consensus, instead falling back on centralised 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.

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 lions share will be given over to the display of the ĐApp (nĂ© 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 & .jpg files). This is the static portion of the ĐApp (-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 "". Name resolution will be carried out by a consensus-engine-based contract and can trivially be redirected or augmented by the user. Periods would allow multiple levels of name resolution - "", 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-ĐApps or ĐApplets 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 ĐApplets, we'll be kept accidentally up to date about that which we care.

After the initial synchronisation 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 synchronised, 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).

As a user of Web 3.0, all interactions will be carried out pseudonymously, securely and for many services, trustlessly. Those that require third party(-ies), 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 utilise differing front-end solutions able to deliver a superior user-experience. Qt's QtQuick and QML technologies could, e.g. 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.

The changeover will be gradual, on Web 2.0, we'll increasingly see sites whose back-ends utilise Web 3.0-like components such as Bitcoin, BitTorrent, 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 e.g. 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.