Chapter 10Build It Yourself

I've been thinking about my mother's kitchen table. Not the table itself — the chair that's been empty at it for twenty years. The chair where I would have sat on an ordinary Tuesday evening, eating something simple she'd made, saying nothing in particular, being present in the way that doesn't require a reason. I left that chair empty because a number on a spreadsheet told me to, and I followed the number across six countries, and the chair is still empty, and the number never arrived anywhere it promised to arrive.

That's what this book has been about. Not the architecture, though the architecture has been described. Not the hard questions, though they've been asked and answered — some with clean answers, some with honest ones. Not even the ordinary morning, though you walked through one step by step and felt what it would mean to live in a world where survival is no longer something you earn. This book has been about the chair. About what gets lost when a system is designed around chasing and what becomes possible when a system is designed around enough. Now the question is how it begins.

Not how it ends. Not the fully realized time economy operating across continents with billions of participants and every supply chain running on a currency that resets at midnight. That's the destination. The beginning is smaller than that. The beginning is always smaller than that.

It starts with a node. One node.

What a node actually is

A node is a single instance of this system, operating under its own roof. A small server somewhere — running in a closet, in a co-working space, in a data center, in a university IT room. A piece of software listening for messages. A database of participants. A scheduler that runs at midnight to issue 24 hours into every Daily Wallet. That's all a node is, in mechanical terms. A modest amount of code, a modest amount of storage, a modest amount of electricity.

What it does is less modest.

A node mints time. Twenty-four hours a day, every day, for every participant registered on it. It receives transfers between participants. It maintains the five Universal Circles — Health, Education, Housing, Environment, Food Security — and the Community Circles its participants create. At one second before midnight, it settles. At midnight, it issues again. It runs the way sunrise runs, because the architecture has no opinions.

A node is a participation point in a global commons. It doesn't ask permission to exist. It doesn't apply for membership to a body that doesn't exist. It comes online, it greets the network, and from that moment forward it is part of something larger than itself — without being subordinate to anything inside that larger thing.

The first node will be awkward. It'll be imperfect. It'll run alongside the money economy the way a seedling grows alongside the trees that are already there — drawing from the same soil, reaching for the same light, small and uncertain and alive. The participants will still have jobs. They'll still pay rent in dollars or euros or baht. They'll still have bank accounts and mortgages and the whole apparatus of the money economy humming in the background of their lives the way it always has. The time economy doesn't ask them to leave that behind. It asks them to start something alongside it.

Many nodes, one network

Until recently this book described the network as a future tense. Federation was the word the early documents used — sovereign nodes, interoperable like email — and it was an aspiration more than a specification. As I write this, that has changed. The federation design exists. The implementation is beginning. The architecture you're about to read is real, even where the code is still being written. I want to describe what it looks like — not in the language of engineers, but in the language a participant will use to understand the world they're standing inside.

A node, by itself, is a village. A federation of nodes is a country of villages, none of them subordinate to a capital. The change is not that the villages get bigger. The change is that the road between them exists.

Here is how the road works.

Until now, every Handle has been three slots, separated by colons. house:cat:888. clay:orange cat:born in 1988. morning:wide:drift. The slots have always been the participant's own — chosen freely, belonging to them alone. When there was only one node in the world, that was enough. The Handle was the participant, and the participant lived in the only village that existed.

Once there are many villages, the Handle needs to know which one is home. So it picks up a small addressing tail — the same @ you already know from email, followed by the node's domain. house:cat:888@cat.ubi.asia. cat:nima:42@tie.ubi.asia. The three slots are still yours. They're still the identity. The domain is the address. They are different things, joined by the same character the world has used for forty years to mean at this place. Inside your own node you don't need to type the tail at all — the system assumes home, the way you assume English when you're in your kitchen. Only when you reach toward another node does the tail appear, because only then does the system need to know which road to take.

The road itself is plain. When a participant on one node sends time to a participant on another, the sender's node does three things. It asks the receiving node, politely: does this Handle live with you? The receiving node answers, yes, here is the person you're trying to reach. Then the sender's node delivers a small signed message — here is what just happened, with my signature so you know it was me — and the receiving node credits the recipient's Vault. The whole exchange takes a second or two. There is no central authority watching the road. There is no toll booth. There is no permission to ask. The two villages just talk.

The signature matters. Each node, when it comes online, generates a cryptographic identity — a pair of keys, one public and one private. The public key is published openly, so any other node can verify a message came from where it claims to come from. The private key stays on the node's server and never leaves. When a node signs a transfer, it is making a promise: this came from me, and you can prove it. No bureaucracy, no membership card, no headquarters issuing credentials. Just math, doing what math does.

