@@ -1,17 +1,252 @@
4title: Roadmap
4title: Roadmap
5−author: Galen Wolfe-Pauly
5+author: Curtis Yarvin
6image: http://urbit.s3.amazonaws.com/16-3-10/blog-5.jpg
6image: http://urbit.s3.amazonaws.com/16-3-10/blog-5.jpg
7−preview: What's next for Urbit: what we're working on and where we're headed.
7+preview: Our near-term goals for the Urbit community, documentation, maturity, utility and governance.
8layout: urbit,post
8layout: urbit,post
9navmode: navbar
9navmode: navbar
10navdpad: false
10navdpad: false
11−navselect: blog
11+navselect: posts
14navclass: urbit
14navclass: urbit
17−# In progress
17+# Urbit roadmap 2016
19+Urbit is in early beta. It works. It doesn't work well enough to be
20+particularly useful, though it's not that far away.
22+It's important to understand that the present Hoon codebase was
23+developed almost entirely by three full-time engineers (Curtis,
24+Philip, Anton). We are good, but not superhuman.
26+We have four separate problems to attack in 2016: community, maturity,
27+utility, and governance.
31+Working on Urbit is incredibly fun. We've kind of bogarted that fun.
32+We're sorry -- no, we're not actually sorry -- but we're going to
35+Since 2013, the community status of Urbit has been that it's open
36+source and you can mess with it if you want, but we don't really do
37+much to encourage you. Or to put it differently: open source,
38+secretly wishing it was still stealth.
40+The sad truth is that we've been doing research, and research doesn't
41+scale. This is one of the reasons why open-source projects are
42+notoriously focused on copying proprietary products. Open source is
43+great for incremental maintenance and development -- almost nothing in
44+software is as mature as a mature open-source project, because "with
45+enough eyeballs, all bugs are shallow." But it's terrible for
46+creative research, because the smallest decisions invite the notorious
47+"bikeshedding" syndrome.
49+Now that Urbit does all the things we want it to do, in (pretty much)
50+the way we want it to do them, our focus is changing. All we really
51+care about going forward is maturity and traction. Also, it's a lot
52+harder to argue about what color the bikeshed should be painted, if
53+the bikeshed is already painted.
55+So, working on Urbit is incredibly fun. If only because it's the
56+programmer's equivalent of astrobiology. But not only because --
57+Urbit is very far from being a mere esoteric curiosity.
59+The first challenge we face is making sure Urbit is properly
60+documented. (See below.) We'll also be:
62+- holding weekly public meetings / office hours maintaining public
63+- developer blogs (probably) running open contests with address-space
68+At the systems layer, Urbit has enough features for right now. What
71+Aside from mere bugs and issues, maturity comes in five flavors:
72+documentation, dogfooding, optimization, security, and testing.
76+Anyone outside the core team who's done any serious work in Urbit has
77+earned their scout badge in Reverse Engineering. The number of people
78+who have done this is impressive, but also slightly embarrassing.
79+Since Urbit is so technically unusual, we have no excuse for leaving
80+any part of it undocumented.
82+Documenting Urbit is not just a matter of writing down specifications
83+for the code as it exists. That would be easy if the code was
84+perfect. It's not perfect.
86+One truism of CS is Knuth's observation that "premature optimization
87+is the root of all evil." Yes, but premature documentation is at
88+least the trunk of all evil. "Documenting into existence" -- making
89+something that doesn't exist exist, by describing it -- is the trap of
90+all vaporware projects.
92+On the other hand, Urbit does exist. It doesn't need to be documented
93+into existence. It does needs to be documented into completion. This
94+doesn't mean simply describing the codebase.
96+Documenting to completion is a two-way process. It always produces a
97+nontrivial set of technical revisions. Large design questions are not
98+open for discussion, but small ones are. This makes documenting to
99+completion a fun and fascinating community process, which neither
100+reduces to mere stenography, nor descends into endless bikeshedding.
102+Nock is completely done, and completely documented. Hoon still has a
103+few small rough spots; its reference documentation is decent but not
104+perfect; its tutorial documentation needs more work, but is reasonably
107+The real target of documentation into completion is Arvo (including
108+the Hoon library). The ideal point at which to prepare stable
109+documentation is the point Arvo is at now: basically working, but
110+largely undocumented.
112+Since Hoon is a programming language for Arvo, not for Unix, Hoon
113+documentation without Arvo documentation remains mostly useless -- so
114+we've got a strong incentive to get this done. But not without
115+actually getting it right.
119+Urbit has no alternative but to dogfood itself into maturity. If the
120+Urbit team itself doesn't solve some problem with Urbit, who else can
121+be expected to? Any use of any external tool in the Urbit development
122+process is a damaging energy leak.
124+We already use Urbit to publish documents about Urbit, to chat about
125+Urbit, and of course to deliver Urbit updates. With this release,
126+we're adding a public chat stream and public comments.
128+The next dogfooding steps: using Github as a backup to Clay, not Clay
129+as downstream from Github; our own internal issue tracker; and
130+replacing internal email with long-form `:talk` messages.
134+You'll notice that some aspects of Urbit are slower than you might
135+expect. This is because of our approach to optimization, which is to
136+throw some elbow grease at it when it gets annoying.
138+Death by unsolvable slowness is a common cause of mortality in
139+language-oriented projects like Urbit. But Urbit actually has two big
140+advantages in optimization.
142+First, our profiler is simple, but quite effective, because it's
143+integrated with the language and runtime at a level usually not found
144+in profilers. Second, anything that's slow can be jetted; as long as
145+there's an inner loop, that inner loop is vulnerable to anyone who can
146+write C. And there's always an inner loop.
150+There is plenty of design work to be done in even figuring out how to
151+systematically test Urbit.
153+We've done appallingly little systematic testing. We've mostly relied
154+on simplicity and elbow grease to get the system to the reliability
155+level it's at now. `~zod` has been up for a few months and has a 22GB
156+event log. There's no reason to think that if we replayed that log,
157+we'd end up with any different bits.
159+Simplicity buys a lot. Urbit is not always as simple as we want it to
160+be, though. There are plenty of known bugs; and we're nowhere ready
161+to declare Urbit ready for mission-critical data.
165+Urbit is not yet secure at all. We don't even think it's secure. And
166+this is just the first step in making it secure. After that comes an
167+independent audit and penetration testing.
171+However much we want Urbit to succeed because we're geeks and love
172+functional programming, it can only go somewhere by being useful -- to
173+people who don't care about the technology. Moreover, even for geeks,
174+the amount of fun in working on something that's permanently un-useful
177+What is Urbit? Urbit is a general-purpose personal server whose
178+long-term goal is to replace the whole web-service ecosystem. The
179+long term takes a long time by definition and is always preceded by
182+Fortunately, Urbit isn't that far from being useful in the short term.
183+Three directions we're pushing in: APIs, publishing, and distributed
184+chat. Urbit is a general-purpose system, of course, and it's very
185+hard for us to know what "killer app" will catch on first. It might
186+not even be any of these.
190+It takes a long time to replace Facebook -- or any other mature Web
191+service. But most of these services have APIs. Early in its life,
192+your general-purpose personal server puts most of its energy into
193+controlling special-purpose personal servers.
195+The use case seems a little trivial, but Urbit is actually a great API
196+client. An API client is stateful; it has keys and tokens to manage.
197+And APIs are notoriously unstable, which requires over-the-air
198+hotpatches, which Urbit is quite good at.
200+Also, having your own personal API token on your own personal server
201+is enormously empowering. Most services make it quite easy to
202+register yourself as an "app." Unlike a third-party startup, this "me
203+app" doesn't have to obey any TOS constraints on user experience.
205+For example, if you build an API-driven web service that shows an
206+integrated Facebook and Twitter feed, your API key will be revoked.
207+If you write an Urbit app that delivers the same experience, so long
208+as users bring their own API keys ("BYOK"), nothing bad will happen.
209+It's good for adoption when Urbit can present a user experience that
212+Another area we're focusing on is using Urbit as a shim to put your
213+Unix box in control of your API-driven services. With Urbit and FUSE,
214+you can actually mount remote services in your filesystem. Our first
215+prototypes of this are quite exciting, though they could use some
218+API drivers are also a great area for people to contribute code to
219+Urbit. There's an almost infinite number of drivers to write, each of
220+them is slightly different from the others,
222+### Personal publishing
224+If you put it behind nginx, Urbit already works quite well as a
225+personal publishing tool. You can copy a tree of Markdown files into
226+a directory and have a website or a blog. There's no reason why a
227+well-cached functional publishing system shouldn't replace a static
230+Key features we need for Urbit publishing: Let's Encrypt support for
231+people who need their own secure domains, and a DNS server in stars so
232+that `planet.urbit.org` doesn't have to be proxied.
234+### Decentralized chat
236+A lot of people want an encrypted, decentralized, persistent chat
237+network. Urbit already is this, though its human interface is nowhere
238+near as refined as a marvelous product like Slack.
240+Urbit needs chat because it needs to talk about itself. But the most
241+mature parts of Urbit will always be the ones we dogfood, and chat is
242+central to this list.
244+Can Urbit gain traction as a messaging platform alone? It's certainly
245+conceivable. It's difficult, to put it mildly, to understand what
246+makes one messaging network more popular than another. Ideally,
247+someone who cares deeply about decentralized messaging would take this
248+ball and run with it.
252+See the [interim constitution](./constitution).