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