Big Ideas from Urbit Assembly 2023

Three Things #92: November 5, 2023

As in previous years, Assembly was equal parts tech, culture, and philosophy. There were also cool animations showing Urbit battling flying Windows logos, and excellent live music. Photo by the author.

Urbit Assembly 2023 just wrapped up in Lisbon. This was my third Assembly. The first two events were excellent; last year’s was one of my favorite conferences ever. It was equal parts tech deep dive and plain weird. So despite the longer trip to Europe I didn’t want to miss this one.

Urbit has long fascinated me for many reasons. It’s good computer science: the more I work on related problems, including deterministic, solid state virtual machines and P2P networking, the more I understand Urbit from first principles and the more Urbit’s design makes sense to me (even if it makes little sense at first contact). Sometimes it feels like all computer science roads lead back to Urbit, and that Urbit is the apotheosis of the human-centric computational model.

But it doesn’t stop there. As I wrote last year, as much as it’s a technical project Urbit is equally a social and political movement. Whereas just about every other tech community, especially blockchain communities, pretends to be apolitical, Urbit proudly leans into its politics (although precisely pinning down those politics is not so easy). Urbit cares a great deal about aesthetics which are, after all, upstream of politics: this, too, is unique among tech communities, and correct.

Of course these are all abstract ideas. You can’t expect to understand or appreciate any of them, nor can you expect to understand the Urbit community, remotely or virtually. That’s why these conferences are so important. At the end of the day, blockchains are people and Urbit is people, too. It was through Assembly that I first really began to understand what Urbit is all about and why you and I should care about it; and the previous two conferences have been an opportunity to catch up with everything that’s going on in an increasingly active, diverse ecosystem.

Without further ado, here were my three biggest takeaways from this year’s Assembly.

Thing #1: Urbit is Actually Almost Useful 🤞

A few years ago when I first touched Urbit there was as yet no real frontend. It was just a CLI tool that resembled IRC, BBS, and early newsgroups more than anything else. But the first official frontend, Landscape, launched four years ago and it has continually improved since then. Since Assembly happens once a year and it’s now been two years since the first, this provides a nice, unscientific opportunity to checkpoint the state of Urbit and its app ecosystem “beyond the hype.”

I remember struggling to actually use Urbit at the first Assembly in 2021. My long-running ship had crashed and every time I tried to boot it up it would crash again with mysterious errors. I followed troubleshooting instructions but couldn’t fix it. At the event, one of the core devs kindly fixed it for me, but it died again a few days later. There were no native mobile apps and the mobile web experience of Landscape wasn’t very good. I was using my laptop to connect to the ship I had running at home via ssh tunnel. In practice, I and almost everyone else used Signal to communicate because it was too frustrating to use Urbit.

At Assembly last year, there was a native mobile app and I distinctly remember getting a push notification from Urbit for the first time, which was pretty exciting. I had also migrated my ship to a hosted service which helped a lot: much lower latency and no annoying ssh tunnels to deal with. Most importantly, a major upgrade to Urbit’s core finally fixed the issue I was encountering and allowed me to resurrect my ship, which had been sunk for over a year. (It was actually pretty marvelous watching it come back online, download one OTA update after another, apply them flawlessly, and get caught up over an hour or two.) I remember briefly testing a handful of new Urbit apps, including several that had been developed as part of the hackathon, and I remember thinking they were cool novelties, but none of them solved any actual problems for me and I didn’t touch any of them again after the event.

This year for the first time I actually found myself continually switching back and forth between Signal and the new Urbit native iOS app. I used Urbit for about half of the messaging I was doing. Not because it was better than iMessage, Signal, or Telegram—it isn’t, not yet, not by a long shot—but for two other reasons. First of all, it’s now good enough. It works reliably. It’s not super fast, but it’s also not super slow anymore. It didn’t crash or fail once. It’s smooth and slick enough and the UX isn’t bad: it feels like a modern, clean, native iOS app (which it is).

It needs some polishing and it doesn’t have the bells and whistles of the mainstream apps, but it has something else going for it, which is the second reason I found myself using it a lot: I could easily find and message people using their @p (their Urbit identity). I’m beginning to understand that, to the extent that Urbit ever “wins” and convinces ordinary people to switch from the centralized apps we all know and love, it will do so through a combination of these two things: being good enough, and community. The apps don’t necessarily have to be better than, or even as good as, the incumbents (that’s unrealistic). They need to be good enough, and this combined with the goodwill and affinity I feel towards the Urbit community, and the tight integration with all things Urbit, is enough of a shove for me, and maybe for other people as well.

