--- sort: 6 type: post title: Roadmap author: Curtis Yarvin image: http://media.urbit.org/site/blog-5.jpg preview: Our near-term goals for the Urbit community, documentation, maturity, utility and governance. layout: urbit,post footer: true navmode: navbar navdpad: false navselect: posts navpath: / navhome: / navclass: urbit --- # Urbit roadmap 2016 Urbit is in early beta. It works. It doesn't work well enough to be particularly useful, though it's not that far away. It's important to understand that the present Hoon codebase was developed almost entirely by three full-time engineers (Curtis, Philip, Anton). We are good, but not superhuman. We have four separate problems to attack in 2016: community, maturity, utility, and governance. ## Community Working on Urbit is incredibly fun. We've kind of bogarted that fun. We're sorry -- no, we're not actually sorry -- but we're going to change that. Since 2013, the community status of Urbit has been that it's open source and you can mess with it if you want, but we don't really do much to encourage you. Or to put it differently: open source, secretly wishing it was still stealth. The sad truth is that we've been doing research, and research doesn't scale. This is one of the reasons why open-source projects are notoriously focused on copying proprietary products. Open source is great for incremental maintenance and development -- almost nothing in software is as mature as a mature open-source project, because "with enough eyeballs, all bugs are shallow." But it's terrible for creative research, because the smallest decisions invite the notorious "bikeshedding" syndrome. Now that Urbit does all the things we want it to do, in (pretty much) the way we want it to do them, our focus is changing. All we really care about going forward is maturity and traction. Also, it's a lot harder to argue about what color the bikeshed should be painted, if the bikeshed is already painted. So, working on Urbit is incredibly fun. If only because it's the programmer's equivalent of astrobiology. But not only because -- Urbit is very far from being a mere esoteric curiosity. The first challenge we face is making sure Urbit is properly documented. (See below.) We'll also be: - holding weekly public meetings / office hours - maintaining public developer blogs - (probably) running open contests with address-space prizes ## Maturity At the systems layer, Urbit has enough features for right now. What it needs is maturity. Aside from mere bugs and issues, maturity comes in five flavors: documentation, dogfooding, optimization, security, and testing. ### Documentation Anyone outside the core team who's done any serious work in Urbit has earned their scout badge in Reverse Engineering. The number of people who have done this is impressive, but also slightly embarrassing. Since Urbit is so technically unusual, we have no excuse for leaving any part of it undocumented. Documenting Urbit is not just a matter of writing down specifications for the code as it exists. That would be easy if the code was perfect. It's not perfect. One truism of CS is Knuth's observation that "premature optimization is the root of all evil." Yes, but premature documentation is at least the trunk of all evil. "Documenting into existence" -- making something that doesn't exist exist, by describing it -- is the trap of all vaporware projects. On the other hand, Urbit does exist. It doesn't need to be documented into existence. It does need to be documented into completion. This doesn't mean simply describing the codebase. Documenting to completion is a two-way process. It always produces a nontrivial set of technical revisions. Large design questions are not open for discussion, but small ones are. This makes documenting to completion a fun and fascinating community process, which neither reduces to mere stenography, nor descends into endless bikeshedding. Nock is completely done, and completely documented. Hoon still has a few small rough spots; its reference documentation is decent but not perfect; its tutorial documentation needs more work, but is reasonably adequate. The real target of documentation into completion is Arvo (including the Hoon library). The ideal point at which to prepare stable documentation is the point Arvo is at now: basically working, but largely undocumented. Since Hoon is a programming language for Arvo, not for Unix, Hoon documentation without Arvo documentation remains mostly useless -- so we've got a strong incentive to get this done. But not without actually getting it right. ### Dogfooding Urbit has no alternative but to dogfood itself into maturity. If the Urbit team itself doesn't solve some problem with Urbit, who else can be expected to? Any use of any external tool in the Urbit development process is a damaging energy leak. We already use Urbit to publish documents about Urbit, to chat about Urbit, and of course to deliver Urbit updates. With this release, we're adding a public chat stream and public comments. The next dogfooding steps: using Github as a backup to Clay, not Clay as downstream from Github; our own internal issue tracker; and replacing internal email with long-form `:talk` messages. ### Optimization You'll notice that some aspects of Urbit are slower than you might expect. This is because of our approach to optimization, which is to throw some elbow grease at it when it gets annoying. Death by unsolvable slowness is a common cause of mortality in language-oriented projects like Urbit. But Urbit actually has two big advantages in optimization. First, our profiler is simple, but quite effective, because it's integrated with the language and runtime at a level usually not found in profilers. Second, anything that's slow can be jetted; as long as there's an inner loop, that inner loop is vulnerable to anyone who can write C. And there's always an inner loop. ### Testing There is plenty of design work to be done in even figuring out how to systematically test Urbit. We've done appallingly little systematic testing. We've mostly relied on simplicity and elbow grease to get the system to the reliability level it's at now. `~zod` has been up for a few months and has a 22GB event log. There's no reason to think that if we replayed that log, we'd end up with any different bits. Simplicity buys a lot. Urbit is not always as simple as we want it to be, though. There are plenty of known bugs; and we're nowhere ready to declare Urbit ready for mission-critical data. ### Security Urbit is not yet secure at all. We don't even think it's secure. And this is just the first step in making it secure. After that comes an independent audit and penetration testing. ## Utility However much we want Urbit to succeed because we're geeks and love functional programming, it can only go somewhere by being useful -- to people who don't care about the technology. Moreover, even for geeks, the amount of fun in working on something that's permanently un-useful is quite limited. What is Urbit? Urbit is a general-purpose personal server whose long-term goal is to replace the whole web-service ecosystem. The long term takes a long time by definition and is always preceded by the short term. Fortunately, Urbit isn't that far from being useful in the short term. Three directions we're pushing in: APIs, publishing, and distributed chat. Urbit is a general-purpose system, of course, and it's very hard for us to know what "killer app" will catch on first. It might not even be any of these. ### API aggregation It takes a long time to replace Facebook -- or any other mature Web service. But most of these services have APIs. Early in its life, your general-purpose personal server puts most of its energy into controlling special-purpose personal servers. The use case seems a little trivial, but Urbit is actually a great API client. An API client is stateful; it has keys and tokens to manage. And APIs are notoriously unstable, which requires over-the-air hotpatches, which Urbit is quite good at. Also, having your own personal API token on your own personal server is enormously empowering. Most services make it quite easy to register yourself as an "app." Unlike a third-party startup, this "me app" doesn't have to obey any TOS constraints on user experience. For example, if you build an API-driven web service that shows an integrated Facebook and Twitter feed, your API key will be revoked. If you write an Urbit app that delivers the same experience, so long as users bring their own API keys ("BYOK"), nothing bad will happen. It's good for adoption when Urbit can present a user experience that nothing else can. Another area we're focusing on is using Urbit as a shim to put your Unix box in control of your API-driven services. With Urbit and FUSE, you can actually mount remote services in your filesystem. Our first prototypes of this are quite exciting, though they could use some optimization. API drivers are also a great area for people to contribute code to Urbit. There's an almost infinite number of drivers to write, each of them is slightly different from the others, ### Personal publishing If you put it behind nginx, Urbit already works quite well as a personal publishing tool. You can copy a tree of Markdown files into a directory and have a website or a blog. There's no reason why a well-cached functional publishing system shouldn't replace a static site generator. Key features we need for Urbit publishing: Let's Encrypt support for people who need their own secure domains, and a DNS server in stars so that `planet.urbit.org` doesn't have to be proxied. ### Decentralized chat A lot of people want an encrypted, decentralized, persistent chat network. Urbit already is this, though its human interface is nowhere near as refined as a marvelous product like Slack. Urbit needs chat because it needs to talk about itself. But the most mature parts of Urbit will always be the ones we dogfood, and chat is central to this list. Can Urbit gain traction as a messaging platform alone? It's certainly conceivable. It's difficult, to put it mildly, to understand what makes one messaging network more popular than another. Ideally, someone who cares deeply about decentralized messaging would take this ball and run with it. ## Governance See the [interim constitution](../constitution).

Subscribe to our newsletter: