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