2. A Reader's Primer: Computers, Networks, and Software in Plain Language

This chapter builds, from nothing, the small set of ideas that the rest of the book quietly depends on. It assumes a reader who has used a smartphone, sent a message, and logged in to an account — but who has never had occasion to ask what is actually happening underneath. The aim is not to make the reader an engineer. It is to install a handful of mental models — computer, data, network, server, cloud, database, protocol, software, account, trust — clearly enough that, when later chapters claim Web3 is an attempt to change who controls the database, the sentence lands with real meaning rather than passing as slogan. Everything here is conventional computer science, presented plainly; the controversial material comes later. We end by asking the one question that the entire book turns on: when you use a digital service, whose computer is keeping the record, and what stops them from changing it?

What a computer actually does

Strip away the screen, the apps, and the brand names, and a computer is a machine that does only two things: it stores information, and it follows instructions for changing that information. That is genuinely almost all of it. The conceptual blueprint for this kind of machine — a single device that holds both the information it works on and the list of instructions for working on it, in the same memory — was set out in the 1940s, most influentially in von Neumann's 1945 report on the EDVAC design, and nearly every computer since, including the phone in your pocket, follows that basic plan (von Neumann, 1945). Earlier still, Turing (1936) had shown mathematically that a single, simple machine could, in principle, carry out any computation if you fed it the right instructions — the deep reason one device can be a calculator, a camera, a map, and a telephone by turns.

Two words deserve definition before we go on.

Information here means anything that can be written down as a series of choices — yes or no, on or off, 0 or 1. A single such choice is called a bit (short for "binary digit"). The insight that any message — a number, a letter, a photograph, a song — can be encoded as a string of these on/off choices, and measured in bits, is due to Shannon (1948), and it is the foundation of all digital technology.

In plain terms: a computer is a fast, tireless clerk who can only read and write 1s and 0s, and who never gets bored or improvises. Everything impressive a computer does is built up out of unimaginably many of these tiny, dumb steps, done very quickly.

When we say a computer "stores" information, the information lives in two kinds of place. There is memory (the fast, temporary workspace the machine uses while it is actively doing something — wiped clean when the power goes off), and there is storage (the slower, permanent shelf where things are kept even when the machine is turned off, such as the chip inside a phone or a hard drive in a laptop). The everyday distinction is the difference between the papers spread on your desk while you work (memory) and the filing cabinet you put them back into at night (storage).

Data, files, and programs

The information a computer stores is called data — any recorded fact or content, from a single number to a feature-length film, expressed in those 1s and 0s. To keep data manageable, a computer groups related data together and gives the bundle a name. That named bundle is a file.

A file is, in essence, a labelled box of data — the digital equivalent of a folder with a name written on the tab. "holiday-photo.jpg" and "rent-receipt.pdf" are both just long strings of bits that the system has labelled, sized, and dated so it can find them again.

The second thing a computer does — follow instructions — brings us to the most important distinction in this chapter. A program (the technical word for software, which we return to below) is a list of instructions that tells the computer, step by step, what to do with data: which bits to read, how to change them, what to write back, what to show on the screen.

In plain terms: data is the stuff; a program is the recipe. A photo is data. The app that brightens, crops, and saves the photo is a program. The genius — and the danger — of the von Neumann design is that the recipe is itself just more data sitting in the same memory, which is why a computer can be handed a new program and instantly become a new kind of tool. The honest caveat: this also means a computer will follow a bad or hostile recipe exactly as faithfully as a good one. It has no judgement. This will matter a great deal when we reach software that handles money.

What a network is

A single computer is useful. Computers become world-changing when they are connected, because then they can pass data to one another. A network is simply two or more computers linked so they can exchange data.

A network is, in essence, a postal system for information: a set of agreed routes and rules that let a message leave one machine and arrive, intact, at another. The cables, fibre-optic lines, and radio signals (Wi-Fi, mobile data) are the roads; the messages are the mail.

The internet is the largest such network — in fact a network of networks, the global web of interconnected smaller networks that lets a computer in one country exchange data with a computer in another. The word is a contraction of "inter-network." It is worth holding two facts in mind. First, the internet is physical: real cables (including bundles lying on the ocean floor), real radio towers, real buildings full of machines. It is not a cloud in the sky, whatever the marketing says. Second, no single company or government owns the internet as a whole; it works because everyone who connects to it agrees to use the same rules for addressing and forwarding data — a point we develop under "protocols" below (Kurose & Ross, 2017).

In plain terms: the internet is not a thing you own a piece of; it is an agreement that billions of separately owned machines all follow, so that any one of them can send a message to any other. Think of the global postal union: many national mail services, separately run, that have agreed on enough common rules that a letter can cross borders.