The most interesting thing about this realization is that it doesn’t include the usual schtick: the importance of decentralization, the benefits in terms of privacy, governance, censorship resistance, etc. Of course those things are important, too, but they honestly weren’t very much on my mind the past few days as I found myself interacting with my Urbit dozens of times a day, for the first time ever. I’ve used probably every decentralized chat and groups app ever created, and take my word for it when I say that the UX has always been horrendous. Decentralized chat is really, really hard for a bunch of technical reasons. The fact that Urbit is now usable and good enough is really quite remarkable, because it’s the first decentralized chat app that’s ever been good enough. That’s a surprisingly high bar.

Chat and groups is nice, but Urbit is designed to be a lot more and to do a lot more. For years, at least since the emergence of Landscape, Urbiters have been talking about a mythical first “killer app” that will lead people to adopt Urbit in droves. It’s the same conversation every Web3 community has had: for all of its growth and economic success, Web3 still has no killer app or use case aside from money (including stable coins) and maybe NFTs.

I’m also beginning to realize that Urbit might not actually need a killer app to succeed. I for one would be perfectly happy with Urbit delivering perfectly functional, boring, calm, quiet computing and apps—because all of the mainstream incumbents are none of those things. I’d love nothing more than to ditch my email, chat and groups, calendaring, and note-taking apps for Urbit. Post-Assembly I think that day isn’t so far off. I’m beginning to realize that Urbit wins with a long, slow, drawn-out whimper, with a deflation of and slow defection from mainstream, centralized, “you are the product” apps, not with a bang.

Actually, there were some other nice apps too. At this year’s Demo Day at the conclusion of the hackathon there were a number of useful projects presented including Urbit-native editors (one with built-in inline code execution, like a better Excel/Sheets), Urbit-native application error reporting and issue tracking, an Urbit-native LLM “personal AI” client, and an Urbit-native decentralized marketplace for anything.

A couple of years ago I migrated from using centralized note-taking apps like Apple Notes, Google Keep, or Evernote to a purely open source, decentralized, extensible setup using Logseq and git for simple markdown files. With the benefit of two years of hindsight I can say it was one of the best decisions I’ve ever made. I intend to eventually migrate nearly everything away from centralized, unaccountable, corporate SaaS. I haven’t gotten there yet—for one thing, multiplayer mode is much harder, whereas my notes are for my eyes only—but the fact that I successfully made this migration gives me hope. I could seriously see myself using %eyas, the Urbit-native text editor, instead of my current solution because it saves me the trouble of needing to keep many devices in sync. This is the first time I’ve seen an Urbit app that solves a real problem for me.

It’s not quite there yet but Urbit is almost actually useful. Another Assembly or two and I think I might actually be using it daily for something other than chatting with other Urbiters. That might not sound like much but it’s actually kind of a big deal.

Thing #2: To Mint or Not to Mint? 🪙

One of the best things about the Urbit ecosystem is the lack of financialization. As a result the people attracted to the project tend to be missionaries rather than mercenaries: you don’t really make money on Urbit (at least not yet, more on that in a moment). Urbiters are there for the right reasons—the tech, the values, the culture—and they tend to stick around.

I think for this reason Urbit may have the highest signal-to-noise ratio of any crypto or crypto-adjacent project. The people I’ve met in the Urbit ecosystem are, by and large, the most interesting, thoughtful people I’ve met anywhere. Unfortunately tokenization and financialization tend to attract the wrong types of people. Investors and speculators have a role to play but every ecosystem needs balance. As I wrote last week, if you have too many of those types (mercenaries, investooors, and generally those looking to make a quick buck) relative to actual builders, it can really hurt the ecosystem. This is NOT a problem that Urbit faces, which is refreshing.

The lack of financialization is also one of the things that many Urbiters I know love about Urbit. Urbit is about many things. Good technology. Good aesthetics. Freedom and independent thought. Calm computing. But it hasn’t historically been about money.

Of course, everything is a tradeoff. The same hyper-financialization that led to rampant speculation, an influx of millions of investors, and hype and scams galore in crypto projects also led to the inflow of hundreds of billions of dollars of funding. Sure, a lot of that money, probably most of it, went into garbage projects that never delivered on their promises, or outright rugpulls. But a not insignificant portion of it also got allocated to legitimate projects. You simply can’t have one without the other.

