~2017.1.30 Update

~sorreg-namtyv + ~ravmel-ropdyl

TLDR: a real Urbit is an Urbit that does real work. This means nontrivial progress in two areas: systems maturity and user experience. In 2H 2016 we cleaned out most of the worst holes in Arvo and vere, and totally reconceived the user experience. The new Urbit feels like an MVP and we can't wait to ship it.

In 2013 Urbit was intriguing. By 2015 it had become interesting. In 2016 it was actually exciting (if not always in a good way!). In 2017, we're actually planning to make the darn thing useful. (For certain values of the word "useful.")

Our cc-release stability upgrade (mainly affecting the OS layer arvo and the interpreter vere) is roughly code-complete and being tested into existence. Once it exists and is stable, it can actually be documented -- often, for the first time.

And cc-release is our first release really designed so that neither your ship, nor the whole network, can actually sink. The Urbit network had zero unplanned, and one planned, breach (network flag day) in 2H 2016. The last planned breach, the cc-release update, is planned for 1H 2017.

With the infrastructure converging, we can finally think seriously about the user experience of Urbit. What we're imagining is a small-scale social network and command-line API aggregator. It's just screenshots right now, but we're confident that we can build it and make it work.

System software is boring (at least when done right). So let's start with the user experience.

Design

Galen Wolfe-Pauly is Tlon's CEO and Urbit's interaction designer. Galen went to architecture school. He talks like it. We recorded him secretly and came away with these notes:

Infrastructure: stability, maturity, performance, documentation:

We dragged Curtis, whose hide has turned completely white like a cave fish, from his coding hole to stammer out this update:

We're actually doing pretty well on the infar. Despite there being all kinds of unacceptably broken things about Urbit 2016, the network has actually stayed up since August, and we haven't had an unintentional continuity breach since June.

Of course, it helps that we don't ask anyone to use Urbit in earnest. And ships still do sink. Since an urbit is an identity, sinking your planet is a horrendous experience. You'll never bond with your second planet the way you did with your first -- never mind any data you may have lost.

Our upcoming cc-release is the last planned breaching release. With certain exceptions discussed below, all major parts are now (January 2017) code complete or better.

This includes the rewritten network stack (%ames), code complete but untested; the new secret vault and promise tracker (%jael), mostly tested; and the new u3_pier event execution framework, with worker processes and real two-phase commit, smoke-tested. We've also completely restructured hoon.hoon and zuse.hoon, which now are at least cosmetically acceptable.

This is not to say that the cc-release Urbit won't in many ways embarrass us as engineers. It will. But your ships won't randomly sink, your secrets won't randomly leak, and your datas won't randomly rot. Or if they do, it's an implementation bug, not a design flaw.

There are still a few cracks we need to fill in. The main one: some top-level adjustments to the Arvo event system. The boot sequence now executes correctly, but the actual boot events need to be totally refactored, as does the rather critical Unix-Arvo interface. The long-promised security mask and voltage flags need to be added, and vanes adjusted to use them. Causal tracking of execution crashes needs to actually work. At the user level, :talk needs to be split into a user agent and a daemon, and the user-level %kiln, the "systemd of Urbit," needs a rethink to make upgrade logic state-triggered, not edge-triggered.

The console and the dojo need some work to make our user experience real. One way to view a high-usability command line is that a command, if you don't have the esoteric knowledge to fill it in by just typing the syntax, is essentially a form. This form needs to work both in the browser and the terminal, which isn't trivial. Browser and terminal both need a simple multiscreen navigation model, which we don't have yet.

There's also a bunch of Unix-level work to do, mainly in converting the old "single-player mode" console-bound Urbit into a real system service. Urbit works better as a daemon which runs one or more worker processes, and talks to client consoles over a Unix socket. A real architecture actually makes it practical for star owners to host the planets they issue, for example.

Finally, because we never forget the wisdom of the sages, our last act before asking people to use Urbit will be the long awaited performance crusade. The new event system now at least releases outgoing events before the input queue is clear! You never know what optimization will achieve before you make a serious effort, but I don't see any reason we can't carve out a new empire of speed in the savage, uncharted east.

We haven't touched the documentation since the first half of 2016. As always, maturity has to come before documentation. Premature documentation is almost as dangerous as premature optimization.

Notable contributions

Some notable contributions of late:

Anyone who contributes at this point deserves extreme praise for the ability to work in an immature, often broken system. We look forward to being ready for normal programmers who aren't intrepid jungle explorers.

Next crowdsale

We'll do another crowdsale in the spring. We understand that the last sale left a lot of people unable to participate — and our first priority is making sure those who are excited about Urbit can own some real estate. We'll announce our plans on how this might happen soon. If you're interested, make sure you're on our mailing list.

Contribution prizes

We're still thinking about the right way to award Urbit real estate to outside contributors. Especially after the crowdsale, it really has to feel 100% fair. But it can't be in any way, whether legally or emotionally, a form of compensation. We can't afford to kill the fun.

It doesn't feel right to do this at all when the documentation is completely inadequate, because it's not fair to people who don't have the time to reverse engineer. But we're thinking hard about this issue.

Future updates

We know you love these opinionated, literary state-of-the-urbit updates. We love writing them. But we obsess over them too long and they take too long to write. Urbit's ultimate success depends almost entirely on the code.

Going forward we're going to switch to commit-message style updates on a monthly basis, with longer updates arriving sporadically. Maker DAO does a great job of these shorter updates (here is an example).

If you're ever curious to check in or hear what's going on, don't hesitate to get in touch. You can always chat with us on urbit.org/stream, or by booting your own Urbit. Twitter or email (urbit@urbit.org) are also perfectly fine.

There's also our forum that anyone can post to. We've created this thread to discuss this post.