When data travels across a network, it is not sent as one solid block. It is chopped into small standardized chunks called packets, each labelled with where it came from and where it is going, sent separately, and reassembled at the far end — rather like shipping a house as a stack of labelled flat-pack boxes rather than as a single object. This is why a video call can keep going, a little degraded, even when the connection is poor: some boxes arrive late or get re-sent without the whole delivery failing.

Servers and clients: the restaurant model

Most of the digital services people use every day follow a particular arrangement, and understanding it is essential to understanding what Web3 is reacting against. The arrangement has two roles: clients and servers.

A server is a computer (often a powerful one, kept running constantly in a specialized building) whose job is to provide something — data, a web page, a service — when asked. A client is a computer or program that requests that something. Your phone running an app, or your laptop running a web browser, is the client; the company's machine that the app talks to is the server.

The cleanest analogy is a restaurant.

Think of a restaurant. You, at the table, are the client. You do not walk into the kitchen and cook; you place an order. The waiter carries your order to the kitchen — the server — which prepares the dish and sends it back out. You receive a finished plate without ever seeing the pantry, the recipes, or the chef. In exactly this way, when you open a social-media app (client) and ask to see your feed, the request travels to the company's servers (the kitchen), which assemble the feed from their stored data and send back the finished result for your screen to display.

In plain terms: in the ordinary internet, you do not hold the food, and you do not run the kitchen. You ask, and a machine somewhere else — owned by someone else — decides what to send back. This is convenient: you need only a thin, cheap device, because the heavy work and the real data live on the server. But it also means the party that owns the kitchen is in charge of the meal. They can change the recipe, run out of a dish, refuse to serve you, or close the kitchen — and you, at the table, can only ask.

Where the analogy breaks down, honestly: a restaurant kitchen serves you food you then own and eat, whereas many digital services hand you only a temporary view of data that stays on their server. When you "see" your photos in a typical cloud app, you are usually looking at a copy streamed from the company's machine; the authoritative original sits with them. That asymmetry — they keep the real thing, you get a view of it — is one of the central facts the rest of this book examines.

This pattern is called the client–server model, and it is the dominant shape of today's internet. Its opposite, where there is no special central kitchen and every participant is both client and server — passing data directly to peers as equals — is called a peer-to-peer (or P2P) network. Hold that term lightly for now; peer-to-peer architecture is one of the technical roots of Web3, and we return to it in Part III.

"The cloud" is someone else's computer

Few phrases have done more to obscure how computers work than "the cloud." It sounds ethereal, placeless, almost magical. It is neither magic nor placeless.

The cloud is, in plain and slightly deflationary terms, other people's computers, rented by the hour. When a service runs "in the cloud," it means the servers doing the work, and the storage holding the data, are not in your home or office — they are machines in large buildings called data centres, owned and operated by a company, which rents out their use over the internet.

The most widely cited careful definition comes from the U.S. National Institute of Standards and Technology, which describes cloud computing as "a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources... that can be rapidly provisioned and released with minimal management effort" (Mell & Grance, 2011, p. 2). Translated: instead of buying and looking after your own machines, you tap into a giant shared supply of computing and storage that someone else maintains, paying only for what you use, and turning it up or down as needed.

In plain terms: "saving to the cloud" means sending a copy of your data to a company's data centre and trusting them to keep it safe and give it back. "Running in the cloud" means renting time on their machines instead of owning your own. The cloud is convenient and reliable in a way that few individuals could match on their own. But the deflated definition exposes the core relationship the rest of this book interrogates: your data, and the programs acting on it, increasingly live on machines you do not own, controlled by organizations you must simply trust.

A data centre, mentioned above, is a purpose-built warehouse filled with thousands of servers, plus the power, cooling, and security to keep them running every hour of every day. These buildings are where "the internet" physically lives. They are real estate, and they are owned — a quiet but decisive fact, because whoever owns the machines holds the data on them.

Databases: where the real record lives, and who keeps it

We now reach the single most important concept in this primer for understanding Web3, because Web3's central proposal is, at bottom, a proposal about databases.

Almost every digital service you use is, underneath the colourful screen, an interface to a database. A database is an organized collection of data, structured so that a program can store, find, update, and delete records quickly and reliably.

A database is, in essence, a very large, very fast, electronic ledger or filing system — think of an immense spreadsheet, or a library card catalogue, that a program (rather than a person) reads from and writes to. Your bank balance is a number in a database. Your social-media followers, your messages, your order history, your medical records: each is a set of rows in some organization's database.