If a node ever lies — if its operator turns hostile, or its software is compromised, or it begins flooding the network with garbage — the network's response is simple. The other nodes stop talking to it. Each node maintains its own list of who it will and will not exchange time with. This is not punishment from above. It is community self-defense, exercised locally, the way a town stops letting a particular driver into the market square if the driver keeps running people over. No global blacklist, no court, no central authority deciding for everyone else. Each node makes its own call. If the bad actor cleans up, the doors can reopen. If not, the network simply routes around them. The federation is open by design; defederation is local, deliberate, and reversible. That is the only enforcement mechanism the architecture provides, and it is the only one it needs.

There is no master node. There is no headquarters. There is no DNS root for participants, no registry of who is allowed to play. There is a published convention — a small JSON document each node serves at a well-known address, saying here I am, here is my public key, here is how to reach me — and that is enough. It is enough because email has worked this way for forty years, routing a billion messages a day across hundreds of thousands of independent servers, with no one in charge. Email is not perfect. There is spam. There is fraud. There are bad actors. And email still routes a billion messages a day, because cooperation is cheaper than not cooperating, and the architecture survives the friction. That is the existence proof we lean on. It is not theoretical. It is the network you used this morning to confirm a meeting — and your Handle, with its @ and its domain, is going to feel as familiar in your hand as your email address does.

A question of Circles

There is one place the architecture is still being decided in public, and I want to be honest about it.

The book has spoken of the Universal Circles — singular, global, planetary. The Health Circle. The Education Circle. As if every node's contributions feed into one great commons that covers anyone, anywhere. That was the aspiration the early pages committed to, and I'm not retreating from it. But the honest description of how it grows is more layered than the aspiration suggests.

In the first version of federation, each node maintains its own five Circles. The unspent Wallet time on Stefano's node feeds Stefano's node's Circles. The unspent Wallet time on Nima's node feeds Nima's node's Circles. They cover the participants of their own node, the way a town's school covers the children of its own town. This is the simplest possible starting point — it requires no new mechanism, no new coordination, no distributed accounting between strangers — and it ships first because it ships safely.

In the next version, nodes will be able to flow surplus from their local Circles toward a shared pool — voluntarily, by configuration, the way a town might choose to contribute to a regional fund. Operators decide which pool they trust and how much they pass along. The pool itself is just another node, run by someone the operator community trusts to hold it honestly. Anyone can stand one up. No one is appointed. The arrangement grows by agreement, not by edict.

In the long arc, true global Circles become possible — single planetary pools synchronized across every node in the network, with conflict-free distributed accounting that can survive nodes going offline, coming back, disagreeing, and reconciling without losing a minute. This is the hardest version to build and the truest to the book's framing. It will come when there are enough nodes to justify the engineering and enough trust in the operator community to hold it together.

So when the book says the Universal Circles, what I mean is the destination. The implementation in the first year will be per-node pools. The second year will introduce surplus-flow toward shared pools by operator choice. The planetary version will follow when the network is ready to hold it. That's not a hedge. That's an honest description of how a commons grows: from the village, outward, by agreement, until the village pools become one. The moral commitment doesn't change. The mechanism evolves.

Becoming a node manager

This is where you come in.

A node operator is the person — or the team, or the cooperative, or the institution — that runs a node. Operators are the connective tissue of this entire system. Without them, the architecture is a document. With them, it is a network. They commit no money to the project. They do not become shareholders, because there are no shares. They do not earn a license fee, because there is no license. They run a node because they want a node to exist where they live, where they work, where their community is — and because the only way for a node to exist is for someone to run it.

A node operator might be a university professor who wants her graduate students to study a live economic system instead of reading about one. A node operator might be a teacher who wants the kids in his school to have Handles they can use to give time to each other and to the people in the neighborhood who help them. A node operator might be a co-op that has been running a community kitchen for fifteen years and wants its volunteers and its diners on the same protocol. A node operator might be a hospital that wants its staff and its patients connected through Universal Circles that actually pay the staff and actually cover the treatments. A node operator might be a household. A node operator might be a city.

A node operator might be you.

What it takes practically is honest and small. You need a Telegram account, because the first version of the participant interface runs through Telegram — a place a billion people already are, a place that doesn't require an app store to enter, a place where the bot can simply be talked to. You need a server. The server can be a one-screen virtual machine rented from any hosting provider for a few dollars a month. It can be a shared hosting account at a company that gives you SSH access. It can be a small computer in a corner of your office. The architecture does not care.

You need a domain — a name on the internet that points to your server. mynode.example.org. co-op.city.org. tie.ubi.asia. The domain is how other nodes find you. It is also, gently, the name your community will see — and the name that will sit to the right of the @ in every federated Handle on your node. Choose it with the same care you'd choose the name of a meeting place.

