bfc.do

Introduction
Urbit for Interplanetary Computing

Urbit for Interplanetary Computing

I recently did an Epicenter episode with Chun Wang, the founder of one of the leading staking provider Stakefish and a major mining pool F2Pool. One of Chun's interest is humans becoming multi-planetary and that is also a topic that I'm interest in. In the latter part of the podcast, we spoke about this at some length.

Let's say 40 years from now we have a human settlement on Mars. One of the main issues that this will present is that the communication latency with earth is very high. It depends on their relative location of the planets on their orbit, but it will range between 4 and 22 minutes. Emails will work fine, though delayed. But real-time interactions will be impossible.

The current computing paradigm is dominated by the cloud. This means that some company hosts servers somewhere (probably on AWS, GCP or similar). Most computation happens on those servers. My user interface, which might be via the web browser or a mobile application, frequently pings those servers to read or write information. All this is based on low latency. We are all familiar with the rapidly deteriorating user experience that comes with a bad internet connection. And when we are without a connection at all, most things stop working completely.

The implication is that most of the Earth's applications will not be accessible to people on other planets. For people on Mars, the technology they are used to from Earth will not be available. One solution would be to replicate the Earth's cloud infrastructure on Mars. But that is a bad solution. Let's illustrate it with an application like Instagram.

Take cost as an example. If they were to deploy another infrastructure on Mars to serve customers there with low latency, it would be extremely expensive. If on Earth they have 2bn users and on Mars they have 500k users, then the relative cost for each Mars user would likely be thousands of times what it costs each for Earth user. The business model will not work.

Another issue would be developing and maintaining that infrastructure. This is something the Instagram team does, because they know how everything works. But they are on Earth. And the latency is so high that it will be impossible to do this from Earth. But replicating the Earth's Instagram infrastructure team on Mars is not a solution. It will be too expensive and will the right people even want to go there? And then you have the issue of somehow keeping what is happening on Mars in sync with what is happening on Earth.

In Urbit, on the other hand, applications work in a very different way. Each person has their own server called a planet. An application developer writes the application and then ships that code to the personal server of the users. And then the application runs on the personal server, which is where the computation happens and the data lives. People are often unconvinced that this is a superior approach, but at least for the case of a multi-planetary species it seems vastly superior.

A team on Earth could develop the application and then ship it to people's personal servers. Some of those could be on Earth and some on Mars. The latency doesn't really matter in this case. If I have to wait 30 minutes to download my application, that's a minor inconvenience. And afterwards, my server on Mars can easily serve my application with low latency. The development could continue to happen on Earth. Or a team on Mars could build an application and serve users on Earth.

Urbit also has other nodes like stars and galaxies that serve other functions like peer discovery. It would be very seamless to have some of those hosted on Mars to serve the local population. The entire architecture of Urbit is perfectly suited for this kind of architecture.

Though even the case of remote maintenance is much smoother with Urbit. If an application for a specific user stops working, because of the functional and deterministic nature of Urbit, it will be clear which event caused the malfunction. That data could be sent to Earth for debugging and the users server can be rolled back and continue operating fine in the meantime.

Another benefit I see of Urbit is even more long term. We saw before how the latency will cause the conventional technology stack to break across planetary boundaries. If humans now settle on more planets with greater communication latency, it is natural that culture will diverge more and more. Globalization has decreased cultural differences by decreasing communication latency and interplanetary settlement will have the opposite effect.

But the question is, can we maintain some fundamental level of technological compatibility across planets? If I travel from one planet to the next, it would be bad if all my technology stopped working. And if I had to adopt new applications, learn a new paradigm, start from scratch. This would have an enormous cost and result in the human species growing further apart.

However, the Urbit kernel is minimal and designed so that it will never have to change. This would be a great advantage. I could go to another planet, take my server with me and it will still run as will all my applications. There may be new applications popular on a local planet that I want to adopt. Or applications that are social in nature may be confined in popularity to a particular planet. But on a fundamental level, the technological compatibility should be maintained.

In my view, Urbit is a superior technological paradigm that will prove superior on many dimensions. But today, the benefits are not as apparent, while the immaturity and weirdness is. But the multi-planetary settlement scenario clearly illustrates the elegance and power of Urbit, at least in this instance.

Thanks to Dosnul-Sogteg for pointing out how the functional and deterministic nature of Urbit makes remote maintenance easier.

Author

Brian Crain

View Comments
Previous Post

The Man Who Solved the Market