The dominant way of organizing such data — into tables of rows and columns, with defined relationships between them — was formalized by Codd (1970) in a paper that underpins essentially all the "relational" databases running the modern world. The details do not matter here. What matters is one structural fact about how nearly all conventional databases are run.

Why databases usually have a single owner

A conventional database has an administrator — a person or organization with privileged control over it. The administrator can read any record, change any record, add records, and delete records. This is not an abuse or a flaw; it is the normal, intended design. Someone has to be in charge of the data: to fix mistakes, enforce rules, back it up, decide who may see what, and answer for it if something goes wrong.

There are good reasons this central-control model became universal. A single authoritative copy avoids disagreements about what the data "really" says. One responsible party can correct errors and reverse fraud. Access can be managed and the law can be obeyed. For a bank, a hospital, or an airline, a single trusted administrator of the records is not a problem to be solved; it is the entire point.

In plain terms: behind almost every app is a master record kept by one organization, and that organization holds the master keys. Your balance "is" whatever their database says it is. Your account "exists" because there is a row for you in their table — and it stops existing, for all practical purposes, if they delete that row. You experience a service; they hold the truth.

It is worth being precise and fair about what this does and does not mean. The administrator's power is legitimate and usually well-used. Banks do not casually rewrite balances; reputable companies do not idly delete accounts. They are restrained by law, regulation, competition, contracts, and their own reputations. The point is not that these organizations are villains. The point is structural: in the conventional design, you are relying on the administrator's honesty, competence, and continued goodwill, because they can change the record, and you cannot independently check or stop them. Whether that reliance is wise, and whether an alternative is possible or desirable, is precisely the argument this book will lay out.

In plain terms — and this is the sentence to carry into every later chapter: in today's internet, the question "what is true?" is answered by "whatever the owner of the relevant database says is true." Web3's foundational claim, which we will examine and test rather than endorse, is that for certain kinds of records — money, ownership, identity — we could instead keep the database in a shared way that no single party can quietly alter, so that trust rests on a verifiable process rather than on one organization's say-so. Hold that contrast; the entire book is an inquiry into whether it is real, and whether it is worth its costs.

Protocols: the shared rules that make any of this work

For separately owned computers to cooperate at all, they must agree in advance on how to format and exchange data. Such an agreement is called a protocol.

A protocol is, in essence, a shared language plus a set of manners — an agreed format and procedure that two parties follow so they can understand each other without having met. The clearest everyday parallel is the postal addressing system. Because the whole world has agreed on a convention — recipient name, street, city, postal code, country, in a known order — a letter written in Tokyo can be sorted and delivered in Toronto by people and machines who never coordinated directly. The envelope format is the protocol.

Protocols are everywhere in computing, layered one atop another. A few names will recur later, and you need only the gist of each:

• The Internet Protocol (IP) gives every device on the internet an address (an IP address, like a postal address for a machine) and defines how packets of data are labelled and forwarded toward that address (Postel, 1981). It is the addressing convention that lets any machine reach any other.
• HTTP (HyperText Transfer Protocol) is the convention web browsers and web servers use to request and deliver web pages — the rules behind the "http(s)://" at the start of a web address (Berners-Lee et al., 1996).

In plain terms: a protocol is a rulebook everyone voluntarily follows so that strangers' machines can work together. No one owns the rules of addressing an envelope; they are a shared standard, and that is exactly why the postal system is universal rather than the property of one company. The internet's foundational protocols are similar — open, shared standards rather than any firm's private property. Remember this, because a recurring Web3 argument is that more of the internet — including money and identity — should run on open, shared protocols that no company owns, rather than inside the private databases of individual firms. That is a genuine and important distinction, and we will weigh it carefully later.

A subtle but important design principle sits underneath the internet's protocols: the network's job is kept deliberately simple — just move packets — while the clever, application-specific work is pushed out to the computers at the edges. This "end-to-end" principle (Saltzer, Reed & Clark, 1984) is part of why the internet could host inventions its designers never imagined, from video calls to, eventually, blockchains. The pipes did not need to understand the content.

Software, programs, and apps

We met the word "program" earlier, as a list of instructions. The words software and app name the same idea at different scales and registers.

Software is the general term for programs — the instructions — as opposed to hardware, the physical machine. If the computer is a player piano, the hardware is the piano and the software is the music roll: the same instrument plays utterly different things depending on which roll you feed it. The word "soft" captures exactly this — it can be swapped and rewritten, while the hardware stays put.

An app (short for "application") is simply a program built to do a particular job for a user — a weather app, a banking app, a messaging app. On a phone, "installing an app" means copying that program's instructions onto your device so it can run. Crucially, most apps are only the client half of the restaurant model: the app on your phone is the waiter and the menu, while the kitchen — the server holding your real data — stays with the company.

