# Wetware

Decentralized Cloud architecture for Web3.

[](https://matrix.to/#/#wetware:matrix.org) [](https://godoc.org/github.com/wetware/ww)

## What is Wetware?

Wetware is a portable environment for writing secure, scalable and performant distributed applications. It aspires to be Web3's answer to Cloud Computing, providing a thin cluster abstraction over physical and virtual hardware, and supplementing this with standardized services like pub-sub, blob storage, process management and synchronization primitives.

In keeping with the Web3 ethos, Wetware is built with distribution and decentralization in mind. It sports a fully peer-to-peer architecture, which avoids single points of failure, and allows it to scale effortlessly. It makes judicious use of distributed ledger technology to host security-critical functions like access control away from centralized platforms like Amazon Web Services (AWS), which represent unacceptable risks to system integrity, sovereignty and the founding principles of the Open Web.

Crucially, Wetware resists the urge to overcommit to emerging technologies, reserving these for a carefully-considered selection of use cases. In other words, we believe that the way forward is through reasoned, prudent and judicious engineering, not hype. In practice, this means we adopt blockchain technologies *cautiously*, and only after exhausting alternatives. Wetware does not include a blockchain in its core protocol, for example, and never will. Where blockchains *are* employed, we confine them to the upper layers of the protocol, where they are but one of many pluggable implementations for supporting services like identity management, access control, audit logging and inter-cluster routing.

This caution should not, however, be mistaken for contrarianism. Wetware is a decidedly Web3 project, but takes a broad view of the Web3 ecosystem that ecompases more than blockchains. We take the view that Web3 is fundamentally about P2P architectures in general, and their crucial role in moving *social transactions* off of Big Tech platforms. This idea is defined and further developed in the next section, and it suffices at present to note that blockchains, cryptocurrencies, NFTs, smart contracts, *etc.* are but a small subset of a much richer Web3 ecosystem. By taking the long view of Web3, and by considering it as an extension of established technology rather than a replacement, we hope to win the community's trust and play a leading role in Web3's adoption into the main stream.

To this end, Wetware integrates natively into the [Protocol Labs ecosystem](https://protocol.ai/work/), where it leverages some of the most successful P2P technologies, protocols and paradigms: content-routing, self-optimizing overlay networks, P2P file-transfer, etc. Moreover, it builds on decades of research into capability-based security and network-object protocols, and actively contributes to the the Cap'n Proto ecosystem through Open Source code contributions and funding partnerships. It is also designed to run on any POSIX-compliant OS (*e.g.* Linux, MacOS, BSD, Plan9, *etc.*), using commodity hardware, and to be as general-purpose and unopinionated as possible, providing only a thin "overlay OS" abstraction.

The result is a novel approach to building and managing distributed applications that will feel familiar to anyone who has ever used a command-line interface, while being refreshingly simple to operate, and freeing users from the walled gardens of Big Tech platforms.

## Why Wetware?

To understand the importance of Wetware, we must first state the obvious: cloud vendors, today, are a necessary part of modern Web infrastructure. With some exceptions, the modern web application exhibits several features that make it necessary to distribute its functionality over several compute nodes, often dynamically: horizontal scalability, fail-over redundancy, and low server-to-user latency.

Addressing these is only sufficient in theory, however. In practice, these resources will also need to be managed. This includes provisions for deploying and orchestrating processes, managing configuration, and a whole host of "services" consumed by the application, and which facilitate the development of business logic: pub-sub, blob storage, DNS and key-value storage to name but a few. With this in mind, the appeal of Cloud Computing becomes apparent. Not only does it address the on-demand provisioning of hardware resources, it also reduces development time, and serves as an interface for operations engineers to manage both hardware and the application stack. In other words, the Cloud is more than physical hosting. It is an interface between "dev" and "ops". Without it, software development costs increase dramatically, *especially* in early-stage projects for which the burden of running (to say nothing of _building_) multiple backend services would not amortize well.

With this in mind, let us point to two major problems with contemporary Cloud infrastructure.

### Cloud hosting is not ready for Web3

Cloud hosting is not ready for Web3, and it's unclear whether it even can be in principle. Where Web 1.0 considers self-hosting a political value -- an ideal to be preserved in pursuit of an "Open Internet" -- Web 3.0 makes self-hosting a hard technical obligation. Without a healthy minority of blockchain, IPFS, or other such nodes running under the full control of end-users, the security and censorship-resistance guarantees of these protocols are weakened.

More practically and more immediately, the datacenter-centric architecture of Cloud computing makes little sense in an era of multi-region deployments, edge computing, cloud/dedicated hybrid datacenters, and P2P computing on roaming devices. Our experience working in technology startups has revealed that the current generation of Seed and Series-A companies are already brushing against the limits of the regional datacenter model, and while they are able to invest significant capital into building -- and some would even say *reinventing* -- cluster-orchestration solutions of global scale, individual creators, inventors and the open-source community are left high and dry. Even "small" websites now require distrubtion networks for static assets, and the next generation of web applications will be critically dependent on the distribution, routing and orchestration of _dynamic_ resources.

### Cloud vendors are hostile to the Web

In addition to the incidental threats to the Open Internet, Cloud vendors have shown themselves to be actively hostile to its principles. The phenomenon of retaining customers through "vendor lock-in" is well-documented, especially as it applies to the strategy of "vendored services". Briefly, the strategy is to make available a set of non-portable, though deeply convenient, Cloud services. The aim is to entice customers into treating these servies as core dependencies, at which point it becomes effectively impossible to migrate the application to a different platform. A similar reasoning can be applied to vendor-provided facilities for managing user accounts, access controls and secrets-management. An organization that runs on AWS' IAM platform, say, finds itself locked-in to an even greater degree!

The astute reader will have noted that vendor lock-in through this second vector -- administrative services -- is far more pervasive than the first, and is by no means limited to the Cloud hosting industry. In fact, it points to the most pathological qualities of Web 2.0's "platform economy": gated communities, captive clienteles, closed standards, restricted use of technology and rent-seeking. Volumes have indeed been written about Web 2.0's threat to institutional and national sovereignty, fair market competition, regulatory compliance (especially with regards to data jurisdiction), and individual privacy. Rather than restating what others have better articulated, we draw the reader's attention to what we believe to be the essential defining quality of Web 2.0: _social transaction_.

The bulk of Web 1.0 is best described as the straightforward translation of the mass-media and telecom industries from physical to virtual space. In the 90's and early 2000's, the entities we now call "content producers" were overwhelmingly composed of corporate or institutional actors following a traditional "push" model of media distribution, and what little user-to-user interaction existed was limited to direct communication (*e.g.* via text-based "instant messaging" or e-mail). Conspicuously absent from Web 1.0 is the widespread sharing of web resources as a means of modeling the social interactions that subtend work and leisure. Web 1.0 had no "likes", "shares" and "comments", just as it had no "single sign-on" (SSO), "edit mode" and "role-based access control". In other words, liking a post, assigning a role to a user in one's org, and rebooting a Cloud compute instance are all made of the same "stuff"; that is, they all involve modeling a domain in terms of transferring Web resources between [principals](https://en.wikipedia.org/wiki/Principal_(computer_security)). We refer to this paradigm as *social transaction*, and make the following observation.

>The distinguishing feature of Web 2.0 is the hosting of social transactions on a closed platform, itself hosted on a proprietary domain.

This idea not only captures the "social media" phenomenon, which was long held to be the defining feature of Web 2.0, but also unites it with the other concepts present in the word-cloud of Web 2.0 buzzwords: SaaS, Web platforms, "architecture of participation", community, *etc*. Moreover, it makes plain the reasons why venture-backed startups of the Web 2.0 era prioritize growth (in number of users!) over profit; the users are not the customers, they are the product. Thus, the common feature shared by Web 2.0's most successful enterprises is that each has managed to secure a natural monopoly on an entire class of social interaction. Facebook is where friends socialize, Google is where work gets done, Linkedin is where professionals network, GitHub is where developers collaborate on software, Instagram is where people show off, Twitter is for gossip, Tinder is (in understated terms) for flirting, and Cloud-hosting providers are where engineers go to manage IT resources.

If Web 2.0 is concerned with monopolizing classes of social transaction, what then is Web3? Clearly, the usual appeal to "cryptocurrency", or even "peer-to-peer", is inadequate. Instead, we propose that Web3 is at its core an exercise in breaking these monopolies, specifically by decentralizing social transaction at the technical level. So viewed, blockchains have less to do with using distributed ledgers to store economic value, than the inverse: using economic incentives to secure a distributed ledger *capable of modeling complex social transactions*. Certainly, commercial transactions are one kind of social transaction, and certainly, the invention of the Bitcoin protocol represents a tipping point for Web3. However, reducing the whole of blockchains -- most particularly the Ethereum ecosystem -- to the realm of finance risks missing the forest for the trees. What blockchains uniquely provide are trustless storage mediums, capable of hosting data across domains, beyond the control of any one entity. To wit: NFTs do not need to be exported from OpenSea in order to be used in another system; they are addressable to all internet-connected systems by default. So too should it be unnecessary to migrate IAM roles to alternate hosting providers.

In sum, we espouse the view that permissionless blockchains are best viewed as specialized databases providing "pay to write once; read forever" semantics, which on its own makes them a powerful tool for decentralizing social transaction. Paired with other major breakthroughs in P2P computing (content routing, resilient overlays, distributed clocks, CRDTs, *etc*.), however, they become revolutionary.

## Towards a rebirth of the hacker garage

Let us solidify our understanding of Wetware's role in Web3 with a practical illustration. Consider the process by which the typical Web 1.0 upstart is created, *i.e.* the now-ubiquitous image of the "hacker garage". A handful of co-founders install physical hardware in the garage affixed to the side of the CEO's house. They lay down power cables, connect individual PC towers or rack servers with ethernet cables, plug in a few monitors, and install Linux. For the next few months, these computers will bear the load of their early adopters, over a single upstream WAN connection. When this load exceeds their capacity, they migrate to dedicated hosting in a small, local datacenter. This involves buying or renting rack servers, installing them, and then physically displacing their existing infrastructure. When their company requires regional proximity to their users, they repeat the process again.

Despite back-breaking work and significant fixed costs, the cofounders enjoy one major advantage: complete control over hardware and software. And this advantage is not to be underestimated! For small to medium businesses, it notably allows for a "secure enclave" architecture in which core configuration, secrets and utilities are trivially kept off-site, and under sovereign control. The founders need only access their on-site infrastructure from their garage, via a gateway server, VPN, or similar. This architecture offers significant advantages to small and medium-sized organizations. In particular, it facilitates expansion into other hosting providers using a hub-and-spoke model with the garage (or perhaps later, a VPN of home-office desktop PCs) as the central locus of control. This is especially valuable in cases where hosting providers are prone to denying service to companies that are perceived as disruptive or illegible, a scenario all-too-common in Web3. More generally, this architecture is convenient because it is trivial to secure, reflects the organizational structure of the company, and is invariant across scale (except, perhaps, at the magacorp scale).

Instead of a cheap, flexible and sovereign architecture, Web 2.0 entrepreneurs are given an ersatz of the hacker garage: locked-down hardware, free credits that incidentally expire, a honeypot of convenience designed to ensnare successful upstarts and drain their resources, and no recourse in the event of expulsion.

Let us now examine how Wetware changes the outcome. Rather than a physical hacker-garage or a Cloud account, our Web3 cofounders are able to cluster their physical hardware -- laptops, desktop PCs, mobile phones, home servers, *etc*. -- into a virtual one. Rather than a LAN, this hacker-cluster sports an efficient, hyper-scalable overlay network that works over the public internet. The underlying hardware remains in an office or basement, or roams across cell-towers and cafe hotspots. Moreover, our cofounders still enjoy the most significant benefits of Cloud architecture. Wetware's suite of standardized cluster services provide portable alternatives to those offered by the Cloud, and its authentication layer integrates into any EVM-compatible blockchain to provide decentralized, migration-free hosting of the core social transactions that underpin its operations.

From an architectural perspective, Wetware enables secure-enclave computing to an astronomically larger degree than Web 1.0. As an organization grows, it needs only provision "dumb" compute instances from various hosting providers with Wetware to elastically scale the core cluster. Such instances can be dedicated servers, on-demand virtual machine instances, or even edge-compute nodes. Wetware provides a uniform plane on which to manage heterogenous resources, makes no assumptions about network topology, and is datacenter-agnostic.

The result is a "home base" of personal computing resources that can grow dynamically, investing Cloud providers when under load, and scaling back when quiescent. It bridges the unfettered experimentation of the hacker garage with the mass-scale of the datacenter.

## Where do we go from here?

At the time of writing, Wetware is alpha software. However, it has been [successfully deployed in production settings](https://github.com/wetware/ww#wetware-users) as early as `v0.0.0-alpha.1`, where has proven to be remarkably stable and performant. We encourage developers and operations engineers alike to take it for a spin.

To start, you can [download the latest release](https://github.com/wetware/ww/releases/latest), and visit [wetware.run](https://wetware.run) to learn how to bootstrap a production-read cluster in under 5 minutes. There, you will also find our documentation, which includes step-by-step tutorials and detailed how-tos for a variety of situations.

If you're interested in contributing, hacking on Wetware, or just want to satisfy your technological curiosity, you should visit our [official GitHub repository](https://github.com/wetware/ww).

And if you need any help, or just want to talk nerdy to us, we warmly invite you to join our thriving community on [Matrix](https://matrix.to/#/!nmbyiFdMUXJctbesHp:matrix.org?via=matrix.org) ❤️.

See you on the internets!

-- The Wetware Community