Review of Urbit
Introduction
Urbit is the mysterious, interesting project you’ve never heard of. Or maybe you’ve heard it, because it’s gotten a fair amount of publicity for being a moonshot project. The project operates on a new software stack you don’t quite understand, and claims to be an alternative to the perils of centralized computing today. It’s wacky enough to call performance art, but they’ve published real software which anyone can run. Unlike many other pie-in-the-sky ideas, Urbit was founded by a computer science PhD with expertise in the fields he’s tinkering with. It seems like it’s full of hot air but it’s not easy to dismiss.
Urbit is famously difficult to grasp
Understanding Urbit at first seems much deeper than what it does at a high level because it has its own operating function, interpreter, programming language, virtual machine, and networking model. Each of these has unusual design decisions and understanding the sense in these requires understand the design choices of modern operating systems, interpreters, programming languages, virtual machines, and networking model as well as how these interact with each other.
The steelman case for Urbit
Urbit is an experimental computing paradigm
There are a number of ways to describe Urbit:
- 100 year computer. Namely, the kind of computer you’ll still be using in 100 years.
- An alien computer. If an advanced alien spacecraft crashed into the Earth, what would it’s computer system look like?
- A new computing stack. How would computing look if we threw away everything we knew and reinvented it with the lessons we’ve learned along the way.
- An operating function.
- Your personal private server.
- If your operating system were a blockchain
Sounds wacky that all these things could describe the same thing, right? The most down-to-Earth way of understanding Urbit is that its founder disagrees with the way we’ve done things in computing for the last 50 or so years. Namely, he disagrees with design decisions (e.g. networking, the quasi-deterministic behavior of modern CPUs), the client-server model (your digital life on Google, FB, etc.), and the complexity of modern software (how many lines of code is your operating system?).
What Urbit offers in return is a virtual machine. This virtual machine has some new properties: it’s strongly deterministic, formally specified, simple, and portable. Bundled with this is an interpreter, a new programming language, networking, and an operating function.
Urbit is a server-side browser
Everyone has a client-side browser. Chrome, Firefox, Opera, etc. What makes these browsers client-side is that they are the clients in a client-server architecture, where the servers are typically the services you use (e.g. Gmail, Facebook, Amazon, etc.). By inverting this relationship, you get a browser (i.e. sandboxed kernel) which acts as the server. Put in another way, it’s a peer-to-peer computing paradigm to challenge our client-server computing paradigm.
Urbit reduces leaky abstractions
Software abstractions are often built on top of shaky foundations. Software ultimately runs on hardware, and so can never truly be decoupled from the layers below it. At the software-software interface, the separate modules are not supposed to make assumptions about each other, both imperfect systems. The implications sometimes relate to performance — to have a fast program you sometimes need to violate the abstraction (e.g. traversing a 2D array to use caching best). The implications can also relate to soundness — TCP is a reliable message protocol built off of IP, an inherently unreliable one.
With Urbit remaking the whole computing stack, the hope is that these leaky abstractions can be reduced as they are all being designed against each other.
My take on the project
Urbit is deliberately obfuscated
There is no way to reconcile how detailed and intricate Urbit is and the non-existence of clear explanations. It doesn’t take a genius to understand the big picture of Urbit — the project is just deliberately obfuscated. This is a red flag because vanity (e.g. “Only smart people understand Urbit”) is really not a productive personality trait in technology.
Community building is an important aspect of any new technology. But for people to use it, need to understand its value proposition. Urbit fails badly in that regard.
What is Urbit? It’s a virtual machine built for distributed environments. You won’t find that explanation anywhere because they tend to emphasize every aspect of their new stack like it’s the singular core value proposition. It ends up leading to rabbit holes where the reader gets lost in unnecessary detailed technical discussions when they’re just trying to find out what the big picture is.
And why is Urbit being built? The only de-obfuscated explanation of what Urbit aims to be is from one section in their 57 page whitepaper.
Urbit is designed to work as a “personal server.” This is not yet an established product category, so let’s explain it.
Everyone has a personal client, a secondary kernel isolated from the OS: the browser. Almost no one has a personal server, but they should. Urbit is a “browser for the server side”; it replaces multiple developer-hosted web services on multiple foreign servers, with multiple self-hosted applications on one personal server.
Why attack this problem with a clean-slate stack? Arguably, what stops people from running their own servers is the usability challenge of administering a Unix box on the public Internet. The Unix/Internet platform is 40 years old and has built up a lot of complexity. Mechanical simplicity does not guarantee humane usability, but it’s a good start.
A clean-slate personal server, with its own encrypted packet overlay network, can forget that Unix and the Internet exist. It can run on Linux and send packets over UDP; it can both provide and consume HTTP services; but its native stack is not affected by 20th-century design decisions.
HTTP services? Since a new network has no network effect, a node must find its first niche as a client and/or server on the old network. For its earliest users, Urbit has two main roles: as an HTTP client, a personal API aggregator (which organizes and controls your own data on your existing cloud accounts); (2) as an HTTP server, personal publishing and identity management (blogging, archiving, SSO, etc.). But Urbit still differs from existing Web application platforms in that an instance is designed to serve one primary user for its whole lifespan.
Violates Gall’s Law
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.[9]
This is a general trend in complex systems — complex systems are built up incrementally. Urbit is designed completely from scratch. I would say either the odds are against Urbit, or their development timeline is going to be decades (e.g. by making simple versions of what they want to build, and let that complexity develop over time).
Urbit is conflicted in their deliverables
Supposedly Urbit’s deliverable is a personal server. There are unambiguously better ways of going about creating a personal server. Namely virtualizing existing computing stacks, not creating an entirely new computing stack to virtualize.
Complexity in design is at odds with development speed and a major factor in why Urbit is decades in development. I don’t think it’s reasonable to say Urbit is really a personal server anymore — their focus has primarily been on creating the “perfect” stack oriented towards distributed computing. If you’d like a personal server you are best off working with pre-configured virtual guest operating systems, possibly existing in the cloud.
Architectural astronauts — Urbit is over-engineered
The scope of Urbit’s design is much larger than it should be for their stated deliverables. I’d rank it squarely between Ethereum and IOTA. Unlike Ethereum, Urbit has no use-cases that couldn’t be done through other means. Unlike IOTA, the project is slightly more grounded as it tends to focus on things it can deliver (see: Jinn, a ternary microprocessor).
What these projects share in common is that they are made by architectural astronauts. That is, these systems are made by trying to abstract design to the high heavens and tend to that software is a means to an end, meant to solve a real-world problem:
- Ethereum — what if Bitcoin could be a general-purpose computer?
- IOTA — what if we abstracted a blockchain into a DAG, invented our own cryptography, and abstracted binary to ternary computing?
- Urbit — what if we redesigned the entire computing stack?
What about if we just tried to focus a problem people tend to experience today, right now?
Conclusions
Urbit appears to be more interested in building a “perfect system” than solving the problem they claim to want to solve. I am skeptical that Urbit is going to be anything but a niche project for a few reasons:
- The project is deliberately obfuscated
- Violates Gall’s law
- Urbit is conflicted in its deliverable
- Urbit is over-designed
What it would take to change my mind is an important problem that Urbit uniquely solves or is uniquely capable of solving that alternatives can’t achieve. Failing that, to me Urbit is a vanity project.