You need an hour. Maybe two if it's your first time configuring a server. The deployment guide — published at https://github.com/UBIworld/time/blob/main/DEPLOY.md — walks you through it step by step. Get a bot token from Telegram. Pull the code. Set two or three environment variables in a small text file. Start the process. Watch the logs scroll by until you see your bot greet itself. Send /start to your own bot. Receive a Handle. You are now a node.

Federation adds a small additional layer. The deployment guide covers it: you point your domain at your server, you set up a free TLS certificate (one tool — Caddy — does this in four lines of configuration), you set one environment variable telling the bot what your domain is, and on first startup the bot generates its cryptographic identity and prints it once for you to save. After that, you are not only a node — you are a node that other nodes can talk to. You appear on the road.

There are two paths, and the deployment guide describes both. If you have your own virtual machine with administrator access, the path uses systemd — the standard Linux service manager — to keep the bot running through reboots and crashes. If you are on shared hosting where you have a login but no administrator privileges, the path uses pm2 — a smaller process supervisor that lives entirely in your home directory and survives reboots through a single cron entry. Both paths have been walked. Both paths work. The choice is purely practical: use whichever your hosting situation gives you.

I won't recreate the deployment guide in these pages. The guide is the runbook. The book is the reason. They are different documents on purpose. The guide will change as the software evolves; this chapter should not. What I want to give you here is the shape of what you're agreeing to, not the keystrokes.

The responsibilities of running a node

You become responsible for a small piece of infrastructure that other human beings depend on. That responsibility is real and it's not arduous. Keep the bot running. Apply updates when releases come out — usually a few commands; sometimes a database migration the bot will run for you on startup. Watch the logs occasionally. Notice if something looks wrong. Ask in the operator community if you're not sure. The operator community exists for exactly that.

You become responsible for a small set of decisions about how your node interacts with the rest of the network. Do you want to federate openly, accepting and sending transfers with any node in the world? That's the default, and it's the mode that lets the network behave as a network. Most operators will run this way, and the book recommends it: open federation is what turns the architecture into a commons. Or do you want to limit federation to a list of nodes you trust — an allowlist? You can do that. It's your node. Your community might be a closed cohort that doesn't want outside flow yet, or a sensitive institution that needs to scope its connections deliberately. The architecture doesn't argue. Operator autonomy is the whole point: each node sets its own federation policy, and the network is the sum of those choices.

You become responsible for the most local question of all: who lives on your node. Not because you screen them — the system has no application process, no eligibility test, no credential check. But because you set the social context. A university node is a university node. A neighborhood node is a neighborhood node. A city node is a city node. People find their way to nodes the way they find their way to communities, by being there. You don't manage them. You hold the door open.

What you are not responsible for is the rest of the network. You don't approve other nodes. You don't certify them. You don't audit them. You watch the road from your end. If you see a node behaving badly, you can stop talking to it. If you see a node being useful, you keep talking to it. The network's health is the sum of those small local choices, made by hundreds of operators, none of them in charge of anyone else.

This is what no bureaucracy actually looks like when it's running. Not the absence of decision-making, but the dispersal of it. Decisions live where they belong: with the people doing the work, in the places they live, on behalf of the communities they're part of.

Where the system stands today

I want to be straight about timing.

As I write this, the single-node software is working. People are using it. Daily Wallets are minting at midnight, transfers are moving, Vaults are filling, Universal Circles are settling. The architecture described in Chapter 8 is not a sketch — it is running code, deployed, observed, debugged through real use. The deployment guide referenced above is the same guide an operator would follow today to stand up their own single node. That part is now.

The federation between nodes — the road I described above — has a complete design and is entering implementation. The handle format, the discovery protocol, the signed transfer messages, the retry-and-reverse logic that ensures no time is ever lost in transit: these have been specified and approved. The first federated link will run between two nodes I know well — mine and a friend's — and once it works between two, it works between any number. The book is being written alongside the system, which is to say the system is still becoming itself as you read about it.

This is not a confession. It is the honest shape of how anything new actually arrives. The book describes a working single-node system and a federation design that is being built. By the time the network has hundreds of nodes — and it will — the chapter you are reading will sound like a memoir of a small beginning. That is the intended shape of memoirs.

If you want to be part of the early federation, you can be. Stand up a node. Read the deployment guide. Reach out at ubi.vision. The first hundred operators will know each other by name. The next ten thousand will know each other by node domain. The next million will simply be the network, and no one will think about it any more than they think about the email server that delivers their messages today.

The chair, still

I won't pretend the path is smooth. It isn't smooth. Banks whose business models depend on lending money at interest won't welcome a system that reduces the need for borrowing. Governments whose tax revenue depends on income denominated in a currency they control won't welcome a system that denominates income in a currency no one controls. Corporations whose profit margins depend on the desperation of workers who can't afford to say no won't welcome a system that gives every worker a floor they can stand on regardless of what any employer offers. The resistance will be real. It'll be institutional. It'll come dressed in the language of concern — concern for stability, concern for order, concern for the very people the system is designed to serve. That's how resistance always dresses when the thing being resisted threatens the people doing the resisting.

