Today, most of the apps we use rely on the cloud, storing data centrally for easy access from any device, anywhere, at any time. The elasticity of cloud computing means these applications can handle demand fluctuations without breaking a sweat.
But the cloud isn’t without limitations. This article will look into two distinct technical movements that have emerged in response to the various flaws of the current internet - web3 and the local first internet. While neither of these categories is sufficient on their own to build a strictly superior web than what we have today, their combined technical and philosophical insights pave the way for a powerful new kind of cloud, on which the next evolution of the web will be built.
Local and Global
The balance between local and global is the core topic of this article, and we will begin by defining the terms:
Dynamic, interactive web pages with user-generated content have made for a vastly more interesting internet. Cloud providers such as AWS and Azure have made deploying and maintaining these applications much easier, providing near-100% uptime and providing scale as required.
Most applications we interact with run in the cloud. Tools such as Docker and Terraform enable cloud-native applications to maximally benefit from the cloud’s strengths. Storing data in a centralized purpose built hub makes it easily accessible by any device anywhere in the world, and elastically scalable compute means that apps don’t have to anticipate demand.
Traditional cloud infrastructure is somewhat local: Companies can typically connect to this infrastructure through APIs, allowing them to define their business logic as desired, in whichever programming language or framework they want. This provides customizability and, as a result, locality. On the other hand, every interaction with a cloud-based application has to go through the cloud, and its data is stored in the cloud. The application is therefore not merely reaping the benefits of the cloud; it is bound to it and simply cannot interact with the user directly, independently of it.
In addition, cloud providers that are shared by millions of companies are not very global: It does not make sense to talk about the global state of AWS, as data is siloed and interoperability is limited.
In fact, it would be impossible for AWS to have a global state with a high degree of interoperability, since non-mutually trusting people would have access to each other's state. For AWS to support global state, Amazon would have to define the rules and exact ways for all the possible interactions, and each AWS user would now have to trust Amazon to correctly enforce the claimed rules — this would simply never happen.
Pros
Cons
In highly skeuomorphic fashion, Web3 aims to replace the cloud with a decentralized infrastructure stack using permissionless blockchains. In general, the goal is to reduce the level of control and ownership that big companies currently exercise over their users.
In practice, at a high level, there are two core changes from Web2 to Web3:
Web3 is strongly global, even making possible instantaneous composability across applications, and with all state globally available.
It is not local, however, as applications are now little more than cogs in a machine, giving up all their sovereignty to the blockchain on which they run.
At this point, it is worth pointing out that local and global somewhat contradict each other: If a given programming model is global within the system, for example, participants cannot choose their own programming model.
In a way, the main flaw of Web3 is that it is too global. Later in the article, we will see that the next web should only be *sufficiently* global: it must be permissionless to join, whereby a set of global laws is needed which prevent bad actors from joining the network and harming other participants; there needs to be a minimal global state which allows applications to cater to any user on the network, as well as integrate with other applications; finally we need certain global standards to provide Web3-like interoperability without relying on third parties.
*Typically there are UIs associated with Web3 applications but users can in practice interface directly with web3 applications.
Pros
Cons
Another reaction to the existing web, local-first software aims to move data and compute out of the cloud and into the user devices directly, i.e. to build 100% local, 0% global applications. It should be clear that this complete lack of global features makes the local-first internet insufficient for the next iteration of the web. The reason we’re including it here is twofold: on the one hand, local-first applications exhibit properties which we also want from the future web — even beyond that, as we will later see the main technical underpinning of the local-first internet is also a core building block of the future web.
One arena where local-first software can be useful is collaboration tools: This article was originally written in HackMD, where every change to the document needs to go to the cloud and back, and conflicts have to be resolved manually. A local-first HackMD would have none of these issues, and it would function equally well offline as online, with the latency issues caused by the roundtrip to the cloud now gone.
In fact, it would not rely on the cloud or even the internet at all; collaborators could synchronize via e.g. bluetooth or some P2P network.
Local-first software fully removes dependencies on cloud storage and compute. Local-first software is strictly focused on the interaction between user and application, and does not currently consider shared state across applications, hence it is not at all global. Also, as it is described here local-first software is not suited to global applications with shared state. For example, if everyone in the world had editing rights to your HackMD, the result would likely not be very conducive to effective collaborative work.
Pros
Cons
We have so far seen two very different approaches to building a better internet: Web3 (strongly global, not at all local) and the local-first internet (not at all global, strongly local). This section will suggest how we can take ideas from both to create a system which maximizes the local properties, while being sufficiently global to incorporate the desirable features of Web3. We call this the Glocal Web, and refer to its underlying infrastructure as the Glocal Cloud.
As we will explore further down in the section, developers building applications for the glocal web can enjoy properties which Web3 simply cannot offer them: they can customize their own runtime environment, reliably generate revenue, and scale elastically as their bandwidth demand changes. When we describe the glocal web as sufficiently global, what we really mean is “sufficiently global to have as strong security and interoperability as Web3” — prospective glocal web businesses do not have to sacrifice any desired features provided by Web3.
The core technical ingredient to achieving our goals is a class of data structures called CRDTs. Most local-first software is totally dependent on CRDTs, and as we will briefly explore below before returning to the glocal web, it will become clear how they enable the desired features of local-first applications.
Conflict-Free Replicated Data Types (CRDTs) first appeared in 2011. As the name suggests, a CRDT is a replicated data structure which can be accessed by multiple devices concurrently, without conflicts occurring – for example, a couple with a CRDT-powered shopping list could each modify the list while they're shopping without syncing hiccups.
A core feature of a CRDT is that for all operations applied to it, the operations commute with each other. That is, the result of the operations is always the same regardless of their order. One consequence is that participants working on the same object do not need to continuously synchronize with each other – they can be offline for as long as they want, and then simply send over either the list of operations (operation-based CRDTs), the entire new state (state-based CRDTs), or simply the list of state changes (Delta state CRDTs) once they go back online. At this point, like magic, the CRDT automatically merges the changes in a deterministic, conflict-free way.
As mentioned, CRDTs are heavily used in local-first software. For example, the local-first HackMD would more than likely be based on a CRDT.
In short, here’s the idea:
Interestingly, the social medium Farcaster is somewhat of a special-purpose version of the described system, where the posts are CRDTs and a decentralized validator set periodically agrees on the CRDT set (see more here).
Whereas each local-first application is a distinct CRDT, glocal web applications all interact with a global set of CRDTs.
Similar to the Web2 cloud, the application can connect to the system with APIs. Unlike the cloud-native applications of Web2, the glocal web app only needs to periodically send and read data for the purposes of synchronization and interoperability. Each application can stay offline for as long as it wants, without changing the behavior of the state CRDT when the state changes ultimately do arrive.
Web3’s smart contract based applications are cogs in a machine that rely on third party validators of the underlying blockchain to process transactions. On the other hand, glocal web applications themselves process their users’ interactions with their application.
A glocal web application can be written in any programming language, and its runtime environment only needs to satisfy a few minimal global laws to uphold the security of all the applications making up the network—the expressivity of application developers is as strong as it can be without enabling forbidden actions such as the ability of the app to spend its users’ funds without requiring a valid signature.
The glocal cloud is strongly local, with applications needing to use the decentralized global cloud only for synchronization and interaction with other apps.
Similar to a blockchain, the enforced rules and standards of the glocal system enable the applications to share data securely, providing trusted infrastructure such that even untrusted parties can interact without risk, and trusted parties can integrate more deeply without a third party reliance.
As we saw above, the glocal web is not overly global; as aforementioned, only minimal global state, laws, and standards are implemented, and this makes possible things like safe atomic composability between applications, with no third-party reliance.
In the context of the glocal web, we think of the word glocal as being the full word local with just the first letter from global, as this reflects the relative strength of the properties much better than “it has Hamming distance 1 from both words”.
Here we look at additional benefits of the Glocal web beyond the local (customizability, flexibility) and global (interoperability, connectivity) properties we have already covered.
Just like Web3, the glocal web enables ownership and assets baked into the cloud itself, whereby people can self-custody their money and freely engage with the financial applications of the glocal web, with no limitations imposed by the underlying glocal cloud. This is ensured by the protocol on which the decentralized glocal cloud is based.
Unlike Web3, these financial applications can innovate along many different axes and have a lot of autonomy, since the glocal cloud is so strongly local.
The global properties of the future internet cannot simply be tied to its state, as explored previously; for the network to be permissionless to join and yet still safe against bad actors, the glocal cloud needs to run a consensus protocol.
Consensus is the main bottleneck preventing blockchains, and by extension, Web3 from scaling. The weaker consensus requirements for CRDT-based systems make them considerably more performant than blockchains. Specifically, the validator set does not have to agree on a total order of transactions (state changes) – agreeing on ordering is the most labor-intensive aspect of consensus.
Moreover, since the state changes submitted by the applications do not need ordering, validators can propagate and process them all in parallel. Parallelization here means that the network can scale its throughput simply by validators adding workers (transaction-processing computers) – in short, it can scale indefinitely.
The glocal web will allow applications to scale based on need, just as current cloud infrastructure such as AWS does.
Similar to the local-first internet, users can interact with an application directly, without the (decentralized) cloud roundtrip that Web3 requires, or the (centralized) cloud roundtrip that current applications demand.
For a different kind of speed, blockchains often speak of block times, or the frequency with which state is updated. Many applications, in particular financial ones, benefit greatly from low latency, meaning that this frequency is high. It is a feature of strongly global systems such as blockchains that the latency is high — realistically at least 400ms thanks to consensus with globally distributed nodes. Glocal web applications can update their state with whichever frequency they like, meaning that latency can be as low as 1ms or even less!
Latency is an example of a property which should clearly be local as in the glocal web, but which is global in Web3.
Building applications which work equally well offline as they do online is possible on the glocal web, just as it is in the local-first internet: Applications locally compute changes to state based on user inputs (transactions), and periodically submits lists of changes to the validator set (the glocal cloud) for synchronization.
Note that we here refer to “offline” in terms of the glocal cloud: most user-application interactions will still take place over the regular internet.
Let's say there is a public voting app, which stores votes of participants as part of some globally readable state – this provides transparency, and is practical for people who already interact with other applications using the same cloud infrastructure. Now, in order to vote, you need to provide the app with some sort of identity document.
Barring some fancy cryptographic tools (note: there are Web3-like protocols which enjoy stronger privacy guarantees than the glocal web), Web3 would require the user to post this document directly to the blockchain, visible for everyone to see.
In contrast, a glocal voting app could simply verify the user's identity locally, and then allow them to vote.
More generally, glocal applications can make use of arbitrary amounts of private data which are not shared with the rest of the cloud's participants.
The CAP theorem states that permissionless systems need to choose between strong finality guarantees and strong liveness guarantees, and cannot have both. The CAP theorem is not outcome-based however; two different execution traces leading to the same result are considered different by CAP.
For the glocal web we only care about nodes all reaching the same outcome: we have already seen that the CRDT-based glocal cloud does not need a uniform total ordering to achieve this. This means that two different nodes running the cloud can execute the same set of transactions in a different order, but because of the way the state model is organized, they will both have the same end state. Moreover, as part of the CRDT definition, a transaction which has been deemed valid cannot be invalidated by other transactions.
This property is called logical monotonicity, and it is the main assumption needed to satisfy the CALM (Consistency As Logical Monotonicity) theorem. The CALM theorem states that logical monotonicity gets you consistency (finality) for free. Systems that satisfy the CALM theorem in practice circumvent the impossibility presented by the CAP theorem: they can satisfy all three properties (we suggest this article for anyone who wants more detail on CALM in itself and in the context of CAP).
The glocal web will not be affected by the CAP theorem.
The glocal web builds on ideas from Web3 and local-first software to build an internet which is non-skeuomorphic and more efficient than the current iteration of cloud-enabled applications and experiences, and which enables the unencumbered movement of money and assets.
It's coming sooner than you think.