If crypto is or was seriously overvalued, Urbit as an ecosystem is underfunded and Urbit is undervalued relative to its potential, to the things being built on it today, and to the quality and talent of the people in the ecosystem. One reason is that most mainstream investors and even most crypto investors wouldn’t consider investing in the Urbit ecosystem today for multiple reasons including lingering distaste of the founder (who is no longer involved) and, well, lack of funding. You see, funding is a self-fulfilling prophecy. Investors like to invest in things that they know other investors are investing in. It’s hard to be the first mover. While there are a handful of small funds that have invested in Urbit and its projects, and Urbit was backed by Founder’s Fund and a16z in the early days, no large investor has written a check recently to the best of my knowledge (for Urbit/Tlon directly or for an ecosystem project).

This goes back to financialization: ironically I think the root cause is lack thereof. It’s hard to invest in Urbit. For one thing, the only anointed asset is address space, which is confusing for multiple reasons. It’s nonfungible, there are three types of address space (galaxies, stars, and planets), and the roles and responsibilities of each aren’t totally clearly delineated in Urbit’s current design. Urbiters talk about stars and galaxies as acting as infrastructure providers “at some point in the future,” and possibly receiving revenue streams as a result, but with very few exceptions this doesn’t happen today (I’m not totally clear on why; probably the project just isn’t quite mature enough yet). And perhaps most importantly, unlike with typical blockchain coins and other cryptographic assets, there’s no clear “in-protocol” revenue stream for holders of these assets, especially stars and galaxies. No staking, no burning. Galaxies get a seat at the governance table, which is clearly worth something, but it’s hard to value. The value of a star is even more nebulous.

While the lack of financialization is nice in a warm and fuzzy sort of way—people who hold and invest in address space today tend to do it out of a feeling of stewardship or wanting to support Urbit—it’s not scalable. Urbit is at a stage where, if it does want to continue to grow and achieve its potential, it needs to attract more attention and more capital.

The idea of launching an Urbit-native blockchain has come up several times over the years. Most recently, at Assembly this year, Sunny Aggarwal gave a talk on how to use the Cosmos SDK and some novel cryptoeconomic designs to launch an Urbit-native blockchain with clear roles for each class of address space. You might argue that the world doesn’t need yet another blockchain, but Urbit is Not Like the Others.

For one thing, it has a clear, intrinsic use case, which is extraordinarily rare: Urbit address space, otherwise known as Urbit ID, is a property ledger that requires global consensus on ownership and transfers, which is a perfect application for a blockchain. It’s currently hosted on Ethereum, but it can and should be self-hosted because the Urbit ecosystem is essentially paying tribute to Ethereum (i.e., leaking value to Ethereum) for something it’s perfectly capable of doing on its own. In fact I’d go a step further and argue that outsourcing its property ledger to a blockchain that’s subject to the values and governance of a different community is antithetical to Urbit’s values, including responsibility and self-reliance, but that’s probably the subject for another issue.

For another, Urbit has some Unfair Advantages. Unlike every other public blockchain, it cannot by sybil attacked because all users have to own a planet, which is scarce and which is tied to one’s identity and reputation throughout the network. You cannot do anything on Urbit anonymously; literally every action you take and every message you send is tied to your Urbit ID. It also has a natural set of trusted validators in the form of the galaxies. That’s a really unique, important set of strengths.

People have tried to launch a blockchain and tokenize Urbit before but the community rejected the attempts. The farthest Urbit got was the creation of the Wrapped Star ($WSTR) a couple years ago, but that failed to take off for lack of accountability, marketing, awareness, and liquidity. I’m hopeful that a more thoughtful, well-planned effort would be better received by the community and could go a long way towards attracting the sort of funding the ecosystem and the project need and deserve.

If one could simply “invest in Urbit” the way one can invest in Ethereum or any other chain or ecosystem, by buying a fungible, liquid coin or token, that could go a long way and do a lot of good. I know multiple investors that would be interested. Getting there will require addressing a number of remaining challenges, such as what to do about the inevitable dilution of existing address space holders and figuring out the relationship between a new, fungible token and the existing nonfungible address space. In my opinion it’s an experiment worth trying, but it can’t happen without the support, goodwill, and blessing of the community.

