The last post I wrote was about the serfs of Facebook - or more broadly, about how we’re all primarily just accounts on other people’s computers. Since then (about a year ago) I left my job after a decade at Palantir to join Tlon, the company doing the core development for Urbit.

I’ve written about Urbit before, once as a brief mention in the serfs of Facebook post and earlier with an Urbit-specific startup guide. Since then I’ve become convinced that Urbit is the best tool we have for escaping our life as serfs and clawing back the peer-to-peer web the hackers in the 90s dreamed of. I think Urbit or something like it is necessary for this and attempts to solve this problem on top of the existing stack are doomed to fail - at best they will end up only serving a handful of technical users without widespread adoption.

The hackers and cypherpunks of the 90s had the right dream, but they failed to follow the existing incentives of the web through - if they had, they could have predicted that things would centralize. There are a couple of problems with the current software stack that lead to centralization.

Megacorp

The first is spam. When it’s free to spin up new accounts, there’s a constant war to combat new spam accounts that spring up instantly as old ones are banned. There’s a financial motive for spammers to evade detection, and blocking spam well requires sophisticated tools. This tends to mean that centralized corporations will do a better job of this than individuals. This is an old problem that goes back to the 90s. The original proof-of-work described in the hashcash paper (pre-bitcoin) was about using proof-of-work as an anti-spam measure for email. While the problem has been known for a long time, it was only recently that a solution (decentralized consensus of ID ownership via the blockchain) that gives us a way to solve this without centralization became viable. In Urbit this is solved by IDs stored on Ethereum that have a non-zero (but low) cost which simultaneously makes spam not economically viable and makes moderation easy (IDs can be blocked).

Email is a good example of how federated systems fail. Spam made email unusable, which resulted in most accounts being centralized in a handful of companies that had the resources to fight spam. Even technically sophisticated users can’t run an email server because these centralized companies will blacklist them. Even if you somehow are able to run your own email server without getting blacklisted it’s so difficult to do this that the majority of people you’re communicating with are using gmail anyway, it’s hardly decentralized.

The second problem is operational complexity. Moxie is right, nobody wants to run their own server. Running a Linux server is too hard, requires too much technical knowledge, and has too many dependencies. To solve these issues from first principles really requires boiling the ocean - starting from scratch. It’s also why (before finding Urbit) I had resigned myself to this being hopeless. Urbit boils the ocean and it actually works. You can try it now as a comet (a free temporary ID) and see it for yourself. It has a simplified set of op codes called Nock, the OS is a new, entirely functional (in the programming language sense) design, and it runs in a virtual machine/runtime that interprets the op codes to run on your local machine. It’s a “personal cloud OS”, meaning that you can run it locally, but it’s better to run in it some place where it’s always online and you can access it on all your devices.

Most people will have a hosting provider run it for them (though there are people working on very cool solutions for easy self hosting) - the major distinction here is that you can always take your Urbit computer from your host and run it either locally or elsewhere and you retain all of its content and abilities. The host is merely a steward of your computer, and doesn’t have anything to do with the actual state. When you “download” your data from Facebook you get a subset of the information they have about you, but you can’t do anything with it. When you export your planet (the name of the standard user ID) from a host to run yourself, you have the exact same experience as you did when the host was running it for you. Running your Urbit is also “zero click” maintenance, meaning you get updates over the air, booting it is a single start up command, and that’s it. The ID is tied to the planet and it’s required to boot it. This prevents the issue with Mastodon where you end up back to a handful of centralized servers that people have accounts on (because running a federated Mastodon linux server is too hard).

The third problem is development complexity. Building an application on the old web is a mess of complexity. It’s so difficult that doing it requires teams of highly specialized technologists working together, which necessitates massive amounts of venture capital. This can only be profitable with massive scale - the incentives around this lead to the ad driven business model of giving everything away for free to drive adoption, collecting as much information on users as possible to create targeted ads, and then designing applications to be as addicting/engaging as possible to keep users watching these ads. We wanted bicycles for the mind and ended up with slot machines that poison the soul.

