The Problem with Urbit
The Problem with Urbit
Sure, meme magic is real, but not like that.
For some time now I have been collaborating with fellow theoretical computer scientist Charles Rosenbauer on a new project we call Anodyne. In May of 2022 we embarked on an impromptu road trip, touring the continental US to solicit support for the product’s development and our own survival.
One of the things that came up repeatedly (and virtually always when we spoke with anyone of technical capacity) was a point of comparison to another project you may have heard of if you spend more than a little time online: Urbit. The point always was, this was the closest thing anyone knew of to what we were building. We couldn’t disagree.
I suppose it’s typical for the brainchild of a reactionary political theorist to have a star-studded Achilles’ heel like this, but I should caution I don’t mean to generalise or diminish it. Urbit is a large project, and I would cautiously admit optimism for some of its strangest features, like verbiage, for example. But I must admit that Urbit has one massive flaw, and funnily enough, it’s a political one: the burden of protocol interchange.
This is more obvious to people who either studied the distinction between functionalism and mechanicalism, or intuited it as many scientists of decades past did, but Urbit imposes an immense burden of protocol conformance onto its users as the technical price of participation. As the astute will note, this cannot be papered over through the papier-mâché of genericism or metaprogramming. In human terms, there is, like, a gargantuan amount of assumptions about how this stuff actually works under the hood. As I have surely said before, good systems engineers don’t ignore what’s under the hood – it’s actually their main focus.
I often like to help people imagine their way outside of the IBM-PC box their minds are trapped in by stating a fact: the Soviets had computers, too. The fact that they weren’t comparatively as good is a different matter, but suffice to say that for a while, the Soviets had their own bespoke computing industry, which mostly revolved around a series of machines they called BESM. This means that the Soviets made their own transistors, their own logic systems, their own storage mechanisms, their own memories, their own human interface devices, and so on, with no help or influence whatsoever beyond key theoretical devices such as the vacuum tube. Until they tried to clone the IBM 360, Soviet computers were as different from American computers as Soviet nukes were from American ones. Totally different timeline.
As systems engineers we shouldn’t be taking things like the IBM-PC for granted. It’s a very old system by today’s standards, and believe it or not, immense resources have gone into propping up its outward interfaces for the sake of continuous backwards compatibility. Market players are too entrenched at this point to commit to anything more daring than this due to diminishing returns, and now that we’re reaching the end of Moore’s law, things are beginning to heat up. When Nvidia is calling for 800 watt TDP targets for their next-generation graphics cards, the writing is on the wall: the silicon gravy train is over. This is probably why they, along with Intel and AMD, are rushing to see who can break the wattage ceiling fast enough, plopping consumers right into the Pentium Extreme Edition debacle, this time potentially with no way out. Their engineers know.
But what does that have to do with Urbit? Nothing at all, and that’s precisely the problem. Urbit is at such a pinnacle of abstraction that it can only even begin to appreciate it in the most expensive and white-glove fashion, with its specially-crafted “jetpack” accelerator modules that let you write C like a normal systems engineer. It is by no means native-first, and in the real world that implies massive (and wholly uncompetitive) cost differentials for having the privilege of writing your code in Runic script. There’s a reason they can only get the cost of Ether down so much, and the reason is because it’s abstract like this. Since Urbit is built on top of it, I imagine it would fare even worse.
I think that from a product conception the similarities are many, but that’s exactly where they end. The problem Urbit faces is a technical one, and one of ignorance, too – how could they have known about John Backus’ obscure research about the “von Neumann style”? Whatever happened, it’s too late now.
Lastly—and not to be a party pooper for all of the people who like to have drinking parties around crypto, but—you can’t socially engineer your way around this. Fundamentals will still have a critical influence over this technology, and your fate too, to whatever extent you are invested in it. The fundamental thing is, this just depends on too many protocols. There’s too much to keep up with by hand, and automatic shortcuts for that kind of engineering stewardship will always be much more expensive from a cost standpoint. There is no way to “optimise” this out, like it’s some kind of normal codebase. You have to come down from the tower of abstraction.
Hey, thanks for reading! This was another free post by Alexander Nicholi. I try to make about a third of what I write free for public reading, but presently I’m still trying to make it and get by on my own. If you could support me with a subscription, that would mean a lot. My asking is just $5.55/month, or $55.55/year. Make a difference in the world by helping people like me stay fed!