Urbit :: the good, the bad, and the insane

In this post I’m gonna be making all kinds of fun of Urbit. And all that after spending just a few hours poking around it.

Originally, I wanted to write in the layout of the good, the bad, and the ugly, but I’m not entirely sure how that would pan out.1

Before I begin, I’ll somewhat oversimplify and explain Urbit to those of you not in the know.

And before I do that, here’s a PSA: there’s a tl;dr at the end. So you don’t need to read all this drivel. You’re welcome.


According to its own webpage, Urbit is an “overlay OS” and network for the 21st century.

What that means at the time of writing2 is that it’s a single-threaded interpreter running as a unix process that speaks udp protocol to a meshed network (and http to your browser).

And all of that in the name of delivering you flaky, unreliable, and feature-poor implementation of an internet forum. (in a nutshell)3

An additional component of Urbit is its “distributed” identity component, where your identity is uniquely tied to a 32-bit integer. And to go with the zeitgeist, it’s backed by Ethereum blockchain. Naturally.

All we need is quantum computing and ML, and we have all the latest buzzwords. Oh, wait.

But to better explain what’s going on, let’s look at…

A bit of history

I’m going to take Urbit’s history page on authority here.

This project started in 2002 as a PhD thesis to reinvent computing. Over the next 6 years the progress was a language specification (Nock) for a turing-complete language with ~11 instructions.

Then, over 10+ years other people ran with it, took it further, and implemented:

If this smells like a bad case of NIH, it’s probably because that’s exactly the case.

Urbit as an ideal: good and insane at the same time

But let’s talk about Urbit as an ideal for a moment.

Let’s assume that when the marketing materials speak of

defining an operating system on a single piece of paper


throwing away every line of code from the 1970s

they mean well. Given some sort of hardware implementation of Nock (the low level language) you theoretically could throw away everything and start from scratch.

And it would be all kinds of awesome, if you could have decent control over your personal computing without all the cruft accumulated since ’70s.

Only… with Urbit this ideal would be so slow as to be useless. See, Nock has one arithmetic operation, increment (x+1). So if you want to decrement x, you have to loop from 0 to x-1. Or you can break your promise of throwing away all the code from ’70s… and implement decrement in C.

And the same story (of replacing godawfully ineffective implementation of native code with C implementation) goes pretty much for any reasonable functionality you might expect. Crypto? Sorting? Basic math and string ops? All of it.

The entire frickin’ peer to peer protocol is written in C, too. So are vast swaths of the OS: db, ames, http, terminal, database, event processing, …

Is it possible to truly throw away every line of code from the 1970s up until now… and start from clean slate? Hell yeah. Only, probably not with Nock.

So we have the pivot to “overlay OS” (mentioned on urbit.org), in other words: let’s not throw away any lines of code, but instead build on top of them. And then access the UI using a conventional browser over http, that will interpret the React-based javascript (among other things).

So far so good.

Ubit’s core promise:reality – 0:1.

Hoon as a language: amazing

Let’s move on to the Hoon language4, the workhose of the platform.

Once you start diggin in, you will be constantly met with such vomit inducing beauty:

::  ConCATenate file listings
::::  /hoon/cat/gen
/?    310
/+    pretty-file, show-dir
:-  %say
|=  [^ [arg=(list path)] vane=?(%g %c)]
=-  tang+(flop `tang`(zing -))
%+  turn  arg
|=  pax=path
^-  tang
=+  ark=.^(arch (cat 3 vane %y) pax)
?^  fil.ark
  ?:  =(%sched -:(flop pax))
    [>.^((map @da cord) (cat 3 vane %x) pax)<]~
  [leaf+(spud pax) (pretty-file .^(noun (cat 3 vane %x) pax))]
