@@ -0,0 +1,104 @@
2+title = "~2019.5 Roadmap"
4+author = "Galen Wolfe-Pauly"
5+description = "Where we are and where we're going as of mid-2019."
6+aliases = ["/posts/essays/2019-5-roadmap"]
11+
13+We often get so busy that we forget to tell you what we’ve been up to. Here’s an update on what we’re doing and where we’re headed with each layer of the stack.
15+At a very high level we have two goals for 2019: make Azimuth easier to use, and get Arvo to a 1.0.
17+Next year we’ll begin to move away from some of the MEGACORP software we use in the office and replace it with our own tooling. There’s some exciting work happening in that department, but we’ll cover that in a future post.
19+For some related recent thinking on all of this, see [The 100 Year Computer](/posts/essays/the-100-year-computer/), [The State of Landscape](/posts/essays/the-state-of-landscape/) and [Azimuth as MultiPass](/posts/essays/azimuth-as-multipass/).
21+For now, let’s just look at what’s on the immediate horizon:
25+At lunch the other day someone on our team said something like, ‘We built a complete and working public key infrastructure, but we haven’t told anyone.’
27+It’s true. Azimuth is operational, secure, and well tested. It’s a pretty cool piece of technology, and it’s out there in the world for anyone to use. It also doesn’t require that you use Arvo — Arvo happens to make use of Azimuth, but it’s a completely separate system.
29+So, the question is, why haven’t we told the world about it?
31+I tend to think that in order for a technology to succeed, it has to not only be an important technical innovation, but also easy to understand as a product. And that’s our answer: we’ve undersold Azimuth because we want it to be easier to understand by *using*, not just by reading the code. Azimuth is quite elegant as a piece of technology, but that doesn’t matter until it has a great user experience to match.
33+That’s why, in the near term, we’re focused on building on top of Azimuth ourselves. We can’t ask others to go down roads if we haven’t already been down ourselves.
35+So, here’s what we’re building first:
39+- A simplified onboarding flow for getting an Azimuth point that’s simple to share with friends over email, text or as a URL.
40+- A redesigned and improved Bridge for managing your points.
41+- An interface that allows you to easily send money between Azimuth points without running Arvo.
45+- Expanded Azimuth-centric example modules, documentation and developer tooling.
47+Still under consideration:
49+- An OAuth server for Azimuth, allowing any service to log users in with Azimuth.
50+- A mobile app for point to point payments using Azimuth.
54+Azimuth is beginning to feel like [multipass](/posts/essays/azimuth-as-multipass/), with a variety of ways to use Azimuth points without ever booting Arvo
58+The Arvo interface has always been held back by Arvo’s technical immaturity. This is still true to some degree. The system has not stabilized completely.
60+But! We’ve been using Landscape quite a lot lately. I use it daily, in fact — even [on my phone](https://itunes.apple.com/us/app/landscape-urbit/id1393148862). An encrypted (although not audited — so let’s not call it ‘secure’) authenticated chat where I own the keys and can read the source code is pretty cool, really. The interface isn’t perfect, but it’s nice. Landscape is a great preview of where we’re going: a simple, permanent, self-sovereign computer.
62+There are still rough edges, and Landscape is not nearly general purpose enough, but we have plans:
66+- A new update to the Arvo interface that we’re calling Modulo. Modulo expands beyond chat and longform discussion to make your Arvo interface feel much more like the computer it actually is.
67+- Upgrades to our event persistence, networking, and DNS integration aimed at much better stability. Arvo instances don’t crash that often, but with these changes it should be very rare.
68+- Significant improvements to testing with a new simulation testing framework and integration testing pipelines.
72+- A significant overhaul to Gall, our application model, making it much simpler for users to write apps or ‘agents’ in Arvo.
73+- A new version of the compiler that makes us less reliant on jets. This will eliminate a major obstacle to achieving network continuity, or the ability for ships to upgrade themselves totally over-the-air, forever.
74+- A significant overhaul and stability update to Clay, our filesystem, making it possible for us to trust it for self-hosting, search it easily, and depend on it for long-term data storage.
75+- Tooling for hosting and hopefully a beta program for hosted Arvo instances run by Tlon.
79+- A completely overhauled Arvo interface, Daigo, with a complete but simple set of messaging and collaboration tools.
80+- We come to work every day, use Arvo, go home.
84+Historically, we’ve been shy about even acknowledging we have a community at all. We’ve often felt like it was far too early to invite others in to the system.
86+As long as we’re up front about the state of this 100 year computer – that it’s live, but incomplete – I think it’s a good thing to welcome people on board. There are many opportunities for contribution and there’s plenty to play with.
88+Hoon school was the first effort in this direction. We intend to do a lot more:
92+Scaling Hoon school up to include both a track for experts and for beginners, and allowing many more participants.
94+- Holding more meetings and events on Landscape, experimenting with Arvo-native discussion.
95+- A clear program for address space grants for developers + contributors.
96+- New documentation site with searchable library docs.
100+- Hoon School participants understand clearly how to build a Modulo agent, and invite others into it.
101+- The road toward building an Azimuth module is well understood, paved, and clear.
102+- We have clear instructions and tutorials for building Azimuth modules and using Azimuth as a login or reputation primitive.
104+**Galen Wolfe-Pauly** ~ravmel-ropdyl