Everyone has heard of Urbit, but nobody really knows what it is. This makes it a point of fascination in tech circles. Here’s a cypherpunk project with grand ambitions that has been worked on for nearly twenty years, funded by Silicon Valley luminaries. Formerly led by neoreactionary Curtis Yarvin, Urbit’s air of controversy and mystery makes it seem not just like a computing project, but like a secret society. What’s behind these doors?
At a glance, Urbit’s premise is appealing: allowing users to take ownership of their data again, and defining ways for users to interact on the internet without letting corporations play middleman. In short, it’s a peer-to-peer network, built to decentralize the internet.
I’m passionate about cypherpunk-style decentralization, so I was excited when a friend offered me a hosted Urbit instance to play around with this weekend. My takeaways follow.
My Urbit server
On Urbit, every user has their own server with an identity. I set up my server, installed some apps, and joined some chat rooms. As I accumulated a bit of data, I asked: where does my data live? By Urbit’s thesis, it lives only on my server. I could run my server on my own hardware – e.g. my laptop or a dedicated Raspberry Pi – but that’s unwieldy, subject to downtime, and so on. The alternative is to host a virtual server on a third-party cloud provider. This is unbelievably ironic. The best way for me to participate in Urbit’s decentralized, peer-to-peer universe is… to run a server on AWS.
Obviously neither of those two options are desirable for hosting my Urbit server. Hosting on my own hardware is annoying, hosting in the centralized cloud defeats the whole point.
This is where Urbit shows its age: it has no ambition for decentralized server ownership. The notion of a user running their own server, having to guarantee its uptime, backup its data, etc., is antiquated. If Urbit were reimagined in 2021, it would be running on Sia or Ethereum: your data is stored on the blockchain, your applications are running as perpetual smart contracts, and you can access it from anywhere in the world with just your private key. That’s compelling. In that world, both uptime of your personal instance and storage of your data are guaranteed as long as the network is healthy.
But Urbit has none of those things. It may not even have such plans. Right now it’s just a platform to make peer-to-peer servers. If your server dies, you lose your data. I hate that.
What can I do with my Urbit server?
You can enter decentralized, peer-to-peer chat rooms. You can torrent. You can do other classic peer-to-peer stuff. But that’s pretty much it. Urbit has deep infrastructure for supporting a set of APIs for virtual servers, but they aren’t meaningfully distinguishable from existing services at the application layer. I can do lots of peer-to-peer stuff from my ordinary computer. The benefit of Urbit over existing peer-to-peer tools is not clear to me.
Urbit’s architecture
Urbit tries to basically reinvent the whole networking model. Of course, it has mostly built things that look very similar to what’s in the traditional model, but now they all have different names. Instead of DNS, you have galaxies. Instead of ISPs, you have stars. Instead of servers, you have planets. You get to write code in Hoon and Nock instead of languages that actually work1 and are known by the public.
Urbit’s recreate-everything-from-scratch model is probably a net negative. On one hand, it is impressive and sort of awesome, a fever dream come true: finally someone just rebuilds everything from scratch and does it their way. Every programmer has had this urge,2 but it is a siren’s call. Futility lies this way, and the Urbit team has fallen for it. No team, no matter how talented, can out-build the rest of the global community. Urbit’s development speed was likely slowed by years due to this indulgent choice, and it has enormously harmed accessibility. For any engineer to dip their toes into Urbit, they have to study its terminology and languages for days. That’s a prohibitive barrier to most.3 If you want to do everything your way and have your project be an exclusive club, that’s fine, but you will not win adoption.
This leads to what I believe is the deepest problem with Urbit: it’s light on actual substance. Urbit seems to have spent many years developing fundamental infrastructure – programming languages, tools, etc. – that are a gigantic maintenance burden and orthogonal to its actual mission. That’s a huge distraction, and as a consequence, the “stuff you can do with your Urbit server” section was unimpressive.
In this sense, Urbit reminds me of an amateur novel or a poorly paced film: an outrageously detailed beginning that goes on forever, a hasty middle section, and a paper-thin ending as the author either gets tired or realizes it’ll take them a thousand years to finish everything at the same level of detail.
This half-bakedness discredits Urbit: if you’re really serious about your work, then you should be disciplined and focus on the stuff that actually matters, not toying around with the fun-but-marginal stuff for twenty years.
Conclusion
I am disappointed by Urbit. Its deep hubris in rearchitecting the entire computing/networking stack has wasted years of development effort, created an impossible maintenance burden, and made it inaccessible to most people who value their time. The product that Urbit actually ended up shipping is light on substance, offering little over what is otherwise already available today. Furthermore, its development slowness means that it is missing many features that seem like obvious table stakes in the age of blockchains: with no model for decentralized data storage or server ownership, I see no value. The notion that I should host my decentralized, peer-to-peer server on a third-party cloud feels like a bitter joke.
The final nail in the coffin is that – opposite to the real world – in Urbit, 0 is a truthy value, and 1 is falsy. This is the most pretentious, harmful, arrogant, and vain design decision I have seen in years.4 It underscores that Urbit is not a serious effort but a vanity project.
This essay first appeared on my website. Follow me on Twitter.
I don’t touch on this elsewhere in this essay because I think it’s nit-picky, but Urbit seemed really buggy to me. The disadvantages of building everything from scratch are considerable.
Some, like Terry Davis, have taken it further than others.
Imagine if Satoshi had written the original Bitcoin client not in C++ but in some insane, handrolled domain specific language. Nobody would have bothered engaging.
To whoever came up with this: fuck you. And fuck everyone who didn’t stop them.
The modern alternative to Urbit is Holochain. holochain.org
completely agree with this take