?-     dir.ark                                          ::  handle ambiguity
  [rose+[" " `~]^~[leaf+"~" (smyt pax)]]~
    [[@t ~] ~ ~]
  $(pax (welp pax /[p.n.dir.ark]))
  =-  [palm+[": " ``~]^-]~
  :~  rose+[" " `~]^~[leaf+"*" (smyt pax)]
      `tank`(show-dir vane pax dir.ark)

that makes Perl the world champion of readable languages by comparison.

I’m not being entirely fair here, because I’m sure you can memorize the digraphs in a few weeks5, and eventually you get the hang of writing this. But in the grand scheme of things… why the heck would you want to?!

It is hard enough to write bug free code in a language that you can find tens of thousands of top notch coders for (that would give you an honest code review). It’s quite another thing doing basic reading of Hoon.

But let’s say I’m biased, this is the future, and 5 years down the road it will be the gold standard for personal computing dev6.

What can you expect in terms of features, then?

Well, since you’re essentially supposed to run on top of Nock, and it’s all supposed to be strictly deterministic on top of an event stream, my imagination is failing me as to how it’s going to support some sort of parallel processing, because you probably don’t want to be stuck humping one core of your CPU.

Let’s say you try to make it work in parallel using message passing. Hmm, there goes determinism.

Or shared memory? There goes using “Nock” (as you’re poking yet another hole in the substrate).

I’m sure there’s a solution, but I’d bet you a doughnut it’s not going to be as pure as the marketing.

Hoon:reality – draw (it works, but sigh)

Urbit as an OS – capable?

Do you remember how we were supposed to throw away all that code from ’70s?

So that’s not happening (as described above).

But at least the OS is a shiny awesome thing capable of real tasks, yes?


Given my short exposure to Urbit I’m sure I’m missing some dark corners where clumps of awesome lurk, but if you expect more than a Weather app, half-assed web forum, simple shared notebooks, and a weird ass terminal, you will be sorely disappointed.

Again, this will be rectified in the future (of that I’m actually and honestly sure).

There are already some third party Hoon implementations of bit torrent, chat bots, etc.

And there’s some plans for bitcoin integration, 3rd party apps, etc.

So if the ecosystem takes off, it could be rich and wondrous.

Except… most of it won’t be written in Hoon or Nock. Since Urbitians are hard at work providing language bindings for well known languages.

So what are you gaining by using Urbit that you couldn’t get elsewhere? No, seriously… I have yet to figure this one out.

Let’s move on…

Hosted Urbit – only if you want to wash your dirty laundry in public

Now, let’s think about hosting Urbit for just a moment.

You can run it on your Raspberry (and it will work). You even own your data that way. (duh? don’t you always, in that case?)

But let’s suppose you want to host it elsewhere. I mean, there’s this awesome peer-to-peer encrypted protocol in Urbit, so it’s secure, right?

Well, there’s encryption during transit, and then there’s encryption at rest.

And the failboat comes in the latter case.

Nothing in Urbit is encrypted at rest.

No, seriously, all the chat logs, events, everything… is dumped into a journal on disk7 in cleartext form.

So, hey, also the whole “a vault for secrets” from the marketing video? Hmm… are you going to risk it?

And are you going to risk storing your bitcoin wallet on Urbit, unencrypted?

In other words, when hosting urbit at any 3rd party, you better be the only one with access to the underlying OS (and have it fully encrypted), lest you want your entire history worth of data readable by the company running the instance for you. Or anyone with access to the system.

So, running this on GCP? Digital Ocean? Tlon’s hosting? Only if you’re comfortable [potentially] washing your dirty laundry in public.

Urbit:real world – 0:1

Let’s fail together over the air

So say you run your Urbit securely on your Pi, you love the platform, the UI, the whole shebang.


Nothing to fear then?

Yeah, maybe except the teeny tiny detail that if you want to stay up to date, you need to configure OTA8.

So you will be receiving updates to your Urbit instance from one of your neighbors (one that you configure).

And you talk to your neighbors over an end to end encrypted channel.

Sounds great, since this is 2021, and surely the updates are signed.

Well, no. They are not. The transmission is, though. Big help!

So – I guess it wouldn’t be that hard for one rotten apple somewhere on higher ranks of the network9 (rogue operator, hacked machine, hacked core dev’s machine) to push a code update that exfiltrates all your data, possibly including all your secrets (hey, remember the BTC integration)?

And imagine the fun of auditing Hoon for potential security holes in an update, if you were paranoid. Just the thought is hilarious.

Urbit:security – 0:1

Urbit ID – scarcity creates value, and you pay a premium for that

So I watch in great amazement the booming ecosystem of cryptocurrencies of different shapes and colors, and of all things blockchain.

Urbit ID is even better than all of them, though.

You see, the entire identity address space is artificially constrained to 32bit integers10.

And according to the Urbit promoters and backers, scarcity creates value.

Just like that.

No need for demand or anything. It’s scarce, hence it has value. Done11.

The fact that a desperate enough person could do an equivalent of a hard fork, and run it independently with a different Identity root is… impossible?


But anyway, let’s say you want a permanent identity in Urbit.

Well, you’ll have to pay for it. Dearly.

Given the Ethereum insanity with gas prices past several months… an Urbit identity will set you back some $200. $20-$40 for the identity itself, the rest on the gas fees (transaction costs).

Of course, since the entire Identity framework is bound (for no good reason) to Ethereum, should you want to perform some operations (like rotating your encryption keys), you’re gonna pay again.

As with many other things mentioned thus far, even this issue might eventually get solved. But the todo list is about a mile long now, isn’t it?

Urbit as an ecosystem to understand

When you first visit urbit.org, it might all make sense on 10k mile high level. The premises are interesting, the website readable.

The problem is that you cross the chasm to weirdness in a jiffy. And then it just keeps on getting better.

I think the weirdness is on purpose, though. To get you interested.

So forget all you know. Learn what the following terms mean:

Azimuth, Galaxies, Stars, Planets, Comets, Ship, Nock, Hoon, Arvo, Ames, Gall, Dojo, Landcape, @p, (sein:title our now our), …

And with these I’m barely scratching the surface of what you need to grok.

Should you want to learn about any of it beyond definition, you have your work cut out for you for several weeks at minimum.

And I think it’s all done on purpose. Because once you invest that much time, it’s hard to rationalize to yourself that it was all just so you can chat with people on a forum. There has to be a higher purpose to all of it.

And I still can’t shake off a bit of a cult-ish vibe there. Regardless whether on purpose, or purely accidental.


At the top I promised a tl;dr. Here it is. All honesty, no jokes:

Urbit is a great idea (independent personal computing), with a hypocrite for implementation, and [as of today] a tunnel vision of personal computing == yet another social network / chat app.

The implementation doesn’t meet today’s minimum bar in several dimensions:

  1. End user usability: who wants to learn what scry means?
  2. Near-zero security:
    1. no encryption at rest
    2. no signed updates
    3. zero chance for auditability of the whole thing
  3. Features: right now a weather app, a shared notebook, and a feature-poor forum
  4. Extensibility: Unless you drop to the real world and use the various conventional programming language bindings, there’s near zero chance you will be extending this thing [in its native language]12.

And that’s not to talk about the broken promises:

  1. Urbit is not deprecating OSes, it builds on top of them
  2. Urbit isn’t 30k lines of code; just pkg/urbit/{jets,vere} is 36k lines of C, pkg/arvo is 103k lines of Hoon, and UI is 6k lines of Javascript.

More or less, it seems to me that Urbit is an ill-defined solution looking for a target audience that fits.

Final word

I’m sure that with an enthusiastic community (they have that in abundance), enough time, and herculean effort, this can be mildly interesting yet-another-social-network-or-chat-app-only-independent type of deal.

But other than that?

I see exactly no reason to switch away from the conventional computing stack.

  1. Because when you meet such a dense concentration of fail, you have to wonder.

  2. 2021-02-17

  3. Their marketing machinery would have you believe that it’s a huge breaktrough, since it’s built “from scratch” on top of a minimalistic language called Nock that has ~11 instructions. And that by doing so you get all kinds of benefits, like owning your own data and identity. But I skip ahead…

  4. That would be your assembly. Because Nock == writing CPU opcodes directly. Hoon == assembly.

  5. I wish I could say that I’ve seen worse. But no, having been through my share of alien technology adoption (while working for my current employer), I have yet to find something this bad, with the notable exception of Brainfuck and obfuscated C competition. But at least those two aren’t meant to be production code.

  6. No not among general populace, but among the general nerdery of the Internet.

  7. So far no way to trim the journal. It’ll come in the future. So there goes all of your history since first “boot” (or, rather, last “breach”).

  8. Over the Air updates.

  9. Galaxy level, for those fluent in Ur-lingo.

  10. Well, it isn’t, because comets exist, but let’s all pretend it is. Wink wink.

  11. No, seriously, since the entire codebase is MIT licensed, there has to be some other business model for it. And selling the IDs and “ship” hosting is it. So it better be valuable and in huge demand, or they’re screwed.

  12. Which could be a way to ensure job security, yes?