Thing #3: Strengths and Weaknesses 🔩

Sometimes it takes a little while to understand the strengths and weaknesses of a product, platform, or network. As one example we designed Spacemesh to be exceptionally friendly to home miners, but after launching the network it turned out that it wasn’t as easy for home miners as we thought and that it was in fact even friendlier to miners joining pools (something we’re working on addressing).

Urbit wasn’t designed to specialize in anything particular. It’s a general-purpose computer and it was designed to do all of the things that modern computers do. Today that means networking, messaging, identity, content, compute, storage, and all sorts of apps and services that can be built on top of this powerful set of primitives. As it turns out Urbit isn’t equally good at all of these things, and its relative strengths and weaknesses are becoming clearer. This was a big topic of conversation at Assembly and in many of my side conversations.

It’s been a bit of a tough year for the project. One major ecosystem participant, one of the most promising projects and one that raised a lot of money, announced that it’s giving up on building on Urbit because it’s too hard. Another important, promising project decided to launch its own chain and isn’t directly relying on any existing Urbit infrastructure. I spoke to several other builders and projects that are in a similar place: they love Urbit, but they want to ship usable, friendly apps and feel that this is impossible on Urbit today. There seems to be a pattern here: projects that want to build real products today usually end up taking ideas from Urbit but migrating away from the platform itself.

In its defense, as I wrote above Urbit has gotten a lot better than it was a year or two ago. It’s much more reliable and much faster than it used to be. But it still isn’t fast. And there’s still a lot of work to be done. Urbit’s compute model is extraordinarily robust and verifiable, and it’s highly elegant, but it’s very difficult to optimize. It’s single-threaded, and that single thread moves very slowly. Unlike how modern apps run on just about every other platform, Urbit apps are compiled and executed inline, on the fly because Nock doesn’t differentiate between code and data. This makes it impossible to apply modern optimization techniques, the things that make modern apps run fast on modern hardware, such as branch prediction and adaptive optimization (note: I may be wrong about this, and if I am, please tell me). The developers I spoke to also reported a lot of frustrations with the network layer: Urbit offers guaranteed only once delivery but makes no promises about when those packets will arrive, and peer discovery is quite difficult today.

Of course Urbit also has many unique strengths. It handles things like identity, encryption, and networking for you. These things are provided to applications and indeed to Hoon itself as primitives so developers don’t have to think about them at all. I’ve complained about how broken identity systems such as usernames and passwords are many times; this alone is a huge advantage of building on Urbit. While Urbit’s compute model isn’t the fastest, it turns out that it’s especially well suited to certain applications such as writing compilers, since compilers rely on things like tokenization and tree manipulation, which Urbit is very good at. There are probably other applications that it’s especially well-suited for. Finally and most importantly, Urbit is trusted computing: unlike just about any other operating system, your Urbit is cryptographically yours and you own and control it completely. No other application architecture today can offer this.

It’s unclear whether these strengths are enough to overcome Urbit’s weaknesses for application developers and users, or how long it’ll take until the weaknesses have been addressed to a sufficient degree. They’re definitely being worked on but some of them, such as the compute model, are truly core to Urbit’s design and I don’t see them changing anytime soon. Compute can be sped up to some extent through the runtime and a tool called jets, but without the additional speedup of multithreading and various other optimizations it’s unclear if Urbit apps will ever be competitive for many tasks. Elegance is nice for art and research but at the end of the day users want functional applications and developers want to build functional, useful, user friendly applications. Today that’s simply too hard to do on Urbit. I think this is the single biggest reason Urbit has struggled to escape the “art and research” phase.

There’s a rule of thumb in the blockchain world that you should split your application architecture and run most of your app “off chain” (which is fast, efficient, and free) and only the “consensus critical” portion (e.g., minting, burning, transferring coins, or updating a ledger) on chain (which is slow and expensive). It seems that such a model might work well for Urbit: only run on Urbit what needs to be run on Urbit—basically, the portion of an application that needs to be “trustless,” verifiable, and bound to a user’s identity (i.e., the portion that makes use of Urbit’s powerful primitives). Everything else can probably just run natively on a user’s device or in their browser, and the two pieces can communicate using an API. This isn’t a terribly well-formed hypothesis and as is always the case with application architecture the devil’s in the details but I hope to build a proof of concept “hybrid” app like this to test it. Let me know if this is something you’ve seen or built, or would like to work on!