We ended up in this world because the web offered something the old operating systems designed before the web didn’t - cross-platform collaboration. Unfortunately in order to get it, it required all of us to reside on a handful of servers managed by megacorporations. Urbit solves this by moving the auth and network layer into the OS itself. This enables devs to be able to rely on these parts of the OS to build truly decentralized applications with out of the box support for collaboration between existing users (Urbit IDs). This dramatically reduces the complexity and cost to build something.

Urbit ID

Urbit’s IDs are public/private key pairs. In addition to their anti-spam role, the IDs act as a minimal hierarchy that allow the network to find public keys in order to establish p2p routing between users (all without the users having to do anything), as well as managing the distribution of over the air updates. Applications built on Urbit get auth and secure networking between users out of the box. Applications can also be published and distributed to anyone on the network immediately. Devs get collaboration for free and they don’t need to worry about handling personally identifying information either (since the apps run on the user’s machines). Devs can focus on just building their app and rely on the OS to handle everything else. The apps can share state with each other and understand the shared OS API. This plus out of the box auth means you can do things like have one app for contacts that everything else can use. You can have contacts that automatically update when the contact changes their phone number (assuming they haven’t revoked your access). It’s a better experience than what can be built on the legacy web. It’s also the strategic lever that gives Urbit a path to success. For users, their application’s incentives are truly aligned with them and not with advertisers.

Urbit cannot succeed by just “being a decentralized Discord”. Even with feature parity, it’s competing with a centralized competitor designed to be engaging. Even if IDs were given away for free by a hosting provider and even if we pretend it matched Discord on performance - it’s still competing with a service designed to be addicting. Urbit is vegetables to the ad driven web’s heroin and people like heroin even though it’s bad for them. To win, you need something more than the promise of data ownership and control - that’s important and captures a small percentage of the market that cares about that, but it will never capture everyone else. That’s why the development complexity bit is so important.

Apps on Urbit are easier to develop than apps on the legacy web, you can build apps on Urbit that can’t be built on the legacy web, devs don’t have to rebuild auth every time, and devs can rely on secure out of the box networking and collaboration support built into the OS. What will pull a regular user to Urbit is not the promise of owning their own data, it’s apps that only exist on Urbit because the dev didn’t bother trying to get it to work on the legacy web. This lower threshold makes it possible to make a living selling great p2p applications on Urbit without needing an expensive team. Today there are already several different companies and individuals building and shipping applications across the network. In an Urbit-dominated future there will almost certainly be hosting providers that do free ad-supported hosting, but for those that don’t want it there’s a way to reject that model - the capability to self-host or pay for a hosting provider that doesn’t run ads is what matters. People will pay for something they can’t get elsewhere (like Spotify premium) - but it has to be something special. If you’re just selling vegetables while someone else is giving away heroin you will lose.

Urbit Machine

I think there’s a clear path for Urbit where success is among the potential outcomes. I think this can’t be said for any other federated system in existence (where success is avoiding recentralization). There’s work to do and a lot of the things I described above (particularly around devex) can be made a lot easier than they are today, but if this succeeds the payoff would be a massive shift in computing. We’d be able to escape the local max we’ve been trapped in since the late 90s. If we can make Urbit work, the cypherpunks will finally have the future they dreamed about.

If you’re interested in getting on the network, the easiest way is with the newly launched tlon.network hosting service. It’s currently $20/mo, but we’re working on getting the price down as we expand the feature set over time. The cost directly supports core development and we run your planet on high performance instances. As always you can get an ID and run it yourself (it’s just more work). I’ve started a substack to write more specifically about Urbit and the people building applications on Urbit. You’ll be able to read about this at martiancomputing.substack.com. “Martian Computing” is a reference to an old (and great) introductory Urbit blog post about what it’d be like to find a computer on Mars that had worked for millions of years.

Why a substack vs. writing this on Urbit? My goal is to reach the people not already on Urbit and a substack is the best way to do this broadly. There is an app to publish a newsletter from Urbit to the web and if things go well I might eventually move to doing that, but communicating about Urbit to people that are stuck on ‘earth’ is the primary goal.

Urbit Home

See you on the network.

~dovsem-bornyl