~2017.5.11 Roadmap

~sorreg-namtyv + ~ravmel-ropdyl

Urbit today (May 2017) is a working proof-of-concept. The Urbit test network has been up continuously since last August, hosting its own distributed chat, distributing its own updates, serving its own website and forum, etc, etc.

Everyone has heard of the minimum viable product (MVP). Urbit in summer 2016 (the current test network) is the MVP's first cousin: the AVP (almost-viable product).

From AVP to MVP

Urbit is an open-source project. Its sponsor, Tlon, is a company. So we can't exactly tell the public to go away. But there is nothing much the public can use Urbit for, besides hanging around and talking about Urbit.

Going from AVP to MVP means changing that. And of course, it means issuing real Urbit keys. And promoting Urbit to users. And preaching it at developers. And all that normal stuff. But not until we're ready, because we ship only the most beautiful bits.

Sometimes we forget to remind people that no one has ever built anything even remotely like Urbit. It's not like, people had cars, so we built a better car. It's like, people had cars, so we built a rocket unicycle.

Our rocket unicycle is a lot more awesome than a Chevy. But it demands more custom engineering. We have to invent every little widget as we need it. Usually that involves rebuilding it two or three times (see the (see the long-term strategy). This process converges from the bottom of the stack up, and accelerates as our progress advances.

Nock, which is now frozen, and which is a page of pseudocode, took from 2002 to 2008 to invent. Hoon took from 2008 to 2012, and is stable but not frozen. All the real technical problems in 2016 Urbit are either in the top layers (Arvo, its vanes and apps), or outside Urbit proper (Vere, the Unix event processor).

Except for one major component (the security vault %jael), there isn't any single big thing wrong with 2016 Arvo or Vere. In retrospect, they can even be seen as inspired stabs in the right direction. But hammering square pegs into round holes isn't the Urbit way.

If we made our AVP into an MVP by straight-out debugging, we'd be limping across the finish line. An MVP must be minimal in affordances. In its aesthetics, it must be sublime. It has the rest of its life to grow features, but beauty only fades.

A parallel process

Architecture is entropy in reverse. Urbit has to become more elegant, as it becomes more functional. This delicate process must be carefully controlled.

To keep Urbit on the path to absolute zero, we have to work in three directions at the same time:

Pushing in all three directions at once keeps the whole project in balance. We could drop any two of these goals and head at top speed for the other. This would produce a nice simulation of doneness in a single dimension.

But if we just hardened our infrastructure from the bottom up, we wouldn't be responding to the needs of the user experience. If we just built a user experience on top of our prototype infrastructure, it wouldn't be stable enough to be usable. If we documented the prototype, it would become much harder to revise. And so on.

And the balance between these directions shifts with the seasons. After spending the fall and winter writing infrastructure, and the spring testing it, it'll be time to spend summer and fall working toward the user and the developer.

Since the last crowdsale

Maybe this is too vague. What we actually did since the last crowdsale:

We replaced about half the Unix interpreter (the whole vere directory, event handing and storage), and about a third of Arvo: the lifecycle function, boot sequence and kernel %arvo, the network %ames, the PKI (adding a new security module %jael), the console :drum, and the :talk app. If Arvo was a car, we replaced the powertrain.

At the Hoon level, we added formal docstrings and reorganized (or rather, organized) the kernel and standard library. At the Nock level, we of course did nothing. And on the client side, we redesigned the Web API, and prototyped a completely new Urbit user experience. And all the new code is high-quality, fully documented, and generally ready for anyone to copy and/or abuse.

This cc-release (continuity candidate) isn't quite done — the Arvo code is written but not fully tested, and one module (the application sandbox %gall) is still waiting for its rewrite. But the new Arvo has that "not quite perfect, but basically right" feeling of architectural doneness which Hoon has had for a while.

Note that we remain a super-tiny team. We've had some serious outside contributions, but clean loose ends that outsiders can pull on remain frustratingly scarce. Hoon is too stable and Arvo is too unstable. Architectural work scales poorly in personnel, and you can't really renovate a house while people are trying to live in it.

Moving forward

After cc-release this summer, we'll move from bottom-up, infrastructure-driven engineering, to top-down, user-driven engineering. Naturally this is dd-release (deck-directed).

Our planning target is a stable, useful Urbit we can ship in 2017. Since we're working top-down, we can abandon the deep architectural essays and work, like normal human beings, from an illegible list of features scribbled on a poorly-erased whiteboard.

A whiteboard list

Our feature list for dd-release, in no particular order:

If you know the current maintenance Urbit, you know that most of these features are mostly in sight. None of them is exactly quite complete. None of them is anywhere near a stretch. We have significant parts of all of them.

Also, since this is the release after the release we're doing now, we're probably missing as many checkboxes as we've caught. And triage is a thing that happens. It's really better understood as the kind of work we're going to do.

We'd really like to get all these things done in 2017. But a lot depends on what kinds of resources we have access to. And of course, as we document the system, it gets easier for all the people who believe in Urbit to help us build it.

As usual, comments are on fora. Check out this thread.