Urbit - The Good, the Bad, and the Glitches

An Interview with Urbit Developer Jurij Jukic

Hello Jurij! Thanks for taking the time to do this interview with me at The Cultural Futurist about Urbit. A few of my readers are already on Urbit, while others want to know more about it yet feel confused by the technology. Others have no idea what it is, yet could stand to enhance their perspectives since they have an interest in decentralized protocols. You’ve been working on Urbit for this past year, so you seem like the right person to speak with about it.

The goal of my interview with you is to find out more about the technology behind Urbit, rather than focusing on its social scene like that annoying group of journalists desperate for their 15 minutes. So, let’s take some time to get to the core of Urbit’s technology.

---

Rachel Haywire: 

For anyone who is entirely new to this, can you tell my readers what Urbit is?

Jurij Jukic:

Urbit is an attempt to solve the following two problems: 

1. Software is a ‘ball of mud’

Software is incredibly complex which precludes individuals from building interesting projects and instead requires large entities to build SaaS for it to make financial sense.

     2. The internet is centralized

Most of our internet activity is on ‘the cloud’, i.e. on a server somebody else owns. This means that true data ownership is impossible for individuals, as well as true peer-to-peer activity on the internet without a mediator.

The way Urbit approaches these problems is by rebuilding the software and computing stack from scratch as to avoid the ‘ball of mud’ problem, whilst building a personal server (not the cloud) with peer-to-peer networking primitives that function as building blocks. You could call this the personal server/OS thesis.

Urbit is an attempt to make computers great again, and to make the perfect computer and networking stack, which would allow for a truly free and sovereign internet. 

RH: 

What is the history of Urbit? How did it come into existence?

JJ: 

With the caveat that I wasn’t there when any of this was happening and that this information comes solely from my reading, I want to emphasize that Urbit is the brainchild of Curtis Yarvin, who started it in 2002. He had the forethought to see how both the internet and software would suck in the future. The idea for Urbit originated in a thought experiment where Yarvin contemplated a Martian civilization which would have to rebuild its software from scratch to address the big ball of mud problem. From Curtis himself:

“Rebuilding from scratch is such an obvious and essential response to the big ball of mud pattern that, despite the fact that we know nothing about Mars, we can deduce that it must have happened on Mars. Probably several times. Probably several hundred. For each of these attempts but the last, of course, the result was either (a) abject failure, (b) another big ball of mud, or (c) both.

But the last, by definition, succeeded. This is the crucial inference we can draw about Mars: since the Martians had 50 million years to try, in the end they must have succeeded. The result: Martian code, as we know it today. Not enormous and horrible - tiny and diamond-perfect. Moreover, because it is tiny and diamond-perfect, it is perfectly stable and never changes or decays. It neither is a big ball of mud, nor tends to become one. It has achieved its final, permanent and excellent state.”

A note here - Urbit calls itself Mars, while all other software is Earth software. This speaks to the ambition of the project to redo everything, and separates itself from the past mistakes of Earth.

By 2013, the first command-line version of Urbit was working, and the company to steward Urbit was founded – Tlon.  In 2020, the first Urbit user-facing product was launched by Tlon, a minimal interface for groups and chats. Since Tlon was burdened with both userspace and kernel development, a new organization was formed in 2021 - Urbit Foundation - to focus on the kernel, while Tlon would then be able to freely build user-facing products.

This was a long time to be working on a project without having a well-tested business model. This long development time, to me, felt like a feature and not a bug, because Urbit is supposed to be the 100-year-old computer - a computer that will stay frozen long into the future.

RH:  

What drove you to join the Urbit, and what was your role in the project?

JJ: 

It was my deep-seated hatred for the social media algorithms that enslave people. Urbit seemed like the only credible way to fix this problem. I thought the internet sucked and that we needed to rebuild it from scratch. I discovered it in early 2022, and spent the summer learning how to code in Hoon, which is Urbit’s unique programming language. 

Initially, I got a grant to build a decentralized app store on Urbit, which would allow people to curate Urbit apps. As new people came on board, we soon realized that the real problem here was curation. Not only of apps, but of everything. The project slowly morphed into a social media/discover-everything app, and we eventually managed to secure the funding to build a startup. My role was userspace development, and I wasn’t messing with the kernel. I was deeply involved in Hoon, though.

RH:  

You’ve described Urbit’s technology as distinct from its aspirations. Can you elaborate on the current state of Urbit versus its intended goals?

JJ: 

I’ve outlined the aspirations of Urbit as both the personal server and an overhaul of the computing stack as if they’re intrinsically connected. They aren’t. Building the computer from scratch is an incredibly risky and ambitious project which is likely to fail. What are the odds that Urbit is the diamond perfect software Yarvin references? More likely, it’s just one iteration amongst many to come - a ball of mud (technical argument here), which Yarvin wanted so badly to avoid.

A personal server should not require such a tremendous task to be achieved. Therein lies the bane of Urbit. 

RH: You’ve mentioned Urbit has had issues with reliability and security. Could you detail these concerns and suggest potential improvements?

JJ:

As anyone who has used Urbit knows, it’s extremely clunky and slow. A lot of times random things simply don’t work, and you can’t even run your own Urbit. Those on Urbit barely use Urbit to coordinate. It’s a constant upward struggle to use it - and that’s coming from a developer. The Urbit Foundation and Tlon are aware of this, and they are working to fix it, but for a system that touts itself on fixing computing and reducing complexity, this systematic occurrence of bugs should not happen. It is precisely a product of excess complexity (i.e. a ball of mud), and a lack of modularity which good software should have.