In plain terms: when you "use an app," you are usually running a small program on your own device that mostly just talks to a much larger program and database running on the company's servers. The pretty part is on your phone; the power, and the data, are on their machines. This is why an app can suddenly change, lose a feature, or stop working entirely when the company alters or shuts down the server side — the part you cannot see and do not control.

This sets up a distinction that becomes central in Part IV. In the ordinary world, the program that matters — the one holding the authoritative database — runs on a company's private servers, where only they can inspect or change it. One of Web3's defining technical moves is to run certain programs on a shared, public infrastructure instead, where the program's rules are open to inspection and no single operator can alter them at will. Such programs are called smart contracts, and they get a full treatment in Chapter 13 (Ethereum and Smart Contracts). For now, only the contrast needs to land: software can run on one owner's machine, or on shared infrastructure, and the difference is about who can change the rules.

Accounts and passwords: what they really are

Two of the most familiar objects in digital life are also two of the most misunderstood: the account and the password. Both are best understood through the database concept we just built.

An account is, in essence, a row reserved for you in some organization's database — a record that says "this person exists in our system" and stores what the organization knows about you, plus a label (your username or email) that points to that row. "Having an account" with a service means they have created and maintain a record of you. It exists at their pleasure and on their machines. This is why a company can suspend, restrict, or delete "your" account: the record was always theirs, in their database, even though it concerns you.

A password is, in essence, a shared secret that lets the organization decide you are the rightful person for a given account — proof, when you arrive, that you are entitled to the row labelled with your name. It is like a secret word agreed with a doorkeeper who does not recognize your face: speak it correctly and you are let in to your record.

A few honest clarifications matter here, because they foreshadow a major theme.

First, in the conventional design, the company knows or can reset your password. Even when passwords are stored scrambled for safety (a process related to the "hashing" explained in Chapter 8), the company controls the door and the lock. If you forget your password, they can let you back in; conversely, if they choose, or are compelled, or are breached, the door can be opened without you.

In plain terms: an ordinary account is not really yours in the way a key to your own house is yours. It is more like a membership at a club: you have privileges as long as the club maintains your membership and recognizes you at the door — but the club owns the building, keeps the member list, and can revoke entry. Your access depends on their continued cooperation.

This is the precise point at which Web3 proposes something genuinely different in kind, so it is worth previewing carefully. In a Web3 system, identity and control are anchored not in a company's account-row plus a password the company can reset, but in a cryptographic key — a very large secret number that only you hold, which mathematically proves your control of your records without any company keeping a copy. The mechanics (public and private keys, digital signatures) are the subject of Chapter 8 (Cryptography for Non-Specialists) and Chapter 18 (Wallets, Keys, and Self-Custody). The promise is "ownership without a landlord"; the peril, equally real, is that if no company can reset your key, then losing it means losing everything, with no doorkeeper to appeal to. We flag both sides now and adjudicate them later. The structural contrast is what matters here: account-plus-password places the doorkeeper in charge; a private key places you in charge — for better and for worse.

What it means to "trust a company with your data"

We can now state plainly something the previous sections have been circling. Every time you use a typical digital service, you enter a relationship of trust — and it is worth defining that word precisely rather than sentimentally.

To trust a party, in this technical setting, means to accept a position in which they have the power to harm you, and to rely on the expectation that they will not. When you trust a company with your data, you are accepting that they hold the authoritative copy on their machines, that they can read it, change it, share it, lose it, or cut off your access — and you are betting that they will not do so in ways that hurt you. Trust, here, is not a warm feeling; it is exposure to someone else's choices.

Stack up what the earlier sections established and the scope of this exposure becomes clear. Your data lives in their database, on servers in their data centres ("the cloud"), reached through an app that is mostly just a client, gated by an account and password they ultimately control. At every layer, the authoritative thing is on their side of the counter. You hold a view; they hold the original and the controls.

Why do people accept this? Because, for the most part, it works well and the alternative is laborious. Running your own servers, securing your own database, and never losing your own keys is hard, and most people neither can nor wish to. Centralized custody buys real benefits: convenience, recoverability when you forget a password, someone to call when something breaks, fraud reversal, and the legal accountability that comes with an identifiable owner. These are not trivial; a sober account of Web3 must credit them, and later chapters do.

