Chapter 9. The Limelight. The Sandbox. The Future. 

**The Limelight**

What are computers for? It’s a question that may seem unanswerable on the one hand, and on the other hand painfully obvious. 

It might be unanswerable, or at least not worth answering, from the standpoint of an enthusiast who knows just how broad a computer’s applications may be. A computer, after all, can do just about anything, depending on the circumstances. It can fly a passenger airplane, monitor an invalid’s health, distribute vital information, spread worthless gossip, simulate an infinitely complex virtual world, or hook you on the exquisite pleasures of Flappy Bird. Some believe that a computer will bring about the Singularity, at which point the very nature of human existence will have been permanently altered; others ponder a future in which computers have brought on a global holocaust through their very indifference to human concerns, as in the famous thought experiment in which intelligent machines accidentally snuff out human life in an effort to make paperclips[1](https://www.nickbostrom.com/ethics/ai.html). But for those in the professional field of computers, the most prominent question is likely not *what for?*, but *what’s next?* There are a thousand and one interesting problems to solve in order to keep today’s digital networks and associated computer systems running, and a lot of money in store for those who are motivated to solve them.

The question *what are computers for?* might seem equally silly from the perspective of someone on the opposite side of the table. Let’s say you stop any random person in the street and ask him what a computer is for. Assuming he himself is not a programmer, the likelihood is he’ll give a series of very straightforward answers: it’s for staying in touch with friends and family, it’s for playing games, it’s for watching Netflix. All these answers are of course correct. A computer is for whatever we use it for, and the above list covers the majority of the ground of how computers and smartphones are commonly used. 

The answer to our question must then exist between the poles of *what is technically possible?* and *what is culturally sanctioned?* This holds true for anything, not just computers.

Take for example The Church of Holy Communion, a sprawling, lovely, Gothic Revival building on 6th Avenue and 20th Street in Manhattan. The church was designed by the notable British-American architect Richard Upjohn, and consecrated in 1846. Episcopal parishioners around that time had taken a dislike to the fact that in Manhattan they were being compelled to rent or buy their pews, due to a general shortage of space, and clergyman William Augustus Muhlenburg decided to erect a church “where the rich and poor could worship side by side.”[2](http://daytoninmanhattan.blogspot.com/2010/05/church-of-holy-communion.html). If you were to walk past the building today it would certainly still appear to be a church, and a rather attractive one at that. But today it’s not a church. It’s a disused building serving no function. Before that, it was an independent gym. Before that, it was a David Barton gym. And before that, it was The Limelight[3](https://patch.com/new-york/new-york-city/limelight-stunning-photos-1990s-favorite-nyc-nightclub), Manhattan’s most notorious nightclub, which was eventually shut down by the city for acting as an all-night drug den. 

Was the Church of the Holy Communion still a church when it was awash with go-go girls and molly? In some sense, yes. It would never have been such an attractive site for the club’s proprietors if it had not been a church on the exterior. And the late-night revelers probably *were* having spiritual experiences amid the rumble of the bass and the flashing lights.

I’ve gone so far afield here to try to convey that sometimes what a thing is for completely changes, despite remaining ostensibly the same; and that sometimes the possible, or even the intended uses of a thing can be so fully occluded by its customary use as to disappear. Now, The Church of Holy Communion didn’t change its function on its own. It changed its function because it was sold. Much else that was once considered holy can be bought and sold today. Whereas in the distant past the world was filled with objects, places, and beliefs on which no one could put a price, today the phenomena of our existence are mostly fungible. Whether you want to call this *Kali Yuga*, or simply *how things are going lately* is up to you. A good stand-in word is probably just *modernity*. And this is what computers are: modernity machines, which facilitate our exchange of one thing for another.

But just like the Church of the Holy Communion was only contingently, not *necessarily* the Limelight, a computer could function differently. For one thing, it’s now possible to have trustless, cryptographic assurance of funds, and of personal identity. These technical advances may lead to a different kind of computer: one built not as a modernity machine but as a machine for whatever comes next.

These are not mere abstractions. The details for how this paradigm is shifting are open to anyone who wishes to read them. The modernity machine was a modernity machine in part because everything about it was designed for ephemerality. What about a computer where everything about it is built for permanence?

**The Sandbox**

In the previous chapter I touched on the way the Urbit system was built to be, from a back-end standpoint, *simpler* than other computer systems. But that is only one of its creators’ overarching aims. Another one is durability: how does one design a personal computer system that’s meant to last? To my knowledge, Urbit is the only platform making real inroads in answering that question. To investigate that, we’ll have to take a little detour into computer hardware.

The central component of a computer--its brain, if you will--is the microprocessor. As Tlon engineer Ted Blackman explains in the second part of his podcast series Urbit from the Outside In[4](https://youtu.be/hnAmcsaGYKQ?t=1866), “the way that modern processors expect for code to be written is as a sequence of instructions . . . . The way the processor works is it starts at the beginning of a program, reads the first 64-bit value, runs it, and then moves to the next one, and runs that.” (Some of these instructions will tell you to jump backwards, allowing for loops.) A good analogy, Blackman explains, is to think of this sequence of instructions as a recipe. Indeed one of the common ways of getting introductory CS students to think about computer programming is to get them to think about the *exact* steps you would need to make a peanut butter and jelly sandwich. (Naive students, when faced with this task, might forget the steps which are so obvious that we forget that they are steps at all--steps such as going to the cupboard and getting out the bread, or opening up the jar of jelly before dipping the knife in it.) At the level of hardware, and of the machine code that speaks to hardware, an operating system tells a computer: *do this, then do this, then do that.* 

If you’ll recall from the previous chapter that Hoon, the language in which Urbit is written, is a functional language, then you might recognize a potential mismatch here. Writing a program as a pure function is quite different from writing a program as a sequence of steps. (Even for non-programmers like me, a comparison[5](https://spin.atomicobject.com/2017/09/21/why-functional-programming/) of the fibonacci sequence written in Haskell, a functional language, and the fibonacci sequence written in C, an imperative (recipe-like) language, can convey the difference. In Haskell, the program is written much the same way a human might explain to another human how to find the fibonacci number of n. In C, the program is written as a sequence of discrete steps: much more like a recipe for making a peanut-butter-and-jelly sandwich, which is so exhaustive as to include the steps for opening the fridge, and unscrewing the jelly cap.) So what is to be done? Hoon and every other functional programming language have to interact with the imperative (recipe-like) paradigm of machine code. Where do the functions fit in?

The answer to this question will go a long way toward explaining the advantages that Hoon gives Urbit for meeting the properties of *durability*, in addition to its affordances for simplicity discussed in the previous chapter. The first thing to understand is that any functional language, whether it be Hoon or a better-known functional language such as Haskell, requires something that can be broadly understood as a *wrapper*. Again, very broadly speaking, this wrapper will wrap up the functions of a functional language in order to convey them to the lower level machine code, which expects something that looks like a recipe. The way Haskell handles this task is to employ special functions[6](https://youtu.be/hnAmcsaGYKQ?t=2701), which cause imperative actions to fire at the level of hardware and machine code. But, as Blackman points out, the specifications for how these “side effects” occur are not encoded by Haskell itself. They’re encoded by the environment in which Haskell is run. “If you were going to try to put together a full specification for exactly what a piece of haskell code does,” Blackman continues “you really can’t do it, because it might depend on what host operating system you’re running it on.”

This is not how Urbit works. The Urbit idea is to create an operating system “whose functionality is frozen in stone forever.”[6](https://youtu.be/hnAmcsaGYKQ?t=3035) This means that when a facet of Urbit wraps up the Urbit operating system’s function, it brings this function to the machine code in such a way that the environment where the function is running has no bearing on the function itself. This wrapper system is the Urbit virtual machine, Vere. (Vere can also be referred to as the *runtime* or the *interpreter*: these terms all indicate that Vere is the system that relays Urbit’s functional language to the underlying environment, and relays information from the underlying environment to Urbit’s functional operating system.) As the official Urbit docs put it[7](https://urbit.org/docs/system-overview), “Each urbit is sandboxed in a virtual machine, Vere, which runs on Unix. . . . Vere observes the list of output events, and when external action is called for makes the appropriate system calls itself. When external events relevant to your urbit occur in the Unix layer, Vere encodes and delivers them as input events.” That means that the behavior of what’s inside a given Urbit computer is not controlled by what’s outside it.

**The Future**

At this point you may be asking yourself, *so what?* What does it matter whether an operating system is *sandboxed* or not? What is it, with Urbit, that you’re boxing yourself in or out of?

To answer that question, we might think back to the story of the Church of the Holy Communion, which eventually became the Limelight. Of course buildings change hands all the time, as do the technical details of various appliances. But it might be worth considering that in the modern era, forms drift toward a specific function in a very recognizable pattern. That is, the fate of the Church of the Holy Communion resembles the fate of the personal computer, in that it gave way to the cultural logic of the era: Anything can be exchanged for anything else, and the highest value any item can provide is as a means by which to facilitate such exchange. In this paradigm, the more useful computer is the computer which constantly needs updates, and which encourages streaming services as opposed to ownership; and the more useful version of the Church of the Holy Communion is the one to which tickets can be sold. But what if someone didn’t want their computer, or any feature of their life, to drift toward disposability. Shouldn’t that at least be an option?

From this perspective we can see what might make a durable computer computer desirable, and in the previous section we discussed what might make it technically possible--but what are the social conditions that might allow it to flourish? From the typical commentariat perspective, it would appear that there’s no end in sight. After all, people are not going to stop exchanging things any time soon. They’re still going to want to trade some form of money for food, shelter, and entertainment. From this perspective our trajectory is simply toward a greater degree of control over how that exchange takes place--control exercised by an increasingly symbiotic hybrid of first world nations, transnational corporations, and global NGOs. Today the field of political science still tends to center around questions of how national governments can better redistribute the resources of their citizens; the underlying assumption is that such large scale top-down re-jiggering will continue to be possible; that the state-corporation-NGOs will remain sovereign; and that their citizen-employees will produce and consume in the direction toward which they nudge. 

But look closely, and there are some elements of 21st century life which already seem to render this paradigm obsolete. Whereas in the 20th century, individuals were largely tied to specific locations by family, local resources, and general limitations around travel, today there is little to stop someone who has the means from swapping locations on a dime, perhaps even going so far as to renounce citizenship and acquire citizenship of a new country. Whereas in the 20th century, governments could successfully determine precisely which financial transactions were valid in which geographical regions, and tax the populace accordingly, in the 21st century Bitcoin has already allowed financial transactions to transcend borders. And whereas in the 20th century the owners of the largest armies and the deadliest bombs ruled the roost, a 21st century in which key networks are formed digitally rather than nationally means that mass violence may no longer be a viable strategy for subduing one’s opponents.

Given the above, it would appear that the balance of power has shifted from multi-million-human nations to talented individuals and the small networks they form. This is the thesis of James Dale Davidson and Lord William Rees-Mogg’s provocative and, at times, downright prophetic *The Sovereign Individual: Mastering the Transition to the Information Age*, which they wrote together in 1997, when Bitcoin was but a twinkle in young Satoshi’s eye. Davidson and Rees-Mogg’s thesis that the internet would subsume the global order likely seemed highly eccentric in the late ‘90s; today it seems obvious. But even today few follow this line of thought to its logical conclusions. If software truly has eaten the world, then the bogey men against whom many still fight--Western Imperialism, Capitalism, Communism, Big Pharma, the Surveillance State--are already dead, only their opponents haven’t realized it yet and continue to spar with ghosts. Such a sea change is comparable to the changes in the global order that were brought on by the printing press; perhaps the changes are even greater. As Davidson and Rees-Mogg put it, “The civilization that brought you world war, the assembly line, social security, income tax, deodorant, and the toaster oven is dying. Deodorant and the toaster oven may survive. The others won’t.” (8)(*The Sovereign Individual*, 53)

If social security and the income tax die off, then what will live? According to Davidson and Rees-Mogg, the answer is smaller networks in which “citizens” are more like customers, who can at any point pack up and leave the geographical entity they’ve chosen, if that entity should fail to provide the necessary services. If the rules and affordances that these highly flexible organizations use to conduct their business is not tied to a specific geographical location, then obviously it will be tied to computers--tools which allow people to organize, debate, and transact without geographical constraints. “This new equation of identity,” Davidson and Rees-Mogg write, “unlike nationality, will not be a product of the systematic compulsion that made nation-states and the state system universal in the twentieth century.” And here we come full circle to the question of the durability of computers: If one’s identity is inextricably tied up with digital networks, as opposed to nation state, then one will certainly want his computer to be durable. It will need to last one’s own life and possibly the lives of one’s children. In such a society, a computer that serves as a permanent extension of oneself will oustrip by far the benefit of a computer that is liable to change according to someone else’s whims. 

For some uses, such a system already exists in the form of Bitcoin and other blockchain computers. Such networked computers, in which records are distributed across the entire range of participating nodes, are certainly built for durability, and we have already seen truly extranational organizational systems forming around them. But not all things one might want to do on a computer need to be done on a blockchain--either because they are meant to be private, or because it would not make sense to use a blockchain’s large computational resources for such a task. Sending direct messages from one user to another, for instance, is an obvious case where a blockchain is not needed. But then there is also the whole host of other features--medical records, proprietary software, business secrets, or simply family albums and calendars--which one might want to be durable but for which one either does not need or does not want a blockchain solution. 

To these and many other problems, one simply wants a computer. One does not want a surveillance network, or a bevy of pop-ups commanding him to update, or software that he merely rents from someone whose aim is to bilk him. Perhaps he wants something like Leibniz’s vision of a machine that will calculate the secrets of God and man. Or perhaps he simply wants a tool, which augments his natural human talents. Such ideas of a human-centered society often sound like a thing of the past. Could they also be our future? 

Chapter 8. A Software Psychoanalyst. Functional Breathing. Tea at the Palaz.

**A Software Psychoanalyst**

> I was the world in which I walked, and what I saw
Or heard or felt came not but from myself;
And there I found myself more truly and more strange.

--Final Stanza of Wallace Stevens's "Tea at the Palaz of Hoon"

Even a non-architect will have at least a vague sense of why an architect might build a building with steel instead of brick, or with wood instead of glass; even a non-filmmaker can guess at a filmmaker's aim in shooting in black-and-white instead of color, or in casting a certain actor in a certain role; and these days we're increasingly sophisticated enough to know why the news sources that intend to provide us our reality choose to associate certain images or certain phrases with certain ideas, or why they might feature certain stories at all, at the expense of other world occurrences.

And yet, ask a non-programmer why certain choices have been made in the composition of the programming languages that act as the lifeblood of our networked existence--and you’ll be lucky if you get anything beyond a blank stare. In the realm of programming languages--and the operating systems, web stacks, and mobile apps that flow out from them--we are like our distant ancestors who took for gospel that every event that rolled through their lives was the will of the gods. The fire that we started in order to cook our mutton ended up burning down our hut? It happened because it was the will of the gods.  The whole tribe got sick after drinking from the river down yonder? It happened because it was the will of the gods. These are also the thought patterns of paranoiacs and the catatonically depressed. Those of us who are software users--which is to say, everyone in the developed world--might be well served by a software psychoanalyst. This modern-day sage would help us to see the history of our digital lives as a series of *choices*.

Urbit is written in a unique and (to some) disorienting programming language called Hoon. To understand the choices that led to the composition of Hoon (or of any other programming language), it might be useful to consider what computer programming actually is.

In the foreword to the second edition of the canonical text *Structure and Interpretation of Computer Programs*, which was taught to entry level computer science students at MIT for the better part of two decade, authors Harold Abelson, Gerald Sussman and Julie Sussman provide a provocative answer to this question.{1}(Abelson, Sussman and Sussman, *Structure and Interpretation of Computer Programs, 2nd Ed.*, xxiii)

> Underlying our approach to this subject [computer programming] is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might best be called procedural epistemology—the study of the structure of knowledge from an imperative point of view, as opposed to the more declarative point of view taken by classical mathematical subjects. Mathematics provides a framework for dealing precisely with notions of “what is.” Computation provides a framework for dealing precisely with notions of “how to.”

This is to say, a programming language is something that is constructed to *do things*. In this it differs from subjects like mathematics or philosophy, or even, perhaps with human languages. (One major linguistic theory proposes that human languages emerged as an outgrowth of abstract thought, *not* for the humdrum purposes of communication with other humans.){2}(Chomsky and Berwick, *Why Only Us?*) All aspects of a computer program, on the other hand, are in some way tied to the results that will be reached by running that program. A computer program is never something static to be contemplated for its beauty (although it may be beautiful underneath the hood); it is something dynamic to be iterated over time. A computer thus has the same preferences as the 19th century Missouri Congressman William D. Vandiver, who gave that state it's nickname when he declared, "Frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me."[3](https://www.netstate.com/states/intro/mo_intro.htm). And differences in programming languages will emerge from differing philosophies about how best to do things (i.e. how to structure algorithmic procedures), or, perhaps, from differing philosophies about which things are worth doing and which things aren't. 

**Functional Breathing**

What then, are the ideas about how to do things and which things are worth doing which went into the construction of Hoon? For the technically knowledgeable, Tlon engineer Ted Blackman has provided a thorough explanation in the urbit.org blog post "Why Hoon?"[4][https://urbit.org/blog/why-hoon]. The docs at urbit.org also provide a full course for learning Hoon and a glossary definition.[5](https://urbit.org/docs/glossary/hoon) Here is the first line of the definition:  "Hoon is a strict, higher-order typed functional programming language that compiles itself to Nock." I discussed Nock a bit in the previous chapter, and I'll cover "strict, higher-order typed" in the next one. For now let's focus on "functional."

*Functional programming languages* constitute a class of programming languages, typically in opposition to the class of *imperative programming languages*. Yet the term *functional programming language* has the potential to be misleading. After all, a function is simply something that takes an input and produces an output. Any programming language, functional or not, is going to be chock-full of functions. Moreover, the terms *functional language* and its counter-category, *imperative language*, were created after the fact to describe programming language paradigms that already existed. That is, when John McCarthy invented the first functional programming language, LISP, he didn’t call it a "functional programming language." He was just inventing a language that would be able to do the things he wanted it to do, with the most sensible parameters he could conceive. It should also be noted that whether a language is functional or not is a matter of degree. There’s room for argument about whether certain languages can be classified as functional or not, and their performance as functional languages might depend on the importation of certain libraries (tranches of code that give the coder new powers, as it were). 

With that out of the way, what *is* a functional programming language? In what sense is Hoon a functional language, and why does it matter? 

In a 2015 post “What is Functional Programming?” software developer Kris Jenkins gives a straightforward answer to this question--an answer meant for “jobbing programmers” as opposed to academic theorists.[6][http://blog.jenkster.com/2015/12/what-is-functional-programming.html] His answer? 

> Functional programming is about writing pure functions, about removing hidden inputs and outputs as far as we can, so that as much of our code as possible *just* describes a relationship between inputs and outputs.

This might seem a little odd at first. Doesn’t *all* code just describe relationships between inputs and outputs? If not, what *else* would code do? Certainly that's all that a computer in its most basic iteration does. Take for instance the simplest computer around: an abacus. Let's say your abacus has ten beads per row and you want to subtract seven. *Seven* is your input, the process of sliding the beads over to the right is the execution of the program, and the number of remaining beads on the left (three) is your output. All of this is perfectly above board.

Jenkins’s observation is that actually a fair amount of computer code has *hidden inputs* and *hidden outputs*. The computer programming term of art for these inputs and outputs is *side effects*, although Jenkins is careful to note that *side causes* are as much of an issue as *side effects*. To make his point, Jenkins shows an example of some computer code that does not *seem* to have any inputs or outputs at all. On the surface of it, this set of instructions does not depend on anything and it does not produce any effects. No actual functions are called in the code. And yet running the code under different conditions would show that the code *does* actually depend on things, and it *does* produce effects. It's as though the abacus were shifting beads around, but your the operator of the abacus was blindfolded so that he could not see the start point or the endpoint of this shifting operation. 

The simple way of saying this that any computer code not only depends on the inputs it is given; it also depends on the state of the machine. Let's return once more to the abacus. Obviously, anyone intelligent enough to use an abacus is intelligent enough to know that his or her calculations will only come out correctly if the beads of the abacus are reset before performing the next operation. That is, if I have ten beads in a row and subtract three in order to find out the difference, it is obvious that I cannot subtract from those seven remaining beads in order to obtain the difference of 10 - 2. I must reset the total number of beads back to ten. 

Another potentially useful (if not rigorously exact) analogy for thinking about this is to imagine you’re designing a human being. The first obvious thing you might want to program this human to do is to *breathe*. The human needs to breathe whether he is in Amsterdam or Zanzibar, whether 2,000 feet above sea level or 2,000 feet below. So from a certain perspective, it seems that *breathe* has no inputs and no outputs. It’s simply something that gets done. But there are going to be exceptions to this rule. What if your human is under water, or in a room filled with carbon monoxide? These are factors that are going to affect the health and happiness of your human when he tries to breathe. In which case, you do not want these factors to be *hidden* within the *breathe* operation. Your human might be sucking up seawater when he’s supposed to be holding his breath, or turning purple on an otherwise idyllic picnic. 

Now, you can write some code that instructs your human to cease breathing temporarily if he's swimming underwater, or if he's in a room with a noxious smell. But in that case, you're definitely going to want to make these conditions explicit in the function. Even though in the vast majority of cases, you want your human to breathe instead of holding his breath, you still want your function to look like *If on land, and if no carbon monoxide, if no noxious smell, etc. etc., then breathe*. This would be in contradistinction to something more like *Assuming the state of the human is propitious for breathing, let him breathe.* In the latter case, the human's state is not an explicit part of the *breathe* function. Maybe the programmer can still handle keeping his human alive, but this will entail a lot of hidden complexity managing his state; and any errors stemming from the hidden complexity of this program might well prove to be fatal. 

**Tea at the Palaz**

Although there can be arguments over the exact definition of "functional" or "purely functional," one can certainly call Urbit's Hoon a functional language in Jenkins's sense: that is, its aim is to do away with hidden side-causes and sife-effects. Recall from Chapter 1 of this book that the "Martian software" Urbit intends to emulate is *tiny* and *diamond-perfect*. Complexity is at the absolute minimum. And to bring complexity to a minimum, you absolutely do not want code that’s rife with hidden causes and hidden effects. Thus in order to create tiny and diamond-perfect code, you want to use functional programming language principles. (It should be noted that one of the co-authors of the Urbit whitepaper has offered the opinion that Hoon actually is "not quite" functional programming, "though it's in a similar area." The technical explanation for this touches on the limitations in explicitness of more common functional programming languages such as Haskell when compared to Hoon.){7}(see sigryn-habrex's 8.15.21 comments in the Chat channel of this group) For our purposes in this chapter, however, the important point is that Hoon uses principles of explicitness in order to reduce complexity. One of the aims of Hoon is that any Hoon/Urbit user should be able to fully understand the processes going on beneath the hood. Another is that Hoon code should be fully deterministic; that is, the behavior of one's Urbit computer should always be determined solely by the code that it's running, and not by the hardware or the underlying operating system beneath Urbit. Both of these aims depend on explicitness. As Blackman puts it in “Why Hoon?”, “One of the best ways to reduce software complexity is to restrict oneself to pure mathematical functions — no side effects, no implicit arguments.” So if you were using Hoon to program your human to breathe, you would not have to do any digging to find out whether he is in a sitation where he ought to be breathing or not. This information would be explicit.

But another, related aspect of Hoon gives an even better sense of its devotion to rooting out implicit arguments, and this aspect should also give the reader a better sense of Hoon's uniqueness. This is the fact that Hoon is a "subject-oriented language." Unlike "functional lanuage", "subject-oriented language" is not a term in common use among everyday computer programmers. To get a sense of what it means in the context of Urbit and Hoon, we can turn to the official Urbit Hoon tutorial documents: "every Hoon expression is evaluated relative to some subject . . . [and] the subject defines the environment in which a Hoon expression is evaluated."[8](https://urbit.org/docs/hoon/hoon-school/the-subject-and-its-legs). This sounds rather abstract, but actually the concept can be understood pretty easily. 

In Hoon, when you define what is normally called a variable (but which is called a "face" in Hoon), you are merely altering your computing environment, and whatever inputs you give to the computer will then be evaluated in terms of that altered environment. To put it as simply as possible, naming a variable (saying that b=5, for example) changes the environment of your computer in an explicit way. And any future calculations you wish to do on your Urbit computer will invoke that newly altered computing environment in an explicit way. This may be illustrated by turning once more to the abacus analogy. You can imagine you have an abacus with ten rows of ten blue beads, making for one hundred blue beads total. And then you can imagine you've painted the first bead on the third row red. Now you've got a different abacus than the one you had before. As a human, it's very easy for you to recognize this imformation and go about your business. You can perform operations on the fourth row or the fifth row or whatever other row, without letting the fact that the third row now has one red bead distract you. However, the fact is, you're no longer performing operations on *abacus with 100 blue beads*. You're performing operations on *abacus with 99 blue beads and one red one*. The environment has changed. And this is true for more complex modern computers, just as it is true for the abacus. 

The value-add a Hoon-style abacus would bring is this: Whenever you are performing any kind of function in Hoon, the change in the environment is explicitly stated. So, if you were performing 10 - 9 on the eighth row of a Hoon-stlye abacus, the operation would look like this: *given an abacus with 100 beads, where the first bead on the left in the third row is red instead of blue, slide nine beads to the right on the eigth row.* It might not seem that the information about that one red bead is relevant; but making all this information explicit is precisely the sort of maneuver that prevents hidden side-causes and hidden-side effects.

The point can also be illustrated with an actual example from Hoon. Entering the command `(add 2 2)` in your Urbit programming environment will, as one might guess, give the result `4`. On one level of inspection, all you're doing here is adding two and two. But a closer inspection of what's going on will reveal Hoon's unique structure. All Hoon expressions, including our simple addition of two and two, are evaluated relative to a *subject*. The subject, in the case of `(add 2 2)`, is what I've been calling the "computing environment" or "environment": it is a tranch of computer code taking into account the temporal state of your Urbit comuter, the ownership details of your Urbit computer (i.e. what is its unique identity?), as well as other 'entropic' code to keep your computer cryptographically safe, and "standard library" code which facilitates the performance of functions like *add*. What your Urbit computer is hearing when you tell it `(add 2 2)` is "find the command *add* within the standard library of Hoon functions, apply that command to the inputs *2* and *2*, and then return the entire environment, given that *2* and *2* have now been added together. That is to say, there are no isolated events within Urbit. Every operation you run is an alteration of the urbit computer you're running it on, and the result of every operation is the altered state of your urbit computer. There's not outside or inside. Hoon is both the operator and the operand of its operations.

For a computer programmer, these are not idle, theoretical concerns. And in the case of Urbit/Hoon, they're choices made with very specific aims in mind. Those aims are long-term durability (so that in 100 years the code will run the same way it runs today), simplicity (so that there are no hidden side effects or side-causes in the code), and independence (Hoon expressions will not depend on the changing software landscape that surrounds it, and thus anyone who owns an Urbit computer owns it fully). Programmers coming to Hoon from more normative paradigms have often found it strange; and, strangeness being relative to what one is used to, Hoon no doubt *is* strange. It has been conjectured that Yarvin, a poetry fan and a composer of verse himself, named the language after the Wallace Stevens poem "Tea at the Palaz of Hoon," excerpted at the beginning of this chapter, which indeed ends with the line "And there I found myself more truly and more strange."[9](https://www.openculture.com/2012/02/harold_bloom_recites_tea_at_the_palaz_of_hoon_by_wallace_stevens.html) 

And yet the more relevant line may be "I was the world in which I walked." Certainly there are parallels between this line and the behavior of Hoon: as stated above, a Hoon expression is never separate from the context to which it is applied. A dramatic way to conceptualize this is to recall the climax of *The Matrix*, in which the progagonist Neo recognizes that, when in the Matrix, he is made up the exact same substance as his surroundings. At a fundamental level there is no difference between himself and the world around him. Like Neo in the matrix, any computer program is made up of the same stuff as its environment: binary digits. And, as with Neo, certain new powers may come to a computer that makes this similarity explicit.

Chapter 7. I Decided to Listen Less. Eternal Eternal September. The Absence of Bubba.

**I Decided to Listen Less**

On September 25, 2013, a fast-talking, but otherwise unassuming man in a button down gray T-shirt and jeans stood before an audience that could not have numbered much more than a dozen or so, and made his pitch for the computing project he had been working on for the past decade. “I remember when the internet was a social network,” said Curtis Yarvin, “I graduated from college in 1992. Everybody’s ports were open. Nobody had heard of firewalls. . . . It was a general-purpose distributed social network. We’re all basically trying to recover that state of innocence. And what happened was Eternal September, and hordes of orcs were released, and it all died.” 

The crowd laughed. It wasn’t the first time in the talk laughter could be heard, and it wouldn’t be the last. The laughter seemed to combine mirth and incredulity--as if to ask (genuinely, though not unkindly) *is this guy for real?* After the talk was over, and a few befuddled questions were asked, a large, jovial man with a thick German accent chimed in. 

“I’ve been talking to this guy {Yarvin} off and on for like six months,” he said, “and, I have to admit that I understand only this much (holding thumb and forefinger parallel, in the universal sign of *just a little bit*) . . . but that is blowing away my mind, so I decided to listen less, because nothing is left of my mind.”

Yarvin, appearing slightly uncomfortable with the praise, smiled and offered to play a video demonstration of his concept later on, before walking back through the folding chairs into the audience.

---

Yarvin’s invention, Urbit, would require nothing less than leaving behind the entire commonly used computing stack. But it wasn't totally *ex nihilo*. It rested on the back of a new functional programming language he had invented, called *Hoon*, which compiled down to *Nock*. Nock could be described as a low level language similar to what is known as “assembly language” on typical computers. *Assembly language* simply connotes the set of basic operations into which a given computer's *machine code* is assembled; machine code consists of strings of bits, such as `1101 0100`, etc. it is one step away from machine code

The first notable thing to mention about Hoon is that it is a functional language. Functional programming languages might be (a little whimsically) described as the cool aloof cousin of the computer programming language family. Lisp, the earliest and perhaps best-known functional programming language today, was influenced by a mathematical system known as the Lambda Calculus. Invented by American mathematician Alonzo Church in 1928, the Lambda Calculus is a way of stating the most elementary concepts in mathematics. Unlike other similar methods, the Lambda Calculus privileges the *function* instead of privileging the *set.* (The mathematical field of *set theory* tends to privilege the *set*). Church was following in the footsteps of European mathematicians David Hilbert, Moses Schoenfinkel, John von Neumann, and the American Haskell Curry (who got his own functional programming language named after him) in trying to find a solid foundation for formal logic that could hold strong no matter how hard one might push against it, [1](https://www.researchgate.net/publication/228386842_History_of_lambda-calculus_and_combinatory_logic). 

Unfortunately for mathematicians like Church and his predecessors, Kurt Gödel’s famous incompleteness theorems would soon render them somewhat moot. Gödel showed once and for all that the “Hilbertian program” of attempting to axiomatize the building blocks of math was doomed to failure. “It will never be possible,” wrote fellow mathematician John von Neumann, summarizing Godel’s findings, “to acquire with mathematical means the certainty that mathematics does not contain contradictions.” {2}(Dyson, *Turing’s Cathedral*, 94). 

But the Lambda Calculus got a second life as an influencer for programming languages. Foremost among these is the above-mentioned Lisp, invented by MIT’s John McCarthy and formally introduced in 1960. [3](http://www-formal.stanford.edu/jmc/recursive/recursive.html)
A major feature that Lisp inherits from the Lambda Calculus is that, as Paul Graham puts it, “code and data are made out of the same data structures.” {4}(Paul Graham, *The Roots of Lisp*). This is also true of Urbit's Nock, the low-level language that rests at the core of Hoon. But one difference in Nock is that both code *and* data are composed entirely of unsigned integers, i.e. the natural numbers plus zero. 

An example of a very simple Nock formula is

`5 [1 32]`

In this formula 5 is the subject. The symbol that signifies the performance of a function is *1*. And what does this *1* want us to do, in Nock? Is it telling us to add, or subtract, or multiply? No, something even simpler.  What *1* means is: ignore whatever came before the *1*, and return the value after the *1*. What comes after the *1*? *32*. So, when we run

`5 [1 32]`

we get

`32`

The `1` function shown above is one of only twelve “opcodes” that Nock runs. The specifications for Nock are meant to be as bare-bones as possible--so much so that they fit on the front of a T-shirt. (This T-shirt has in fact been printed and worn.) To give some comparison, the typical instruction set for an internet server's assembly language has between 1300 and 4000 opcodes.[5](https://urbit.org/blog/why-hoon/)

**Eternal Eternal September**

Seeing as Urbit was launched in the 21st century, the real launch was not the day Yarvin gave his presentation in front of that small crowd at th Personal Cloud Community Gathering. The real launch was on the internet. A day before the event, Urbit’s ur-docs were released by an anonymous user, called *tsax*, to Hacker News, the highest signal place on the net for news relevant to computer programmers.[6](https://news.ycombinator.com/item?id=6438320) “I guess on the Internets,” Yarvin quickly responded, “you never release anything - it's released for you.”

Hacker News warrants its own mini-history, for it is both unique among Facebook-era social networks, and, in other ways, perfectly representative of their limitations. One unique feature of the site is that it was invented as a proof of concept. The concept was a functional programming language called Arc, written by Hacker News inventor Paul Graham. Today Graham is best known for being the co-founder of the start-up incubator Y Combinator, a mentorship program that has become a famous benchmark for young companies trying to make it big. But his first foray into the public square was as author of the book *On Lisp*.[7](http://www.paulgraham.com/onlisp.html), a well-received guide to the subject. As a matter of fact, Yarvin mentions Graham and Arc within the first 500 words of his Moron Lab post announcing the existence of Urbit. There are some obvious parallels between Graham’s way of thinking and Yarvin’s. A quotation from Graham on the design philosophy behind Arc should be sufficient to demonstrate this:

> Good design is timeless, and if you want something timeless you can't pander to the limitations of some hypothetical "average" user. It's too vague a target. It's also a moving target: the average user might not be as stupid as you think.[8](http://www.paulgraham.com/design.html?viewfullsite=1)

Another interesting feature of Hacker news is that it was meant to be both a social network and a funnel for potential entrepreneurs toward Y combinator. In his announcement post for the site, which was originally called “Startup News,” Graham describes it as something more like what a listserv might have been in the early days of the internet, or what Google Groups is today. “We created this partly for our own use,” Graham writes, “we've now funded about a hundred people, so it doesn't work well anymore to send links around by email.” [9](https://news.ycombinator.com/announcingnews.html). In the early days at least, Graham meant for Hacker News to function as something like a reputation system for its users: a place where Graham and the rest of the team at Y Combinator could get to know potential entrepreneurs based on their posts. 

The other Hacker News *raison dêtre* was to replace Reddit, which already in 2007, had ceased to be a good place to find “a concentration of startup-related links.” Whereas at its birth Reddit had been a tech news hub, once it became popular it began to lean more towards news, politics, and other topics that have more interest to the general public. This was a version of the phenomenon that has come to be known as “Eternal September.” The phrase refers to an occurrence on AOL, in September, 1993. Back before then, the internet had been a more rarefied place. Usenet groups had a particular etiquette, such as not posting advertisements (a.k.a. spamming) in inappropriate groups. [10](http://www.catb.org/jargon/html/S/September-that-never-ended.html). Around every September, Usenet would see an influx of new users, because many people would get their first internet connection at college. And with this influx would come a an influx of people violating the general *netiquette*. Then they’d get chastised and they would adapt, and things would go back to normal. 

But in 1993, America Online’s vice president of marketing Jan Brandt had an idea that changed the face of the internet forever. It was her job to grow AOL’s userbase, and she had the fundamental insight that AOL’s biggest need wasn’t advertisements selling any of its individual features; the company just needed to get AOL into people’s hands so that they could see what it actually was. {11}(McCullough, *How the Internet Happened*, 61). So she got the company to spend a quarter of a million dollars printing diskettes and shotgun sprayed them into the homes of anyone within distance. The results were astounding. People were taking the disk, loading it onto their computers, and simply handing over their credit card numbers. “When I saw that,” says Brandt, “honestly, it was better than sex.” In fact, so many people got on Usenet through AOL, in such a short span of time, that they were never compelled to adjust to the netiquette. Newbs just kept coming and coming, overwhelming the earlier users so that the previously established mores could not be enforced. This was the September that Never Ended, or Eternal September. By most accounts, on the internet today, we’re still living in it.

The process of Eternal September has repeated itself in various ways over the years, on various forums. Most people reading this can probably recall a Facebook group or a Reddit forum or a Twitter community that, at one point, was pointedly and focusedly *about* the thing that it claimed to be about, and which later became noisy, spammy, and dominated by those suffering from an excess of yellow bile. And in some ways, the case was no different for Hacker News. Whereas in 2007 its reason for existence was to replace techie Reddit, which had fallen prey early on to an Eternal September influx, by 2011 Hacker News appeared to have reached its own Eternal September. “Now that Hacker News is so much more popular” wrote entrepreneur Imran Ghory in (appropriately) September of 2011,  “the top links tend to be general technology, or geek, or political news” as opposed to news that's refined for the tastes of start-up entrepeneurs. [12](https://blog.imranghory.org/what-happened-to-hacker-news) Today Hacker News is still an interesting link aggregator, which continues to feature useful and intriguing information about all kinds of things, including start-ups, new technologies, culture, and politics. (A sample front page from April, 2021 listed articles about resources for amateur compiler writers, the geology of Mars, and a memoiristic essay from a man who believes he may be Bob Dylan’s illegitimate son.) But even a glancing comparison between 2007 comments and 2021 comments will betray a userbase that has become more ideological and splenetic. As Hacker News’s own moderator Daniel Gackle put it in 2019, “the one consensus is that it’s not as good as it used to be.”[13](https://www.newyorker.com/news/letter-from-silicon-valley/the-lonely-work-of-moderating-hacker-news)


**The Absence of Bubba**

Back in another September--September of 2013--Urbit’s debut on Hacker News garnered what one might call a mixed review. “It seems like Urbit is art for art's sake,” wrote cloud infrastructure architect and former IBM researcher Wes Felter, “the fact that it executes is a side benefit.” Commenting on the style of the early docs, which quickly became a flashpoint among HN commenters, software engineer Cory Burgett wrote “I thought the style was a refreshing departure from the usual tone of expository technical documents. I actually enjoyed reading it, even though I disagreed with many of the assertions that were made.” Soon afterward, a games designer named Lewis Pollard retorted, “Personally, I was reminded of the schizophrenic guy on HN who built his own OS.” Software engineer Risto Saarelma pasted in the comment he had made on the popular "rationalist" blog Less Wrong, founded by AI researcher and essayist Eliezer Yudkowsky. Saarelma's post gave an account of a strange dream he had the night before, in which Yarvin had

>  gotten tired of the state of the software industry and the Internet and had made his personal solution to it all into an actual piece of working software that was some sort of bizarre synthesis of a peer-to-peer identity and distributed computing platform, an operating system and a programming language. Unfortunately, you needed to figure out an insane system of phoneticized punctuation that got rewritten into a combinator grammar VM code if you wanted to program anything in it. I think there even was a public Github with reams of code in it, but when I tried to read it I realized that my computer was actually a cardboard box with an endless swarm of spiders crawling out of it while all my teeth were falling out, and then I woke up without ever finding out exactly how the thing was supposed to work.

Another user, who went by the handle Touche, wrote, “Watching the video blew my brains out the back of my head. Figuratively of course.” (It would appear Touche meant this as a good thing.) 

In general, the comments included a fair amount of befuddlement, a fair amount of admiration, and a fair amount of back-and-forth kibbitzing. One person claimed that the general idea was wonderful, but that the language of Hoon was ridiculous. One person liked the idea but felt it was obviously just for laughs and could have no practical implementations. (One person, whose interest in the project was expressed without equivocation, would later join the company built to bootstrap Urbit, and become its CEO). No matter what the take--and this would be in stark contrast to the comments that would become typical on Urbit-related posts in the second half that decade and in the few years of the ‘20s--almost everyone expressed respect for the grandness and novelty of the vision. Maybe certain details were off. And maybe the docs could be clearer. But at least it was something interesting and new. After all, the project was open source, so those who didn’t like certain aspects of it were always free copy some parts of it and make new and better versions. As Yarvin himself would put it, in an early document about the Urbit address space:

> If you don't like this, found your own kingdom in the cloud! Nothing could possibly prevent you. Heck, you can even take the Urbit function, copy it, replace the prince's root key with your own, and call it "Bubba."  Bubba and Urbit will compete on a perfectly level playing field.  I won't even be offended.[14](https://github.com/cgyarvin/urbit/blob/1bc9086a3fd62594e8bd631744cb9bf804f6a43b/Spec/urbit/3-intro.txt)

As of April 2021, there still isn't any Bubba.



Chapter 6. Lost and Found. PRINT 2+2. All the Cokes Are Good.

Chapter 5. Behind the Throttle. Flipping a Finger. Just for Fun.

Chapter 4. Pascal's Fearful Calculating Machine. The Only Thing He Couldn't Count. Symbiosis or Parasitism?

Chapter 3: Total Aesthetic Environment, Redux. Fake Engagement Team: World Police. Higher Ground.

Chapter 2: We are Giving Back to Our Community. Social Cooling. Act Promptly, Make Your God Happy.

**Martian Code**

In September, 2010, the three chairs of the Workshop on Self-Sustaining Systems received a highly unusual submission for entry into their annual conference, to be held that year in Tokyo.  One of the three admitted that the paper they received, which described a self-sustaining functional programming language called “Watt,” defined by a computation kernel called “Nock,” was “interesting and well worth pursuing.” Another noted that “the author has very good reason to use an alien language to create Watt.” Yet each of them ultimately decided to reject the proposal.

One chair began with this laconic observation: “A workshop contribution does not have to be perfect, but it needs to be presented in a way that allows for a technical evaluation. This paper is written in a different style,” citing as evidence for the paper’s indigestibility such sentences as “The relationship between Urth and Earth is unclear,” “Urth code is nothing like Earth Code,” and “Watt is functional programming for stupid people like you.” The chair concluded with the earnest rejoinder, “While reading the paper I sometime felt vaguely insulted, which is not something you want your readers to be.”

Earlier that year, in January 2010, the same author had first published his explanations of Nock and Watt (the latter of which would be renamed *Hoon*) on a blog inauspiciously titled Moron Lab. The title was a pun on *molon labe*, meaning *come and take them*—the phrase supposedly uttered by Sparta’s King Leonidas, when Persia’s Xerxes demanded that the Spartans lay down their arms. But while that phrase has come to signify defiance, the blogger evidently meant it in a double-sense. That is, he was posting his creations, which he had worked on in private for seven years, as open source projects, free for the public to come and take. “So long as you don't pretend my work is yours,” the author writes, “you can do whatever you like with it. (If my work actually is yours, it's probably because you had the same idea, but you had it first. This is common with good ideas! Send me a link and I'll post it.)”

The other double-entendre—the moron part—was that the research presented was meant to be *amateurish*—in the literal sense of doing what one does for the love of doing it, and not for the plaudits or access to bureaucratic posts. “Moron lab,” the author wrote, “presents my independent (but stupid) computer science research. Actually, like all sound engineers, I despise this term. I am a computer programmer.”

In another post, the author went on to draw out an elaborate conceit about the difference between software on Earth, and the sort of software that might be used by a highly advanced 50-million-year-old civilization on Mars. (He had by now chosen the conceit of *Mars* over that of *Urth*; Mars is the that stuck.) In this conceit, the author speculated that at some point in Martian history, its software would have become so complicated that a Martian “code monkey”—that is, someone who has a thankless and boring coding job—would have devised a method to toss it out and start from scratch again. Perhaps this code monkey’s initial effort would have failed. But then someone else would have tried. And then someone else. “Since the Martians had 50 million years to try,” the author writes, “in the end they must have succeeded. The result: Martian code, as we know it today. Not enormous and horrible - *tiny and diamond-perfect*.”

What makes code “diamond-perfect”? It must be both immutable (after all, in the Martian metaphor, it has lasted 50 million years or so) and self-complete (thus avoiding the patches, circuitous bug fixes, and tangled complexity lamented by Mars’s first maverick code monkey). “Earth-produced Martian code,” the author writes, “is truly Martian in character only if it is obviously and self-evidently immune to any extension or improvement.” What’s another way of putting it? Finally the author circles back to the conceit that gives his blog its title. “Martian software,” he writes, “must be far beyond simple. It can only be described as stupid in its majestic triviality. Or, of course, *moronic*.”

Thinking back to the consternation of the chairs of the 2010 Workshop on Self-Sustaining Systems, it seems possible, retrospectively, to sort out at least one misconception. Though the initial proposal paper may be lost to time, we can guess that “functional programming for stupid people like you” was not meant to imply that the chairs of the self-sustaining systems workshop were actually stupid. (Almost certainly, they’re not.) What was likely meant was that this new programming language, the one inspired by Martians, was meant to write software that anyone can understand *in toto*. In this way, the project would differ entirely from our current *earth* software, a complex mass of interlocking threads, with most of the knotty bundles understood only by specialists.

If you’re like me, and your version of *moronic* has more to do with zoning out with some chicken wings in front of the game, and less to do with designing diamond-perfect code, then you probably haven’t actually spent much time thinking about why the internet is designed the way it is. Like most highly contingent processes, the current internet’s birth, growth, and gradual usurpation of all our lives has a way of feeling both natural and inevitable. But in truth it is neither. The history of the internet, and of computing, is very strange indeed—that story will be briefly told in chapters 4 and 5 of this book. But the salient part for now is this: on Earth, unlike Mars, no one ever took an ax to the big knot of code that made things so complex.

That’s why, on earth, we don’t *run* our computers—at least, not the same way we run our cars, or our businesses; instead, we outsource our computing to data centers run by huge corporations that can change out entire computing experience on a whim. That’s why, on earth, we don’t actually own our online identities; instead, we can be impersonated, hacked, or arbitrarily denied service. That’s why, on earth, we don’t actually have online communities; instead we have online malls where we’re allowed to gather for free in exchange for enduring manipulative, unending, and increasingly madness-inducing algorithmically tailored advertising. And that’s at least one big reason why earth in the year 2050 might end up looking like a pretty scary place.

We’ll get to look at Martian computing itself, otherwise known as Urbit, later on, but for in the next few chapters let’s take a closer look at some of the ways the current internet falls short of Martian ideals.

The date is January 1, 2050. The place, New York City. The vibe . . . subdued. Back in 2020, you made a note to yourself to take stock of the world around you here at the half-century mark. And now the time has come. What do you find? The air quality is a bit worse, the bad parts of town are a bit more dilapidated, the Knicks are still terrible—all in all, from the outside at least, not much has changed from 30 years ago. Today you wake up groggy on your self-adjusting Smart Bed (Smart Bed Never Sleeps), you make yourself a steaming pot of coffee (locally sourced, delivered within the half-hour by a drone, now that you’ve got Titicaca Prime), you shower and get ready for work.  

But what was that dream you had last night? Only the faintest traces of it remain. A luminous rainbow, a mountain landscape, a sense of profound inner peace, mixed with euphoria, mixed with . . . an intense desire to go out and buy some Health Morsels cereal?

That’s odd. You’ve never even had Health Morsels. You open up your laptop, where you can view the activity of the iThink microchip that you got implanted in your cortex a few years ago. “Ads help Elysium provide you with free, quality sleep-monitoring. To disable ads, please upgrade to Elysium Premium.” That explains it. After all—and you pause for a moment over whether the forthcoming thought is yours or the iThink’s, before deciding that it’s much the same anyway—Health Morsels probably are delicious. And healthy, too.

As usual, they’re setting something on fire outside your home. Normally you’d scroll back through your Squawker feed to see what it was all about, but today you’re late for work, and anyway you’re in a pleasant haze after the Health Morsels dream—no point ruining it by poring over the latest Squawker pile-on. You glance at the awning. Ah, it's the bodega that's aflame.  Toilet paper and Juul Pods are cheaper in bulk from Titicaca anyway.

Another day at the office. You were never exactly passionate about content moderation, but hey, it keeps the lights on. (And since ConEd got absorbed by Titicaca, it’s been pretty important to have a Verified Income Stream.) It’s a normal day at work. Algorithms haven’t yet been able to filter out all Unverified Content—so it’s up to you the flag Unacceptable Violence, Disputed Claims, and Unfederated Currency transactions.

Except after your pleasant dream, it all suddenly seems so drab. You start to wonder whether there was an error last night—maybe they turned the dream levels up too high. Something from your night-time vision just won’t leave your mind, like a film strip looping over and over. It’s that river beside a sloping field, like you used to swim in when you were a kid. You can almost feel the icy cold against your skin, the sticks and mud against the soles of your feet, and then there’s the ripe, marshy scent of the riverbed. Uh oh. You realize you’re close to danger levels. This isn’t where your head’s supposed to be at. Frantically you scroll through content, seeking to moderate it. A user threatening violence against Titicaca. A stream that violates DMCA. A highly dubious Squawker claim, with no support from experts. Flagged. Flagged. Flagged.

Yet the river remains. You see it, you feel it, just as you feel the kiss of the sun on your shoulders, the breeze rustling through your damp hair.

Now you know what’s coming. You brace for it and wait. Three. Two. One. ZAP. Your iThink produces an electric shock: plenty painful but not permanently damaging—at least that’s what the Verified studies show. The river recedes from your mind. Following the shock, your iThink, as versatile a little machine as ever was invented, delivers a few milligrams of both amphetamine and oxycodone, bringing on a wonderful feeling of simultaneous alertness and relaxation.[1](https://news.mit.edu/2018/ultrathin-needle-can-deliver-drugs-directly-brain-0124]) You look up at your monitor. Content moderation doesn’t seem so bad, with the stimulant and the barbiturate swirling paradoxically through your system. It’s true what they say in the ads: iThink doesn’t just make you think better, it makes you *feel* better. You dive back into your content moderation with renewed verve, even flagging a couple completely innocent posts just out of surplus exuberance. So what if you hardly get outside at all these days, so what if you’ll never swim in that stupid river. The fastest electronics, your Health and Wellbeing tracked and adjusted by an intelligence far greater than that which you could ever hope to possess, a brain-reining gizmo that gives a whole new meaning to the term neural net.

2050 turned out to be a pretty good year after all.



**July 7, 2021 Update**: As I noted in the group feed, the scope of this project has expanded. The way I see it now, Chapters 8 and 9 of *Ab Urbit Condita* will continue along in an expository, technical (though not too technical) vein. I'll then release *Ab Urbit Condita* on its own, but I'll also cannabilize from it to write a longer book, still untitled, which will be more of a social history. (*The Soul of a New Machine* is a good comp). 

I'm trying to look a bit closer into what's under Urbit's hood before I post Chapters 8 and 9. Reading recommendations are always welcome.

**End of update**

I'm writing a book on the history of Urbit. I'll also write, in an Urbit-centric way, about the wider internet. I'll post chapters monthly. Right now I see it as going something like this:

1. Prologue. A short story about the year 2050. 
2. Introduction to the concept of Urbit.
3. Laundry list of the things wrong with the current internet, only more dramatic than a laundry list
4. Laundry list of the things wrong with the current internet, only more dramatic than a laundry list, continued.
5. Social history of computers
6. Social history of computers, continued
7. Technical explanation of Urbit, only more dramatic than a technical explanation
8. Technical explanation of Urbit, only more dramatic than a technical explanation, continued
9. Social history of Urbit
10. Social history of Urbit, continued
11. Summing up

All of which is subject to change, of course. 

I've never written an editable book in public before. Turns out it’s hard to resist tinkering all the time, if the option is available. So the book is always in a state of revision. But I’ll try to keep whatever’s up here more or less self-contained and coherent.

There's a lot I don't know about Urbit. And, doubtless, there's a lot I'll get wrong. I hope people pointing out where I'm wrong is one of the things that'll happen in this group. I'm learning as I go, which is the fun part for me.

Even though I'm writing this on Urbit, the audience I have in mind is: intelligent people who have not heard of Urbit and do not know much about computers. After all, these people far outnumber the people who know about Urbit. So I'm thinking like, *New Yorker*-level of technical explanation, if that's useful. 

Please do:
- DM me if you want to talk
- Point out technical mistakes in chat
- Point out typos in chat
- Be a grammar pedant in chat (some of my best friends are grammar pedants)
- Suggest people for me to talk to / Introduce me to people 
- Feel free to mention the project in other Urbit groups and link people to this group

Thanks,



Stations

The Machine War; or, Ab Urbit Condita

Chapter 9. The Limelight. The Sandbox. The Future.

Chapter 8. A Software Psychoanalyst. Functional Breathing. Tea at the Palaz.

Chapter 7. I Decided to Listen Less. Eternal Eternal September. The Absence of Bubba.

Chapter 6. Lost and Found. PRINT 2+2. All the Cokes Are Good.

Chapter 5. Behind the Throttle. Flipping a Finger. Just for Fun.

Chapter 4. Pascal's Fearful Calculating Machine. The Only Thing He Couldn't Count. Symbiosis or Parasitism?

Chapter 3: Total Aesthetic Environment, Redux. Fake Engagement Team: World Police. Higher Ground.

Chapter 2: We are Giving Back to Our Community. Social Cooling. Act Promptly, Make Your God Happy.

Chapter 1: Martian Code

Prologue: 2050, A Pretty Good Year

Prospectus and Notes on the Project

Links

Stack Podcast