The Urbit Foundation knows the necessary improvements to reliability and security, but it’s going to be years before it gets where it needs to be. By that point, who even cares for an isolated system that is functional but not complimentary with AI?

A consequence of Urbit’s design decisions – an isolated language/VM built from scratch (Hoon/Nock) – is that backward compatibility with the rest of the software world is non-existent. Most significantly, Urbit is behind on AI. LLMs cannot generate Hoon code well enough to compete with generating any other language. Either Urbit builds AI on Hoon, which is a difficult task to achieve, or it tries to be compatible with existing AI. (which is antithetical to the entire design of Urbit)

RH: Urbit is often discussed in the context of its ideology. How would you describe this ideology?

JJ: 

‘We are destined to succeed.' Because Urbit is doing God’s work to make the perfect computer, it will be able to eventually outcompete Earth software. This timeline is, of course, long. It’s not simple to reinvent everything. This leads to a lack of iteration and testing of the initial hypotheses. It is about achieving the perfect system, but the properties of this perfect system are rarely questioned or iterated upon because of the sunk cost fallacy.

Recently Urbit has been getting a feeling of urgency because you can’t keep spending money without delivering. There seems to be a ‘there is growth just around the corner’ kind of tone. The most potent thing Urbit has going for it is a large, concentrated amount of intelligent people with some type of cultural sensitivity, which makes it a great environment for nerds and outcasts. Since Urbit is so obscure, it’s selected for the kinds of people who like obscure things and are willing to put in the effort to understand them.

It’s actually kind of hard to encapsulate what Urbit is about. I mean, it’s sort of about these cool nerds and outcasts doing something great for civilization. At least that’s my cynical take. It’s a massive virtue signal, it’s great fun, I fell in love with it, and it fucking sucks. There is some real technical skepticism, but the ideological discourse was so strong that I ate up the technical ideas  – which have yet to be tried and tested – as truth as truth. Being a young, inexperienced engineer, I never questioned them. 

RH: What advice would you offer engineers looking to build a new platform inspired by Urbit but without its early pitfalls?

JJ:

I would point them to better engineers than me who have learned from Urbit that are already building more interesting projects. Specifically, Uqbar is going to build a personal server without Hoon and all the Urbit-y stuff with the most pragmatic tools possible, rather than building a computer from scratch. Plunder, continuing the legacy of Urbit, is building the next-gen SSI which is also compatible with Earth software.

Referring back to ideology, these are the people who know that ubiquitous personal servers and/or reinventing computing is not inevitable, and in fact, an extremely unlikely goal to achieve. 

RH: Finally, can you describe your vision of an ideal decentralized platform for readers of The Cultural Futurist?

JJ:

Let’s go back to the original vision of Urbit here, which I think is correct - to reduce software complexity. If you look at the web3 landscape today, it is ridiculously complex. You have to take care of data infrastructure, blockchains, identity and reputation, and protocols. Some startups are helping to fix a piece of that puzzle, while others are trying to have more ambitious projects that try to integrate the pieces into a web3 social media platform, which requires many of these pieces. 

Now, put AI into the picture. Do you want to be calling Sam Altman’s API forever? No? Then you need open source models running on trusted servers. For interesting use cases, you not only want AI to talk to in a ping-pong fashion, but you want it to be able to write and run code on all existing data to be your assistant. How can AI use all your existing data if each of the pieces of data is in a separate place? You look at the blockchain for transaction data, you look at Gmail for emails, you look at docs, etc. 

So what’s going to happen, at the lowest common denominator, is that your ‘personal’ AI is going to run in the cloud and all of your data will be on the cloud. There is no way web3 infra will be able to compete with the quality of context a centralized server can provide for the AI, because it requires aggregating data from a million different sources.

This is just the AI angle. Let’s talk about the network state. How are you going to create a network state if all the people there are busy trying to build infrastructure for themselves, instead of using it to create value? Fuck it, why not just transact over PayPal and worry about creating something interesting? 

For 99% of things, you will not be building anything transgressive enough to make PayPal censor you. Instead, all the effort is going towards bypassing PayPal and all the centralized monsters (which I admittedly hate), but it’s going towards infra! The amount of investment going towards actual useful products compared to infra on web3 is ridiculously small.

With all of that being said, the solution here is data and code integration across the board. Can you integrate data and code across the board, making a system that fixes all these problems that is not backward compatible with all the data and services that already exist? Yes. Can you get enough network effects for such a system so that it becomes useful? No. You need to build a system that integrates data and code across the board that is also backward compatible with the data and services that already exist. 

RH:

Thanks for taking the time to do this interview. With all the questions surrounding Urbit, I think this will be an illuminating piece for anyone looking to understand how it functions at a core level, additionally propelling the evolution of new decentralized protocols in the future.

****************************

Jurij Jukic is a software engineer with a focus on the edge of technology and philosophy. He dropped out of maths college and tried building a startup on Urbit. He is interested in the social consequences of technology, and currently figuring out what to build next.

---

Get 50% off an entire year of The Cultural Futurist to kick off 2024! That’s only $30 for the whole year, which is less than a single meal in San Francisco.