But the same arrangement carries characteristic risks, and naming them now lets later chapters be precise rather than alarmist. When one party holds the authoritative record and the controls, then: a single breach can expose millions of records at once (the data is concentrated, so the prize is large); the holder can change the rules, the terms, or the price unilaterally; the holder can, by choice or under legal or political pressure, deny you access or hand your data to others; and if the holder fails, is acquired, or simply shuts the service down, the records — and the access — can vanish. Critics of the present internet, whose arguments we examine in Chapter 6 (The Discontents of Web 2.0), add a further charge: that some businesses are built on extracting value from this concentrated data in ways users neither see nor meaningfully consent to (a critique most prominently associated with Zuboff, 2019). The book will weigh these claims on their evidence; here we are only equipping the reader to follow the argument.

In plain terms: "trusting a company with your data" means they keep the real copy and the master keys, and you hope they behave. Usually they do. Sometimes — through error, greed, coercion, bankruptcy, or attack — they do not. The conventional internet asks you to make this bet constantly, often without noticing you are placing it. The deep question Web3 raises is whether, for some especially important records, the bet could be avoided altogether: whether we could arrange things so that no one has the master keys to your records but you, and no one can quietly change the shared record, so that you would not have to trust an owner because there would be no single owner to trust.

Synthesis: the question that the rest of the book answers

This chapter has assembled a small toolkit, each piece defined plainly and tied to the next. A computer stores data (organized into files) and runs programs (software, packaged for users as apps) that change that data. Networks, above all the internet, let separately owned computers exchange data by following shared protocols — open rulebooks, owned by no one, like the conventions of postal addressing. Most services follow the client–server model: your device asks (the client, the diner at the table) and a company's machine answers (the server, the kitchen). Those machines increasingly live in the cloud — other people's computers in data centres. Behind the service sits a database, the authoritative record, kept by a single administrator with the power to read, change, or delete any entry. Your account is a row in that database; your password is a secret that lets the owner's doorkeeper admit you to it. And so, every time you use such a service, you trust the owner — that is, you accept their power over your data and bet they will not misuse it.

One thread runs through all of it: in the conventional internet, important records are kept in databases owned and controlled by single organizations, and "what is true" is whatever the owner's database says. That is not presented here as a scandal. It is, for most purposes, a reasonable and well-functioning arrangement, with genuine advantages this book will not pretend away. But naming it precisely lets us pose, at last, the question on which everything that follows depends, and which earlier chapters could only gesture toward:

In plain terms: Who controls the database — and what, if anything, could let strangers share one trustworthy record without putting any single party in charge of it? Web3, as Part III will show in technical detail and Part V will define with care, is in large part an attempt to answer the second half of that question — to build shared records that no one owns yet everyone can verify, using the cryptography of Chapter 8, the distributed-systems ideas of Chapter 10, and the blockchain of Chapter 11. Whether that attempt succeeds, at what cost, and for which uses it is actually better than a well-run conventional database, is the inquiry this book now begins. The reader who carries forward just one image should carry this: a record book, and the unsettled question of whose hands are on it.

We turn next, in Chapter 3, to where this whole edifice came from — the origins and architecture of the internet and the World Wide Web — so that the eventual claims of Web3 can be measured against the system it proposes to revise.

References cited in this chapter

Berners-Lee, T., Fielding, R., & Frystyk, H. (1996). Hypertext Transfer Protocol — HTTP/1.0 (RFC 1945). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc1945

Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685

Kurose, J. F., & Ross, K. W. (2017). Computer networking: A top-down approach (7th ed.). Pearson.

Mell, P., & Grance, T. (2011). The NIST definition of cloud computing (NIST Special Publication 800-145). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-145

Nakamoto, S. (2008). Bitcoin: A peer-to-peer electronic cash system. https://bitcoin.org/bitcoin.pdf

Postel, J. (1981). Internet Protocol: DARPA Internet Program protocol specification (RFC 791). Internet Engineering Task Force. https://www.rfc-editor.org/rfc/rfc791

Saltzer, J. H., Reed, D. P., & Clark, D. D. (1984). End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4), 277–288. https://doi.org/10.1145/357401.357402

Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379–423. https://doi.org/10.1002/j.1538-7305.1948.tb01338.x

Turing, A. M. (1936). On computable numbers, with an application to the Entscheidungsproblem. Proceedings of the London Mathematical Society, s2-42(1), 230–265. https://doi.org/10.1112/plms/s2-42.1.230

von Neumann, J. (1945). First draft of a report on the EDVAC. Moore School of Electrical Engineering, University of Pennsylvania. (Reprinted in IEEE Annals of the History of Computing, 15(4), 27–75, 1993.) https://doi.org/10.1109/85.238389

Zuboff, S. (2019). The age of surveillance capitalism: The fight for a human future at the new frontier of power. PublicAffairs.