But the system is federated. No central authority can shut a node down. No government can revoke a currency it didn't issue. No corporation can acquire a protocol that has no owner. The resistance will be real, and the architecture was designed to survive it. That's no accident. That's five years of thinking about exactly this problem, ending in a network where the only thing anyone can do to a node they don't like is stop talking to it — and the only thing anyone can do to a network they don't like is build a better one and let people choose.

I started this book as a zombie chasing a number. Six countries. Twenty years. A spreadsheet that was never quite large enough, in service of a destination that didn't exist because the system has no destinations. It has a direction, and the direction is more, and the word for a person who has internalized that direction so completely that they can't stop moving isn't ambitious. I said that in the opening pages and I meant it then and I mean it now.

My mother is in Italy. She has been there the entire time. Twenty years of dinners I didn't eat at her table. Twenty years of ordinary weekdays when she was there and I was somewhere else, optimizing. I left to build a career abroad because the system I was inside told me — through the air, through assumption, through the things that go without saying — that the number on the spreadsheet was the point. That if I got it high enough I could go home. That the chase had an end. It didn't have an end. It had a direction. I followed the direction for twenty years before I stopped and looked at what it had cost.

In the system described in these pages, my mother's healthcare would be covered by a Health Circle funded by the daily flow of every participant in her node — and, in time, by every participant in every node connected to it. Her housing would be covered. Her food would be covered. Not by my number. Not by my distance. Not by the salary I earned on the other side of the world in exchange for the years I gave up. By the architecture of a community that decided those things shouldn't depend on whether someone's son was earning enough, far enough away, fast enough.

I can't get the twenty years back. But I can build the node. And so can you.

Everything in this book — every mechanism, every rule, every piece of the system, every line of the federation protocol — is published, open, and free. There's no patent. There's no owner. There's no investor who needs a return. The full technical specification, the protocol documentation, the open-source implementation, and the operator's deployment guide are available at ubi.vision and at https://github.com/UBIworld/time. They've been there since before this book existed, and they'll be there after the last copy has been read.

This isn't a product. It's a gift. And I'm not pretending it's perfect. The architecture may have flaws I haven't found. The federation may reveal failure modes only real traffic exposes. The governance questions may prove harder than I think. I've given you the answers I have and I've told you where the answers run out. That's more than most proposals offer, and it's less than what a working network will eventually require. The distance between the two is the work.

I'm asking you to do the work. Not to believe in this system the way people believe in ideologies — with the door closed and the measuring stick put away — but to take it apart, examine it under every light you have, and tell me what you find. If there are flaws, I'd rather discover them now, from people who took the proposal seriously enough to look for weaknesses, than later, when real lives depend on the architecture holding. And if there are better alternatives to what I've described, I'd rather those alternatives exist because someone built them than because someone wished for them. This is an invitation to participate in the construction, not the applause.

The work looks different depending on where you stand. If you're in a university research lab, the experiments haven't been run yet — the pricing dynamics haven't been modeled at scale, the settlement protocol hasn't been simulated under the kinds of stress that real economies produce, and the questions that can only be answered by data are still waiting for someone to generate the data. If you're part of a community organization — the kind that has been holding a neighborhood together with meal programs and tutoring exchanges and the quiet, unglamorous labor of people showing up for each other — then you already know how to run a pilot, because you've been running one your entire life; the difference is that now there's an infrastructure designed to support what you've been doing with nothing. If you're a developer, the code is waiting for you at ubi.vision, and the distance between a protocol that exists on paper and a node that exists in the world is exactly the distance your hands can close. If you're a node operator already — if you've read the deployment guide and you've watched your own bot greet itself for the first time — then you already know the feeling. You know what it is to be a participation point in something larger than yourself. The next operator needs to know what you know. Help them get there. If you're an economist, the model needs the stress-testing that only an economist's instinct for edge cases can provide — the scenarios I haven't imagined, the failure modes that only reveal themselves when someone who has spent a career studying how systems break turns that attention here. And if you're a critic, I'm not asking you to be gentle. I'm asking you to be thorough. The system will either survive scrutiny or it won't, and I need to know which before anyone depends on it.

This is one proposal. It may not be the final answer. But the question has been asked seriously, and an answer has been designed seriously, and a network is being built around it as you read this sentence. The conversation is now open. That's what this book was for. Not to deliver a finished world, but to demonstrate that a different world is designable — that the currency can be changed, that the floor can be built, that the ceiling can be set, that the road between communities can be drawn, and that the things human beings need to live with dignity don't have to depend on a number that someone chases across six countries for twenty years.

The technology is a gift to humanity. Take it. Run it. Connect it.

Build it yourself.