As usual, we're guilty of wanting to write code more than prose. Last time we announced our plans for Ethereum integration. This month we'll stick to basic project status:
Fall release goals and status
Curtis, Ted, Paul
Sometime in the next few weeks, we'll ship the Hoon 143 / Vere 0.5 release. This release will of course be a continuity breach. The mighty engine is still running in the lab while we screw on the last bells and make sure the boiler isn't leaking oil, steam or memory. Currently, Curtis is fighting memory leaks while Ted and Paul make sure the memoization cache can actually get reclaimed.
We want this fall 2017 Urbit testnet release to be reasonably rugged across the board. It is not a production network and its keys remain test keys. However, it should not crash, sink, etc.
This is new. For previous releases, it wasn't a realistic goal to keep ships from sinking, or salvage every pier. It's just incredibly disruptive and unpleasant in a pseudonymous network to sink people's identities. In this era, if your ship sinks, please (a) post an incident report to the Urbit fora; (b) know that we will strain every fiber to help you wrest it from Poseidon's grim grip.
Furthermore, although there will be no direct formal continuity between this release and the next one, we will provide tools to directly convert any data in your urbit. So, in case you actually do put meaningful datas in your urbit, you won't have to convert your datas completely by hand. Again, we will do everything to help.
Curtis, Iceman, Ted, Anton, Mark
Curtis has spent most of 2017 quasi-surreptitiously in "auteur mode," trying to complete his initial authorship of Hoon. After this release he promises to work only on Arvo and above.
Hoon 143 is not perfect, but it will do for a while. Nothing in Hoon 143 is so bad it's embarrassing. No one has any need to wait for it to stabilize. Any errors in the above must be fixed by Hoon 142.
Hoon 143 establishes a set of standards and conventions which define modern, high-quality code. Most of the Urbit codebase isn't quite to this standard. Changing this includes removing the use of deprecated language features, then removing support for the deprecated features (to create Hoon 142). Someone should definitely do this work.
Here are some of the things Curtis has done to Hoon, without asking anyone's permission. (Did Godard ask permission?) On some of these things he had fellow conspirators -- Iceman was an equal contributor on the decorators, the team of Ted, Anton and Mark on Udon.
Big changes in Hoon 143:
- Hoon 151's "electroplating," which replaced Hoon 164's "vulcanization,"
has been replaced by 143's "repainting." This means wet gate namespacing
works, so you can write
(weld ~[1 2] ~[3 4])and get
~[1 2 3 4]instead of
- There's now only one wide syntax
[a=term b=term]. This is like Hoon 164 syntax, but without the ubiquitous, and horrible, prefix comma. The price is modes.
- Decorators: formal syntax for adding documentation to types, available at runtime for reflexive help and diagnosis.
- In addition to the Sail dynamic XML syntax (which everyone forgets about, and which is basically JSX in Hoon), Hoon now has an embedded, Markdown-flavored rich text language: Udon. Few dynamic document platforms have this kind of range -- one file, with everything from code to tree-structured data to styled text.
- Keywords, which everyone despised, have been fully eradicated.
Curtis is done with Hoon and will never again change or improve it. He may offer occasional opinions. Ted and Iceman are the new maintainers of Hoon (including all of hoon.hoon and zuse.hoon, excluding Arvo models). Anything all they agree on is probably good.
What's not in this release
2017 was also the year we learned the lesson that, while Urbit is awesome and makes many system-software problems trivial, it is not so awesome that a team this small can advance two branches at once. This fall 2017 release is a classic, Microsoft-style stick save, cutting off about half of the research ("master" or "cc-release") branch and merging it back with splints and bandaids.
What got cut (this work is mostly coded, but not fully tested / integrated):
- The all-new event system in Vere, the all-new Arvo kernel with correct whitepaper-style lifecycle function
- The all-new (not just repaired) Ames (network) vane
- Ted and Anton's the mostly-rewritten Ford (build) vane
- Mark's rewritten Talk app (now Hall)
- The all-new Jael authentication vane
- The new generalized console library
There is plenty of other stuff that needs to go into our next release. Some of it is described below.
SPA rendering and build system
Ted and Anton
Ever notice how urbit.org gives 504 errors far too much? Hell, it probably 504-ed when you tried to load this page. This is clearly a problem.
Perhaps we could hack our way around it — but, as usual, we prefer to get to the root of the problem. When you request a webpage from an Urbit we use our build system, Ford, to produce it. Then our single-page app, Tree, renders and builds the page in the browser.
There are two problems with the current system:
The Ford cache is cleared every time something in Clay changes.
On the client side, pages are built through multiple requests.
To fix (2) we want to move to a system where each page is a single static build. This means doing 'server side rendering' with Ford — rather than having the client make multiple requests for every page component.
The basic parts of this are done. We implemented a subset of markdown in Hoon and added some new runes to Ford. This means you can write files that include other files without any JSX or client side craziness.
(1) is a bit more complicated, and has taken up quite a bit of Anton and Ted's time. We've implemented a new cache algorithm, which is designed to promote unchanged content across revisions. The algorithm seems correct, but doesn't properly promote unchanged content in all cases.
With these two things actually completed we'll be able to get much snappier page loads. The next step is properly terminating SSL at an individual ship — but more on that next month.
The details of this project are outlined in UP1 - Ford Caching Redux: fora/posts/~2017.10.19..04.47.50..c107~/. More on UPs below.
Isaac, Galen and Jimmy
One thing we still don't do a particularly good job of is communicating about what Urbit is. Even to savvy tech and crypto folks.
We're working on a new, illustrated, single-page explanation to go up on urbit.org. The text is coming together and we're starting to work on design.
Josh and Galen
Josh is a PhD student who has a lot more teaching experience than we do. To boot, he's convinced that Nock is incredibly simple and can be taught to just about anyone. So, he put together a few video tutorials.
We're touching up the look and feel — but they should go up in the next week or so.
Mark and Curtis
Working from Curtis' designs, Mark has helped us implement the Urbit constitution as a set of ETH contracts. They're off to the auditors, but the code lives here: github.com/urbit/constitution for public scrutiny.
Anthony and Galen
We want to make interacting with the Urbit ETH contracts as easy as possible. Especially for people who aren't necessarily particularly familiar with interacting with dApps.
So, we designed an Urbit-specific frontend for MyEtherWallet. And Anthony, who actually knows Angular, has been helping us implement it. He has been working privately, but progress will be visible here: github.com/urbit/etherwallet soon.
Keaton, Ted and Galen
About a month ago we were discussing how we'd really like to be more transparent about the projects we undertake. And, we'd really like to have a way of cataloging projects we discuss but can't take on.
Enter the UP or 'Urbit Proposal'. UP0 gives an outline for what a UP should contain: fora/posts/~2017.10.19..03.45.26..dbec~/.
Jaque, an independent interpreter in Java
Paul is delighted to announce Jaque, an independent implementation of Urbit using Graal/Truffle on the JVM.
Jaque is not just another Nock function -- it boots an actual Urbit pill to a working dojo prompt. Jaque has no compiler jets and has exposed several jet mismatches in Vere. It works and is reportedly quite snappy. Paul is still tuning the interpreter, changing it from a tree interpreter to a small bytecode, because Graal does not like big stacks and tree interpreters make big stacks. He'll say more about it when he considers it done, which is not yet.