git.iko.soy/urbit.org
on master help sign in
pasted the zola port of urbit.org
4f285abfriederjanmoerman
config.tomlnew file+50
compare with master
unifiedsplit
@@ -0,0 +1,50 @@
1+# Used in RSS by default
2+title = "Urbit"
3+description = "Official website Urbit"
4+
5+# The default language, used in RSS
6+default_language = "en"
7+
8+# The URL the site will be built for
9+base_url = "https://hardcodepunk.be/_private/urbit"
10+
11+# Whether to automatically compile all Sass files in the sass directory
12+compile_sass = true
13+
14+# Whether to do syntax highlighting
15+# Theme can be customised by setting the `highlight_theme` variable to a theme supported by Zola
16+highlight_code = true
17+
18+# Whether to build a search index to be used later on by a JavaScript library
19+build_search_index = true
20+
21+# The taxonomies to be rendered for that site and their configuration
22+# Example:
23+# taxonomies = [
24+# {name = "tags", rss = true}, # each tag will have its own RSS feed
25+# {name = "categories", paginate_by = 5}, # 5 items per page for a term
26+# {name = "authors"}, # Basic definition: no RSS or pagination
27+# ]
28+#
29+taxonomies = [
30+ {name = "posts", rss = true},
31+]
32+
33+[extra]
34+urbit_menu = [
35+ {url = "$BASE_URL", name = "Urbit"},
36+ {url = "$BASE_URL/primer", name = "Primer"},
37+ {url = "$BASE_URL/posts", name = "Posts"},
38+ {url = "$BASE_URL/docs", name = "Docs"},
39+]
40+
41+urbit_footer = [
42+ {url = "$BASE_URL/privacy", name = "Privacy Policy"},
43+ {url = "$BASE_URL/tos", name = "Terms of Service"},
44+ {url = "$BASE_URL/bounty", name = "Bug Bounty + Security"},
45+]
46+
47+docs_number_chapters = true
48+
49+[extra.author]
50+name = "Tlon Corp"
content/_index.mdnew file+3
@@ -0,0 +1,3 @@
1++++
2+title = "Home"
3++++
content/_primer.mdnew file+4
@@ -0,0 +1,4 @@
1++++
2+title = "Primer"
3+template = "primer.html"
4++++
content/bounty.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Bug Bounty + Security"
3++++
4+## Upcoming Bug Bounty Program
5+
6+We are in the process of designing our Bug Bounty Program, and it should be live in several days. In the meantime, if you believe you have discovered a bug or vulnerability in our code, please report it at security@tlon.io.
7+
8+We'll review the issue, and a member of our dev team will get back to you ASAP. If your bug has merit, we'll work with you to fix it, and award a bounty based on the severity of the bug. We determine severity using the [CVSS](https://www.first.org/cvss/calculator/3.0) model.
9+
10+Once the fix is complete, we'll publish a full retrospective in the interests of transparency. If the bug leaks prior to the retrospective being published, the bounty is void.
11+
12+We look forward to working with you.
content/posts/2016-10-6-update.mdnew file+261
@@ -0,0 +1,261 @@
1++++
2+title = "~2016.10.6 Update"
3+date = 2016-10-06
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "September's monthly update slipped into October! But don't worry, it's a good one."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+September's monthly update slipped into October! But don't
10+worry, it's a good one.
11+
12+## "Hard tech"
13+
14+In [this amusing talk](http://www.themacro.com/articles/2016/09/chad-rigetti-on-building-quantum-computers/),
15+Chad Rigetti defines "hard tech" as "solving problems you don't
16+even know are solvable." Rigetti is building a quantum
17+computer, which is definitely "hard tech." More power to him!
18+
19+But software can be "hard," too. Is Urbit "hard tech"?
20+
21+The correct answer at this point is: no, but it _used_ to be hard
22+tech. Now it's actually real, if not exactly easy. The Urbit
23+network hasn't crashed once this summer, though we did one
24+intentional breach (right before delivering the stars). I'm
25+still kind of amazed by this.
26+
27+But we still need to get to the point where (a) the whole network
28+can't crash ever, (b) you can put your data in an urbit and be
29+pretty sure it'll live forever, (c) Urbit works well as a social
30+network, and therefore (d) we can distribute planets to ordinary
31+human beings and not have them be like, "gah, what is this?"
32+
33+If we had the resources of Microsoft or Google, or even of
34+Mozilla, we could solve these problems with a brute-force
35+human-wave attack. We could just debug the system into
36+existence. It must be nice.
37+
38+But not. In some ways it's essential to Urbit's mission that
39+there isn't a giant army behind it. It means that the only way
40+Urbit can succeed, or even survive, is to be excellent. That's
41+the right attitude for a stack designed for the 2020s. Not that
42+we can wait until the 2020s to get (a) through (d). Just that we
43+don't want our children and grandchildren to curse the day this
44+stack was born. Unix, the Internet and the Web gained the world
45+and lost their souls -- we don't have that option.
46+
47+Given this attitude, the thing that terrified me most of all
48+about this summer's crowdsale is that the most important parts of
49+Arvo -- the network and the PKI -- simply didn't exist in any
50+viable sense. Yes, the present `%ames` network does net work.
51+There is even in theory a sort of PKI, although no one has ever
52+even tried to revoke a key. It might be secure -- who knows?
53+
54+More concretely, the existing `%ames` vane (kernel module) contains
55+both the protocol and the PKI, mixed together in a single giant
56+state machine of the sort I've learned never to build again.
57+There is no perfect code anywhere in the present production Arvo,
58+but the only body of _dead-end_ code -- which needs replacement,
59+not documentation and maintenance -- is `%ames`.
60+
61+Unfortunately, networking and key management is the most
62+important part of Urbit. In a sense it _is_ Urbit. So having it
63+not exist, except as a design in our heads, was not a good thing.
64+
65+While documenting, evangelizing and in general growing Urbit is
66+vastly important, what's even more important is finishing it --
67+without compromising its elegance. Elegance is the only thing
68+Urbit has. It's not like there aren't other operating systems.
69+
70+So the first thing I did after the crowdsale was to disappear
71+into a hole and take care of this technical debt. This was not
72+"hard tech" in the sense that I knew it was solvable. I didn't
73+know it was solvable _well_, though. And it has to be solved
74+_well_, because otherwise who cares.
75+
76+## Check out our new, improved cc-release
77+
78+I'm delighted to report that the new, rewritten `%ames` network,
79+and the all-new `%jael` PKI, are now at code complete. (Code
80+complete means "compiling but not tested," which is actually
81+saying a lot in a typed functional language.) They've been
82+checked in to a new `cc-release` branch on
83+[`github.com/urbit/arvo`](https://github.com/urbit/arvo).
84+
85+I think these two vanes are definitely the best code in Urbit.
86+There's still a bit of fundamental work in Arvo (implementing the
87+boot sequence and event security mechanisms described in the
88+whitepaper), but this is not "hard tech" -- the designs are
89+clear and surprises seem unlikely.
90+
91+## `%xmas`: the new network
92+
93+New `%ames` (currently `arvo/xmas.hoon`, since old `%ames` is still in
94+the build) has had all the key management stripped out; it's just
95+a network vane. It's also no longer a single giant state
96+machine, but a system of five simple 200-line state machines.
97+
98+It was wonderful to discover that Hoon lets you write purely
99+functional programs with what are essentially global variables.
100+Specifically, nested cores generalize across global variables,
101+local variables, and objects, in a way I find technically quite
102+lovely if I do say so myself. On the other hand, Hoon ain't
103+magic, and it's not like we've solved any of the
104+software-engineering problems inherent in a 2000-line state
105+machine based on global variables. So, nice to kill that.
106+
107+Don't look at new `%ames` just yet. It was done in July and
108+August. It needs a few touchups to fit the `%jael` interface.
109+And it needs to be brought up to `%jael`'s quality standards.
110+
111+## `%jael`: reference code, PKI, and personal ledger
112+
113+`%jael` (`/arvo/jael.hoon`), the PKI, is what I'm really excited
114+about. It's what you should take a look at if you know any Hoon
115+or even if you don't. There's several really important things
116+about `%jael`.
117+
118+The first is that it's actually reference-quality code. Or so I
119+believe. It's literally intended to serve as a reference style
120+for what all production-quality Hoon should look like. If you're
121+reading the code and you see anything that isn't absolutely
122+perfect, whether it's cosmetic or structural or anything in
123+between, file a PR. `%jael` is fully commented -- if you think
124+it needs more comments, or fewer, file a PR...
125+
126+Needless to say, a reference style will be an enormous help in
127+managing community contributions. It's not that, for now at
128+least, we won't accept patches not written in line with the
129+reference `%jael` style. But we'll always accept patches to bring
130+'those patches' up to reference. For the moment, the code will just
131+define the style by analogy, but it'll eventually spawn an actual
132+document.
133+
134+If you're feeling ambitious and want to change the reference
135+style itself, your change is best submitted as a patch to `%jael`
136+itself. And _really_ ambitious people can create their own
137+alternative Hoon styles -- hopefully defined at the same same
138+level of precision.
139+
140+Second, `%jael` actually implements the Urbit PKI as designed,
141+right down to unusual but politically critical features like
142+escaping a bad parent. Since the code is readable and heavily
143+commented, it can and will serve as the best possible reference
144+for the PKI's semantics.
145+
146+Both `%ames` and `%jael` are designed for the new and correct
147+single-homed urbit model, where one pier is one ship. In the new
148+world, to boot your planet, you use your ticket to generate a
149+symmetric key that authenticates you to your parent. When you
150+share your public key with your parent, over that initial secure
151+channel, it notices that it hasn't signed it yet and shares its
152+signature back to you.
153+
154+Third, `%jael` isn't just a PKI -- it's a generalized system for
155+formal promises. The whole point of a PKI is that entities can
156+make secure statements to each other. Of course, every `:talk`
157+message is a signed statement, but the really important messages
158+are _promises_ -- such as, for instance, "Tlon owes you 3 stars."
159+
160+(Right now, the stars we sold in the crowdsale are recorded in the
161+state of a higher-level application (`:womb`). (We have an
162+encrypted offline backup, of course.) This is fine at a certain
163+level, but it's a bit rickety and not really up to Urbit's
164+standards of architectural elegance. Promises and secrets are
165+fundamental state and need to be handled at a fundamental level.)
166+
167+In a secure distributed social network, people need to be able to
168+make formal promises to each other. Essentially, every ship is
169+an _accounting entity_. It records its liabilities, which are
170+the promises it's made to others, and its assets, which are the
171+promises others have made to it. When I update the promises I've
172+made to you, I send you an updated statement.
173+
174+All kinds of promises fit this mold. For instance, while you
175+don't usually think of a symmetric key as a promise from one
176+entity to another, it is. It's a promise from ship A to ship B,
177+that B can identify itself to A by this secret.
178+
179+So `%jael` will, among other glorious things, essentially allow
180+every galaxy to serve as an exchange for star invitations, and
181+any star to serve as an exchange for planet invitations. Mere
182+payments are just the start of what you can do with this. And of
183+course, one of our big near-term goals is to make first Urbit
184+invitations, then (once the crypto is truly final) actual ships,
185+tradeable on "regular" cryptocurrency exchanges.
186+
187+One of my views about Bitcoin is that its decentralized,
188+trust-free ledger isn't really the most important thing about it.
189+Humans build trust quite easily. For instance, Bitcoin doesn't
190+even enable trust-free payments -- a payment is always an
191+exchange for other good or service. Do I provide the good or
192+service before, or after, the Bitcoin payment? Either way,
193+trust is unavoidable.
194+
195+The important thing about Bitcoin is just that it enables users
196+to manage their obligations to each other digitally, without
197+interacting with a 20th-century asset management system made of
198+paper and magnetic tape. Giving every user their own asset
199+management ledger is another small revolution in that direction.
200+And if I'm defining and issuing my own digital assets, why do I
201+need to put them on a global blockchain? You're still trusting
202+me to actually live up to my promises.
203+
204+Last but not least, `%jael` solves one of Urbit's most important
205+and hardest problems: how do I back up my urbit? I know I said
206+this was impossible, but I lied.
207+
208+Urbit uses persistent sessions, which means a pair of ships uses
209+the same session sequence numbers for life. Since every packet
210+is a transaction, when you send an acknowledgment, you mean it.
211+The upside is that we get exactly-once messaging, which if you've
212+ever done distributed programming is a very, very good thing.
213+The downside is that if you lose your state, there's no way to
214+recover it, since you don't know what sequence number to send
215+next. (See under: [Two Generals'
216+Problem](https://en.wikipedia.org/wiki/Two_Generals%27_Problem)).
217+
218+In the new world, the Unix layer will subscribe to a stream of
219+`%jael` changes which contain all certificate and rights actions.
220+We'll save this separately from the rest of the pier state, and
221+it's small and trivial to back up.
222+
223+When restoring, if you have all your private keys but have lost
224+all other state (obviously if you don't have the latest private
225+key, you're hosed), you sign a new version of your will which
226+contains a "brain damage" bit. When this will is propagated to
227+your neighbors, they learn that you're brain-damaged and reset
228+their sequence numbers -- and forget you know anything they told
229+you, treating you as a new stranger.
230+
231+At the application level, all your subscriptions get closed.
232+Apps already have to deal with this. Forward messages shouldn't
233+involve any state coupling; that's what subscriptions are for.
234+In case there is some coupling anyway, you'll get an event that
235+"ship X lost his mind, forget anything you know about him."
236+
237+Essentially, we're cheating the fact that you can't have
238+transient sessions and [exactly-once delivery](http://bravenewgeek.com/you-cannot-have-exactly-once-delivery/)
239+by letting the abstraction leak in this special case, and putting
240+the responsibility for fixing it on the brain-damaged ship. It
241+may even leak up to the user. But dude, you're the one that let
242+your brain fall out of your skull.
243+
244+Another thing I like about this solution (and about `%jael` in
245+general) is that it solves the problem of how you use someone
246+else's secrets, if you manage to steal them. There's no point in
247+security through technical difficulty -- if you have the latest
248+private key for a ship, you're the captain now. You shouldn't
249+have to hack something up to make this work.
250+
251+## Keep in touch / office hours
252+
253+`:talk` is always a great place to come and ask questions.
254+Someone from Tlon will be available in `:talk` from 12PM - 3PM
255+PDT each weekday. And [our forum](https://fora.urbit.org) is a
256+great place to post questions. We've created [this
257+thread](https://urbit.org/fora/posts/~2016.10.7..17.28.21..b058~/) to
258+discuss this post.
259+
260+For anything else you can always get in touch with us via
261+[`urbit@urbit.org`](mailto:urbit@urbit.org).
content/posts/2016-5-16-roadmap.mdnew file+243
@@ -0,0 +1,243 @@
1++++
2+title = "~2016.5.16 Urbit Roadmap 2016"
3+date = 2016-05-16
4+author = "Curtis Yarvin"
5+description = "Our near-term goals for the Urbit community, documentation, maturity, utility and governance."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+
10+Urbit is in early beta. It works. It doesn't work well enough to be
11+particularly useful, though it's not that far away.
12+
13+It's important to understand that the present Hoon codebase was
14+developed almost entirely by three full-time engineers (Curtis,
15+Philip, Anton). We are good, but not superhuman.
16+
17+We have four separate problems to attack in 2016: community, maturity,
18+utility, and governance.
19+
20+## Community
21+
22+Working on Urbit is incredibly fun. We've kind of bogarted that fun.
23+We're sorry -- no, we're not actually sorry -- but we're going to
24+change that.
25+
26+Since 2013, the community status of Urbit has been that it's open
27+source and you can mess with it if you want, but we don't really do
28+much to encourage you. Or to put it differently: open source,
29+secretly wishing it was still stealth.
30+
31+The sad truth is that we've been doing research, and research doesn't
32+scale. This is one of the reasons why open-source projects are
33+notoriously focused on copying proprietary products. Open source is
34+great for incremental maintenance and development -- almost nothing in
35+software is as mature as a mature open-source project, because "with
36+enough eyeballs, all bugs are shallow." But it's terrible for
37+creative research, because the smallest decisions invite the notorious
38+"bikeshedding" syndrome.
39+
40+Now that Urbit does all the things we want it to do, in (pretty much)
41+the way we want it to do them, our focus is changing. All we really
42+care about going forward is maturity and traction. Also, it's a lot
43+harder to argue about what color the bikeshed should be painted, if
44+the bikeshed is already painted.
45+
46+So, working on Urbit is incredibly fun. If only because it's the
47+programmer's equivalent of astrobiology. But not only because --
48+Urbit is very far from being a mere esoteric curiosity.
49+
50+The first challenge we face is making sure Urbit is properly
51+documented. (See below.) We'll also be:
52+
53+- holding weekly public meetings / office hours
54+- maintaining public developer blogs
55+- (probably) running open contests with address-space prizes
56+
57+## Maturity
58+
59+At the systems layer, Urbit has enough features for right now. What
60+it needs is maturity.
61+
62+Aside from mere bugs and issues, maturity comes in five flavors:
63+documentation, dogfooding, optimization, security, and testing.
64+
65+### Documentation
66+
67+Anyone outside the core team who's done any serious work in Urbit has
68+earned their scout badge in Reverse Engineering. The number of people
69+who have done this is impressive, but also slightly embarrassing.
70+Since Urbit is so technically unusual, we have no excuse for leaving
71+any part of it undocumented.
72+
73+Documenting Urbit is not just a matter of writing down specifications
74+for the code as it exists. That would be easy if the code was
75+perfect. It's not perfect.
76+
77+One truism of CS is Knuth's observation that "premature optimization
78+is the root of all evil." Yes, but premature documentation is at
79+least the trunk of all evil. "Documenting into existence" -- making
80+something that doesn't exist exist, by describing it -- is the trap of
81+all vaporware projects.
82+
83+On the other hand, Urbit does exist. It doesn't need to be documented
84+into existence. It does need to be documented into completion. This
85+doesn't mean simply describing the codebase.
86+
87+Documenting to completion is a two-way process. It always produces a
88+nontrivial set of technical revisions. Large design questions are not
89+open for discussion, but small ones are. This makes documenting to
90+completion a fun and fascinating community process, which neither
91+reduces to mere stenography, nor descends into endless bikeshedding.
92+
93+Nock is completely done, and completely documented. Hoon still has a
94+few small rough spots; its reference documentation is decent but not
95+perfect; its tutorial documentation needs more work, but is reasonably
96+adequate.
97+
98+The real target of documentation into completion is Arvo (including
99+the Hoon library). The ideal point at which to prepare stable
100+documentation is the point Arvo is at now: basically working, but
101+largely undocumented.
102+
103+Since Hoon is a programming language for Arvo, not for Unix, Hoon
104+documentation without Arvo documentation remains mostly useless -- so
105+we've got a strong incentive to get this done. But not without
106+actually getting it right.
107+
108+### Dogfooding
109+
110+Urbit has no alternative but to dogfood itself into maturity. If the
111+Urbit team itself doesn't solve some problem with Urbit, who else can
112+be expected to? Any use of any external tool in the Urbit development
113+process is a damaging energy leak.
114+
115+We already use Urbit to publish documents about Urbit, to chat about
116+Urbit, and of course to deliver Urbit updates. With this release,
117+we're adding a public chat stream and public comments.
118+
119+The next dogfooding steps: using Github as a backup to Clay, not Clay
120+as downstream from Github; our own internal issue tracker; and
121+replacing internal email with long-form `:talk` messages.
122+
123+### Optimization
124+
125+You'll notice that some aspects of Urbit are slower than you might
126+expect. This is because of our approach to optimization, which is to
127+throw some elbow grease at it when it gets annoying.
128+
129+Death by unsolvable slowness is a common cause of mortality in
130+language-oriented projects like Urbit. But Urbit actually has two big
131+advantages in optimization.
132+
133+First, our profiler is simple, but quite effective, because it's
134+integrated with the language and runtime at a level usually not found
135+in profilers. Second, anything that's slow can be jetted; as long as
136+there's an inner loop, that inner loop is vulnerable to anyone who can
137+write C. And there's always an inner loop.
138+
139+### Testing
140+
141+There is plenty of design work to be done in even figuring out how to
142+systematically test Urbit.
143+
144+We've done appallingly little systematic testing. We've mostly relied
145+on simplicity and elbow grease to get the system to the reliability
146+level it's at now. `~zod` has been up for a few months and has a 22GB
147+event log. There's no reason to think that if we replayed that log,
148+we'd end up with any different bits.
149+
150+Simplicity buys a lot. Urbit is not always as simple as we want it to
151+be, though. There are plenty of known bugs; and we're nowhere ready
152+to declare Urbit ready for mission-critical data.
153+
154+### Security
155+
156+Urbit is not yet secure at all. We don't even think it's secure. And
157+this is just the first step in making it secure. After that comes an
158+independent audit and penetration testing.
159+
160+## Utility
161+
162+However much we want Urbit to succeed because we're geeks and love
163+functional programming, it can only go somewhere by being useful -- to
164+people who don't care about the technology. Moreover, even for geeks,
165+the amount of fun in working on something that's permanently un-useful
166+is quite limited.
167+
168+What is Urbit? Urbit is a general-purpose personal server whose
169+long-term goal is to replace the whole web-service ecosystem. The
170+long term takes a long time by definition and is always preceded by
171+the short term.
172+
173+Fortunately, Urbit isn't that far from being useful in the short term.
174+Three directions we're pushing in: APIs, publishing, and distributed
175+chat. Urbit is a general-purpose system, of course, and it's very
176+hard for us to know what "killer app" will catch on first. It might
177+not even be any of these.
178+
179+### API aggregation
180+
181+It takes a long time to replace Facebook -- or any other mature Web
182+service. But most of these services have APIs. Early in its life,
183+your general-purpose personal server puts most of its energy into
184+controlling special-purpose personal servers.
185+
186+The use case seems a little trivial, but Urbit is actually a great API
187+client. An API client is stateful; it has keys and tokens to manage.
188+And APIs are notoriously unstable, which requires over-the-air
189+hotpatches, which Urbit is quite good at.
190+
191+Also, having your own personal API token on your own personal server
192+is enormously empowering. Most services make it quite easy to
193+register yourself as an "app." Unlike a third-party startup, this "me
194+app" doesn't have to obey any TOS constraints on user experience.
195+
196+For example, if you build an API-driven web service that shows an
197+integrated Facebook and Twitter feed, your API key will be revoked.
198+If you write an Urbit app that delivers the same experience, so long
199+as users bring their own API keys ("BYOK"), nothing bad will happen.
200+It's good for adoption when Urbit can present a user experience that
201+nothing else can.
202+
203+Another area we're focusing on is using Urbit as a shim to put your
204+Unix box in control of your API-driven services. With Urbit and FUSE,
205+you can actually mount remote services in your filesystem. Our first
206+prototypes of this are quite exciting, though they could use some
207+optimization.
208+
209+API drivers are also a great area for people to contribute code to
210+Urbit. There's an almost infinite number of drivers to write, each of
211+them is slightly different from the others,
212+
213+### Personal publishing
214+
215+If you put it behind nginx, Urbit already works quite well as a
216+personal publishing tool. You can copy a tree of Markdown files into
217+a directory and have a website or a blog. There's no reason why a
218+well-cached functional publishing system shouldn't replace a static
219+site generator.
220+
221+Key features we need for Urbit publishing: Let's Encrypt support for
222+people who need their own secure domains, and a DNS server in stars so
223+that `planet.urbit.org` doesn't have to be proxied.
224+
225+### Decentralized chat
226+
227+A lot of people want an encrypted, decentralized, persistent chat
228+network. Urbit already is this, though its human interface is nowhere
229+near as refined as a marvelous product like Slack.
230+
231+Urbit needs chat because it needs to talk about itself. But the most
232+mature parts of Urbit will always be the ones we dogfood, and chat is
233+central to this list.
234+
235+Can Urbit gain traction as a messaging platform alone? It's certainly
236+conceivable. It's difficult, to put it mildly, to understand what
237+makes one messaging network more popular than another. Ideally,
238+someone who cares deeply about decentralized messaging would take this
239+ball and run with it.
240+
241+## Governance
242+
243+See the [interim constitution](../interim-constitution).
content/posts/2016-7-20-update.mdnew file+158
@@ -0,0 +1,158 @@
1++++
2+title = "~2016.7.20 Update"
3+date = 2016-07-20
4+author = "Curtis Yarvin"
5+description = "It's an amazing feeling to realize that the Internet is fully capable of funding and programming its own replacement."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+
10+First, a huge thank you to everyone who helped make our crowdsale a
11+success. It's an amazing feeling to realize that the Internet is
12+fully capable of funding and programming its own replacement. The
13+world both knows enough about it, and cares enough about it.
14+
15+It will still be a lot of work to make Urbit a polished product for
16+ordinary humans, and organizing this work remains a tremendous
17+responsibility. But now we're confident that it can be done.
18+
19+Now that the public has a serious stake in Urbit, we can't really keep
20+up our old habit of working in the dark and occasionally releasing
21+mysterious beautiful things. We'll keep up with these monthly
22+updates, on or about the 20th of each month.
23+
24+As always, you can see the beating pulse of Urbit development at
25+[urbit.org/stream](https://urbit.org/stream).
26+
27+## General status
28+
29+The work required to pull off the sale definitely drained the energy
30+of our two strongest engineers, Philip (`~wictuc-folrex`) and Anton
31+(`~fyr`).
32+
33+Rather than remain on the path to total burnout we decided to push
34+back the issuing of stars. Our goal is to activate invites on August
35+12th, 2016. Apologies for the delay, and the short notice.
36+
37+## Great renaming, rekeying, and new ames
38+
39+If you bought a star, you might notice that while our invitation
40+server (the womb) is up, it's not currently configured to let you
41+create a star.
42+
43+Our first major release, which comes with a continuity breach
44+(complete network reboot where all ships are recreated), needs to (a)
45+fix the ship naming algorithm "`@p`", giving everyone (including us)
46+new names; and (b) replace the somewhat risible cryptosuite A (RSA and
47+other horrors) with the competent cryptosuite B (Curve25519, Ed25519,
48+AES).
49+
50+Not only will this let star buyers collect their stars (they don't
51+need to, but it might be fun), but all planet owners will now claim
52+their new planets via the womb. If you have an old ticket, the womb
53+will convert it into a new invitation.
54+
55+We had planned to run the great renaming today, but about a week or so
56+ago we found ourselves reconsidering. This isn't because the new
57+crypto and `@p` code isn't ready -- it is (largely because it's the work
58+of Ray, `~raplys-lornex`). But...
59+
60+1: Anton needed a break and the womb is his code. For a piece of
61+critical infrastructure, it's also a little under-documented and
62+under-tested. Hoon as a typed language makes you lucky. Urbit is
63+still a testnet, but we're a little tired of relying on luck.
64+
65+2: Slipping the great renaming lets me (Curtis, `~tasfyn-partyv`)
66+resuscitate and integrate my rewrite of the `%ames` network module,
67+which was mostly completed and then put aside six months ago (so that
68+I could do things that didn't involve writing code). New `%ames` is
69+sorely needed, because right now there's a network bug that actually
70+sinks (permanently disables) ships, and we basically can't debug
71+anything in the area because we'd be debugging old code.
72+
73+People have also expressed some concern about the fact that `%ames` is
74+sending mysterious UDP messages which aren't documented in any way
75+(the whitepaper has some protocol description, but it's still not
76+quite comprehensive. Actually, `%ames` is a pretty clean system overall
77+and shouldn't be hard to turn into the kind of literate, stable Hoon
78+code the future should be made of. But again, documenting obsolete
79+code kind of sucks.
80+
81+Finally, we have an idea (half Anton's, half mine) about how to
82+actually end the unfortunate tradition of continuity breaches, by
83+providing a "rough start" model which lets you create a working ship
84+with just the private key. Needless to say, it would be very exciting
85+to actually stop rebooting the universe, permanently.
86+
87+So it's a pretty good fit to push the renaming and the new network
88+protocol out into a single Great Inception, which currently seems like
89+it should happen in early August. I certainly can't wait to pick my
90+new, permanent Urbit name! But as always, we ship no code before its
91+time. We will keep you up to date on our progress.
92+
93+## Other near-term goals
94+
95+The short-term focus remains self-hosting and onboarding. Ray is
96+currently working on building a simple message board on top of `tree`,
97+so that Urbit can be its own phpBB as well as its own IRC. Persistent
98+IRC (ie, `:talk`) is extremely useful, but we need long-form
99+discussion. Reddit is pretty good, but not _quite_ right -- and an
100+ounce of self-hosting is worth a pound of SaaS.
101+
102+Basically, we don't intend to work on user-level features that we
103+don't use ourselves for quite some time, if not ever. Self-hosting is
104+the path to maturity, always and everywhere.
105+
106+## Medium-term goals
107+
108+Our medium-term focus is expanding the attack surface of Urbit as an
109+open-source project in every possible way. We want to completely
110+dispel the aura of mystery.
111+
112+There are two general paths toward this: teaching and documentation.
113+On the teaching front, I think you'll like the new, super-easy Urbit
114+learning series I started [here](https://urbit.org/docs/byte). More
115+Urbytes are forthcoming.
116+
117+On the documentation front, Urbit has a large volume of basically
118+undocumented and undescribed code at the Hoon and Arvo levels. This
119+is incredibly shitty from the perspective of an open-source project,
120+especially because neither I nor anyone has the kind of obsessive
121+attachment to random details that you'd expect in an under-documented
122+system.
123+
124+We need the community to own the technical decisions in Hoon and Arvo.
125+Urbit can't be a real open-source project until we truly open this
126+attack surface.
127+
128+The right way to solve this, I think, is to "document into existence" --
129+producing design documents from the existing codebase, reviewing these
130+designs collectively, then converging the actual code with them. The
131+key areas to attack are Arvo itself and the vanes. The first area I
132+want to do this with is the new `%ames`.
133+
134+There is an excuse for not having done this already: premature
135+documentation is a serious evil. When you're figuring out how a
136+system should work at all, documenting it is counterproductive. But
137+Urbit is past this point. It needs to settle down and become a
138+grownup.
139+
140+## Contributors
141+
142+Many thanks to those who have been providing the fantastic stream of
143+PRs we have been getting. We've had great help on all parts of the
144+stack, from the front-end to the C interpreter to Arvo vanes.
145+
146+We'd love to help you get involved. Come join us on `:talk`!
147+
148+## Keep in touch / office hours
149+
150+`:talk` is always a great place to come and ask questions. Going
151+forward someone from Tlon will be available in `:talk` from 12PM - 3PM
152+PDT each weekday.
153+
154+[r/urbit](https://www.reddit.com/r/urbit) is also a good place for any
155+kind of discussion.
156+
157+For anything else you can always get in touch with us via
158+[`urbit@urbit.org`](mailto:urbit@urbit.org).
content/posts/2016-8-30-update.mdnew file+265
@@ -0,0 +1,265 @@
1++++
2+title = "~2016.8.30 Update"
3+date = 2016-08-30
4+author = "Curtis Yarvin"
5+description = "Here's August's monthly letter from Tlon, only slightly late."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's August's monthly letter from Tlon, only slightly late.
10+We've been doing a lot of planning and, unfortunately, a little
11+bit of research.
12+
13+We hope we're done with this research stuff. There is really nothing
14+more unpleasant than CS research. But the protocol and crypto state
15+(`%ames` and `%jael`) needed another round of basic architecture.
16+
17+## Infrastructure milestones
18+
19+By "infrastructure" we roughly mean everything in `/===/arvo,`
20+ie, the kernel and vanes.
21+
22+Infrastructure development in the presently foreseeable future is
23+a system of four milestones, the first of which we've hit. We
24+have a reasonably good start on the second:
25+
26+- *FI - First inception*: The first milestone (August 15) was "first inception"
27+ (FI), where we claimed our true and final urbits.
28+
29+- *CC - Continuity candidate*: The next milestone is a "continuity candidate"
30+ (CC), a release where it's at least possible that we'll need no further
31+ continuity breaches and/or reinstalls. CC requires a nontrivial amount of
32+ further engineering work.
33+
34+- *FC - Final continuity*: Sometime after that comes "final continuity" (FC),
35+ where we explicitly renounce continuity breaches. CC to FC is a testing
36+ milestone and is satisfied by collective judgment.
37+
38+- *SF - Security freeze*: The last milestone is "security freeze" (SF), where we
39+ declare the PKI final and issue live keys.
40+
41+## FI: first inception
42+
43+The outcome of the FI milestone was a working network, with
44+multiple federated stars and final `@p` names. (Modulo some
45+justified complaints about the `lut` suffix.) Federation
46+probably means we can invite a lot more people to Urbit and it'll
47+keep working, but let's still be a little cautious.
48+
49+The FI keys are not final, but the cryptosystem is (though there
50+may be still be bugs in our implementation).
51+
52+The Urbit network works and is an adequate, if still quite buggy,
53+social network, with two modes of social communication: chat and
54+long-form text with comments.
55+
56+People can learn to program in Hoon and even write `%gall` apps,
57+but the documentation is lacking and involves wide gaps, which
58+must be filled by reverse engineering or public assistance.
59+Fortunately the Tlon people are reputed to be quite helpful.
60+
61+At least one breach is certain. All data in your FI urbits will
62+be destroyed! In the breach to the CC release, we will port the
63+address allocation registry (the urbit.org womb) manually to the
64+new network.
65+
66+If you have been spawning planets from your stars, you'll need to
67+follow our procedures, which we'll post before the next breach.
68+Emergency breaches may also happen. We recommend against
69+spawning at the moment, but of course your star is yours.
70+
71+Data in FI urbits should also be considered completely insecure.
72+(In fact, the urbit process probably should be run in a VM if
73+there is any other important data on the machine, since we have
74+not done any real security analysis and network data is used.)
75+
76+## CC/FC: continuity
77+
78+The CC release at least attempts to maintain continuity. What is
79+continuity?
80+
81+Continuity is when we stop rebooting the universe. You can leave
82+a continuous urbit turned off on a USB key in your attic for 10
83+years. When you activate it on in 2026, it will probably spend
84+several days upgrading itself, but it will work.
85+
86+CC is just a candidate. FC is when we actually believe we've
87+achieved continuity.
88+
89+Here are some features we've lumped into the CC/FC bag. This
90+list may expand, but hopefully won't contract.
91+
92+Urbit is a reliable datastore. For instance, as a developer, you
93+should edit your source files in the Urbit filesystem `%clay`,
94+then back them up with `git` via a one-way mirror. (Most people
95+now edit outside Urbit and copy trees in.) Of course, `%gall`
96+application state you create in a FC urbit can and should also
97+last forever, via state adapters.
98+
99+Urbit has a reliable storage system that can use a cluster log
100+like Kafka, does not lose data even on Linux, encrypts the image
101+as well as the log, and allows log pruning.
102+
103+Urbit handles all crashes correctly on all platforms. A stack
104+overflow or interrupt always produces a usable trace.
105+
106+Urbit boots with the proper, beautiful, functional, boot sequence
107+defined in the whitepaper. It's single-homed -- designed to
108+operate one ship per kernel -- and uses the event security model
109+from the whitepaper.
110+
111+Urbit has a working end-to-end "permanent networking" message
112+system with in-order, exactly-once delivery and end-to-end acks,
113+and perfect causal consistency over the wire with no head-of-line
114+blocking between different ducts.
115+
116+Urbit no longer mixes cryptosystem code with networking code.
117+Secret storage moves into a separate `%jael` vane. `%jael` will
118+hold public, private and symmetric Urbit keys, foreign API keys,
119+tokens, passwords, etc; and other capabilities, like Urbit
120+invitations.
121+
122+Urbit has a communication recovery procedure so that a
123+brain-damaged ship can resume communication after it loses
124+information, even if all it knows is its own identity and key.
125+Only-once delivery is violated, but the onus for recovery is
126+placed on the damaged ship rather than its healthy neighbor.
127+
128+If a ship has a static IP, Urbit can serve a secure website
129+without proxying, either at its own urbit.org subdomain or at a
130+private domain.
131+
132+Urbit has have a FUSE-oriented filesystem interface to the
133+local OS, rather than using libuv filesystem monitoring.
134+
135+Urbit has a mark system that supports mark containers, and
136+handles mark evolution properly in both the network and the
137+filesystem.
138+
139+Urbit handles library versioning properly in `%ford`, never using
140+`=>` to load libraries, using aliases correctly to allow multiple
141+conflicting versions in a dependency graph.
142+
143+Urbit has a stable, extensible but backward-compatible I/O
144+protocol between Arvo and vere (the Unix process). Any future
145+Arvo will work on an old vere.
146+
147+Urbit uses Murmur32 rather than FNV as a short hash (mug).
148+
149+Urbit is still not a cryptographically secure system, and doesn't
150+allow true cryptographic ownership transfers. The cryptographic
151+transfer features exist, but using them is a bad idea until the
152+keys are final.
153+
154+(For right now, everyone who issues urbits to others needs to at
155+least track ownership centrally, ideally with a mirror database
156+outside Urbit. We could not stress this more stressfully!)
157+
158+Urbit has received a thorough performance and scaling audit, and
159+there are no trivial efficiency problems to solve.
160+
161+The Urbit console can output colored text and control a 2D ASCII
162+text array (curses style). The web console (not web dojo) works
163+with some keylag.
164+
165+All Urbit vanes are thoroughly documented/specified with an
166+overview document and inline comments.
167+
168+## SF: security freeze
169+
170+The SF release will render Urbit a "live" cryptographic system.
171+It is unnecessary to point out that all subsystems in the
172+security chain must be audited, and operational procedures for
173+stars and galaxies need to be standardized.
174+
175+(Yes, the SF release needs to invalidate the current
176+cryptographic structure, even if it hasn't been compromised.
177+Since it's not secure, we don't know it hasn't been compromised.)
178+
179+However, the SF release keys will be instantiated via network
180+update, which is essentially "god mode." New keys will be
181+distributed to old key holders, and any disparities between
182+cryptographic and centralized ownership records will be resolved
183+in favor of the latter. Before SF, no one can gain anything by
184+stealing a key or transferring it without authorization.
185+
186+A software update can of course do anything to the PKI. After
187+SF, at least, global Arvo updates (which ideally can become rarer
188+and rarer) will need to be approved through a constitutional,
189+republican governance process.
190+
191+After the SF release, we have no control over cryptographic
192+transfers, but the Arvo code itself may penalize long wills to
193+minimize velocity and keep Urbit from acting as a currency.
194+(This is essentially a Tobin tax.)
195+
196+The SF release needs to run the actual Arvo interpreter, with
197+jets, in a completely sandboxed subprocess with no I/O privilege.
198+Sandboxing jets, or even a safe jet language, should also be
199+investigated. Network jet update must also be possible.
200+
201+An SF urbit can issue and manage children without any problem.
202+It can be hosted easily in a commercial data centre. The
203+interpreter can migrate images securely, automatically and
204+efficiently to a different hosting service.
205+
206+An SF urbit will have a framework for DoS defence, blocking and
207+banning, and other nuisances of the modern world. There will be
208+at least the beginning of a global reputation system.
209+
210+## CC: work overview
211+
212+The one subsystem that needs a complete rewrite is `%ames` (the
213+network). The `%jael` vane is completely new. Fortunately, the
214+new `%ames` vane compiles, and the `%jael` interface is defined
215+(and not that `%jael` can be complicated).
216+
217+The mug replacement work is also done, but needs to be debugged
218+(which is no easy task).
219+
220+Applying the canonical boot event system sounds like a giant
221+change, but it's actually pretty straightforward -- same for
222+single-homing. Arvo proper is only a few hundred lines of Hoon.
223+
224+The event system in `vere` needs to be replaced, but we have a
225+module built by a contractor with both the local FS and Kafka.
226+
227+All the vanes besides `%ames` need documentation and a general
228+tuneup, but this should not rise to the level of a rewrite for
229+any other vane.
230+
231+## Community involvement
232+
233+Urbit's most serious problem right now is that many more people
234+are interested in it than are actually working on it. This
235+reflects its heritage as a basement project.
236+
237+Our most important work item remains opening up the codebase so
238+that community development can happen. We'll start turning the
239+CC tasks into community operations as fast as possible.
240+
241+But this is a separate topic. It fits under a discussion of
242+Tlon's corporate plans and operations, which we'll post later.
243+
244+## Contributors
245+
246+The contributors have been amazing. We need to make more use of
247+their talents, which are growing daily. And we need to do a
248+better job of chronicling their deeds! But for now, github
249+remembers.
250+
251+## Keep in touch / office hours
252+
253+`:talk` is always a great place to come and ask questions. Going
254+forward someone from Tlon will be available in `:talk` from 12PM - 3PM
255+PDT each weekday.
256+
257+Post to our [new forum](https://urbit.org/fora)! Especially [this
258+thread](https://urbit.org/fora/posts/~2016.8.30..18.05.18..8ba3~/) to
259+discuss this very post. Don't be afraid, the water's fine! Actually there
260+are a few glitches, but it's hosted on Urbit (and also backed up).
261+For the less daring, [r/urbit](https://www.reddit.com/r/urbit) is a
262+reliable old standby.
263+
264+For anything else you can always get in touch with us via
265+[`urbit@urbit.org`](mailto:urbit@urbit.org).
content/posts/2017-1-30-update.mdnew file+342
@@ -0,0 +1,342 @@
1++++
2+title = "~2017.1.30 Update"
3+date = 2017-01-30
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "In 2017, we're ready to start making the damn thing useful."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+> TLDR: a real Urbit is an Urbit that does real work. This means nontrivial
10+ progress in two areas: systems maturity and user experience. In 2H 2016 we
11+ cleaned out most of the worst holes in Arvo and vere, and totally reconceived the
12+ user experience. The new Urbit feels like an MVP and we can't wait to ship it.
13+
14+In 2013 Urbit was intriguing. By 2015 it had become interesting. In 2016 it was
15+actually exciting (if not always in a good way!). In 2017, we're actually
16+planning to make the darn thing useful. (For certain values of the word "useful.")
17+
18+Our `cc-release` stability upgrade (mainly affecting the OS layer `arvo` and the
19+interpreter `vere`) is roughly code-complete and being tested into existence.
20+Once it exists and is stable, it can actually be documented -- often, for the
21+first time.
22+
23+And `cc-release` is our first release really designed so that neither your ship,
24+nor the whole network, can actually sink. The Urbit network had zero unplanned,
25+and one planned, breach (network flag day) in 2H 2016. The last planned breach,
26+the `cc-release` update, is planned for 1H 2017.
27+
28+With the infrastructure converging, we can finally think seriously about the user
29+experience of Urbit. What we're imagining is a small-scale social network and
30+command-line API aggregator. It's just screenshots right now, but we're confident
31+that we can build it and make it work.
32+
33+System software is boring (at least when done right). So let's start with the user
34+experience.
35+
36+## Design
37+
38+Galen Wolfe-Pauly is Tlon's CEO and Urbit's interaction designer. Galen went to
39+architecture school. He talks like it. We recorded him secretly and came away
40+with these notes:
41+
42+![](https://media.urbit.org/site/sketch-1.png)
43+
44+- _UX_? As a kid it was just _design_ or maybe _web design_. At some point I
45+ remember people talking about _user interface_ or _UI_. But I truly don't
46+ understand where the _X_ came from. It's like Monster Energy got involved in
47+ the branding.
48+
49+- An _experience_ sounds like the kind of thing that's going to be littered
50+ with ads, or is going to manipulate me in some way. Something I passively
51+ consume. Not something I actively control. So I prefer _interface_ to
52+ _experience_, and I think you should too.
53+
54+![](https://media.urbit.org/site/sketch-2.png)
55+
56+- Urbit has to be just as usable as any widely used app in 2017. For a personal
57+ server, the usability bar can't be Unix. A Unix server is an industrial tool.
58+ An industrial tool can't be a consumer product. You can attach a blade to the
59+ end of a drill and use it as a blender, but it's not a Vitamix.
60+
61+- What is an app, anyway? It's _shared computing_. Everyone's data is one data
62+ structure, in one program, on one server, owned by one corporation. With _one_
63+ UI for everyone to do _one_ thing.
64+
65+- But there isn't one big corporation that writes _all_ the code. Everyone's
66+ lives are spread across a bunch of different apps. Every app solves the
67+ ownership problem separately.
68+
69+- So the whole user experience of using Web apps involves tracking all these
70+ silly little accounts, learning each and every user experience, and glaring
71+ helplessly at each little piece of data trapped in a different silo.
72+
73+- Even your Google account doesn't feel like one thing. Whatever your Google
74+ Docs are, it's not a bunch of document files on your Google Drive. All the
75+ resources of Google can't make their Borg backend feel like one computer which
76+ belongs to you.
77+
78+- The phrase 'general-purpose computing' sounds scary, but it shouldn't be.
79+ 'Computing' doesn't mean writing code. We're computing when we browse
80+ Facebook or talk to Alexa.
81+
82+- Your personal server will be solving the same problems today's whole ecosystem
83+ of network apps solves, just all in one place that belongs to you.
84+
85+- The closest thing to a general-purpose personal server today is probably the
86+ Chinese service WeChat. If you don't know much about WeChat, you should
87+ really watch [this NYT video](https://www.nytimes.com/video/technology/100000004574648/china-internet-wechat.html).
88+
89+- From a distance WeChat is great. Everyone in China loves the one-app,
90+ one-identity, all-my-own-stuff user experience. It's clearly better than
91+ being forced to switch apps constantly.
92+
93+- But WeChat is just another giant shared-computing service. It's made out of
94+ the usual 2010s server stack mess. The visual and interaction design looks
95+ pretty dated. WeChat tells us that users want one experience, but not much more than that.
96+
97+![](https://media.urbit.org/site/sketch-3.png)
98+
99+- To paraphrase Walter Sobchak: say what you want about the tenets of shared
100+ computing, but at least it's an ethos. We know how to build very good
101+ special-purpose user experiences. What's the conventional UI for a
102+ general-purpose personal server? It doesn't exist.
103+
104+- For most users, your urbit runs in a data center (like a web app). You log
105+ into it with your browser (like a web app). Other than that, where do you
106+ even start? A `bash` prompt isn't what we're looking for.
107+
108+- But wait, is the idea of a command line bad UI? Or is the Unix command line
109+ just bad UI? We know ordinary people can use command lines. They use
110+ chatbots. Long ago, they used MS-DOS.
111+
112+- Today's computing user experiences, the PC and its mobile cousin, rejected the
113+ command line. This made computing easy enough, at the cost of hiding much of
114+ its creative power.
115+
116+- The power of a general-purpose server which can command not only local
117+ applications, but also network services, is at a whole new level. We don't
118+ think any visual metaphor or 2D control panel can do it justice.
119+
120+- We need to bring the full power of the machine to the user, without breaking
121+ their trust that the machine is on their side. We can't let the user get lost
122+ or break the system. It has to feel safe and simple to explore its furthest
123+ reaches.
124+
125+![](https://media.urbit.org/site/sketch-4.png)
126+
127+- As Neal Stephenson [tells us](http://cristal.inria.fr/~weis/info/commandline.html),
128+ the command line is the natural UI for any computer. It's especially the
129+ natural UI for a _network_ computer, like a personal server. A command line
130+ scales way better than a GUI to a large selection of actions. And a network
131+ computer can do almost infinitely many things.
132+
133+- When we've tried to put a simplified "for dummies" GUI on top of Urbit, it's
134+ just awful. It's like a bad Linux desktop GUI. You feel instantly that
135+ you've got a choice between something limited and lame, and something
136+ mysterious and scary. So we threw those designs out, in search of something
137+ better.
138+
139+- The true command line is generally thought of as something mysterious and
140+ scary. Somewhere that you can do things to irreparably damage your computer.
141+ It's powerful, but also dangerous.
142+
143+- This tradeoff — between control and safety — is false. The unfriendly command
144+ line is actually just another artifact of 70s computing. The UI of the
145+ command line is designed for a programmer, not an ordinary person.
146+
147+- `bash` is a bad UI because there's no easy way to control its power, or learn
148+ all the things it can do, or separate its power to do dangerous things from
149+ its power to do safe ones.
150+
151+- At the other end of the spectrum is the chatbot, which is a bad UI because
152+ it's hard to make it much more than a toy. Like so many innovations, chatbots
153+ happened by accident. It's just a way to connect an input string to network
154+ services. But the natural-language metaphor of "chat" is confining. It
155+ doesn't scale well to any problem that isn't trivial.
156+
157+- What does a great command line look like? It should have a strict syntax, not
158+ try to guess what you mean. But it can't be a constant test of your ability
159+ to memorize the phonebook.
160+
161+![](https://media.urbit.org/site/sketch-6.png)
162+
163+- Urbit already has the beginnings of a great command line. We parse your input
164+ with an actual grammar and catch errors as you type. You can't even press
165+ return on an invalid command.
166+
167+- What's missing is help. A great command line needs to reach out and hug you
168+ in every way it can. It needs to assume you don't know anything at all about
169+ the system. It's there for you to solve your problems, but also to help you explore.
170+
171+- There's actually one exotic Unix shell that does it right:
172+ [`fish`](https://en.wikipedia.org/wiki/Friendly_interactive_shell). `fish`
173+ jumps through some pretty amazing hoops, like parsing manpages, to give you
174+ context and completion.
175+
176+- It's a lot easier for Urbit because we're designing the system from scratch.
177+ From a technical standpoint, all we have to do is add contextual help to our
178+ existing parser framework. An extended rule can parse a string, or tell the
179+ user what it wants to parse. In simple terms: we have to make the `:dojo`
180+ (our shell) much friendlier.
181+
182+- The `:dojo` shell is built around the concept of a _generator_, a program that
183+ builds a noun. The idea is that how you build the noun is orthogonal to what
184+ you do with it. You could print it, send it as a command, etc. There are
185+ several kinds of generators -- simple scripts, prompting dialogs, HTTP
186+ scrapers, etc.
187+
188+- A generator is initialized with command-line arguments and options, in the
189+ classic Unix style (except typed). In the classic Unix style, Urbit at
190+ present provides no help at all in constructing a command line. You just have
191+ to know.
192+
193+- How should it actually work? Let's say you're trying to put Urbit in control
194+ of your Twitter feed. That means you're creating a Twitter gateway on Urbit,
195+ which you can control with a `|twitter` command.
196+
197+- Before you type a character, Urbit offers you `|` (any command with side
198+ effects). (You could also add a `!` prefix, which is like `sudo` -- it lets
199+ you do something dangerous.) Once you type `|`, you can page through a list
200+ of commands. Once you type `|t`, that list is much shorter. Once it can tab
201+ complete to `|twitter`, it prompts you with that.
202+
203+- And once you get to `|twitter`, you're in a "meta-generator" that's helping
204+ you build the correct command line. At least in a browser, you'll be stepping
205+ through a form with rich entry. But the command line will show you the text
206+ of the command you're building, so next time you can just type it.
207+
208+- Building a command is just a case of data entry. In a command-line world,
209+ data entry is always serial. You answer questions serially, one at a time.
210+ The only navigation is forward and back.
211+
212+- A great Urbit console also has to be accessible both from a browser and a Unix
213+ terminal. That means a prompt needs to tell the console if it could be a
214+ radio button, even though a terminal can't have a radio button. We'll improve
215+ the interactivity of our terminal a little, but we're not rewriting Lynx.
216+
217+- So, what do you do with this fancy command line? Command everything -- from
218+ your urbit to the world. Installing an app is a command. Publishing a tweet
219+ is a command. Paying someone in bitcoin is a command.
220+
221+- Your urbit can show you all the things you can do, and help you do them. If
222+ there's something you'd like it to do, build it!
223+
224+- A great command line alone is not all that Urbit needs. But it feels like the
225+ right central paradigm for interacting with your Urbit. We'll get into the
226+ specifics in a future post.
227+
228+![](https://media.urbit.org/site/sketch-5.png)
229+
230+## Infrastructure: stability, maturity, performance, documentation:
231+
232+We dragged Curtis, whose hide has turned completely white like a cave fish, from
233+his coding hole to stammer out this update:
234+
235+We're actually doing pretty well on the infar. Despite there being all kinds of
236+unacceptably broken things about Urbit 2016, the network has actually stayed up
237+since August, and we haven't had an unintentional continuity breach since June.
238+
239+Of course, it helps that we don't ask anyone to _use_ Urbit in earnest. And ships
240+still do sink. Since an urbit is an identity, sinking your planet is a horrendous
241+experience. You'll never bond with your second planet the way you did with your
242+first -- never mind any _data_ you may have lost.
243+
244+Our upcoming `cc-release` is the last planned breaching release. With certain
245+exceptions discussed below, all major parts are now (January 2017) code complete
246+or better.
247+
248+This includes the rewritten network stack (`%ames`), code complete but untested;
249+the new secret vault and promise tracker (`%jael`), mostly tested; and the new
250+`u3_pier` event execution framework, with worker processes and real two-phase
251+commit, smoke-tested. We've also completely restructured `hoon.hoon` and
252+`zuse.hoon`, which now are at least cosmetically acceptable.
253+
254+This is not to say that the `cc-release` Urbit won't in many ways embarrass us as
255+engineers. It will. But your ships won't randomly sink, your secrets won't
256+randomly leak, and your datas won't randomly rot. Or if they do, it's an
257+implementation bug, not a design flaw.
258+
259+There are still a few cracks we need to fill in. The main one: some top-level
260+adjustments to the Arvo event system. The boot sequence now executes correctly,
261+but the actual boot events need to be totally refactored, as does the rather
262+critical Unix-Arvo interface. The long-promised security mask and voltage flags
263+need to be added, and vanes adjusted to use them. Causal tracking of execution
264+crashes needs to actually work. At the user level, `:talk` needs to be split into
265+a user agent and a daemon, and the user-level `%kiln`, the "systemd of Urbit,"
266+needs a rethink to make upgrade logic state-triggered, not edge-triggered.
267+
268+The console and the dojo need some work to make our user experience real. One way
269+to view a high-usability command line is that a command, if you don't have the
270+esoteric knowledge to fill it in by just typing the syntax, is essentially a
271+form. This form needs to work both in the browser and the terminal, which isn't
272+trivial. Browser and terminal both need a simple multiscreen navigation model,
273+which we don't have yet.
274+
275+There's also a bunch of Unix-level work to do, mainly in converting the old
276+"single-player mode" console-bound Urbit into a real system service. Urbit works
277+better as a daemon which runs one or more worker processes, and talks to client
278+consoles over a Unix socket. A real architecture actually makes it practical for
279+star owners to host the planets they issue, for example.
280+
281+Finally, because we never forget the wisdom of the sages, our last act before
282+asking people to use Urbit will be the long awaited performance crusade. The new
283+event system now at least releases outgoing events before the input queue is
284+clear! You never know what optimization will achieve before you make a serious
285+effort, but I don't see any reason we can't carve out a new empire of speed in the
286+savage, uncharted east.
287+
288+We haven't touched the documentation since the first half of 2016. As always,
289+maturity has to come before documentation. Premature documentation is almost as
290+dangerous as premature optimization.
291+
292+## Notable contributions
293+
294+Some notable contributions of late:
295+
296+- `~ponnys-podfer` wrote a MUD
297+- `~palfun-foslup` created a surprisingly capable talkbot
298+- `~master-morzod` reworked the console in both the Hoon and C layers, adding color and cleaning up a bunch of stuff.
299+
300+Anyone who contributes at this point deserves extreme praise for the ability to
301+work in an immature, often broken system. We look forward to being ready for
302+normal programmers who aren't intrepid jungle explorers.
303+
304+## Next crowdsale
305+
306+We'll do another crowdsale in the spring. We understand that the last sale left a
307+lot of people unable to participate — and our first priority is making sure those
308+who are excited about Urbit can own some real estate. We'll announce our plans on
309+how this might happen soon. If you're interested, make sure you're on our mailing
310+list.
311+
312+## Contribution prizes
313+
314+We're still thinking about the right way to award Urbit real estate to outside
315+contributors. Especially after the crowdsale, it really has to feel 100% fair.
316+But it can't be in any way, whether legally or emotionally, a form of compensation.
317+We can't afford to kill the fun.
318+
319+It doesn't feel right to do this at all when the documentation is completely
320+inadequate, because it's not fair to people who don't have the time to reverse
321+engineer. But we're thinking hard about this issue.
322+
323+## Future updates
324+
325+We know you love these opinionated, literary state-of-the-urbit updates. We love
326+writing them. But we obsess over them too long and they take too long to write.
327+Urbit's ultimate success depends almost entirely on the code.
328+
329+Going forward we're going to switch to commit-message style updates on a monthly
330+basis, with longer updates arriving sporadically. Maker DAO does a great job of
331+these shorter updates
332+([here](https://blog.makerdao.com/2016/12/14/maker-update-925/) is an example).
333+
334+If you're ever curious to check in or hear what's going on, don't hesitate to get
335+in touch. You can always chat with us on
336+[urbit.org/stream](https://urbit.org/stream), or by booting your own Urbit.
337+[Twitter](https://twitter.com/urbit) or email
338+([urbit@urbit.org](mailto:urbit@urbit.org)) are also perfectly fine.
339+
340+There's also [our forum](https://urbit.org/fora/) that anyone can post to. We've
341+created [this thread](http://urbit.org/fora/posts/~2017.2.1..22.36.47..9f54~/) to
342+discuss this post.
content/posts/2017-10-7-update.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "~2017.10.17 Update"
3+date = 2017-10-17
4+author = "tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2017.10.17."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+`~master-morzod` joins Mars Talks to talk about the Urbit operating system. The core team and contributors talk about how to best teach Urbit. Ted explains Hoon casting and does a full expansion of the Nock macros to draw a better connection between Hoon and Nock.
10+
11+- [Mars Talks, Ep. 2](https://www.youtube.com/watch?v=kh4Ai5YXFaA) hosted by `~taglux-nidsep` with guest `~master-morzod` on Arvo, the Urbit operating system. [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.5..03.57.51..f4c0~/)
12+- [The Absolute State of the Urbit Docs](https://github.com/urbit/docs/issues/137#issuecomment-333444336), a conversation on Github between `~taglux-nidsep`, `~sorreg-namtyv`, `~rovnys-ricfer` and `~master-bottec`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.3..03.04.45..b532~/)
13+- [`~rovnys-ricfer` on Hoon casting](https://github.com/urbit/docs/pull/201#issuecomment-333546648). [Discussion on Fora](https://urbit.org/fora/posts/~2017.10.3..01.53.05..07b3~/)
14+- [Nock macro expansion: A clear explanation that anyone can understand](https://urbit.org/fora/posts/~2017.10.6..23.50.35..fb74~/) by `~rovnys-ricfer`
content/posts/2017-11-14-update.mdnew file+215
@@ -0,0 +1,215 @@
1++++
2+title = "~2017.11.14 Update"
3+date = 2017-11-14
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "As usual, we're guilty of wanting to write code more than prose."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+As usual, we're guilty of wanting to write code more than prose. Last time we
10+announced our plans for Ethereum integration. This month we'll stick to basic
11+project status:
12+
13+## Fall release goals and status
14+
15+*Curtis, Ted, Paul*
16+
17+Sometime in the next few weeks, we'll ship the Hoon 143 / Vere 0.5 release.
18+This release will of course be a continuity breach. The mighty engine is still
19+running in the lab while we screw on the last bells and make sure the boiler
20+isn't leaking oil, steam or memory. Currently, Curtis is fighting memory leaks
21+while Ted and Paul make sure the memoization cache can actually get reclaimed.
22+
23+We want this fall 2017 Urbit testnet release to be reasonably rugged across the
24+board. It is not a production network and its keys remain test keys. However,
25+it should not crash, sink, etc.
26+
27+This is new. For previous releases, it wasn't a realistic goal to keep ships
28+from sinking, or salvage every pier. It's just incredibly disruptive and
29+unpleasant in a pseudonymous network to sink people's identities. In this era,
30+if your ship sinks, please (a) post an incident report to the Urbit fora; (b)
31+know that we will strain every fiber to help you wrest it from Poseidon's grim
32+grip.
33+
34+Furthermore, although there will be no direct formal continuity between this
35+release and the next one, we will provide tools to directly convert any data
36+in your urbit. So, in case you actually do put meaningful datas in your urbit,
37+you won't have to convert your datas completely by hand. Again, we will do
38+everything to help.
39+
40+## Hoon 143
41+
42+*Curtis, Iceman, Ted, Anton, Mark*
43+
44+Curtis has spent most of 2017 quasi-surreptitiously in "auteur mode," trying to
45+complete his initial authorship of Hoon. After this release he promises to work
46+only on Arvo and above.
47+
48+Hoon 143 is not perfect, but it will do for a while. Nothing in Hoon 143 is so
49+bad it's embarrassing. No one has any need to wait for it to stabilize. Any
50+errors in the above must be fixed by Hoon 142.
51+
52+Hoon 143 establishes a set of standards and conventions which define modern,
53+high-quality code. Most of the Urbit codebase isn't quite to this standard.
54+Changing this includes removing the use of deprecated language features, then
55+removing support for the deprecated features (to create Hoon 142). Someone
56+should definitely do this work.
57+
58+Here are some of the things Curtis has done to Hoon, without asking anyone's
59+permission. (Did Godard ask permission?) On some of these things he had fellow
60+conspirators -- Iceman was an equal contributor on the decorators, the team of
61+Ted, Anton and Mark on Udon.
62+
63+Big changes in Hoon 143:
64+
65+- Hoon 151's "electroplating," which replaced Hoon 164's "vulcanization,"
66+ has been replaced by 143's "repainting." This means wet gate namespacing
67+ works, so you can write `(weld ~[1 2] ~[3 4])` and get `~[1 2 3 4]` instead of
68+ `error: %mull-bonk-b`.
69+- There's now only one wide syntax `{a/term b/term}` becomes `[a=term b=term]`.
70+ This is like Hoon 164 syntax, but without the ubiquitous, and horrible, prefix
71+ comma. The price is modes.
72+- Decorators: formal syntax for adding documentation to types, available at
73+ runtime for reflexive help and diagnosis.
74+- In addition to the Sail dynamic XML syntax (which everyone forgets about, and
75+ which is basically JSX in Hoon), Hoon now has an embedded, Markdown-flavored
76+ rich text language: Udon. Few dynamic document platforms have this kind of
77+ range -- one file, with everything from code to tree-structured data to styled text.
78+- Keywords, which everyone despised, have been fully eradicated.
79+
80+Curtis is done with Hoon and will never again change or improve it.
81+He may offer occasional opinions. Ted and Iceman are the new maintainers of
82+Hoon (including all of hoon.hoon and zuse.hoon, excluding Arvo models).
83+Anything all they agree on is probably good.
84+
85+
86+## What's not in this release
87+
88+*Curtis*
89+
90+2017 was also the year we learned the lesson that, while Urbit is awesome and
91+makes many system-software problems trivial, it is not so awesome that a team
92+this small can advance two branches at once. This fall 2017 release is a
93+classic, Microsoft-style stick save, cutting off about half of the research
94+("master" or "cc-release") branch and merging it back with splints and bandaids.
95+
96+What got cut (this work is mostly coded, but not fully tested / integrated):
97+
98+- The all-new event system in Vere, the all-new Arvo kernel with correct whitepaper-style lifecycle function
99+- The all-new (not just repaired) Ames (network) vane
100+- Ted and Anton's the mostly-rewritten Ford (build) vane
101+- Mark's rewritten Talk app (now Hall)
102+- The all-new Jael authentication vane
103+- The new generalized console library
104+
105+There is plenty of other stuff that needs to go into our next release. Some of
106+it is described below.
107+
108+
109+## SPA rendering and build system
110+
111+*Ted and Anton*
112+
113+Ever notice how urbit.org gives 504 errors far too much? Hell, it probably
114+504-ed when you tried to load this page. This is clearly a problem.
115+
116+Perhaps we could hack our way around it — but, as usual, we prefer to get to the
117+root of the problem. When you request a webpage from an Urbit we use our build
118+system, Ford, to produce it. Then our single-page app, Tree, renders and builds
119+the page in the browser.
120+
121+There are two problems with the current system:
122+
123+The Ford cache is cleared every time something in Clay changes.
124+
125+On the client side, pages are built through multiple requests.
126+
127+To fix (2) we want to move to a system where each page is a single static build.
128+This means doing 'server side rendering' with Ford — rather than having the
129+client make multiple requests for every page component.
130+
131+The basic parts of this are done. We implemented a subset of markdown in Hoon
132+and added some new runes to Ford. This means you can write files that include
133+other files without any JSX or client side craziness.
134+
135+(1) is a bit more complicated, and has taken up quite a bit of Anton and Ted's
136+time. We've implemented a new cache algorithm, which is designed to promote
137+unchanged content across revisions. The algorithm seems correct, but doesn't
138+properly promote unchanged content in all cases.
139+
140+With these two things actually completed we'll be able to get much snappier page
141+loads. The next step is properly terminating SSL at an individual ship — but
142+more on that next month.
143+
144+The details of this project are outlined in UP1 - Ford Caching Redux:
145+[fora/posts/~2017.10.19..04.47.50..c107~/](https://urbit.org/fora/posts/~2017.10.19..04.47.50..c107~/).
146+More on UPs below.
147+
148+## New primer
149+
150+*Isaac, Galen and Jimmy*
151+
152+One thing we still don't do a particularly good job of is communicating about
153+what Urbit is. Even to savvy tech and crypto folks.
154+
155+We're working on a new, illustrated, single-page explanation to go up on
156+urbit.org. The text is coming together and we're starting to work on design.
157+
158+## Nock tutorials
159+
160+*Josh and Galen*
161+
162+Josh is a PhD student who has a lot more teaching experience than we do. To
163+boot, he's convinced that Nock is incredibly simple and can be taught to just
164+about anyone. So, he put together a few video tutorials.
165+
166+We're touching up the look and feel — but they should go up in the next week or
167+so.
168+
169+## ETH contracts
170+
171+*Mark and Curtis*
172+
173+Working from Curtis' designs, Mark has helped us implement the Urbit
174+constitution as a set of ETH contracts. They're off to the auditors, but the
175+code lives here: [github.com/urbit/constitution](https://github.com/urbit/constitution)
176+for public scrutiny.
177+
178+## MyEtherWallet
179+
180+*Anthony and Galen*
181+
182+We want to make interacting with the Urbit ETH contracts as easy as possible.
183+Especially for people who aren't necessarily particularly familiar with
184+interacting with dApps.
185+
186+So, we designed an Urbit-specific frontend for MyEtherWallet. And Anthony, who
187+actually knows Angular, has been helping us implement it. He has been working
188+privately, but progress will be visible here:
189+[github.com/urbit/etherwallet](https://github.com/urbit/etherwallet) soon.
190+
191+## UPs
192+
193+*Keaton, Ted and Galen*
194+
195+About a month ago we were discussing how we'd really like to be more transparent
196+about the projects we undertake. And, we'd really like to have a way of
197+cataloging projects we discuss but can't take on.
198+
199+Enter the UP or 'Urbit Proposal'. UP0 gives an outline for what a UP should
200+contain:
201+[fora/posts/~2017.10.19..03.45.26..dbec~/](https://urbit.org/fora/posts/~2017.10.19..03.45.26..dbec~/).
202+
203+## Jaque, an independent interpreter in Java
204+
205+*Paul*
206+
207+Paul is delighted to announce Jaque, an independent implementation of Urbit
208+using Graal/Truffle on the JVM.
209+
210+Jaque is not just another Nock function -- it boots an actual Urbit pill to a
211+working dojo prompt. Jaque has no compiler jets and has exposed several jet
212+mismatches in Vere. It works and is reportedly quite snappy. Paul is still
213+tuning the interpreter, changing it from a tree interpreter to a small bytecode,
214+because Graal does not like big stacks and tree interpreters make big stacks.
215+He'll say more about it when he considers it done, which is not yet.
content/posts/2017-12-16-update.mdnew file+26
@@ -0,0 +1,26 @@
1++++
2+title = "~2017.12.16 Update"
3+date = 2017-12-16
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2017.12.16."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Greetings, intrepid Martians. Thanks for bearing with us these past couple weeks as we pushed through the breach into a new continuity era. It's been a bit of a bumpy ride, but the turbulence is finally beginning to calm down.
10+
11+Last Thursday night, we performed the continuity breach, bringing with it some deep changes to the Hoon language, a parser for a new markup language for web publishing, and an entirely new `:talk` app. Those changes had been in the works since the beginning of the summer, and we spent the past month or so preparing the breach itself. We pushed the breach out knowing there would likely be some bugs, with the explicit intent of using the deployment to find and fix those bugs as soon as possible.
12+
13+Here's what's been going on since the breach:
14+- Urbit is somewhat slower than it was -- Galen may have exaggerated when he said it's 300x slower, but it is noticeable. *Curtis* `~sorreg-namtyv` is working on fixing a major performance issue in the Nock output of the Hoon compiler involving constants not getting folded at compile-time. I assure you, no one is more upset about Urbit being slow than the people who work on it all day long ... we'll fix it.
15+- New `:talk` is working, more or less. There are a few bugs that we're still working on, including some fixes for urbit.org/stream, which is currently down. *Mark* `~palfun-foslup` has been putting out fires like crazy, and due to his efforts, with some help from *Ted* `~rovnys-ricfer` and *Anton* `~pittyp-datfyn`, new `:talk` is getting under control.
16+- *Keaton* `~tonlur-sarret` has updated the docs for new Hoon, and also improved the links and organization. *Joshua* `~taglux-nidsep` has also made some docs improvements.
17+- *Isaac* `~davtyr-nimren` is progressing on server-side rendering for web publishing, using the new `udon` markup language. Latest code (still a work in progress) can be found [here](https://github.com/ixv/arvo/tree/153ae2e35e77c7453601f84f956be3fe4509c104/ren/tree).
18+- *Ted* has started working on designing a system to run automated stress tests of a fleet of Urbits, sort of like a DIY botnet. This should help us hit more bugs *before* pushing code to the live network, many of which only appeared at "web scale."
19+- *Anthony* `~poldec-tonteg` now has a working alpha of an [Urbit fork of myetherwallet](https://github.com/urbit/etherwallet) (design by *Galen*), with usage instructions. We haven't gone live on Ethereum yet, but you can still check this out to see a glimpse of the future.
20+- *Galen* `~ravmel-ropdyl` and *Jimmy* have been working on an Urbit primer to help explain whatever it is we do here.
21+
22+There have also been two Mars Talk episodes since our last update:
23+[What is Urbit? Panel Discussion](https://www.youtube.com/watch?v=hqACJVSJc5s&t=3703s)
24+[Learning about Clay, Urbit's Filesystem](https://www.youtube.com/watch?v=aJqNmUMYHHg)
25+
26+We're holding a [meetup](https://www.meetup.com/urbit-sf/events/245925902/) at our office next week. No presentations this time, just a party.
content/posts/2017-12-2-update.mdnew file+74
@@ -0,0 +1,74 @@
1++++
2+title = "~2017.12.2 Update"
3+date = 2017-12-02
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2017.12.2."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+This week Tlon has mostly focused on testing the upcoming continuity breach. We also fixed some compiler problems, made
10+progress on restructuring web publishing to use server-side rendering, and have started working on closing some of arvo's
11+oldest open pull requests. From the community, we're excited to report that `~master-morzod` has an initial
12+implementation of SSL termination in vere.
13+
14+*Ted* `~rovnys-ricfer` has been working on the [urbit fleet
15+repo](https://github.com/urbit/fleet/tree/e20400315bbea2091579b7beaa36eb50bbbd2796), which we use for spawning testnets.
16+The repo now works with the new `urbit` command-line arguments that are part of the breach, and it's now at the point
17+where we can launch ships from galaxies all the way down to comets. We've been using it to test various aspects of
18+Urbit's multi-ship functionality, such as `:talk` and filesystem syncing. Turns out there is a bug with filesystem
19+syncing in master, so we're going to have to fix that before breaching.
20+
21+*Anton* `~pittyp-datfyn` has knocked out a bunch of items in our breach checklist. Some highlights:
22+- Fixed single-sign-on
23+- Cleaned up a bunch of old unused code
24+- Reorganized `:hood` libraries
25+- Lots of testing
26+
27+*Keaton* `~tonlur-sarret` has been working with Anton on the breach checklist. He also updated the docs and examples to
28+reflect the changes made in hoon `%143` (which will be deployed with the breach) and helped Ted debug some urbit/fleet
29+problems.
30+
31+*Curtis* `~sorreg-namtyv` has made a number of improvements to hoon's defaulting system (bunting). Part of the work
32+included fixing an inconsistency in how hoon determined which subtype of a fork type would be chosen as default. After
33+fixing that, he implemented a cache for those defaults, which improved compilation speed by 10-20%. This code has been
34+merged into Arvo's master branch. He's still working on a parallel defaulting system, which might go even faster.
35+
36+*Galen* `~ravmel-ropdyl` and Jimmy have been working on the new urbit.org homepage, which will be Tlon's next priority
37+after the breach. This will feature a complete redesign using a new base.css to provide a standardized look and feel for
38+the Urbit web experience.
39+
40+*Mark* `~palfun-foslup` / `~palnup-salwyx-mortyl-silfyl--digrel-pitbud-dorsym-livpyl` has been working with
41+~poldec-tonteg to troubleshoot some issues with Urbit's Ethereum constitution. He's still waiting for the rest of Tlon to
42+test his [monumental PR](https://github.com/urbit/arvo/pull/452) for new talk, which he submitted a couple weeks ago. Now
43+that we have the fleet repo working, we can use it to test this work more thoroughly. This week he also made some changes
44+to Hall, which he has expressed in haiku form:
45+
46+> the hall has opened,
47+ circles form to admire,
48+ people's collections.
49+
50+He also says:
51+
52+> Or if you want something slightly more serious:
53+ Hall has received some more fixes and quality of life improvements since I opened the PR. It's > never been more ready
54+ for the breach! I'm already working on something interesting that uses > it: an interface for managing your own notes,
55+ blogs and foras. Complete with filesystem, storage, and hall notifications!
56+
57+*Joe* `~master-morzod` has written an implementation of SSL termination in vere. This will allow your Urbit to serve true
58+end-to-end-encrypted HTTPS, as opposed to Tlon's servers operating as man-in-the-middle, which is not a viable long-term
59+solution. This has been an important piece of missing functionality, so we're excited to see it start to come together.
60+Latest code can be found [here](https://github.com/joemfb/urbit/tree/346de776c5fabe3e02fecb7cab3d1652e4cc46e3).
61+
62+*Isaac* `~davtyr-nimren` has been building the next generation of Urbit's web publishing system, currently located in the
63+ren/tree directory of Arvo. This new system, instead of serializing data down to the client to be fetched after the
64+initial page load, will perform the HTML rendering on the server. This is now possible because of the integration of our
65+Udon markup language with the Hoon compiler. This allows us to include Udon files in other Udon files using Ford runes.
66+The new system is much simpler and should improve page load time. Once we've written our planned Vere HTTP cache, this
67+new paradigm should also improve the coherence of that cache. This system is mostly complete now, and Isaac is now
68+working on smaller bugfixes.
69+
70+There was also a [new episode of Mars Talk](https://youtu.be/1xcjnBu6qFo) with Ted and Joe discussing Hoon's type system.
71+
72+Those are the highlights from this week. Back to breaching!
73+
74+`~rovnys-ricfer`
content/posts/2017-12-22-update.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "~2017.12.22 Update"
3+date = 2017-12-22
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2017.12.22."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+This past week:
10+
11+*Mark* `~palfun-foslup` has continued to fix bugs in new `:talk`. We've finally reinstated our public chat stream [urbit.org/stream](https://urbit.org/stream), which had been down since the breach, and as far as we know all the major, show-stopping `:talk` bugs have now been fixed. All currently known `:talk` bugs can be found on our [github issues page](https://github.com/urbit/arvo/issues). Mark, with some help from Ted, has also been working on reproducing and diagnosing [an old Clay bug](https://github.com/urbit/arvo/issues/501) that popped up again recently involving failed filesystem syncing across ships. We now know how to fix the bug, so that's up next for Mark.
12+
13+*Ted* `~rovnys-ricfer` submitted a [PR](https://github.com/urbit/urbit/pull/910) that fixes a long-standing performance bug in Urbit's event-processing model, where effects wouldn't be performed until the whole queue of input events had been processed. The PR is currently in review. He's also resumed work on the Ford caching fixes that he and Anton had been working on before the breach. It's a difficult project, but once it lands, the dreaded 504 errors when loading urbit.org should finally cease.
14+
15+*Anton* `~pittyp-datfyn` has been working on the `:collections` app, which will replace and generalize `:fora`. This work is nearing completion. This work will likely land with the frontend overhaul that Galen is leading.
16+
17+*Isaac* `~davtyr-nimren` has contined to make progress on the new version of `ren/tree`, Urbit's web publishing frontend. The new system has now matured enough that Keaton has been able to translate several of our docs pages to it.
18+
19+*Keaton* `~tonlur-sarret` has been chugging along on converting Urbit's documentation to the new `ren/tree`. He also booted up a new web ship to run urbit.org, since the old one had gotten verklempt.
20+
21+*Galen* `~ravmel-ropdyl` has continued work on the revamped Urbit frontend, including a base.css and a redesigned look and feel and more diagrams, explanations, and blog posts. *Jimmy* and *Chris* are working with him on this project. He's also been working with Anton on the `:collections` app.
22+
23+*Anthony* `~poldec-tonteg` has fixed several more bugs with [Urbit's fork of myetherwallet](https://github.com/urbit/etherwallet).
24+
25+*Curtis* `~sorreg-namtyv` has continued working on Hoon performance. Performance of his branch is currently estimated at 30% faster than master.
26+
27+*Joshua Reagan* `~taglux-nidsep` and Ted had Mark and Keaton on [Mars Talk episode 13](https://youtu.be/CfdoGY0u044) and they live-coded a Gall app.
28+
29+We also threw what was generally considered to be a pretty good party last night. It was a nice way to end the year. Happy holidays from Mars!
content/posts/2017-3-1-update.mdnew file+105
@@ -0,0 +1,105 @@
1++++
2+title = "~2017.3.1 Update"
3+date = 2017-03-01
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "Arvo is done, there's a prototype in progress, and more."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+*Curtis* (`~sorreg-namtyv`) has reached code-complete (compiling but not tested) on
10+the `arvo.hoon` rewrite. The super-impatient can have a look at
11+[this file](https://github.com/cgyarvin/arvo/blob/revere-ivory/sys/parv.hoon).
12+
13+The entire boot sequence from Nock through the Arvo kernel has now been rewritten,
14+and actually makes sense. The old Arvo did work, it's true, under most
15+conditions. It didn't work because it made sense, but mainly through pure
16+persistence and luck. This is not viable for the deep core of a stable platform.
17+It has, however, managed to stay alive on the network for the past 7 months.
18+
19+This all-new Arvo kernel (at a very fluffy 1065 lines) joins the all-new `%ames`
20+and `%jael` vanes (kernel modules), and the `%zuse` library, in the new family of
21+reference-quality Hoon code. (`%ames` is almost there -- the code is good, but not
22+documented.)
23+
24+Roughly speaking, Urbit including all application, library, and kernel code, is
25+about 40,000 lines of Hoon, in three grades, categorized by how clean and easy to
26+read they are.
27+
28+C-grade Hoon is found in `%eyre` (Web server) and `%dill` (console); a bit of it
29+has accumulated in `:talk`; the markdown parser; some of the examples; some of
30+`hoon.hoon`; etc.
31+
32+C-grade Hoon is write-only code. To even look at it, even if you know Hoon, is
33+reverse engineering. It follows no conventions, not even its own. If it has
34+comments, they mean nothing, except (possibly) to the author. (One bad property of
35+Hoon is that, like C, it does nothing to stop you from writing obfuscated code.)
36+Most C-grade Hoon dates to 2014 or early '15.
37+
38+B-grade Hoon can be followed with some effort. It is structurally simple, but not
39+always conceptually simple. It makes no particular effort to explain itself,
40+either through documentation or otherwise. `%behn`, `%clay` (B+ for decent
41+comments), `%ford`, `%gall`, most of `hoon.hoon` and most userspace code is
42+B-grade. Most B-grade code is from late '15 or early '16.
43+
44+The A-grade Hoon is everything produced since our crowdsale: `%ames`, `%zuse`,
45+`%jael`, and `%parv`. Hoon of this quality, you just spread on a cracker and eat.
46+It's completely smooth. You can almost see what it's doing even if you don't know
47+Hoon. The only places where A-grade Hoon is hard to understand are places where
48+the problem is actually tricky.
49+
50+Urbit succeeds exclusively through software quality. All A-grade code should be
51+permanently maintainable at consistent quality. All B-grade and C-grade code will
52+deteriorate over time and eventually needs to be replaced.
53+
54+But `cc-release` is an "infrastructure MVP" in which the critical parts are
55+A-grade: the boot sequence and OS, networking, and secrets. Lower-grade code
56+remains suitable for light-duty kernel and userspace work. The good news is that
57+the longer we wait to rewrite it, the better the replacement will be.
58+
59+These new A-grade subsystems remain untested (except `%jael` and `%zuse`) and have
60+not been integrated. This will involve further tinkering with other vanes and
61+userspace code. However, Arvo should be the last major module rewrite before
62+`cc-release`, so we're on our way.
63+
64+*Anton* (`~pittyp-pittyp`) and *Galen* (`~ravmel-ropdyl`) are working from the
65+opposite end. They're designing the new, easy-to-use, command-completing Urbit UI
66+from the top down, using ES6 and React.
67+
68+This new framework isn't even connected to Urbit. Its first use is actually a demo
69+video. We published a few screenshots from our mockups in the last blog post, and
70+want to give a more complete impression of where we're headed to the public.
71+Making this interface real will, of course, require nontrivial console engineering
72+on the Urbit side. We think it's going to be great.
73+
74+Like our new server-side code, the new Urbit client-side framework is designed to
75+be high-quality code that other human beings can read and extend.
76+
77+*Raymond* (`~maldeb-hapben`) has finished breaking the new `vere` system into
78+client, manager and worker processes. Curtis earlier rewrote the event loop and
79+the logging system, with correct use of concurrency and `fsync()` in an actual
80+two-phase commit.
81+
82+There's still a large number of small tasks to perform, but we're essentially
83+turning `vere` into the C equivalent of A-grade Hoon: clean code that just
84+obviously works. Also, the new `vere` works like an actual, industrial-grade
85+server, and should be reasonably adapted to the task of hosting nontrivial numbers
86+of urbits.
87+
88+The absolutely crucial requirement for `cc-release` is ships that don't sink. We
89+have not observed any problems with the new event log so far, but we still need to
90+stress-test it with powercycles. Yes, Urbit really is an ACID database!
91+
92+*Keaton* (`~livweb-havweb`), our intern, has written a bunch of examples and
93+cleaned up a bunch of doc.
94+
95+*Elliot* (`~ponnys-podfer`), an outside contributor, sent an amazing `doccords`
96+patch that adds documentation strings to Hoon. This sounds like a superficial
97+change, but it actually involved deep work in the heart of the type system. He's
98+also added a bunch of this doc himself.
99+
100+You can check out the pull requests [here](https://github.com/urbit/arvo/pull/353)
101+and [here](https://github.com/urbit/arvo/pull/356). The original `fora`
102+discussion is [here](http://urbit.org/fora/posts/~2017.1.16..06.08.17..ae0f~/).
103+
104+As usual, comments are on fora. Check out
105+[this thread](http://urbit.org/fora/posts/~2017.3.1..22.06.50..bf2a~/).
content/posts/2017-4-17-update.mdnew file+155
@@ -0,0 +1,155 @@
1++++
2+title = "~2017.4.17 Update"
3+date = 2017-04-17
4+author = "The Urbit team"
5+description = "Individual updates from everyone"
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's our April update, covering the last month or so. I've taken people's own
10+reports and added a little background where necessary.
11+
12+It might help to have a broader roadmap. We'll post that next.
13+
14+### `~palfun-foslup` (Fang)
15+
16+I've been focusing entirely on `:talk` work.
17+
18+After documenting most parts of the existing talk implementation, I tore it apart
19+into a "guardian" and "agent" (daemon and user-agent), or "broker" and "reader" for
20+talk specifically.
21+
22+Along the way, I took note of and corrected some architectural weirdness, with the
23+prime goal of making the whole simpler and more clear. The split talk currently
24+mostly works, but there's still some improvements to be made, both in existing
25+implementation and in new features.
26+
27+_Background: in the cc-release world, the user-level application container %gall
28+is scheduled for a somewhat cosmetic internal partitioning. Right now there is
29+only one kind of "app," ie, dynamic core managed by the `%gall` vane. In future
30+there are "guardians" (system daemons), "agents" (user agents), "tunnels" (HTTP
31+security drivers, currently in %eyre), and "gateways" (foreign API interpreters)._
32+
33+_This is not as big as a change as it sounds -- all these partitions use the same
34+mechanisms. It's just about policy limitations. Eg: only a guardian can receive
35+inbound messages and subscriptions. In `:talk`, the separation matches the split
36+between mailserver and mailreader in classic Unix email, news server and news
37+reader in NNTP, etc._
38+
39+### `~tonlur-sarret` (Keaton)
40+
41+I've started a new multi-part tutorial series on building and deploying Urbit web
42+apps. The goal of the series is to highlight Arvo's technical features and the
43+flexibility of Urbit's API/UI model through interactive code examples and full
44+demos that technical readers can extend.
45+
46+_Background: Urbit isn't yew a platform you'd want to deploy anything real on.
47+But userspace isn't going to change that much, so we're trying to make it more
48+accessible for early explorers._
49+
50+_It's true that the network has now maintained continuity for almost nine months,
51+while ~zod has eaten 180GB of of events and seems no worse for the wear. This
52+should not be mistaken for stability! Any data in your present urbit will need to
53+be retrieved by hand when the universe is finally rebooted. And of course, the
54+PKI is still non-final and invalid._
55+
56+_And the changes to the core `%gall` programming model will be mostly cosmetic.
57+For example, `%gall` will do more to help you handle subscriptions; pending events
58+will be inside your core; little stuff like that._
59+
60+_The main change for the programmer is just that in the present `%arvo` and
61+`%ames` (whose total rewrite is now being tested), message transaction handling is
62+shitty from end to end. But you're used to that. Distributed programming with
63+exactly-once transactional messages is such an awesome experience that even when
64+it's broken, it's kind of ok._
65+
66+### `~ramtev-wisbyt` (Raymond)
67+
68+Before 0.5, Urbit ran as a single monolithic process controlling everything from
69+terminal I/O to computing and storing events. In 0.5, Urbit is split into a more
70+traditional database-server architecture. Thanks to a wrapper application, casual
71+users don't have to notice much difference if they don't want to - except that the
72+bottleneck in the old event code is gone, so things are a lot faster. But the new
73+architecture has a lot more flexibility.
74+
75+At the top level, there is a single urbit daemon process which runs in the
76+background, handling I/O. The daemon can govern multiple ships, each of which has
77+its own worker process to compute and record events. Terminal I/O is moved to a
78+separate client process, which speaks a noun-based protocol to the daemon. The
79+sole client isn't the only thing that can speak this protocol - there's also a
80+command-line client that can handle system admin tasks like loading piers, and
81+urbit commands like the current `urb.py`. You can also write your own clients if
82+you're adventurous, though `libnoun` doesn't quite reach the level of a stable API
83+yet.
84+
85+_Background: the "bottleneck" is that old event code processes its full input
86+queue before deigning to emit any outputs. This highlights Urbit's chelonian
87+agility with brilliantly perverse moments of inexplicable latency. We also have
88+no confidence whatsoever in the data integrity of the old storage layer._
89+
90+_The new Urbit looks much more like a regular production server. Everything
91+outside the noun library has been replaced. We're also hoping to add FUSE access
92+to the Urbit namespace, though the priority isn't immediate._
93+
94+### `~pittyp-pittyp` (Anton)
95+
96+I am in the middle of making an architecture change to the console protocol, with
97+the eventual goal of being able to reconnect sessions.
98+
99+_Background: the console protocol was in a sense the initial test case for Urbit
100+as a true OS. If you've built a working command line by passing events between
101+separate input, history, and application subsystems, with correction/completion
102+that requires multiple writers to the input buffer, you've built an OS._
103+
104+_On the other hand, your initial test case rarely ends up as a showcase demo. For
105+instance, one of the things we didn't understand at first was the importance of
106+the CQRS pattern (command-query separation) behind Urbit's separation of `%poke`
107+and `%peer`. Pokes (messages) are one-way commands, not queries. Peers
108+(subscriptions) have no effect on the server state._
109+
110+_The relationship between pokes and peers is particulary delicate in a very
111+interactive application, like a console. Proper CQRS dictates that sending input
112+to a virtual console, and subscribing to its updates, should be totally
113+orthogonal. But needless to say, this is not how we originally did it._
114+
115+_If you remember the last update, we are obviously asking our console for a lot of
116+UI power. We are also redesigning `:talk` to use it even on the Web. But we have
117+to fix the protocol first._
118+
119+### `~ravmel-ropdyl` (Galen)
120+
121+I'm putting together new materials for the public.
122+
123+### `~sorreg-namtyv` (Curtis)
124+
125+I've done two main things: adding formal decorations to Hoon, and making the Arvo
126+boot sequence coherent.
127+
128+The coherent boot sequence puts a complete Urbit installation in a single sequence
129+of initial events. As always in the development branch, this is a true boot
130+sequence which proceeds directly from nock. We no longer use the `-A` flag to
131+load the initial filesystem from an Arvo repository, nor do we boot userspace over
132+the network. Treating the whole install as a single noun is very helpful in
133+ensuring consistency for the developer. (We're aware that distributing source
134+files jammed into a binary pill isn't optimal from the Internet's perspective --
135+the only inscrutable content actually in the event stream is the self-compiling
136+compiler. A fancier interpreter should probably assemble its own boot sequence
137+from a transparent resource directory, not a binary pill.)
138+
139+For formal decorations, see the accompanying forum post. Briefly, I started from
140+an initial draft by `~ponnys-nacwer` and added a lot of elaborations. The goal is
141+to get Hoon to a high level of literate programming, which documents not only APIs
142+but also data structures. Integrating documentation into the type system is
143+especially important on a user-friendly system with long-lived typed data
144+structures. Hoon is now at 144 Kelvin.
145+
146+The parser and AST changes required for decorations also helped me find a way to
147+disambiguate direct and indirect Hoon syntax, eliminating the duplicate irregular
148+syntax introduced in Hoon 151 -- if we want. Backward compatibility was almost
149+perfect, requiring only a few touchups across the whole codebase.
150+
151+### Oh, and
152+
153+This actually went up on `/fora` before anything else. Feel free to chime in on
154+[this thread](http://urbit.org/fora/posts/~2017.3.1..22.06.50..bf2a~/) with
155+comments and questions. We're here to answer them!
content/posts/2017-5-11-roadmap.mdnew file+231
@@ -0,0 +1,231 @@
1++++
2+title = "~2017.5.11 Roadmap"
3+date = 2017-05-11
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "From AVP to MVP."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Urbit today (May 2017) is a working proof-of-concept. The Urbit test network
10+has been up continuously since last August, hosting its own distributed chat,
11+distributing its own updates, serving its own website and forum, etc, etc.
12+
13+Everyone has heard of the minimum viable product (MVP). Urbit in summer 2016
14+(the current test network) is the MVP's first cousin: the AVP (almost-viable
15+product).
16+
17+## From AVP to MVP
18+
19+Urbit is an open-source project. Its sponsor, Tlon, is a company. So we can't
20+exactly tell the public to _go away_. But there is nothing much the public can
21+use Urbit for, besides hanging around and talking about Urbit.
22+
23+Going from AVP to MVP means changing that. And of course, it means issuing real
24+Urbit keys. And promoting Urbit to users. And preaching it at developers. And
25+all that normal stuff. But not until we're ready, because we ship only the most
26+beautiful bits.
27+
28+Sometimes we forget to remind people that _no one has ever built anything even
29+remotely like Urbit_. It's not like, people had cars, so we built a better car.
30+It's like, people had cars, so we built a [rocket unicycle](https://media.urbit.org/whitepaper.pdf).
31+
32+Our rocket unicycle is a lot more awesome than a Chevy. But it demands more
33+custom engineering. We have to invent every little widget as we need it.
34+Usually that involves rebuilding it two or three times (see the (see the [long-term
35+strategy](/essays/toward-a-frozen-operating-system/)). This process converges
36+from the bottom of the stack up, and accelerates as our progress advances.
37+
38+Nock, which is now frozen, and which is a page of pseudocode, took from 2002 to
39+2008 to invent. Hoon took from 2008 to 2012, and is stable but not frozen. All
40+the real technical problems in 2016 Urbit are either in the top layers (Arvo,
41+its vanes and apps), or outside Urbit proper (Vere, the Unix event processor).
42+
43+Except for one major component (the security vault `%jael`), there isn't any
44+single big thing wrong with 2016 Arvo or Vere. In retrospect, they can even be
45+seen as inspired stabs in the right direction. But hammering square pegs into
46+round holes isn't the Urbit way.
47+
48+If we made our AVP into an MVP by straight-out _debugging_, we'd be limping
49+across the finish line. An MVP must be minimal in affordances. In its
50+aesthetics, it must be sublime. It has the rest of its life to grow features,
51+but beauty only fades.
52+
53+## A parallel process
54+
55+Architecture is entropy in reverse. Urbit has to become _more_ elegant, as it
56+becomes more functional. This delicate process must be carefully controlled.
57+
58+To keep Urbit on the path to absolute zero, we have to work in three directions at
59+the same time:
60+
61+- Stabilizing the Urbit infrastructure
62+- Developing the Urbit user experience
63+- Documenting the Urbit system
64+
65+Pushing in all three directions at once keeps the whole project in balance. We
66+could drop any two of these goals and head at top speed for the other. This
67+would produce a nice simulation of doneness in a single dimension.
68+
69+But if we just hardened our infrastructure from the bottom up, we wouldn't be
70+responding to the needs of the user experience. If we just built a user
71+experience on top of our prototype infrastructure, it wouldn't be stable enough
72+to be usable. If we documented the prototype, it would become much harder to
73+revise. And so on.
74+
75+And the balance between these directions shifts with the seasons. After
76+spending the fall and winter writing infrastructure, and the spring testing it,
77+it'll be time to spend summer and fall working toward the user and the
78+developer.
79+
80+## Since the last crowdsale
81+
82+Maybe this is too vague. What we actually did since the last crowdsale:
83+
84+We replaced about half the Unix interpreter (the whole `vere` directory, event
85+handing and storage), and about a third of Arvo: the lifecycle function, boot
86+sequence and kernel `%arvo`, the network `%ames`, the PKI (adding a new security
87+module `%jael`), the console `:drum`, and the `:talk` app. If Arvo was a car, we
88+replaced the powertrain.
89+
90+At the Hoon level, we added formal docstrings and reorganized (or rather,
91+organized) the kernel and standard library. At the Nock level, we of course did
92+nothing. And on the client side, we redesigned the Web API, and prototyped a
93+completely new Urbit user experience. And all the new code is high-quality,
94+fully documented, and generally ready for anyone to copy and/or abuse.
95+
96+This `cc-release` (continuity candidate) isn't quite done — the Arvo code is
97+written but not fully tested, and one module (the application sandbox `%gall`)
98+is still waiting for its rewrite. But the new Arvo has that "not quite perfect,
99+but basically right" feeling of architectural doneness which Hoon has had for a
100+while.
101+
102+Note that we remain a super-tiny team. We've had some serious outside
103+contributions, but clean loose ends that outsiders can pull on remain
104+frustratingly scarce. Hoon is too stable and Arvo is too unstable.
105+Architectural work scales poorly in personnel, and you can't really renovate a
106+house while people are trying to live in it.
107+
108+## Moving forward
109+
110+After `cc-release` this summer, we'll move from bottom-up, infrastructure-driven
111+engineering, to top-down, user-driven engineering. Naturally this is
112+`dd-release` (deck-directed).
113+
114+Our planning target is a stable, useful Urbit we can ship in 2017. Since we're
115+working top-down, we can abandon the deep architectural essays and work, like
116+normal human beings, from an illegible list of features scribbled on a
117+poorly-erased whiteboard.
118+
119+## A whiteboard list
120+
121+Our feature list for `dd-release`, in no particular order:
122+
123+- The top-level `:deck` UI, an interaction multiplexer like GNU screen, but for
124+ terminals or web consoles. (The front end of `:deck` is a working prototype
125+ now.)
126+
127+- The "helpful console," which offers contextual help and lets you construct any
128+ dojo command with a wizard-style UI. The three-way combination of a command
129+ parser, contextual completion and help, and webform input, may be our most
130+ interesting little challenge. We think we know to do it.
131+
132+- Useful, well-designed web API integrations which contributors can easily clone
133+ to extend Urbit's reach. Stars can proxy APIs for their planets, metering
134+ free service.
135+
136+- Integrations for email and SMS are live, so that any ship can at least message
137+ its owner. A storage integration to S3, etc, lets us save external blobs. A
138+ DNS integration lets us forward ship.urbit.org to ships with public IPs.
139+
140+- Real keys are ready to be born. An instantiation protocol for the real Urbit
141+ keys exists and has received some public review. The current options:
142+ physical delivery of tamper-resistant artifacts, or registering ownership on
143+ Ethereum or another blockchain. (We'll release a separate essay on this
144+ question soon.)
145+
146+- All key updates at the planet level or above are propagated hierarchically
147+ across the network. An offline key can block all transfers. Planet owners
148+ can invite their friends to a self-hosted conversation with webmoons (guest
149+ accounts).
150+
151+- The `%eyre` HTTP server is cleaned up and its API simplified. Web
152+ programmers see a clear, CQRS-based query and subscription interface in JSON.
153+ A cookie makes your browser into a virtual moon, with a unique causal identity
154+ for each page instance.
155+
156+- No user operation can damage the ship, which can be reset to factory condition
157+ with just the private key.
158+
159+- Personal urbits on a home computer don't lose data, except in case of
160+ system/OS failure. Mutual exclusion on interrupt handlers is perfect.
161+ Timeouts, crashes, and user interrupts are handled perfectly. Snapshot
162+ handling is asynchronous and uses two A/B images.
163+
164+- Urbits are configured to rotate logs by default, so they don't grow
165+ infinitely. All caches have continuous expiration, and out-of-memory can't
166+ sink a ship. The Web server is secure and has adequate performance without
167+ an external cache or any auxiliary servers.
168+
169+- Urbit can connect its event loop to Kafka or a similar event replication
170+ service. Replicated urbits on a hosted service don't lose data, except
171+ through acts of God or government.
172+
173+- One star on a normal virtual host can comfortably manage at least 256 active
174+ planets. Dormant planets consume minimal local or remote resources.
175+
176+- The whole Urbit stack is managed with telescoping Kelvin numbers. Upgrades
177+ succeed perfectly or crash the transaction. The stack is permanently
178+ upgradeable, even for backward-incompatible changes in Hoon.
179+
180+- Hand maintenance is only needed to upgrade the Unix interpreter, vere. The
181+ owner gets a notification when an obsolete `vere` blocks an Urbit update.
182+
183+- The new security masks are respected across all vanes. The revision-control
184+ system `%clay` has permission masks. Untrusted code can be installed as a
185+ gateway to a foreign service with same-origin network permissions.
186+
187+- Backward-incompatible changes in the Hoon language or Hoon libraries are
188+ unlikely. But the Arvo upgrade mechanism can make arbitrary Hoon changes,
189+ compatible or not.
190+
191+- All major Arvo subsystems are architecturally stable. Namespaces, cards, URL
192+ routes, the boot sequence, and the upgrade model, are well-specified. Further
193+ change in these specs will involve a slow-track community process. But the
194+ definitions are stable enough to be taught.
195+
196+- Architectural overviews of all major Arvo components are attached to the
197+ source code. Tutorial documentation for both Hoon and Arvo is good enough to
198+ lead a naive programmer up through building a web API gateway (server side
199+ Hoon) and a web agent (client side JS).
200+
201+- Urbit stores and manages all Urbit-related development metadata: todos, bugs,
202+ releases, PRs, discussion, etc. It routes this metadata through `:talk` and
203+ logs it to `%clay`.
204+
205+- A precise system coding convention is in place and enforced, if only by
206+ measurement. All code in Urbit is graded A, B, or C. Grade A Hoon ("Prime")
207+ is well-structured and well-explained. Grade B ("Select") is well-structured,
208+ but not well-explained. Grade C ("Choice") is still great code, but its
209+ style or technique may not meet our latest standards.
210+
211+- All code in Urbit except `++ut` (the compiler itself) is grade B. (We can
212+ relax standards on the compiler because it tests itself so thoroughly.) All
213+ code on the Arvo powertrain (`%arvo`, `%ames`, `%jael`, `%gall`, `:dojo`,
214+ `:helm`) is grade A.
215+
216+If you know the current maintenance Urbit, you know that most of these features
217+are mostly in sight. None of them is exactly _quite_ complete. None of them is
218+anywhere near a stretch. We have significant parts of all of them.
219+
220+Also, since this is the release after the release we're doing now, we're
221+probably missing as many checkboxes as we've caught. And triage is a thing
222+that happens. It's really better understood as the _kind_ of work we're going
223+to do.
224+
225+We'd really like to get all these things done in 2017. But a lot depends on
226+what kinds of resources we have access to. And of course, as we document the
227+system, it gets easier for all the people who believe in Urbit to help us build
228+it.
229+
230+As usual, comments are on fora. Check out
231+[this thread](https://urbit.org/fora/posts/~2017.5.12..20.33.04..3db0~/).
content/posts/2017-8-11-update.mdnew file+109
@@ -0,0 +1,109 @@
1++++
2+title = "~2017.8.11 Update"
3+date = 2017-08-11
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "A short update from the Tlon team for the week of ~2017.8.11."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+
10+Usually after a crowdsale we rethink our direction a little. Sorry for the
11+radio silence — it's hard to talk while you're thinking.
12+
13+We've decided to refocus our efforts a little in the short term, optimizing
14+against long-term infrastructure work in favor of making Urbit work better
15+right now. Bear in mind that this is a short-term decision and Urbit is still
16+a long-term project! We just find ourselves in, um, a very fast-moving
17+industry.
18+
19+There are two sides to this effort: design/usability and stability.
20+
21+
22+## Design and usability
23+
24+
25+### Making static publis hing static
26+
27+`:tree`, the Urbit publishing framework, can be painfully slow. In part, this
28+is because we do too much work client-side to put pages together. It would make
29+a lot more sense for a page to be a single fixed function of a URL -- the
30+original "functional publishing" design.
31+
32+So, we've gone and made that actually work. Server-side includes will now be
33+possible, since we're adding a Markdown subset to Hoon itself. We're also going
34+to improve Vere's internal HTTP server to include our own caching with proper
35+dependency invalidation.
36+
37+### Bootstrapping a style guide
38+
39+![](https://storage.googleapis.com/media.urbit.org/site/type-2-up.png)
40+
41+Currently, all of Urbit's CSS and styling is based on Bootstrap. It's not a
42+very good fit. We do a lot of work to override the default styles.
43+
44+While we were improving some of our example apps a little while back it became
45+obvious that we need our own base CSS and style guide. So, we went ahead and
46+started down that path. After years of working with other CSS frameworks, it's
47+a relief to be producing one that's purpose-built for Urbit itself.
48+
49+Urbit is a tool, so its branding needs to be completely calm and quiet. It
50+can't get in the way. In a way, a CSS framework is the brand itself. Urbit
51+isn't a logo or a tagline — it's a look and feel. This way, it's a look and
52+feel that you can also send pull requests to.
53+
54+There's a working prototype of this style guide today, and we'll publish a repo
55+sometime in the next week or two. Hopefully some substantive design discussions
56+can be had in connection with the code itself.
57+
58+### Write, talk, socialize
59+
60+![](https://storage.googleapis.com/media.urbit.org/site/app-2-up.png)
61+
62+We already use Urbit to chat and write, but the edges are pretty rough. Better,
63+faster publishing and a look and feel refresh will allow us to update and clean
64+up our existing tools for chatting and writing. Hopefully to the point that
65+they clear the 'Facebook 2004' bar. But, of course, in a pretty different way.
66+
67+## Examples
68+
69+![](https://storage.googleapis.com/media.urbit.org/site/examples-screen.png)
70+
71+Also, our examples repo is now hosted on Urbit itself. You can just `|sync` a
72+desk and open a URL on your own Urbit to view the examples.
73+
74+Try it yourself! The instructions are in
75+[this fora post](https://urbit.org/fora/posts/~2017.8.3..20.53.26..c361~/).
76+If you've got ideas for examples to contribute, that'd be great.
77+The source is on [GitHub](https://github.com/urbit/examples).
78+`~poldec-tonteg` just contributed his Tumblr connector, which he is also using
79+to syndicate his Tumblr through Urbit.
80+[Check it out](http://poldec-tonteg.urbit.org/portal.html).
81+
82+## Remaint
83+
84+The last test network managed to stay up for about a year. That's pretty good!
85+During that time we discovered a few bugs that would cause urbits to end up in
86+one-way-connectivity. A short explanation is that remote crashes would often
87+not get properly passed back to the requesting ship.
88+
89+So we fixed that. We could probably hack this change in via an OTA update, but
90+it's much easier to breach this change in, and it'll be great to have it out on
91+the network. So, we'll be doing a breach once the code has been properly
92+tested.
93+
94+## Urbit + ETH
95+
96+Finally, we've been working on a design for how Urbit can bootstrap itself off
97+of the Ethereum blockchain. We have a loose specification of how this could
98+happen, and will present those at the meetup
99+[tonight](https://www.meetup.com/urbit-sf/events/242295411/). Come, critique
100+and ask questions. We'll publish what we come up with in the coming weeks.
101+
102+## Keep in touch
103+
104+As usual, discussion is on fora:
105+[fora/posts/~2017.8.11..21.45.52..4296~](https://urbit.org/fora/posts/~2017.8.11..21.45.52..4296~).
106+
107+Also, we managed to get the `@urbit` Twitter handle:
108+[https://twitter.com/urbit/status/895698846918909952](https://twitter.com/urbit/status/895698846918909952).
109+Finally!
content/posts/2017-9-23-update.mdnew file+22
@@ -0,0 +1,22 @@
1++++
2+title = "~2017.9.23 Update"
3+date = 2017-09-23
4+author = "tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2017.9.23."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Galen and Curtis publish Tlon's plans for bootstrapping the Urbit PKI on the Ethereum blockchain. Ted creates a cheat sheet for Hoon. An Urbit podcast is born. The community talks about searching filesystems and cryptographic hashes.
10+
11+- [Bootstrapping Urbit from Ethereum](https://urbit.org/blog/2017.9-eth) blog post. [Discussion on
12+ Fora](https://urbit.org/fora/posts/~2017.9.20..22.56.04..47ce~)
13+- A [Hoon cheat sheet](https://storage.googleapis.com/media.urbit.org/docs/hoon-cheat-sheet-08-26-17.pdf) by
14+ `~rovnys-ricfer`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.18..22.31.06..24d5~)
15+- [On Searching Filesystems](https://urbit.org/fora/posts/~2017.9.16..06.19.33..72a4~) by `~littel-ponnys`
16+- [Mars Talks, Ep. 0](https://www.youtube.com/watch?v=LFalNG4eTqU) hosted by `~taglux-nidsep` with guest `~rovnys-ricfer`
17+ of Tlon on the fundamentals of Urbit. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.21..04.31.08..9ae7~)
18+- [Exploring Urbit](https://www.youtube.com/watch?v=OOQ2Do6jAi4) by Jordan Leigh of Decypher Media with guest
19+ `~tonlur-sarret` of Tlon. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.22..23.09.25..c613~)
20+- [To Understand Blockchains, You Should Understand Cryptographic Hashes
21+ First](https://fitseb-ropnux.urbit.org/blog/Cryptography2/) by `~fitseb-ropnux`. [Discussion on
22+ Fora](https://urbit.org/fora/posts/~2017.9.19..18.39.11..ebaa~/)
content/posts/2017-9-29-update.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "~2017.9.29 Update"
3+date = 2017-09-29
4+author = "tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2017.9.29."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Galen and Curtis comment on Urbit and the blockchain wars. Curtis and a new fan discuss the ideal Urbit virtual machine. `~poldec-tonteg` joins Mars Talks to spread the gospel of Urbit web development. A new contributor makes it easier to sync Urbit files during development.
10+
11+- [Urbit and the blockchain wars](https://urbit.org/blog/2017.9-critique/) blog post. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~/)
12+- [A question by James Bowery from urbit-dev](https://urbit.org/fora/posts/~2017.9.26..23.26.32..1066~/)
13+- [Mars Talks, Ep. 1](https://www.youtube.com/watch?v=lX0xx70TcJE) hosted by `~taglux-nidsep` with guest `~poldec-tonteg` on Urbit web development. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.28..04.10.26..a4bb~)
14+- [urbit-sync](https://github.com/ngzax/urbit-sync) by `~migsyr_tarnux`. [Discussion on Fora](https://urbit.org/fora/posts/~2017.9.29..11.58.54..4dd1~)
content/posts/2018-1-13-update.mdnew file+25
@@ -0,0 +1,25 @@
1++++
2+title = "~2018.1.13 Update"
3+date = 2018-01-13
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2018.1.13."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+This week:
10+
11+**Galen** `~ravmel-ropdyl`, **Curtis** `~sorreg-namtyv`, and **Jimmy** continued work on the upcoming Urbit primer for the website.
12+
13+**Keaton** `~tonlur-sarret` is almost done converting the documentation to Urbit-flavored markdown, building on the work of **Isaac** `~davtyr-nimren`.
14+
15+**Ted** `~rovnys-ricfer` has been working with Anton on better Ford caching performance.
16+
17+**Anton** `~pittyp-datfyn` has been doing some work with **Joe** `~master-morzod` on [automated Vere memory verification](https://github.com/urbit/urbit/pull/915).
18+
19+**Mark** has a [PR to fix a talk / Gall bug](https://github.com/urbit/arvo/pull/538) and is now working on updating Clay's API to support multiple files per request, which will support the Ford caching improvements.
20+
21+**Iceman** `~littel-ponnys` has submitted a [PR implementing a unit testing framework](https://github.com/urbit/arvo/pull/539) for Hoon, which had been in the works for a long time.
22+
23+**Mikolaj** `~ponmep-litsem` has been making lots of good contributions recently, including reporting several GitHub issues and work on an Elm web frontend for Urbit, which he's using to implement [Plato](https://github.com/mikolajpp/plato), an in-browser Hoon editor.
24+
25+Finally, in [Mars Talk this week](https://youtu.be/oX7TFJ5qzr4) Ted wrote a Gall app using a timer from Behn with help from Keaton and **Josh** `~taglux-nidsep`.
content/posts/2018-1-6-update.mdnew file+35
@@ -0,0 +1,35 @@
1++++
2+title = "~2018.1.6 Update"
3+date = 2018-01-06
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2018.1.6."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Short week this week as we recover from the holidays. The biggest news item is that our fork of MyEtherWallet is now
10+complete!
11+
12+Feel free to download it and try it out: https://github.com/urbit/etherwallet
13+
14+Thanks to *Anthony* `~poldec-tonteg` for building it and to Mark for testing it.
15+
16+*Mark* `~palfun-foslup` has diagnosed [a tricky bug](https://github.com/urbit/arvo/issues/533) involving what appeared to
17+be one-way communication in Gall. More updates on that forthcoming.
18+
19+*Galen* `~ravmel-ropdyl` has been working on the Urbit primer that will become the new urbit.org landing page. That's in
20+review now.
21+
22+*Curtis* `~sorreg-namtyv` has been helping out with the primer and has begun work on an HTTP cache in Vere to help with
23+web performance. That should synergize nicely with upcoming Ford fixes.
24+
25+*Ted* `~rovnys-ricfer` has been modernizing his and Anton's work on Ford caching to work with new Hoon and Arvo.
26+
27+*Keaton* `~tonlur-sarret` has been helping Ted with Ford. With Mark's help, he also moved Fora onto a standalone ship to
28+improve the loading times of the rest of urbit.org. All the old links still work, but Fora's true home is now at
29+[https://fora.urbit.org](https://fora.urbit.org).
30+
31+*Isaac* `~davtyr-nimren` has made some [more
32+progress](https://github.com/ixv/arvo/commit/bc52d9fc494399c2063cfa7817046d180b6f78d5) on the new static webpage serving
33+(`ren/tree`).
34+
35+Early 2018 should see a lot of usability improvements. We're looking forward to being able to ship them soon.
content/posts/2018-10-12-update.mdnew file+60
@@ -0,0 +1,60 @@
1++++
2+title = "~2018.10.12 Update"
3+date = 2018-10-12
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2018.10.12."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+
10+![](https://media.urbit.org/fora/updates/2018.10.12-update.png)
11+
12+It's an exciting time here at Tlon.
13+
14+The Keys team is toiling to make the Urbit Wallet air-tight and foolproof. The
15+Urbit Wallet, a cousin to the more typical cryptocurrency wallet, is an original
16+system for securing cryptographic assets. It's original enough to demand its own
17+Manual, a document that *Will* `~hadrud-lodsef`, *Rob* `~lodleb-ritrul`, and
18+*Morgan* `~hidrel-fabtel` are in the process of perfecting. The Wallet Manual
19+will be a one-stop shop for information on using the Urbit Wallet system, both
20+general concepts and technical details.
21+
22+Someone claiming to have solved a sufficiently large task with their first
23+attempt is probably lying. The Keys team are an honest bunch, and they've
24+decided to simplify our in-house wallet-generation software into something that
25+produces one Urbit Wallet for each ship. That wallet generator provides secret
26+keys to users in the form of PDFs, and these PDFs have been redesigned by
27+*Gavin* `~riglur-figbud` so that they are more informative and easier to
28+organize.
29+
30+Gavin and *Jimmy* `~fallyn-balfus` are designing the UI flows for software
31+that takes the grief out of accessing your ships on the blockchain. This is
32+distinct from the aforementioned wallet-generation software which helps you
33+secure your ships on the blockchain, but we will soon to merge the two apps into
34+a combined application known as Bridge.
35+
36+Our foreign correspondents are lending their talents to the Bridge mission.
37+New Zealand's *Jared* `~nidsut-tomdun` has been working on the attendant
38+key-derivation library, and is also creating the library for displaying
39+Urbit Wallet tickets as human-memorable strings. *Mark* `~palfun-foslup`, our
40+beloved Dutchman, worked with Jared to develop a JavaScript interface to the
41+Urbit constitution.
42+
43+The infrastructure team has labored clanking towards the goal of making Vere
44+less clanky. Two of *Paul's* `~fodwyt-ragful` changes -- a custom-bytecode
45+Nock interpreter and a new jet dashboard -- have been integrated, resulting in a
46+faster and more robust Urbit. Nock itself was updated, too, with the notable
47+addition being the Nock 12 "edit" operator. Paul, *Ted* `~rovnys-ricfer`, and
48+*Joe* `~master-morzod` joined forces to make this happen, and borrowed our
49+resident logician *Josh* `~taglux-nidsep` from the docs team to check it for
50+correctness.
51+
52+All of the above points to the big enchilada: using the Constitution as the
53+address registry for the Urbit network. Mark has capped off this week's progress
54+by booting the Urbit testnet (with all the new Landscape features) against an
55+Ethereum testnet, so now we can do our best to break it. Things are about to get
56+real.
57+
58+See you next week.
59+
60+Rob `~lodleb-ritrul`
content/posts/2018-10-24-update.mdnew file+37
@@ -0,0 +1,37 @@
1++++
2+title = "~2018.10.24 Update"
3+date = 2018-10-24
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2018.10.24."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.10.24`:
10+
11+![](https://media.urbit.org/fora/updates/2018.10.24-update.jpg)
12+
13+The heroic efforts of *Mark* `~palfun-foslup` have ensured that the Ethereum
14+testnet Constitution is transacting properly, all in the face of the testnet
15+itself encountering a consensus-failure bug. We can now test various pieces of
16+our tooling and Urbit functionality against really existing blockchain state.
17+
18+On the Landscape side, *Logan* `~tacryt-socryp` and *Chris* `~sigtus-hossyn`
19+finished integration between the mobile app and its desktop counterpart so that
20+there is a QR-code pairing functionality. These interfaces are now in shape for
21+internal testing.
22+
23+*Ted* `~rovnys-ricfer` has brought important changes to our build system,
24+Ford. The latest, fastest version of that system is titled Ford Fiesta, and
25+it's shaping up to have all the Spartan utility that its name indicates: stack
26+traces, new Ford-specific runes, and a parser for those runes. Ted also tweaked
27+Clay and Gall so that they use Ford Fiesta for builds.
28+
29+In one of our cavernous basement labs, we've been poking away at a replacement
30+for our beleagured HTTP server, `%eyre`. This new beast, dubbed `%light`, has
31+benefited from the talents of *Elliot* `~littel-ponnys`. A test version of this
32+new vane can now hold a connection open and send a steady stream of HTTP data to
33+the client. Big things have small beginnings...
34+
35+See you next week.
36+
37+Rob `~lodleb-ritrul`
content/posts/2018-11-20-update.mdnew file+52
@@ -0,0 +1,52 @@
1++++
2+title = "~2018.11.20 Update"
3+date = 2018-11-20
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2018.11.20."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.11.20`:
10+
11+![](https://media.urbit.org/fora/updates/2018.11.19-update.jpg)
12+
13+The dreams of the keys crew are finally escaping their heads. After months of
14+excruciating reworking and fine-turning, *Will* `~hadrud-lodsef`, *Gavin*
15+`~ridlur-figbud`, *Morgan* `~hidrel-fabtel`, and *Jimmy* `~haptyl-wanwes`
16+have completed the client-side tools for registering Ethereum addresses to
17+receive and access their purchased ships. The registration process begins with
18+the emails that we've begun to send out to ship-owners. The first batch has been
19+sent, and the next batches will go out in the coming week. If you own address
20+space, keep an eye out for an email from the urbit.org domain.
21+
22+Address registration points towards the real prize: the full ledger of Urbit
23+ships nesting in the cozy, decentralized embrace of the Ethereum-based PKI. To
24+this end, *Mark* `~palfun-foslup` added some Ethereum-facing cryptographic
25+functions [in the form of jets](https://github.com/urbit/urbit/pull/1028). And
26+they do what exactly what jets are supposed to do: take things from "unusably
27+slow" to "actually pretty good." This means that we can start deploying
28+Constitution transactions.
29+
30+Performance isn't always a matter of engineering challenges being surmounted,
31+though. Occasionally it's a matter of hearing the cracking of joints in
32+something that's turning the wrong way. *Elliot* `~littel-ponnys` felt something
33+so ghastly: a 200-millisecond delay on every Ford build. So the search began.
34+What was uncovered was two otherwise-benign lines that didn't get along with
35+*Paul's* `~fodwyt-ragful` recently merged Vere changes. Elliot handled the
36+Arvo side, Paul charged the Vere flank, and the build-system bug was vanquished.
37+
38+Yes, Urbit is a mission fearsome and sprawling, but we at Tlon live for the
39+hunt. Tearing up and replacing the entire stack just isn't enough, so we put our
40+own, meticulous spin on the concept of a cryptocurrency wallet. The *Urbit
41+Hierarchical Deterministic Wallet* is a _system_ of related key-pairs that have
42+distinct powers. That's because you want it to be easy to, say, authenticate
43+packets without having to risk a chunk of your net worth. It's *deterministic*
44+because key-pairs of a lower tier can be derived from those of a higher-tier,
45+making the whole system a nice balance of usability and security. Sound cool?
46+Check out the details in Tlon's
47+[Urbit Proposal](https://fora.urbit.org/proposals/posts/~2018.11.8..19.31.59..ba77~/)
48+on the matter.
49+
50+See you next week.
51+
52+*Rob* `~lodleb-ritrul`
content/posts/2018-11-6-update.mdnew file+45
@@ -0,0 +1,45 @@
1++++
2+title = "~2018.11.6 Update"
3+date = 2018-11-06
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2018.11.6."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.11.6`:
10+
11+![](https://media.urbit.org/fora/updates/2018.11.7-update.jpg)
12+
13+*Gavin* `~ridlur-figbud`, *Will* `~hadrud-lodsef`, and *Jimmy* `~haptyl-wanwes`
14+have been working tirelessly on the front-end tooling for bootstrapping our
15+[PKI on Ethereum](https://urbit.org/blog/2017.9-eth/). The fruits of their labor
16+are nearly ripe: all that's left is finalizing the copy and the documentation.
17+
18+*Philip* `~wicdev-wisryt`, a powerful Hoonist, is making sure that the Arvo
19+level of the stack is ready for the Great PKI Migration. Previously, every time
20+a ship booted, it would need to process every Ethereum block all the way up to
21+the present. This was _slow_, and we prefer life in the fast lane. So Philip
22+souped up `%jael`, our keys vane. When a child boots now, its parent sends it a
23+snapshot of the blockchain, rather than each individual event. And if we ever
24+need to revert some events because of a chain reorganization, we can just
25+restore an earlier snapshot instead of starting from scratch.
26+
27+Landscape is the charming, user-facing bow on the top of all of this, and it's
28+just completed the first round of internal user-feedback testing. The entire
29+company came together to raise interface hell, providing *Isaac*
30+`~davtyr-nimren` and *Chris* `~sigtus-hossyn` with a lot of useful data on the
31+performance and reliability characteristics of the web-facing Arvo
32+infrastructure, by way of the profiler in the Arvo interpreter.
33+
34+Pretty sweet.
35+
36+Or, _probably_ sweet. They tell you in college that it's never a compiler error,
37+but some of the "interesting" results of our profiling may, in fact, be
38+artifacts of a compiler error. *Ted* `~rovnys-ricfer` and *Elliot*
39+`~littel-ponnys` are spelunking the lowest depths of the stack, illuminating any
40+profiler bugs with their combined brilliance. It's unlikely that our heroes will
41+find any Balrogs, but you can never be too sure.
42+
43+It won't be long now, Martians.
44+
45+*Rob* `lodleb-ritrul`
content/posts/2018-12-18-update.mdnew file+56
@@ -0,0 +1,56 @@
1++++
2+title = "~2018.12.18 Update"
3+date = 2018-12-18
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2018.12.18."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.12.18`:
10+
11+![](https://media.urbit.org/fora/updates/2018.12.18-update.png)
12+
13+With December comes a promise of the land going to sleep to awaken renewed. We
14+at Tlon carry spirit of the season with us, even amid the perpetual 60-degree
15+weather of San Francisco.
16+
17+The Urbit network has, indeed, been renewed. *Logan* `~tacryt-socryp`
18+performed a breach on the network, wiping the slate clean. All urbits must be
19+booted again with their original tickets, which means that your crashed ships
20+now have a second chance at life. If your ship is now experiencing connectivity
21+troubles, don't worry: deleting your old pier should fix everything.
22+
23+On the infrastructure side, *Elliot* the Wonderworker `~littel-ponnys` brought
24+us a gift-sack of miraculous performance improvements. He started by fixing
25+memory management, slashing the amount that is required to be pre-allocated for
26+cells. Next, he found multiple places where the compiler was called
27+unnecessarily, replacing such calls with less-expensive caching. Also redundant
28+were many type-checker calls, which were squashed as well. Elliot *also* updated
29+the atom parser to remove a big chunk of latency from its operations. And, if
30+that wasn't enough, he wrote new jets that shaved precious milliseconds from the
31+web interface. Yes, five separate fixes, all of which add up to Urbit becoming
32+much, _much_ faster. The once-characteristic CLI input lag is now almost
33+imperceptible.
34+
35+*Morgan* `~hidrel-fabtel` and *Jimmy* `~haptyl-wanwes` are hard at work
36+overhauling the site for the New Year, both in terms of web design and the
37+presentation of content. The new website will also include Jimmy's primer,
38+which neatly explains Urbit in layman's terms.
39+
40+The docs boys -- *Rob* `~lodleb-ritrul`, *Josh* `~taglux-nidsep`, and *David*
41+`~rapfyr-diglyt` -- are helping out on this front. The documentation is being
42+completely reorganized so that it's more accessible and less overwhelming. A
43+great deal of new tutorial content will be included, and it's good enough that
44+it might put a dent in Urbit's arcane reputation.
45+
46+And finally, rejoice! The great Ethereum address-space migration has begun!
47+
48+If you own address space, you should have received an email with instructions
49+about how to register an Ethereum address with us so that we can grant you
50+cryptographic ownership of your address space. If you haven't received an email
51+a) check your spam folder and, if that doesn't work, b) send an email to
52+[registration@urbit.org](mailto:registration@urbit.org).
53+
54+See you next week.
55+
56+Rob `~lodleb-ritrul`
content/posts/2018-2-17-update.mdnew file+32
@@ -0,0 +1,32 @@
1++++
2+title = "~2018.2.17 Update"
3+date = 2018-02-17
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.2.17."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's what we've all been up to this week:
10+
11+*Curtis* `~sorreg-namtyv` this week, on behalf of `urbit.org,` [awarded Winter 2018 star grants](https://fora.urbit.org/posts/~2018.2.13..20.22.22..bddb~) to Urbit's top recent contributors. The winners this term were:
12+
13+- *Gold*, _64 stars_: Joe Bryan `~master-morzod`
14+- *Silver*, _32 stars_: Joshua Reagan `~taglux-nidsep`
15+- *Silver*, _32 stars_: Mikolaj `~ponmep-litsem`
16+- *Bronze*, _16 stars_: Assaf Berg `~rophex-hashes`
17+- *Bronze*, _16 stars_: Matt Levan `~mastyr-bottec`
18+- *Bronze*, _16 stars_: Anthony Arroyo `~poldec-tonteg`
19+
20+Thank you all again for helping bring Urbit to life!
21+
22+*Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`, and *Chris* `~sigtus-hossyn` have been progressing further on the new Urbit frontend.
23+
24+*Anton* `~pittyp-datfyn` has been working hard on making Urbit-flavored markdown, and subsequently, Fora, a lot less slow than it currently is.
25+
26+*Mark* `~palfun-foslup` submitted an [`urbit/arvo` pull request](https://github.com/urbit/arvo/pull/610) that implements permissions for Urbit's Clay filesystem, which Ted merged this week. Among other things, this will play a pivotal role in the new _Collections_ app actively being worked on, so that an Urbit user can store private notes, create invite-only fora and blogs, and collect a private archive of typed documents, all while maintaining referential transparency in the global immutable namespace.
27+
28+*Ted* `~rovnys-ricfer` and *Keaton* `~tonlur-sarret` have been working on a design for the data structures and control flow for the next version of Ford, Urbit's build system. We'll post to Fora once we've revised it some more.
29+
30+*Joshua* `~taglux-nidsep` rejoined [Mars Talk this week](https://www.youtube.com/watch?v=--hvpMqIeSA) as host with Ted and Keaton for Episode 21. We decided to take a break from deep technical talk to chat about the proposed _Nock 4K_ spec (a cosmic event in the Urbit universe), Josh's dissertation, Vere parallelism, and Urbit as a personal command center to call out to Earth blockchains.
31+
32+Have a great weekend, everyone!
content/posts/2018-2-24-update.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "~2018.2.24 Update"
3+date = 2018-02-24
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.2.24."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+This week was another busy one at the Tlon office. Here's what we were up to.
10+
11+This week we performed another [continuity breach](https://urbit.org/docs/using/admin/#-continuity-breaches). Now that we've fixed most of the bugs in new Talk, we think the network is going to be pretty smooth for a while. If you haven't already, follow our [setup](https://urbit.org/docs/using/setup) doc again to reboot your planet in this new continuity era. If you'd like a planet, [email me](mailto:keaton@tlon.io)!
12+
13+We're hosting a [Meetup now](https://www.meetup.com/urbit-sf/events/247797527/) at the Tlon office. *Josh* `~taglux-nidsep` is in town, and we all need a drink after the breach. Bring your laptop, stop by for a beer, and let us install Urbit for you. Or just relax and talk to people.
14+
15+*Mark* `~palfun-foslup` had a number of PRs merged this week for various bug fixes to Talk and Hall.
16+
17+*Joe* `~master-morzod` fixed several issues with Urbit's terminal.
18+
19+*Anton* `~pittyp-datfyn` made a one-line fix in Ford that fixed a major bug in cache performance. As a result, the website and Fora feel snappier.
20+
21+*Ted* `~rovnys-ricfer` and *Keaton* `~tonlur-sarret` continued working on the new Ford design.
22+
23+*Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`, and *Chris* `~sigtus-hossyn` worked more on the new frontend.
24+
25+*Curtis* `~sorreg-namtyv` is finishing up work on Hoon type defaulting, and has started working on a new design for the Hoon pretty printer.
26+
27+Josh, Ted and Keaton took a hiatus from Mars Talk this week to discuss future plans. We'll be back next week, better than ever.
28+
29+Have a great weekend!
content/posts/2018-2-5-update.mdnew file+25
@@ -0,0 +1,25 @@
1++++
2+title = "~2018.2.5 Update"
3+date = 2018-02-05
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2018.2.5."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+*Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`, and *Chris* `~sigtus-hossyn` worked on the upcoming frontend overhaul, including the new homepage, the _Collections_ and _Streams_ apps, and the primer. *Ted* `~rovnys-ricfer` and *Anton* `~pittyp-datfyn` continued to work on Ford.
10+
11+*Curtis* `~sorreg-namtyv` worked on fixing the defaulting behavior in Hoon. "The future is not wonky," he declares.
12+
13+*Keaton* `~tonlur-sarret` tested Isaac V's Fora implementation using his static `ren/tree`. It works.
14+
15+*Mark* `~palfun-foslup` gave a presentation at the FOSDEM open source conference in Belgium. Video can be found [here](https://www.youtube.com/watch?v=U-QBW6QIDto).
16+
17+*Isaac V* `~davtyr-nimren` completed the initial version of the static `ren/tree` replacement. The _Collections_ and _Streams_ apps are now being built on top of this foundation. See the [`mve` branch](https://github.com/urbit/arvo/tree/mve) of Arvo to track development.
18+
19+*Paul* `~fodwyt-ragful` [fixed a performance issue](https://github.com/urbit/urbit/pull/920) in unifying large nouns.
20+
21+*Iceman* `~littel-ponnys`'s testing framework has been merged into master. To use the framework to write unit tests, see the [user guide](https://github.com/urbit/arvo/blob/master/web/testing.umd). This pull request also includes a Hoon port of [Haskell's Prelude](https://hackage.haskell.org/package/base-4.10.1.0/docs/Prelude.html), which is [now available](https://github.com/urbit/arvo/blob/master/lib/new-hoon.hoon) as an alternate version of the Hoon standard library, including [unit tests](https://github.com/urbit/arvo/tree/master/tests/new-hoon). Discussion of this subject can be found on [Fora](https://fora.urbit.org/posts/~2017.10.17..04.09.16..7eb8~/).
22+
23+On [Mars Talk Episode 19](https://www.youtube.com/watch?v=q3Fjnv0RcR0) (our 20th episode!) this week, Keaton and Ted explained Ford, Urbit's functional reactive build system.
24+
25+`~rovnys-ricfer`
content/posts/2018-2-9-update.mdnew file+38
@@ -0,0 +1,38 @@
1++++
2+title = "~2018.2.9 Update"
3+date = 2018-02-09
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.2.9."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+*Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`, and *Chris* `~sigtus-hossyn` continue work on the new Urbit front-end.
10+
11+*Ted* `~rovnys-ricfer` and *Mark* `~palfun-foslup` finished their month-long project of labelling the Arvo issues.
12+
13+`~palfun` says:
14+After moving over Arvo-related issues from the Vere repository, Arvo hit >100 open issues. Knowing a lot is wrong is the
15+first step towards making a better product, but a big ol' pile of issues isn't really conducive to that. After
16+[proposing](https://github.com/urbit/arvo/issues/572) a set of labels for our repositories to use, `~rovnys` and I set
17+out to show all the issues some love.
18+Today we finally made it through the last of them! You can now look for issues that are
19+[easy](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22difficulty+low%22) or [good for
20+contributors](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+contributor+issue%22) to
21+tackle. There's plenty of labels now for all your filtering needs. Internally, we'll try to get eyes on issues labeled
22+[RFC](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22request+for+comments%22) and [help
23+wanted](https://github.com/urbit/arvo/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) every so often.
24+While contributors can't add labels themselves, we'll make sure your issues get tagged correctly. Enjoy!
25+
26+*Curtis* `~sorreg-namtyv` has been helping Ted and *Anton* `~pittyp-datfyn` with Ford. He's also continued his work on
27+improving default values for types in Hoon.
28+
29+*Keaton* `~tonlur-sarret` has been working on a super-secret project that he cannot discuss. Loose lips sink ships ...
30+
31+*Mark* `~palfun-foslup` has submitted a PR for Clay permissions. We just completed a second round of review, and Mark is
32+now doing more testing.
33+
34+*Iceman* `~littel-ponnys`, *Joe* `~master-morzod`, and Ted [had some
35+fun](https://fora.urbit.org/posts/~2018.2.9..21.50.49..709f~/) discussing various forms of persistence in Clay and Gall
36+in `urbit-meta`.
37+
38+Keaton and Ted demoed some Urbit web app examples in [Mars Talk Episode 20](https://www.youtube.com/watch?v=emWy1Afe4qY).
content/posts/2018-3-24-update.mdnew file+54
@@ -0,0 +1,54 @@
1++++
2+title = "~2018.4.7 Update"
3+date = 2018-04-07
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.4.7."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+We've had a busy past few weeks here at Tlon -- here's an update:
10+
11+We hired some people! We've added to the full-time team:
12+
13+- *Chris* `~sigtus-hossyn`
14+- *Jimmy* `~haptyl-wanwes`
15+- *Morgan* `~hidrel-fabtel`
16+- *Anthony* `~poldec-tonteg`
17+- *Elliot* `~littel-ponnys`
18+
19+Tonight we're hosting a [meetup](https://www.meetup.com/urbit-sf/events/248852261/) at the Tlon office. It's a party.
20+Morgan is DJing. Galen's showing Beat Takeshi movies on the back wall. Bring your laptop, and we can write Fizzbuzz in
21+Hoon together. Or just relax, have some drinks, and talk to the weird array of people who also want to replace the
22+internet.
23+
24+*Curtis* `~sorreg-namtyv` is in the Netherlands this week visiting *Mark* `~palfun-foslup`. They're self-auditing the
25+last parts of the [Urbit Constitution](https://github.com/urbit/constitution). While sitting in Gatwick Airport, Curtis
26+also wrote up some ideas he's been thinking about. Check out these essay drafts, posted to Fora:
27+
28+- [The Urbit public record draft](https://fora.urbit.org/posts/~2018.3.23..03.42.41..ab6d~)
29+- [Spirit and practice of digital homecoming draft](https://fora.urbit.org/posts/~2018.3.22..19.46.35..3499~)
30+
31+*Galen* `~ravmel-ropdyl`, *Anton* `~pittyp-datfyn`, *Chris* `~sigtus-hossyn`, *Jimmy* `~haptyl-wanwes`, and *Anthony*
32+`~poldec-tonteg` have been working more on the new Urbit frontend.
33+
34+*Ted* `~rovnys-ricfer`, *Elliot* `~littel-ponnys`, and *Keaton* `~tonlur-sarret` authored and published an Urbit Proposal
35+(UP) on New Ford:
36+
37+- [UP 4 - Ford Turboencabulator](https://fora.urbit.org/posts/~2018.3.15..04.24.35..a47f~)
38+
39+It's a monster post, but if you're a systems geek and want to read into the redesign of this important kernel module,
40+check it out.
41+
42+Ted's and Elliot's daily Ford progress can be tracked here:
43+
44+- [`urbit/arvo 'ford-turbo'`](https://github.com/urbit/arvo/tree/ford-turbo)
45+
46+*Joshua* `~taglux-nidsep`, Ted, and Keaton debuted _Mars Talk, Season 2_ on Wednesday night. To reboot the show, we gave
47+a high-level overview of the Urbit stack for new developers:
48+
49+- [Mars Talk Season 2, Ep. 1: High-Level Overview of the Urbit Stack](https://www.youtube.com/watch?v=UaRZVxthVeY)
50+
51+Subscribe to [Josh's channel](https://www.youtube.com/channel/UC3c0F4NhOD1LT5A1ShXEWiQ), and tune in weekly for all your
52+latest and greatest educational content and Urbit news.
53+
54+See some of you at the meetup tonight, and the rest of you Hoons on the network.
content/posts/2018-3-5-update.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "~2018.3.5 Update"
3+date = 2018-03-05
4+author = "~rovnys-ricfer"
5+description = "A short update from the Tlon team for the week of ~2018.3.5."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+*Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Chris* `~sigtus-hossyn`, *Jimmy* `~haptyl-wanwes`, and *Anton*
10+`~pittyp-datfyn` have continued the push toward the new Urbit frontend.
11+
12+*Curtis* `~sorreg-namtyv` has been working more on simplifying default value calculation in the Hoon type system.
13+
14+*Ted* `~rovnys-ricfer` and *Keaton* `~tonlur-sarret` have a design for a better Ford caching and rebuilding architecture,
15+and are now converting it to a UP to be reviewed by the community.
16+
17+*Mark* `~palfun-foslup` submitted a [pull request](https://github.com/urbit/arvo/pull/651) that implements the _Keccak_
18+family of cryptographic hashing functions in Hoon, including `SHA-3`, `shake`, and `rawshake`. We'll need `keccak` to
19+integrate Urbit with Ethereum.
20+
21+Also, [moons](https://urbit.org/docs/using/admin/#-moons) are back! You can run the `+moon` generator from your galaxy,
22+star or planet to create a ticket for a new moon. If you run your ship in the cloud and SSH in to use Talk, try booting a
23+moon on your laptop and using that for Talk instead. Messages you send from your moon will appear to have been sent from
24+your usual (parent) identity.
25+
26+*Iceman* `~littel-ponnys` wrote some deep thoughts on Clay, Urbit's filesystem, in this [meaty Fora
27+post](https://fora.urbit.org/posts/~2018.2.25..02.28.04..bd6d~/).
28+
29+P.S. We're hiring! If you're interested, email `galen@tlon.io`.
content/posts/2018-4-14-update.mdnew file+54
@@ -0,0 +1,54 @@
1++++
2+title = "~2018.4.14 Update"
3+date = 2018-04-14
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.4.14."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Replacing the internet is hard. Luckily, we have great people helping us do it. Here's what's new this week in Urbit:
10+
11+We hired more people! Tlon is pleased to have with us:
12+
13+- *Erik* `~patnes-rigtyn` - Erik is our new head of operations. He'll be keeping us all fed and organized, as well as
14+ helping us with some legal things.
15+- *Joe* `~master-morzod` - Joe... well, [you know Joe](https://joemfb.github.io/ez-urbits/). He's going to help us make
16+ Urbit easier.
17+- *Logan* `~tacryt-socryp` - Logan is going to build us a mobile app, work on which has already begun! Very exciting,
18+ indeed.
19+
20+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` have been working more on [new
21+Ford](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/). They turbocharged the `+execute` algorithm to
22+use a worklist data structure. This will not only be simpler to reason about, but in the future, it will allow future
23+support for parallelization of builds at the Vere level in MapReduce fashion. Their work is on
24+[Github](https://github.com/urbit/arvo/tree/ford-turbo).
25+
26+*Curtis* `~sorreg-namtyv` has been working hard to make Hoon's type system less confusing, as well as working on the
27+problem of data inspection in Hoon. Now that his "structure-to-type" code is mostly done (going from an abstract type
28+definition to its real compiled internal representation), he'll soon be done with his "type-to-structure" reverse
29+converter for getting abstract structure data out of any sets of values. More soon, but all of this will supersede the
30+current mold system and help make Hoon easier to understand, we think.
31+
32+*Galen* `~ravmel-ropdyl`, *Anton* `~pittyp-datfyn`, *Jimmy* `~haptyl-wanwes`, *Gavin* `~ridlur-figbud`, *Chris*
33+`~sigtus-hossyn`, and *Logan* `~tacryt-socryp` have been putting in more hard work on the new Urbit frontend. It's all
34+coming together really nicely, and things seem to be on schedule for a big mid-to-late summer release.
35+
36+We haven't posted an obscure graphic in a while. Here's one for the update to tide you over:
37+
38+![](https://media.urbit.org/fora/updates/~2018.4.13-Update-1.png)
39+
40+What it's for is totally top secret.
41+
42+*Keaton* `~tonlur-sarret` deployed sections to Fora, which will help categorize discussion content better and lead to better curation of StackOverflow-like questions and Urbit Proposals (UPs). He also merged some important pull requests into the system and deployed them to the network.
43+
44+*Mikolaj* `~ponmep-litsem`'s contributor work on moving Vere from Make to the [Meson](https://github.com/mesonbuild/meson) build system was merged this week. This solves several issues with bundling of dependencies, as well as making binary builds generally faster. Great work!
45+
46+*Joe* `~master-morzod` got his [HTTP pull request](https://github.com/urbit/urbit/pull/942) finally merged, which rewrites Vere's HTTP client and server to use the `h2o` library. This is great, as it will allow for full TLS termination in Urbit, which sets us up for full HTTPS connections to direct IP addresses of Urbit ships at `your-ship.urbit.org`, to be fully implemented soon.
47+
48+*Robert* `~lodleb-ritrul` has made a number of helpful PR's to the [Urbit docs](https://github.com/urbit/docs).
49+
50+*Mark* `~palfun-foslup` worked more on the Urbit constitution and put out some important fires caused by code-update syncs over the network and type mismatches. Computers are hard!
51+
52+*Joshua* `~taglux-nidsep`, Ted, Keaton, and Joe went on [Mars Talk](https://www.youtube.com/watch?v=EZKNLcdRbE0) to discuss the Facebook data scandal, the greater battle for privacy and personal computing, and Urbit's role in all of this. We think it turned out great.
53+
54+All in all, life has been good over here. Now it's time for a good weekend. See you all on the network!
content/posts/2018-4-7-update.mdnew file+38
@@ -0,0 +1,38 @@
1++++
2+title = "~2018.4.7 Update"
3+date = 2018-04-07
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.4.7."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+As always, the Urbit community has been working hard this week to replace the internet. Here's a summary:
10+
11+We're hosting [Hoon School](https://www.meetup.com/urbit-sf/events/249019207/) at our San Francisco office this Sunday. Come, bring your laptop, and we'll get you started building things in Urbit's language -- Hoon.
12+
13+Tlon has brought on two new interns! We're excited to have with us:
14+
15+- *Gavin* `~ridlur-figbud` - Gavin's going to help us with some promising frontend design projects.
16+- *Robert* `~lodleb-ritrul` - Robert's going to work with us on revamping our documentation, examples, and blog, writing
17+ high-quality original content. He has submitted several pull requests to the docs already this week, which have been
18+ merged.
19+
20+*Galen* `~ravmel-ropdyl`, *Anton* `~pittyp-datfyn`, *Chris* `~sigtus-hossyn`, and *Jimmy* `~haptyl-wanwes` have been
21+continuing to advance the state of the new Urbit frontend.
22+
23+*Mark* `~palfun-foslup` has been working hard with *Curtis* `~sorreg-namtyv` to bring the Urbit constitution into its
24+final, launchable state. He believes it's ready for its final security audit, which keeps us on track to launch it this
25+summer. You can find the latest contract code [here](https://github.com/urbit/constitution).
26+
27+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` have assembled a basic prototype of the main engine of the new Ford
28+redesign. They've been improving the design as they go, posting updates as comments to the [original Fora
29+post](https://fora.urbit.org/posts/~2018.3.15..04.24.35..a47f~/). Their code can be found
30+[here](https://github.com/urbit/arvo/tree/ford-turbo).
31+
32+Lastly, big shoutout to *Mikolaj* `~ponmep-litsem` for his work on [Plato](http://plato.urbitetorbi.org:8080/plato.html),
33+which now allows remote Hoon code execution without logging in. This is a big step towards improving our developer
34+onboarding, as it will allow newcomers to experience interactive Urbit programming in the browser quickly without having
35+to wait to boot their own ship. See Mikolaj's original thread on Github [here](https://github.com/urbit/docs/issues/239).
36+
37+We look forward to teaching some of you this Sunday the beginnings of the art of Martian functional programming. To all
38+else, we'll see you on the network. Have a great weekend, everybody!
content/posts/2018-5-16-update.mdnew file+49
@@ -0,0 +1,49 @@
1++++
2+title = "~2018.5.16 Update"
3+date = 2018-05-16
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.5.16."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Summer is around the corner, and the community has been working hard to make Urbit real. Here's an update on what new and exciting things have been happening:
10+
11+> _Meta_: We're going to start posting these to the new *Updates* section in Fora now -- and actually weekly!
12+
13+On [Mars Talk last week](https://www.youtube.com/watch?v=gBd0TZyz_HE), *Anthony* `~poldec-tonteg`, *Joshua* `~taglux-nidsep`, *Ted* `~rovnys-ricfer`, and *Keaton* `~tonlur-sarret` talked about Sail, a DSL for representing XML/HTML data in Hoon. We built a simple web page with Sail and highlighted what features Sail gives you, like Hoon's type system, the Ford build system, and full access to Hoon programming inline. Check it out!
14+
15+Tlon hired someone this week! We're excited to have with us:
16+
17+- *Isaac V* `~davtyr-nimren`
18+
19+Isaac has solid Hoon and frontend chops, having already implemented server-side rendering of Tree pages for us a short while back. He'll be taking on some of the Collections/Streams work to help us get ready for our summer release.
20+
21+*Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Chris* `~sigtus-hossyn`, *Gavin* `~ridlur-figbud`, and *Jimmy* `~haptyl-wanwes` have been working more on the new interface projects. Here's another leak:
22+
23+![New visual leak](https://media.urbit.org/fora/updates/~2018.5.15-Update-1.png)
24+
25+*Logan* `~tacryt-socryp` almost has a complete demo of the new Urbit iOS app working. This includes TouchID login authentication, an encrypted local database, full support for the Talk/Hall API for Streams, and automatic background fetching, among other features.
26+
27+*Curtis* `~sorreg-namtyv` has been working more on several important major language feature improvements to Hoon: namely, pretty-printing of typed data, and simplifying the type system. Work can be found on his [research branches](https://github.com/cgyarvin/arvo), but we plan on publishing a more formal post of the changes and major documentation updates when they roll out in the coming months. More soon!
28+
29+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` have made a bunch of progress on Ford Turbo. In addition to having a proof-of-concept solution for the main performance bottleneck of current Ford, they've now finished writing over half of the schematics (build types), implemented proper cache reclamation support, and they've gotten basic Clay integration functioning properly. You can find their work [here](https://github.com/urbit/arvo/tree/ford-turbo). They're posting more detailed updates as comments to their original [Urbit Proposal](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
30+
31+*Mark* `~palfun-foslup` has been wrapping up Urbit/ETH integration, and is now working on getting Jael, the new Arvo secret-storage vane, to compile. This would be a great addition to the summer release.
32+
33+*Joshua* `~taglux-nidsep`, *Robert* `~lodleb-ritrul`, and *Keaton* `~tonlur-sarret` have been getting lots of
34+documentation work done. They've seen several PR's go through to improve the Hoon standard library docs, simplify the
35+Hoon demo, update our examples to the latest syntax, improve the Urbit installation process, and more. Josh's
36+work-in-progress is happening [here](https://github.com/joshuareagan/doc-drafts/). The main docs are [on
37+Github](https://github.com/urbit/docs): if there's a piece of doc that's confusing to you, don't hesitate to file an
38+issue. Or better, submit a pull request.
39+
40+*Joe* `~master-morzod` is making strides on full HTTPS support for individual ships. He's implemented LetsEncrypt
41+support, ASN.1, and has Dynamic DNS functioning on our testnet. When all this work is done, `your-ship.urbit.org` should
42+connect automatically to the IP of the Unix machine your urbit is running on, rather than connecting to one of Tlon's
43+ships, which currently proxies Urbit network data through one of our stars, is slow, and is basically a straight-up
44+man-in-the-middle. Combined with private Collections and Streams, Urbit will be a lot more secure and usable within the
45+year.
46+
47+Overall, we're making progress. More next week!
48+
49+`~tonlur-sarret`
content/posts/2018-5-23-update.mdnew file+62
@@ -0,0 +1,62 @@
1++++
2+title = "~2018.5.23 Update"
3+date = 2018-05-23
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.5.23."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from Tlon for the week of `~2018.5.22`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.5.22-Update-1.jpg)
12+
13+We're hosting a meetup [this Friday](https://www.meetup.com/urbit-sf/events/250889557/) at the SF office. Ted will give a
14+quick update on new Ford, and then it'll be time to relax, listen to music (our friend Grayson will be playing records),
15+and talk IRL. Feel free to bring your laptop, and we'll install Urbit for you and give you a tour of Arvo.
16+
17+This week, the interface team -- *Galen* `~ravmel-ropdyl`, *Gavin* `~ridlur-figbud`, *Jimmy* `~haptyl-wanwes`, *Chris*
18+`~sigtus-hossyn`, *Isaac V* `~davtyr-nimren`, *Logan* `~tacryt-socryp`, and *Anthony* `~poldec-tonteg` -- has continued
19+building the new Arvo frontend. Here's a teaser of something the desktop guys have been working on:
20+
21+![](https://media.urbit.org/fora/updates/~2018.5.22-Update-2.jpg)
22+
23+*Joe* `~master-morzod` fixed an important performance issue in Vere where galaxy IP resolution has been happening
24+synchronously. This now works asynchronously, which should help take some load off of our stars. He also got support for
25+`/.well-known/*` LetsEncrypt paths working in Eyre and refactored a lot of parsing and cryptography code in Arvo as part
26+of his HTTPS-implementation work on his [personal WIP Arvo fork](https://github.com/joemfb/arvo/tree/acme-wip), to be
27+brought onto master soon.
28+
29+*Keaton* `~tonlur-sarret` got a demo AMI (Amazon Machine Image) working on Amazon Web Services with the Urbit binary
30+pre-installed, avoiding the need for the user to manually build from source. He plans on documenting this more and
31+working on a clean-slate onboarding system with *Morgan* `~hidrel-fabtel` for our summer MVE release. But for now,
32+consider this a proof-of-concept for one way to get an Urbit running in the cloud more easily. You can follow the short
33+bulleted steps [here](https://gist.github.com/keatondunsford/8c19bc232650ec1adbb9b6c38954cd90) to get up and running .
34+
35+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` are getting their new beautiful build system closer to the finish
36+line. New Ford supports nearly all of the functionality laid out in the original [Urbit
37+Proposal](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/) and passes all current tests. This past
38+week, Ted and Elliot have implemented more schematics and a bunch of the `+cranes`, or Ford runes. If you're into build
39+systems, check out their more detailed updates they've been posting as comments to the UP.
40+
41+*Mark* `~palfun-foslup` has been working on getting the Urbit/ETH integration logic into Jael, Arvo's new secret-storage
42+vane, to go live in the summer MVE release. Part of this is implementing direct support for querying the Ethereum
43+blockchain for the state of the the Urbit constitution smart contract. In this model, Urbit ships can choose to either
44+get this state directly from their parent stars or galaxies, or they can query the blockchain themselves. An important
45+step towards making Urbit address-space ownership real, Mark's work-in-progress can be found
46+[here](https://github.com/Fang-/arvo/tree/research-constitution).
47+
48+*Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` have been continuing to do ~zod's work to improve the state of the
49+Urbit documentation. Josh has been writing a [new Hoon tutorial series](https://github.com/joshuareagan/doc-drafts) to
50+supersede the current Urbytes, while Robert has been blazing a trail through the current standard library docs, making
51+sure they're up-to-date and [improving them](https://github.com/urbit/docs/tree/rmariani-patch-6) as he goes. There's
52+been a lot of activity on Github recently. Don't be shy: [submit your first docs pull
53+request](https://github.com/urbit/docs), a classic rite of passage for the neophyte Hoon programmer.
54+
55+Lastly, Josh, Ted, and Keaton will be live on Mars Talk tomorrow night, Wednesday at 8:30PM PST. We'll post the Hangouts
56+link in Talk. Tune in!
57+
58+Overall, summer is getting closer, and we're excited about the work that's getting done. More this week.
59+
60+See you on Friday!
61+
62+`~tonlur-sarret`
content/posts/2018-5-29-update.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "There is no Urbit ICO"
3+date = 2018-05-29
4+author = "~Erik Newton"
5+description = "It's a dangerous internet out there, don't get scammed."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+FYI: We are not conducting an ICO of any kind. Anything you have heard to the
10+contrary is wrong. Please be careful of scams.
11+
12+Any future information about the distribution of address space will come from
13+urbit@urbit.org or [https://twitter.com/urbit](https://twitter.com/urbit).
14+Accept no substitutes!
content/posts/2018-5-30-update.mdnew file+74
@@ -0,0 +1,74 @@
1++++
2+title = "~2018.5.30 Update"
3+date = 2018-05-30
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.5.30."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's an update from the team at Tlon for the week of `~2018.5.30`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.5.30-Update-1.jpg)
12+
13+We had a great meetup last Friday. Thanks to Ted for talking about Ford, Grayson and Morgan for DJing, and everyone for
14+showing up! We'll keep you updated about the next one.
15+
16+We performed a [continuity breach](https://urbit.org/docs/using/admin/#-continuity-breaches) last week. This means that,
17+if you haven't already, you need to recreate your urbit. The good news is: the network is faster, people are hanging out
18+in in `/urbit-meta`, and a couple of infrastructure changes were made to make `urbit.org` authentication and proxying a
19+bit more snappy. See [this post](https://fora.urbit.org/general/posts/~2018.5.26..03.57.28..7b26~/) for help getting set
20+back up.
21+
22+*Curtis* `~sorreg-namtyv` has been working more on data printing in Hoon. Still work-in-progress, the end result will
23+have new, simpler ways to express Hoon types, data you want to print, helpful conversion arms accessible via the standard
24+library, and a couple new runes. If you like deep language code and compiler internals, you can check out Curtis's
25+research branch [here](https://github.com/cgyarvin/arvo/tree/research-tome).
26+
27+The interface team -- *Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Logan* `~tacryt-socryp`, *Chris*
28+`~sigtus-hossyn`, *Jimmy* `~haptyl-wanwes`, and *Gavin* `~ridlur-figbud` -- has been working more on MVE. We'll have more
29+to show in the next couple weeks.
30+
31+*Isaac V* `~davtyr-nimren` worked on Arvo and Collections last week. He implemented a query parameter in Eyre to support
32+setting the longpoll timeout duration manually, which solves an issue in the way of us doing background refreshes in our
33+iOS app we're developing. He also got Clay permissions logic into Collections so that the tool will support read-only,
34+write-only, and private/invite-only collections in addition to public ones. Lastly, Isaac's been working on a static-site
35+generator in Urbit to support more performance-ready web serving over Nginx in tandem with Eyre. The first step was
36+modifying Kiln to support batch-writing multiple files to Clay at once. Isaac's work-in-progress can be found
37+[here](https://github.com/ixv/arvo/branches) -- check it out if you're looking to start hacking near the border between
38+Arvo's interface and infrastructure.
39+
40+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` finished _all_ of the new Ford Turbo schematics (Ford build types)
41+and a bunch more cranes (Ford runes). Their next step is to integrate new Ford with the current master kernel by loading
42+it in as a separate vane, then incrementally connecting the wires needed for it to start working together with real Arvo.
43+You can find Ted and Elliot's work [here](https://github.com/urbit/arvo/tree/ford-turbo). If you're into functional
44+programming, build systems, or just want to read the best Hoon code we have on display currently, check it out, and the
45+updates they've been posting to their Urbit Proposal
46+[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~).
47+
48+*Mark* `~palfun-foslup` worked on Jael, Urbit's new secret-storage vane, which we're also expanding to include the logic
49+for querying the state of the [Urbit consitution](https://github.com/urbit/constitution) which will go live on the
50+Ethereum blockchain in the coming months. Mark has been implementing the necessary Arvo `+gift`s and `+task`s of Jael's
51+to properly interface with the Urbit constitution via the Ethereum API, then update the local urbit's state of the land
52+registry and other contract data so that it can use it for networking and in other services. You can find Mark's
53+work-in-progress [here](https://github.com/Fang-/arvo/tree/research-constitution). Check it out if you're excited by
54+blockchains, or also just want to see what good, documented Hoon code looks like.
55+
56+*Joe* `~master-morzod` worked more on the HTTPS project. This week was mostly about refactoring the existing code by
57+adding comments, renaming some things, and improving the style. Safe to say that when this project is done, we think it
58+will be understandable. The ASN1 and PKCS libraries are mostly complete; progress will continue to finish up the last of
59+the libraries and necessary styling, then integrate this into current Arvo/Vere. Joe's work-in-progress is
60+[here](https://github.com/joemfb/arvo/tree/acme-wip).
61+
62+*Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` made a bunch more progress on the docs. Josh has been adding more
63+to his [new WIP Hoon tutorials](https://github.com/joshuareagan/doc-drafts), and both Josh and Rob have gifted us with
64+several [pull requests](https://github.com/urbit/docs/pulls) documenting the simple but elusive `=,` rune and refactoring
65+much of the existing standard library doc. The docs are a great place to start learning and contributing. [Check them
66+out](https://github.com/urbit/docs) on Github, and [submit an issue](https://github.com/urbit/docs/issues), tagging Josh
67+and Rob, if you're confused by anything, or think something is documented wrong.
68+
69+Josh and Ted also did a [Mars Talk](https://www.youtube.com/watch?v=IgQo5aSezK4) this week -- Season 2, Episode 6 -- to
70+help people get started with Hoon. They went through some simple onboarding steps and basic math functions to introduce
71+some of the fundamental concepts in Hoon. If you're new to Hoon and not sure where to start, check out that episode, and
72+feel free to leave comments below here for feedback.
73+
74+Overall, work continues to wipe the slate of computing clean. More news next week.
content/posts/2018-6-14-update.mdnew file+70
@@ -0,0 +1,70 @@
1++++
2+title = "~2018.6.14 Update"
3+date = 2018-06-14
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.6.14."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.6.14`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.6.13-Update-1.jpg)
12+
13+*Ted* `~rovnys-ricfer` and *J* `~leb / ~ribben-donnyl` had a great time in Boulder, CO last week at LambdaConf 2018. Ted
14+gave his same Ford talk he gave at the last meetup to a small group there. We should see the video recording of that
15+published in a few months when the editing process is finished. J's talk on Hoon was a success. He posted to Fora this
16+week with a link to his slides and talk turned into article form for Martian consumption. Check it out
17+[here](https://fora.urbit.org/general/posts/~2018.6.10..19.25.23..6f16~/)!
18+
19+J also designed some [new T-shirts](https://urbit.threadless.com/). What a fan! We're working on designing some new
20+official ones ourselves, but until then, feel free to score one of these.
21+
22+We breached again last Friday. People were hitting a [nasty Vere issue](https://github.com/urbit/urbit/issues/996)
23+between versions from a breaking change, but breaching fixed it. We posted a short reminder of post-breach steps to Fora
24+[here](https://fora.urbit.org/general/posts/~2018.6.9..08.37.48..f79a~/). Let us know if you're hitting any issues
25+getting back up and running in the new continuity era.
26+
27+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` reunited this week after LambdaConf. Gall and Dojo on the
28+`ford-turbo` branch now both use new Ford. Next up is Clay, in tandem with one big necessary algorithm change: adding
29+support for the promotion of one-time builds, useful for things like generators. As usual, their code progress is
30+[here](https://github.com/urbit/arvo/tree/ford-turbo).
31+
32+The interface team -- *Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Jimmy* `~haptyl-wanwes`, *Gavin*
33+`~ridlur-figbud`, *Chris* `~sigtus-hossyn`, *Isaac* `~davtyr-nimren`, and *Logan* `~tacryt-socryp` -- has commenced
34+internal private alpha MVE testing on web and mobile. Our alpha Urbit iOS app is shipped to Apple's TestFlight, and we've
35+all been having a blast testing it out on our phones. New web Talk in MVE even supports image display. We can't wait to
36+ship this all soon -- just need to fix the last of bugs and design issues here and there first.
37+
38+![](https://media.urbit.org/fora/updates/~2018.6.13-Update-2.jpg)
39+
40+*Curtis* `~sorreg-namtyv` worked more on Hoon. He's been working on generalizing name binding by replacing `+toga` in
41+`hoon.hoon` as part of the new Hoon doc integration. That work in progress is
42+[here](https://github.com/cgyarvin/arvo/tree/research-tome). He's also been working on designing the "launch ceremony"
43+for Urbit/Ethereum private keys with *Morgan* `~hidrel-fabtel` and *Will* for when we go on chain with our Urbit
44+constitution on ETH very soon. We'll publish details about all of this once we've squared everything away.
45+
46+*Mark* `~palfun-foslup` worked more on locking down the Urbit constitution by incorporating feedback from our audits and
47+putting more safeguards around how address space is transferred. Martian soil is too valuable to be lost through a
48+fat-fingered Ethereum transaction or, worse, malice! We've also been working with some contributors out Texas way to get
49+our MyEtherWallet fork up to speed with the latest, greatest contract work. You can check out those changes
50+[here](https://github.com/urbit/etherwallet/pull/29)
51+
52+*Joe* `~master-morzod` is cranking away at setting up a reverse TCP proxy (and all of the associated machinery), so that
53+we can scrap the Ames-based proxy currently done by ship.urbit.org and move over to real, live HTTPS termination for all
54+ships. This is a major undertaking and has required `~master` to touch a lot of different parts of the system: Eyre,
55+Vere, Ames -- you name it. Once his head is above water, he's going to write something up for us and tell us what he's
56+seen in his wanderings through the system.
57+
58+And *Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` have spent yet another week making the docs more awesome.
59+Josh's new Hoon tutorials (WIP link: [here](https://github.com/joshuareagan/doc-drafts)) are nearing completion. Rob
60+opened up a couple more PR's improving the standard-library docs. You can check the latest `urbit/docs` pull requests
61+[here](https://github.com/urbit/docs/pulls).
62+
63+There's also a third set of Hoon exercises which Josh posted to Fora
64+[here](https://fora.urbit.org/answers/posts/~2018.6.7..20.54.43..2261~/). Give them a shot!
65+
66+No Mars Talk this week. Ted and Josh will return next week to talk about treaps, and where we're using them in Arvo.
67+
68+That's it for this week!
69+
70+`~tonlur-sarret` and `~poldec-tonteg`
content/posts/2018-6-21-update.mdnew file+59
@@ -0,0 +1,59 @@
1++++
2+title = "~2018.6.21 Update"
3+date = 2018-06-21
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.6.21."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.6.21`
10+
11+![](https://media.urbit.org/fora/updates/~2018.6.13-Update-1.jpg)
12+
13+The interface team -- *Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`,
14+*Gavin* `~ridlur-figbud`, *Chris* `~sigtus-hossyn`, *Anthony* `~poldec-tonteg`, and *Isaac* `~davtyr-nimren` -- worked
15+more on MVE. We're getting incrementally closer to being able to release a public beta. Life has been active on the
16+testnet as the team coordinates to fix the last known bugs and design issues.
17+
18+*Logan* `~tacryt-socryp` noticed a lacking feature in Hall: read vs. unread messages, a common feature in most messaging
19+applications. Logan decided to embark on his first real Hoon project and successfully implemented this last week. You can
20+check out the code [here](https://github.com/loganallenc/arvo/tree/hall-unread), to be merged into MVE soon.
21+
22+The constitution team -- *Mark* `~palfun-foslup`, *Curtis* `~sorreg-namtyv`, *Morgan* `~hidrel-fabtel`, *Will*
23+`~hadrud-lodsef`, *Anthony* `~poldec-tonteg`, and Texan *Ben* `~mirfet-hocbyt` -- has been continuing to work to get us
24+on chain by the end of the summer. Mark has been fortifying some of the contracts and Arvo-side cryptography and Jael
25+functionality, while Ben and Anthony continue to finalize the control flow of our `MyUrbitWallet` fork. Curtis, Morgan,
26+and Will are striding forward on designing the key-launch ceremony, more details of which we'll publish soon. The latest
27+[constitution](https://github.com/urbit/constitution), [Urbit wallet](https://github.com/urbit/etherwallet), and
28+[Arvo](https://github.com/Fang-/arvo/tree/research-constitution) code with the latest Jael work can all be found on
29+GitHub.
30+
31+*Curtis* `~sorreg-namtyv` worked more on Hoon, continuing to improve face-wrapping (variable naming) around values. He's
32+also been working on a couple of new runes, like `^#`, whose designs aren't yet fully complete, but when they are, we'll
33+document and share with y'all. Curtis' research [Arvo](https://github.com/cgyarvin/arvo/tree/research-tome) and
34+[Vere](https://github.com/cgyarvin/urbit-1/tree/research-tome) code can be found on GitHub.
35+
36+*Joe* `~master-morzod` worked more on HTTPS this past week and got some of his work merged into the `urbit/arvo`
37+`collections` branch, which will go live with the MVE release. Included in the PR are new moves in Eyre and Ames to
38+support his reverse TCP proxy, HTTPS server configuration changes, and child-ship IP address changes. Additionally added
39+is a dynamic-DNS Gall app, which brings us closer to our envisioned ideal of getting `your-ship.urbit.org` to connect
40+directly to your ship's IP address, rather than going through Tlon's intermediary proxying ships. Our next step is to
41+deploy this to our internal testnet before releasing it into the wild. Joe's work can be found
42+[here](https://github.com/urbit/arvo/pull/752) on GitHub -- very exciting.
43+
44+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` now nearly have a fully-integrated Ford Turbo. They can boot a ship
45+with a Clay that exclusively uses Ford Turbo and not old, slow Ford. Gall integration is also complete. Now they're
46+focused on finishing the caching implementation, as well as a new `%walk` schematic to perform a graph-search through the
47+available marks for data conversion. Ted and Elliot's work is [here](https://github.com/urbit/arvo/tree/ford-turbo) on
48+GitHub, and their more detailed updates are [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)
49+as comments to their original Fora post.
50+
51+And last, but not least, *Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` have continued their much-needed
52+doc-improvement work. Josh's in-progress drafts of his new Hoon tutorials are
53+[here](https://github.com/joshuareagan/doc-drafts), and Rob's latest pull requests improving the standard library docs
54+are [here](https://github.com/urbit/docs/pulls). If there's anything you feel should be documented and currently isn't,
55+feel free to write us a comment below.
56+
57+May `~zod` be with you all. Have a great rest of your week.
58+
59+`~tonlur-sarret` and `~poldec-tonteg`
content/posts/2018-6-6-update.mdnew file+77
@@ -0,0 +1,77 @@
1++++
2+title = "~2018.6.6 Update"
3+date = 2018-06-06
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.6.6."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.6.6`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.6.6-Update-1.jpg)
12+
13+We hired somebody! We're happy to welcome to Tlon:
14+
15+- *Will* `~hadrud-lodsef` -- Will studied CS at Stanford and worked for years in VC. Among other things, he likes
16+ ceramics and decentralized systems. He's going to work on a mix of things for us, from operations to Urbit private-key
17+ distribution and management.
18+
19+The interface team -- *Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Isaac V* `~davtyr-nimren`, *Jimmy*
20+`~haptyl-wanwes`, *Chris* `~sigtus-hossyn`, *Logan* `~tacryt-socryp`, and *Gavin* `~ridlur-figbud` -- is narrowing in on
21+an alpha version of MVE, nearing readiness to start testing internally. Anthony and Isaac have been getting our internal
22+testnet set up, and Logan is ready to submit our alpha iOS app to Apple's TestFlight. We'll keep you posted about public
23+beta testing, on the way soon.
24+
25+*Isaac V* `~davtyr-nimren` finished an [in-Urbit static-site generator](https://github.com/urbit/arvo/pull/745) this
26+week. When merged, this will give you the option to easily host your urbit's static files through a production-ready Unix
27+web server like Nginx in tandem with Arvo's web server, Eyre. This way, you can still host fast collections while we
28+continue to work on Arvo's performance.
29+
30+*Ted* `~rovnys-ricfer` has been at LambdaConf 2018 this week spreading the good news of `~zod` and
31+non-lambda-calculus-based functional programming. Our good friend and galactic senator Justin LeBlanc `~leb` gave a talk,
32+_Hoon and You - A Functional Programming Perspective_. Hopefully we can get slides and a video for you soon.
33+
34+*Elliot* `~littel-ponnys` worked more on new Ford. It's now working as its own separate vane in the kernel, `%turbo`, and
35+it reloads itself on Arvo `|reset`s and `|reload`s. While old `%ford` still exists, the next steps are to integrate
36+`%turbo` with the rest of the system. Elliot has been working on a separate Dojo, _Dontjo_, that uses Turbo instead of
37+old Ford. New Ford work is [here](https://github.com/urbit/arvo/tree/ford-turbo), and Fora updates are
38+[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
39+
40+*Mark* `~palfun-foslup` has been wrapping up Urbit-on-ETH constitution work this week. We're just about in our final lap,
41+finalizing our audit reports, fixing the last of known bugs, upgrading the contracts to latest Solidity and OpenZeppelin
42+versions, and rounding our our test coverage, code comments and documentation, and ERC721 compliance. The latest contract
43+code can be found [here](https://github.com/urbit/constitution). We'll come out with an official email blast and
44+urbit.org post with more information when we're all ready to go.
45+
46+*Curtis* `~sorreg-namtyv` has been working more on Hoon. Notably, one new change on the table is switching the model-arm
47+rune from `+=` to `+$`, keeping it more in line with the `$` family of Hoon syntax relating to models. The feedback from
48+the community in `/urbit-meta` on this was positive. Additionally, he's been rethinking the `+toga` data structure for
49+dealing with faces (variable names) on Hoon values. His research branch is
50+[here](https://github.com/cgyarvin/arvo/tree/research-tome). We'll have more to report next week.
51+
52+*Joe* `~master-morzod` has been continuing work on the HTTPS project. Notably this week, Joe's been working on an
53+in-Urbit reverse TCP proxy, so that planets behind private networks / NATs can still have their data served to
54+`ship.urbit.org` via their star over Ames. With this last feature, in addition to Joe's mostly-completed `libh2o`,
55+LetsEncrypt, and dynamic-DNS Gall-app implementations, the fast and secure direct `ship.urbit.org` feature of MVE should
56+be primed to get tested into existence, then shipped. Joe's latest work-in-progress is
57+[here](https://github.com/joemfb/arvo/tree/reverse-proxy-notification).
58+
59+*Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` blazed through more doc this week. Josh's [new Hoon
60+tutorials](https://github.com/joshuareagan/doc-drafts) are starting to come together. Rob has been improving the
61+standard-library docs and has open [several pull requests](https://github.com/urbit/docs/pulls), to be reviewed and
62+merged this week. The docs are getting better.
63+
64+If you haven't already, give Josh's Hoon exercises a shot! (aka Hoon Bootcamp) You can find exercise set #1 on Fora
65+[here](https://fora.urbit.org/answers/posts/~2018.5.24/) and set #2
66+[here](https://fora.urbit.org/answers/posts/~2018.6.1/).
67+
68+With Ted out this week and Josh focused on doc work, they're going to push back Mars Talk to next week. So, look out for
69+next week's update for the time and topic of Season 2, Episode 7.
70+
71+One last reminder: [_there is no Urbit ICO_](https://urbit.org/updates/2018.5.29-no-ico). Anything else that you've heard
72+is wrong. Don't get scammed!
73+
74+We hope you've been enjoying these weekly updates, now [actually weekly](https://urbit.org/blog/weekly-updates/).
75+`/urbit-meta` has been really active lately. Don't be shy to pop in and meet everybody.
76+
77+See you around!
content/posts/2018-7-13-update.mdnew file+65
@@ -0,0 +1,65 @@
1++++
2+title = "~2018.7.13 Update"
3+date = 2018-07-13
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.7.13."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.7.13`:
10+
11+> "A complex system that works is invariably found to have evolved from a simple
12+ system that worked. A complex system designed from scratch never works and
13+ cannot be patched up to make it work. You have to start over with a working
14+ simple system."
15+
16+-[John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)
17+
18+![](https://media.urbit.org/fora/updates/~2018.7.13-Update-1.jpg)
19+
20+The Infrastructure team -- *Curtis* `~sorreg-namtyv`, *Anthony* `~poldec-tonteg`, *Joe* `~master-morzod`, *Ted* `~rovnys-ricfer`, *Elliot* `~littel-ponnys`, *Mark* `~palfun-foslup` -- worked on improving the core of the Urbit system:
21+
22+- Curtis worked on improving Hoon: [`research-tome` Arvo](https://github.com/cgyarvin/arvo/tree/research-tome),
23+ [`research-tome` Vere](https://github.com/cgyarvin/urbit-1/tree/research-tome)
24+- Joe continued to implement in-Urbit HTTPS integration: [`https-acme-wip`
25+ Arvo](https://github.com/urbit/arvo/tree/https-acme-wip), [`https-proxy-config`
26+ Vere](https://github.com/urbit/urbit/tree/https-proxy-config)
27+- Ted and Elliot continued the state-machine reimplementation of new Ford: [`ford-turbo-state-machine`
28+ Arvo](https://github.com/urbit/arvo/tree/ford-turbo-state-machine),
29+ [updates](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)
30+- Mark made crypto additions to the kernel: [`crypto-additions` Arvo](https://github.com/urbit/arvo/tree/crypto-additions)
31+
32+The documentation team -- *Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` --
33+improved how we communicate how Urbit works:
34+
35+- Josh continued work on the new Hoon tutorials: [`master` doc drafts](https://github.com/joshuareagan/doc-drafts)
36+- Robert put in more work improving the Hoon standard library doc: [docs pull
37+ requests](https://github.com/urbit/docs/pulls)
38+
39+The Interface team -- *Galen* `~ravmel-ropdyl`, *Anthony* `~poldec-tonteg`, *Jimmy* `~haptyl-wanwes`, *Gavin*
40+`~ridlur-figbud`, *Chris* `~sigtus-hossyn`, *Isaac V* `~davtyr-nimren`, *Logan* `~tacryt-socryp`, and *Keaton*
41+`~tonlur-sarret` -- worked on Landscape (formerly MVE):
42+
43+- Galen, Jimmy, and Gavin have continued work on Landscape's visual design
44+- Keaton worked on Landscape cloud onboarding on DigitalOcean
45+- Chris improved the desktop client, still in private alpha
46+- Logan improved networking in the iOS TestFlight app, still in private alpha
47+- Isaac V has been rearchitecting the Landscape backend
48+- Anthony has been getting the latest Landscape code onto the testnet: [`testnet`
49+ Arvo](https://github.com/urbit/arvo/tree/testnet)
50+
51+The Constitution/Keys team -- *Mark* `~palfun-foslup`, *Curtis* `~sorreg-namtyv`, *Morgan* `~hidrel-fabtel`, *Will* `~hadrud-lodsef`, *Anthony* `~poldec-tonteg`, and *Ben* `~mirfet-hocbyt` -- worked to make Urbit computing cryptographically real:
52+
53+- Curtis, Morgan, and Will have been fortifying the current proposed key ceremony, still in private draft mode
54+- Ben has been cleaning up Wallet: [`mercury` Wallet](https://github.com/urbit/etherwallet)
55+- Mark has updated our Constitution to ERC721 compliance, among other updates, and built out more of Jael: [`master`
56+ Constitution](https://github.com/urbit/constitution) [`research-constitution`
57+ Arvo](https://github.com/Fang-/arvo/tree/research-constitution)
58+
59+We're alive and growing.
60+
61+`~tonlur-sarret` and `~poldec-tonteg`
62+
63+---
64+
65+Photo credit: [Superstudio](https://en.wikipedia.org/wiki/Superstudio)
content/posts/2018-7-20-update.mdnew file+56
@@ -0,0 +1,56 @@
1++++
2+title = "~2018.7.20 Update"
3+date = 2018-07-20
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.7.20."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.7.20`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.7.13-Update-1.jpg)
12+
13+The Keys team spent another week moving fast to get us on chain. *Anthony*
14+`~poldec-tonteg` and *Morgan* `~hidrel-fabtel` worked on a new design for
15+Wallet, which will manage your Urbit address-space ownership. *Curtis*
16+`~sorreg-namtyv` and *Mark* `~palfun-foslup` fortified the Constitution more.
17+*Will* `~hadrud-lodsef` and *Keaton* `~tonlur-sarret` worked to make sure that
18+existing address-space owners can safely and easily register their ownership
19+within the new system. More on this soon.
20+
21+The Infrastructure team was hard at work this week. *Joe* `~master-morzod`
22+merged much of his HTTPS work into the `collections` branch of Arvo and is onto
23+broader Arvo integration testing (code [here](https://github.com/urbit/arvo/tree/collections)).
24+*Ted* `~rovnys-ricfer`
25+and *Elliot* `~littel-ponnys` cleaned up new Ford (code
26+[here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo)),
27+trimming off several hundred lines
28+of code and making it easier to reason about while staying within our desired
29+performance goals. *Curtis* `~sorreg-namtyv` finished the new implementation of
30+the `?=` ("wut-tis") rune and designed the type analysis infrastructure for the
31+new noun printer. *Mark* `~palfun-foslup` produced an Urbit-specific variant of
32+the Argon2 password-hashing function (code [here](https://github.com/urbit/argon2)).
33+*Travis* `~rigdyn-sondur`, an old friend of Tlon, has also been writing crypto
34+jets this week, and those will go in the kernel soon.
35+
36+The Interface team has had another great week of making Urbit more usable.
37+*Jimmy* `~haptyl-wanwes` has been working on a new urbit.org, written in Sail.
38+*Galen* `~ravmel-ropdyl` and *Gavin* `~ridlur-figbud` have been reviewing and
39+finalizing some Landscape design edits and coordinating with the frontend team.
40+*Chris* `~sigtus-hossyn` and *Logan* `~tacryt-socryp` have been implementing the
41+updated designs on desktop and mobile and churning through issues. *Isaac*
42+`~davtyr-nimren` worked on a better backend JSON interface for the Collections
43+app and made sure that Collections is using all of the permissioning that Clay now offers.
44+
45+And the Documentation team continued their quest to teach the world Hoon. *Josh*
46+`~taglux-nidsep` worked more on his new Hoon tutorials (drafts [here](https://github.com/joshuareagan/doc-drafts)).
47+*Robert* `~lodleb-ritrul` successfully documented the Hoon standard library cores
48+for date/time and hashing (PR's [here](https://github.com/urbit/docs/pulls)).
49+
50+Keep on Hooning, Martians. See you in `/urbit-meta`.
51+
52+`~tonlur-sarret` and `~poldec-tonteg`
53+
54+---
55+
56+Photo credit: [OMA](http://oma.eu/news/from-ciam-to-cyberspace-architecture-and-the-community)
content/posts/2018-7-3-update.mdnew file+64
@@ -0,0 +1,64 @@
1++++
2+title = "~2018.7.3 Update"
3+date = 2018-07-03
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.7.3."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+![](https://media.urbit.org/fora/updates/~2018.7.2-Update-1.jpg)
10+
11+Here's a short update from the team at Tlon for the week of `~2018.7.2`
12+
13+The interface team -- *Galen* `~ravmel-ropdyl`, *Jimmy* `~haptyl-wanwes`, *Logan*
14+`~tacryt-socryp`, *Gavin* `~ridlur-figbud`, *Chris* `~sigtus-hossyn`, *Anthony*
15+`~poldec-tonteg`, and *Isaac V* `~davtyr-nimren` -- worked more on MVE. Chris
16+deployed a new _command palette_ for MVE to our internal testnet which we've been
17+playing around with and are excited to ship soon. Isaac is re-architecting
18+Collections a bit. Logan has been buffing up his read/unread code for Hall/Talk.
19+The design team has been working for a while with our `@p` ship-naming scheme
20+for a cool new thing. Gavin made this visualization program of the current `@p`
21+syllables which we've been pretty entranced by:
22+
23+![](https://media.urbit.org/fora/updates/~2018.7.2-Update-2.jpg)
24+
25+The constitution team -- *Mark* `~palfun-foslup`, *Curtis* `~sorreg-namtyv`,
26+*Morgan* `~hidrel-fabtel`, *Will*
27+`~hadrud-lodsef`, *Anthony* `~poldec-tonteg`, and *Ben* `~mirfet-hocbyt` -- worked more on fortifying our summer
28+key-ceremony gameplan. Mark completed a BIP32 key-derivation library in Arvo. Will has a solid outline for our ETH launch
29+plan, which we're now getting some feedback on from our crypto nerd friends. Ben, Anthony, and Galen have been scheming a
30+MyUrbitWallet redesign while we're still awaiting our final contract audits. Overall, everything here is coming together.
31+The latest [constitution](https://github.com/urbit/constitution), [Urbit wallet](https://github.com/urbit/etherwallet),
32+and [Arvo](https://github.com/Fang-/arvo/tree/research-constitution) code can all be found on GitHub. We're still a short
33+while away from launching all of this, but we'll keep you posted.
34+
35+![](https://media.urbit.org/fora/updates/~2018.7.2-Update-3.jpg)
36+
37+*Joe* `~master-morzod` continued his HTTPS work, moving his development to an actual testnet to sort out the bugs
38+entailed by generating LetsEncrypt certificates and dynamically changing server configs on running ships. In doing so,
39+he's helped track down some of our gnarlier bugs (like [this one](https://github.com/urbit/arvo/issues/740)) and provided
40+some more food for thought for the inevitable Gall and Eyre redesigns. He's also chipping away at a UP describing all
41+this new, exciting functionality. We'll let you know when that comes out. Joe's
42+[Vere](https://github.com/joemfb/urbit/branches) and [Arvo](https://github.com/joemfb/arvo/branches) work-in-progrsss is
43+on GitHub.
44+
45+*Curtis* `~sorreg-namtyv` worked mostly on internal Tlon things this week, but you might get a kick out of his current
46+rendition of renamings for some of Hoon's symbols, pointed out in this recent Fora post: [_Symbol
47+renaming_](https://fora.urbit.org/general/posts/~2018.7.2..01.08.03..c4af~/).
48+
49+*Ted* `~rovnys-ricfer` and *Elliot* `~littel-ponnys` continued work this week on new Ford. They've been hitting several
50+frustrating bugs, and the code they had wasn't as easy to reason about as they were hoping. So to help tackle all this,
51+they decided to start re-architecting parts of new Ford to track the statuses of builds with per-build state machines.
52+This will entail a pretty significant reorganization of the `+ford-state` date structure, but they're confident this will
53+simplify new Ford's semantics and help them get this project fully across the finish line. Ted and Elliot's latest
54+work-in-progress can be found is [here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo), and
55+you can read their technical Fora updates [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
56+
57+Finally, *Josh* `~taglux-nidsep` and *Robert* `~lodleb-ritrul` continue to strengthen our documentation. Josh is well
58+into Chapter 2 of his new tutorials, and Rob has a couple new standard-library documentation sections which turned out to
59+not be documented at all until now. Josh's in-progress work is [here](https://github.com/joshuareagan/doc-drafts); Rob's
60+latest pull requests are [here](https://github.com/urbit/docs/pulls).
61+
62+And that's the way it is. Have a great week!
63+
64+`~tonlur-sarret` and `~poldec-tonteg`
content/posts/2018-7-30-update.mdnew file+62
@@ -0,0 +1,62 @@
1++++
2+title = "~2018.7.30 Update"
3+date = 2018-07-30
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.7.30."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.7.30`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.7.30-Update-1.jpg)
12+
13+The Keys team worked more this past week on specifying and implementing the plan
14+to get the Urbit constitution on the Ethereum blockchain. *Anthony*
15+`~poldec-tonteg` and *Morgan* `~hidrel-fabtel` have nearly completed updating
16+the specification for Wallet. *Will* `~hadrud-lodsef` and *Keaton*
17+`~tonlur-sarret` have a better idea of how to create a smooth experience for
18+current address-space holders to generate their Ethereum keys and get them to us
19+to put in the contract. *Mark* `~palfun-foslup` and *Travis* `~rigdyn-sondur`
20+spent the week implementing more crypto jets (code:
21+[`urbit/argon2`](https://github.com/urbit/argon2)), and Mark is also working
22+on an `argon2` WebAssembly library (code:
23+[`urbit/argon2-wasm`](https://github.com/urbit/argon2-wasm)),
24+which will help us generate private keys during onboarding. *Robert*
25+`~lodleb-ritrul` is now working with us to write user documentation for all of
26+the processes that will be part of our key generation and management
27+applications. We can't wait for Urbit ownership to be cryptographically real.
28+
29+![](https://media.urbit.org/fora/updates/~2018.7.30-Update-2.png)
30+
31+The Infrastructure team spent the week making the Urbit computer more beautiful.
32+*Curtis* `~sorreg-namtyv` worked more on Hoon improvements and started work on
33+the Tlon-official Hoon style guide. *Ted* `~rovnys-ricfer` and *Elliot*
34+`~littel-ponnys` completed several Ford Turbo design changes and got all their
35+tests passing again, now working on completing caching implementation and Eyre
36+integration
37+(code [here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo),
38+technical updates [here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/)).
39+*Joe* `~master-morzod` got full HTTPS support working on the testnet! Ted also
40+wrote up a new UP on his thoughts on Urbit parallelism. Check that out [here](https://fora.urbit.org/proposals/posts/~2018.7.28..19.57.33..7ed3~/).
41+
42+The Interface team worked more on Landscape, our application to allow better
43+communication and collaboration. *Galen* `~ravmel-ropdyl`, *Gavin*
44+`~ridlur-figbud`, and *Jimmy* `~haptyl-wanwes` continued their iterative design
45+revision feedback process, and Landscape is looking good. *Chris* `~sigtus-hossyn`
46+and *Logan* `~tacryt-socryp` continued implementing the latest desktop/mobile
47+features to get the product ready to ship, as well as extending support for the
48+latest backend Landscape API's that *Isaac* `~davtyr-nimren` has been improving.
49+Urbit is becoming more usable by the day.
50+
51+Last but not least, the Documentation team continued doing `~zod`'s work helping
52+teach Urbit to the world. *Josh* `~taglux-nidsep` extended his new Hoon docs to cover Hoon cores, an introduction to the Hoon standard library, and a couple of Hoon examples with very detailed walkthrough commentary (drafts [here](https://github.com/joshuareagan/doc-drafts)). And *Robert* `~lodleb-ritrul` extended the current Hoon-standard-library documentation on random atom generation and atom scrambling, as well as the Hoon cores for computing modular and signed-integer arithmetic (`urbit/docs` pull requests [here](https://github.com/urbit/docs/pulls)). Very soon you'll actually be able to understand how Urbit works.
53+
54+Also: we'll be hosting another party this month on Friday, August 17th. Save the date! Link: [meetup.com: Urbit IRL ~2018.8](https://www.meetup.com/urbit-sf/events/253292678/)
55+
56+Okay! Have a great week.
57+
58+`~tonlur-sarret` and `~poldec-tonteg`
59+
60+---
61+
62+Photo credit: [Studio Olafur Eliasson](http://olafureliasson.net/)
content/posts/2018-8-23-update.mdnew file+83
@@ -0,0 +1,83 @@
1++++
2+title = "~2018.8.23 Update"
3+date = 2018-08-23
4+author = "~poldec-tonteg"
5+description = "A short update from the Tlon team for the week of ~2018.8.23."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+![](https://media.urbit.org/fora/updates/2018.8.23-update-1.jpeg)
10+
11+At Tlon, oars have been bent for some time towards getting the [Urbit PKI
12+bootstrapped on Ethereum](https://urbit.org/blog/2017.9-eth/). Well:
13+The end is in sight! We're not ones to curse an estimate with "dates," so let's
14+say it's "forthcoming."
15+
16+This effort has spurred all kinds of updates to the system, most of which
17+were long in the coming and all of which will have benefits far beyond the
18+Ethereum roll out. We're excited to share them with y'all.
19+
20+We've finalized our suggested wallet derivation scheme. This was a monumental
21+effort that included the expertise of a lot of different parts of Tlon,
22+thanks to *Morgan* `~hidrel-fabtel`, *Curtis* `~sorreg-namtyv`, *Will*
23+`~hadrud-lodsef` and *Mark* `~palfun-foslup`! Look forward to a full public
24+announcement of this derivation scheme once the audit has taken place.
25+
26+Now that that's all wrapped up, we are finalizing work on client-side tools
27+for generating and decrypting these wallets in a usable way. *Gavin*
28+`~ridlur-figbud` and *Will* `~hadrud-lodsef` have been leading this effort, with
29+a non-trivial wasm assist from *Chris* `~sigtus-hossyn` and *Mark*
30+`~palfun-foslup` (codenamed the Dutch Destroyer). We now have parity between the
31+front end crypto tools and their Hoon-side cousins.
32+
33+A key part of this is also the Wallet application, which will allow you to
34+manage your assets easily. *Morgan* `~hidrel-fabtel` has changed the Wallet
35+application architecture a bit to accommodate our wallet deriviation scheme and
36+we're working on getting those changes implemented. *Robert* `~lodleb-ritrul`
37+is on loan from the Docs team to help us make sure that all of our documentation
38+and copy around these tools is crystal clear.
39+
40+A thread connecting these projects is our concept of the Sigil, some of the
41+cryptic shapes you may have seen gracing these very updates. An urbit ship is
42+unique cryptographic property and a Sigil is the visual equivalent of your
43+pronounceable shipname. Sigils will grace our applications for interacting
44+with the Urbit Constitution, our new Landscape UI and many other places we've
45+dreamt up. Work on these Sigils has reached a good point and we're working on
46+integrating them into these applications.
47+
48+Webtalk is not long for this world, into the breach will step: Landscape.
49+After a lot of prototyping and design iteration, we've settled on a feature
50+set that will help the Urbit community (that's you!) communicate and
51+collaborate to reach our next incarnation. Landscape will be on your computer
52+and in your pocket. *Chris* `~sigtus-hossyn` and *Jimmy* `~haptyl-wanwes` have
53+been hard at work hitting the details of the design implementation, including
54+nuances like disconnected and reconnected states and other interaction concepts
55+that we think you'll like. *Logan* `~tacryt-socryp` has been doing double duty
56+on Mobile and improving `%hall` support for DMs. Needless to say, Sigils are
57+present throughout.
58+
59+![](https://media.urbit.org/fora/updates/2018.8.23-update-2.jpg)
60+
61+What about Arvo, you say? Well, the latest news is a veritable supercollision
62+of a merge between our various long running lines of work.
63+[Ford Turbo](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/),
64+whose development you've all been following closely, is now in the process of
65+being integrated with the rest of the our code, complete with not one but two
66+caches (thanks *Ted* `~rovnys-ricfer`). *Elliot* `~littel-ponnys` is taking on
67+the task of integrating Ford Turbo with various affordance we've added in
68+support of Landscape. *Joe* `~master-morzod`, meanwhile, is integrating updates
69+to ames and the boot process occasioned by the Ethereum bootstrap. And finally,
70+*Curtis'* `~sorreg-namtyv` long-anticipated improvements to Hoon are being
71+incorporated into all of the above.
72+
73+The last of these changes will be of particular interest to new learners of
74+hoon, since one of their benefits is the ability to pretty print type
75+information; a useful tool when working in the %dojo.
76+
77+*Josh* `~taglux-nidsep` is closing out a revision of the docs to be released
78+very soon. We hope that the new docs and friendlier Goon will make the task of
79+learning Hoon less of a task and more of an adventure.
80+
81+Next year on Mars!
82+
83+*Anthony* `~poldec-tonteg`
content/posts/2018-8-30-update.mdnew file+55
@@ -0,0 +1,55 @@
1++++
2+title = "~2018.8.30 Update"
3+date = 2018-08-30
4+author = "~poldec-tonteg"
5+description = "A short update from the Tlon team for the week of ~2018.8.30."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+![](https://media.urbit.org/fora/updates/2018.8.29-update-1.jpg)
10+
11+Here is a smattering of the exciting things going on at Tlon this week.
12+
13+Now that we know what the infrastructure for transferring our current
14+property registry will look like, *Will* `~hadrud-lodsef`, *Morgan*
15+`~hidrel-fabtel` are getting the logistics in order. Primary to this is securely
16+generating new keys and securely transferring existing assets. Since Tlon owns a
17+_bit_ of address space, we're particularly interested in making sure this
18+transfer goes down smoothly!
19+
20+The Landscape team has been busy integrating changes to Collections (our new
21+concept for writing, reading and subscribing to static files... like this one!).
22+Our very own Canadian visionary *Isaac* `~davtyr-nimren` did a redesign recently
23+that makes this system more general and takes advantage of the permissions in
24+our file system, `%clay`.
25+
26+Of course, what kind of a square only chats from their desk? Don't most of us
27+want to chat from our soylent-powered electric scooters as well? Luckily,
28+wunderkinder *Logan* `~tacryt-socryp` and *Jimmy* `~haptyl-wanwes` have been
29+grinding on Landscape mobile, including new features such as slick navigation
30+an improved DM flow and, maybe most importantly, a QR-based device pairing flow.
31+
32+![](https://media.urbit.org/fora/updates/2018.8.29-update-2.jpg)
33+
34+*Mark*, resident solidity jurist, is busy updating `%jael` (our vane for
35+handling secrets) to accomodate our newest Constitution.
36+
37+*Joe* `~master-morzod` is making good use of his time in the office to make
38+everyone else feel unproductive. Not only is he the maestro behind the
39+mergepocalypse that I mentioned last week, he is also finishing up work on
40+booting a ship using a keypair generated by, you guessed it, the front end key
41+tools mentioned above.
42+
43+Ford Turbo is getting a good work out from its integration with the updates we
44+made to `%arvo` to accomodate Landscape. Dynamic duo *Ted* `~rovnys-ricfer` and
45+*Elliot* `~littel-ponnys` are fixing these bugs and updating the test suite to
46+account for these cases.
47+
48+Last but not least *David* `~patpex_ponleg` joins the Docs crew. *David* has
49+experience teaching programming, and has even used Hoon in his classes. We're
50+happy to have him help us teach the world to hoon. Come and say hi to him on
51+`%talk`, or even better, ask him to help you with your hoon homework ;)
52+
53+Next year on Mars!
54+
55+*Anthony* `~poldec-tonteg`
content/posts/2018-8-8-update.mdnew file+57
@@ -0,0 +1,57 @@
1++++
2+title = "~2018.8.8 Update"
3+date = 2018-08-08
4+author = "~tonlur-sarret"
5+description = "A short update from the Tlon team for the week of ~2018.8.8."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2018.8.8`:
10+
11+![](https://media.urbit.org/fora/updates/~2018.8.8-Update-1.jpeg)
12+
13+The Interface team spent another week completing the new Urbit frontend. *Gavin*
14+`~ridlur-figbud` finished up his project for putting an image to your `@p`
15+("pat-P") (image is teaser). *Galen* `~ravmel-ropdyl` and *Jimmy* `~haptyl-wanwes`
16+did another round of design reviews for a couple of our interfaces. *Chris*
17+`~sigtus-hossyn` implemented Landscape functionality to reconnect to your Urbit
18+after a long period of disconnection (we _never_ leave `:talk`, so we of course
19+wouldn't know about that). *Logan* `~tacryt-socryp` fixed some more iOS bugs and
20+implemented mobile in-app caching of Collections, making the app more
21+feature-complete. *Isaac V* `~davtyr-nimren` continued the Collections redesign
22+(code [here](https://github.com/urbit/arvo/tree/collections-redesign)).
23+
24+The Infrastructure team put another week in forming a more perfect kernel. *Ted*
25+`~rovnys-ricfer` continued bug hunting in his Ford Turbo cache implementation.
26+*Elliot* `~littel-ponnys` has Ford Turbo integrated with all of Arvo now, but
27+some last steps are still needed to be able to fully remove old Ford from the
28+system. You can find Ted and Elliot's code
29+[here](https://github.com/urbit/arvo/branches/all?utf8=%E2%9C%93&query=ford-turbo),
30+and their technical updates are posted to Fora
31+[here](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/).
32+As Ford Turbo has approached completion, we've realized major performance
33+bottlenecks in our Hoon compiler. So we've called upon *Paul* `~fodwyt-ragful`
34+to help make Hoon really fast. Ted's parallelism UP has also some gotten
35+comments since it was posted last week -- check out the proposal
36+[here](https://fora.urbit.org/proposals/posts/~2018.7.28..19.57.33..7ed3~/).
37+
38+The Keys team got us another week closer to getting on chain. *Joe*
39+`~master-morzod` now has ships booting from the keys in our testnet contract.
40+*Travis* `~rigdyn-sondur` finished implementing our much-needed `secp256k1`
41+crypto jet (code [here](https://github.com/urbit/secp256k1)). *Mark*
42+`~palfun-foslup` nearly completed his `argon2-wasm` library for key
43+generation/derivation. Our man *Chris* `~sigtus-hossyn` is helping him integrate
44+it with our other front end libraries (code [here](https://github.com/urbit/argon2-wasm)). *Anthony* `~poldec-tonteg` and *Morgan* `~hidrel-fabtel` are busy folding all of this new functionality into
45+Urbit Wallet to help you manage your ships. *Robert* `~lodleb-ritrul` is working
46+on the copy for all of these apps, so that their functionality is crystal clear
47+to users.
48+
49+Lastly: We're throwing a party next Friday, August 17th. Link: [meetup.com: Urbit IRL ~2018.8](https://www.meetup.com/urbit-sf/events/253292678/). Be there!
50+
51+See you on Talk, Martians.
52+
53+`~tonlur-sarret` and `~poldec-tonteg`
54+
55+---
56+
57+Photo credit: Tlon
content/posts/2018-9-11-update.mdnew file+59
@@ -0,0 +1,59 @@
1++++
2+title = "~2018.9.11 Update"
3+date = 2018-09-11
4+author = "~poldec-tonteg"
5+description = "A short update from the Tlon team for the week of ~2018.9.11."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+I've gone short on words and long on links for this update, since sometimes the
10+code speaks for itself.
11+
12+![](https://media.urbit.org/fora/updates/2018.9.11-update-1.jpg)
13+
14+After much gnashing of teeth and abuse of git, we now have a
15+[release candidate](https://github.com/urbit/arvo/tree/release-candidate)
16+branch (NB run with the
17+[correct](https://github.com/urbit/urbit/tree/release-candidate) vere branch).
18+This branch brings together, for the first time, a few long-running
19+lines of development. `%ford-turbo`, our new and improved [reactive build
20+system](https://github.com/urbit/arvo/blob/release-candidate/sys/vane/ford.hoon),
21+totally replaces `%old-ford` on this branch (take a look at those comments!).
22+Proud papa *Joe* `~master-morzod`
23+[hard work](https://github.com/urbit/arvo/blob/release-candidate/app/acme.hoon)
24+on HTTPS proxying is baked right in (meaning that ship.urbit.org is graduating
25+from novelty to utility). `%jael` now actually [holds your
26+secrets](https://github.com/urbit/arvo/blob/release-candidate/sys/vane/jael.hoon)
27+and is being used to boot ships. *Curtis'* `~sorreg-namtyv` swansong as the
28+auteur behind `hoon` is now included (a crispy new styleguide is also in the
29+works). Various niceties related to our new web ui are in here (_au revoir_ old
30+Fora and Webtalk), as well as an actually existing
31+[test](https://github.com/urbit/arvo/blob/release-candidate/gen/test.hoon)
32+framework and all kinds of crypto goodies. This release candidate will get the
33+testnet treatment for a little while, while we confirm that it's good enough for
34+you, dear Martian.
35+
36+Much of the Infrastructure team is living the life of the fireman: making chili
37+with your friends interspersed with someone yelling at you to put out a fire.
38+Except, instead of making chili, *Ted* `~rovnys-ricfer` is redesigning the Ford
39+Rune language (why should `~sorreg-namtyv` get all the fun?) and *Elliot*
40+`~littel-ponnys` is bringing `%eyre` into the new Millenium. *Mark*
41+`~palfun-foslup` and *Joe* `~master-morzod`, though, continue in their quest to
42+make Ethereum safe for Martians and *Ben* continues his grueling (for some value
43+of gruel) pair programming regime with *Curtis* `~sorreg-namtyv`.
44+
45+*Chris* `~sigtus-hossyn`, *Isaac* `~davtyr-nimren`, *Jimmy* `~fallyn-balfus` and
46+*Logan* `~tacryt-socryp` continue refining our new web UI, Landscape. Fonts have
47+been argued over, tables overturned over line heights. But it will all be worth
48+it in the end.
49+
50+The Keys crew (*Will* `~hadrud-lodsef`, *Morgan* `~hidrel-fabtel` and *Gavin*
51+`~ridlur-figbud`) are forming like Voltron to get our address space ported
52+over and make sure that we can generate our HD wallets in a secure, usable
53+way. They are joined by the newest edition to Tlon: *Jared* `~nidsut-tomdun`.
54+*Jared* is down south New Zealand way, bringing Tlon ever closer to our goal of
55+`%amesing` over the entire globe. Say `|hi`!
56+
57+Next year on Mars!
58+
59+*Anthony* `~poldec-tonteg`
content/posts/2019-2-11-update.mdnew file+39
@@ -0,0 +1,39 @@
1++++
2+title = "~2019.2.11 Update"
3+date = 2019-02-11
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.2.11."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team for the week of `~2019.2.11`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.2.11-update-1.jpg)
12+
13+## Network
14+
15+The network has been frothy since [the transition](https://urbit.org/posts/essays/azimuth-is-on-chain/), with *Isaac* `~novlud-padtyv`, *Joe* `~master-morzod`, *Philip* `~wicdev-wisryt`, *Ben* `~pitmug-roptic`, and *Ted* `~rovnys-ricfer` working non-stop to fix first memory and then `%ames` connectivity issues. Their efforts have paid off and we now appear to be sailing calm seas.
16+
17+If you haven’t booted into the new era, follow [Getting Started](https://urbit.org/docs/getting-started/) and feel free to `;join ~dopzod/urbit-help` if you need help or want to learn more about the system. See [Messaging](https://urbit.org/docs/learn/arvo/arvo-internals/messaging/) if you don’t know what that means.
18+
19+If you’re having connectivity issues, make sure you're running urbit 0.7.3, try updating again, [try this fix](https://twitter.com/zodisok/status/1096982801373491202), or if you're stumped, [let us know](mailto:support@urbit.org).
20+
21+To stay up to date on network status, follow [@zodisok](https://twitter.com/zodisok) on Twitter.
22+
23+## Team
24+
25+*Ted* `~rovnys-ricfer` and *Joe* `~master-morzod` got an `%ames` rewrite to compile and are working on documentation and unit tests. *Elliot* `~littel-ponys` is rewriting `%eyre`, our webserver, which is some of the gnarliest code in Arvo. Outbound web requests are now working, which has allowed us to delete old `%eyre` from the [lighter-than-eyre branch](https://github.com/urbit/arvo/tree/lighter-than-eyre), and work continues porting individual `%gall` applications over to `%light`. We’re looking forward to moving Landscape onto new `%eyre` soon. *Logan* `~tacryt-socryp` is rewriting the HTTP client in Vere (Arvo’s interpreter) to better support HTTP/2. This will allow us to provide push notifications in the heretofore rumored Landscape iOS app. Finally, *Gavin* `ridlur-figbud` and *Jimmy* `fallyn-balfus` are working on a new design system to enable fast UI prototyping. We’re very excited to share more about that in the near future!
26+
27+Shout-out to *Philip* `wicdev-wisryt` for [this heroic weekend PR](https://github.com/urbit/arvo/pull/1072) that fixed persistent connectivity issues on the network after [Thursday’s breach](https://twitter.com/zodisok/status/1096225302210957312).
28+
29+## Media
30+
31+Palladium, a magazine on governance futurism, talk about Urbit through the second half of [Palladium Podcast Ep. 2](https://palladiummag.com/2019/02/18/palladium-podcast-ep-2/) in a conversation about their recently published article [Facebook’s Political Problems are Inherent to Centralized Social Media](https://palladiummag.com/2019/02/14/facebooks-political-problems-are-inherent-to-centralized-social-media/). Worth a listen.
32+
33+## Meetups
34+
35+If you're in San Francisco on March 1st, we're hosting [an AMA with Galen Wolfe-Pauly](https://www.meetup.com/urbit-sf/events/259144802/), Tlon's CEO.
36+
37+;br;
38+
39+*Morgan* `~hidrel-fabtel`
content/posts/2019-2-25-update.mdnew file+35
@@ -0,0 +1,35 @@
1++++
2+title = "~2019.2.25 Update"
3+date = 2019-02-25
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.2.25."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team for the week of `~2019.2.25`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.2.25-update-1.jpg")
12+
13+## Network
14+
15+The network remains frothy, but functional. Many connectivity issues have been resolved with a `|bonk` or simply by waiting.
16+
17+We published [Operating a Star](https://urbit.org/docs/getting-started/operating-a-star/) and founded a city for star operators. [Contact us](support@urbit.org) for access to the latter.
18+
19+Expect a breach next week. We’ll announce the date and instructions on [@zodisok](https://twitter.com/zodisok) once scheduled.
20+
21+## Team
22+
23+Work continues on *Elliot*'s `~littel-ponys` [lighter-than-eyre](https://github.com/urbit/urbit/tree/lighter-than-eyre) branch. *Ted* `~rovnys-ricfer` made great strides toward the design for new `%ames`. Most notably, *Ben* `~pitmug-roptic` got a [Nix](https://nixos.org/nix/) build working and [merged it](https://github.com/urbit/urbit/pull/1196) into the [cc-release](https://github.com/urbit/urbit/tree/cc-release) branch. Finally, support for push notifications is [coming along](https://github.com/urbit/urbit/pull/1203) thanks to *Logan* `~tacryt-socryp`.
24+
25+## Community
26+
27+The Hoon School pilot begins Monday. We've received a lot of interest since announcing it last week and we can't wait to get started. [Contact us](mailto:support@urbit.org) if you want to be added to the waitlist for future iterations.
28+
29+If you're in Austin on March 8th, *Anthony* `~poldec-tonteg` and *Alex* `~mignyt-mogseb` are hosting [a meetup](https://www.meetup.com/urbit-sf/events/259307805/) at [Garage](https://www.garagetx.com/) from 5–7pm.
30+
31+In San Francisco on March 26th, *Galen* `~ravmel-ropdyl` is speaking on [a panel](https://www.eventbrite.com/e/the-future-of-free-speech-online-registration-57429323653) hosted by [Lincoln Network](https://joinlincoln.org/) at [Galvanize](https://www.galvanize.com/campuses/san-francisco).
32+
33+;br;
34+
35+*Morgan* `~hidrel-fabtel`
content/posts/2019-2-26-network-update.mdnew file+39
@@ -0,0 +1,39 @@
1++++
2+title = "~2019.2.26 Network Update"
3+date = 2019-02-26
4+author = "~poldec-tonteg"
5+description = "A short update on network status as of ~2019.2.26."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+![](https://media.urbit.org/site/posts/updates/~2019.2.26-update-1.jpg)
10+
11+## Toward a Permanent Network
12+
13+We conduct significant network upgrades to Arvo’s network protocol by “breaching” into discontinuous “eras.” Eventually, the network will reach a final era, after which no more major upgrades will be made. In the meantime, the network should be considered under test.
14+
15+We are currently in the third era since [launching Azimuth](/posts/essays/azimuth-is-on-chain) and much work lies ahead. We expect network instability and regular breaching throughout the next few months. If you’re using the network today: hang in there!
16+
17+## Recent Progress
18+
19+Some recent process improvements should accelerate the path to maturity. Arvo updates are now continuously integrated on `~zod`, Tlon’s galaxy, through which we distribute Arvo updates. Moreover, we’re working on an integration testing framework, tentatively named pH, that allows us to test across virtual networks of ships and dramatically improve debugging.
20+
21+## Getting Involved
22+
23+In the meantime, there are a few things you can do to get involved.
24+
25+### Get an Azimuth point
26+
27+We’re working on making the process smoother, but right now you can get an Aizimuth point from a friend. You can also generate your sigil using [sigil-js](https://github.com/urbit/sigil-js), or grab it from the Azimuth points metadata API.
28+
29+### Try Arvo
30+
31+Arvo isn’t ready for prime time, but you can definitely experiment with it. Follow the [Getting Started](/docs/getting-started) guide to boot a ship and access Landscape, our experimental messaging app.
32+
33+### Join Hoon School
34+
35+If you’re interested in learning how to write software for Urbit, we’ll be running online classes to teach the language, Hoon, and more in coming months. If you’re interested to join, [shoot us an email](mailto:support@urbit.org) and we’ll add you to the waitlist.
36+
37+;br;
38+
39+*Anthony* `~poldec-tonteg`
content/posts/2019-2-4-update.mdnew file+27
@@ -0,0 +1,27 @@
1++++
2+title = "~2019.2.5 Update"
3+date = 2019-02-05
4+author = "~lodleb-ritrul"
5+description = "A short update from the Tlon team for the week of ~2019.2.5."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here's a short update from the team at Tlon for the week of `~2019.2.5`:
10+
11+![](https://media.urbit.org/fora/updates/2019.2.4-update.jpg)
12+
13+Welcome to the other side. The Urbit PKI, Azimuth, now fully [migrated to the Ethereum blockchain](https://urbit.org/posts/essays/azimuth-is-on-chain/). This migration means that all address-space-holders have cryptographic ownership of their assets. The guide to getting on the network can be found [here](https://urbit.org/docs/getting-started/).
14+
15+Azimuth is one of three layers of the Urbit project, alongside _Arvo_ and _Aegean_. Arvo is the Urbit operating system. Aegean is something more abstract; a pattern for building “cities”: Urbit communities whose members run the same custom suite of software on their Arvo servers. Our [Primer](https://urbit.org/primer/) explains these concepts in depth.
16+
17+An integration of this size is not without its difficulties, though. ~zod labored mightily for a few days then `bail: meme`d (Arvo for “ran out of memory”). *Joe* `~master-morzod`, *Ted* `~rovnys-ricfer`, and *Isaac* `~novlud-padtyv` discovered the problem: `~zod` had so many neighbors that Vere ran out of memory upon restart. [One fix](https://github.com/urbit/urbit/pull/1167) changed how Vere put header metadata on the event log, allowing it to be traversed both forwards and backwards, and [another fix](https://github.com/urbit/urbit/pull/1180) conserves memory by clearing the cache more often. A [third improvement](https://github.com/urbit/urbit/pull/1171) brings an important memory diagnostic tool, `|mass`, back to Arvo. Our champions breached the network to implement these changes, and problems seemed to be solved. _However_, they ran into new issues with event-playback, and they’ve been debugging that ever since.
18+
19+(There’s also a new Twitter account, [@zodisok](https://twitter.com/zodisok), that tweets out updates about `~zod`’s network status and any relevant pull-requests. It also provides a bit more insight into the challenges of building your own tools to maintain a network. Follow it to stay in the loop.)
20+
21+*Will* `~hadrud-lodsef`, *Gavin* `~ridlur-figbud`, and *Jared* `~nidsut-tomdun` are making incremental changes to our Azimuth front-end, Bridge: UI fixes, new wallet support, adding conditional star-release capabilities for galaxies, and integrating a wallet-generator feature. The Bridge crew will try to implement these changes on a weekly schedule, and you can keep track of them in the Bridge repo’s new [CHANGELOG](https://github.com/urbit/bridge/blob/master/CHANGELOG) file.
22+
23+BONUS: *Mark* `~palfun-foslup` aka The Dutch Destroyer decided that full bitcoinification was not happening fast enough for his liking and submitted a PR that added bitcoin rpc support to Arvo. Watch the demo [here](https://twitter.com/mdfang/status/1092171862178701313).
24+
25+See you next week.
26+
27+*Rob* `~lodleb-ritrul`
content/posts/2019-3-11-update.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "~2019.3.11 Update"
3+date = 2019-03-11
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.3.11."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team for the week of `~2019.3.11`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.3.11-update-1.jpg)
12+
13+## `@p` Bug
14+
15+The `@p` bug [is solved](https://github.com/urbit/arvo/pull/1110), thanks to [@max19](https://github.com/urbit/arvo/issues/1105#issuecomment-472585937) and *Jared* `~nidsut-tomdun`.
16+
17+## Team
18+
19+*Ted* `~rovnys-ricfer`, *Philip* `~wicdev-wisryt`, and *Joe* `~master-morzod` developed a proposal for formalizing the semantics around state persistence in a way that enables parallelism, event replay, and a new model for error handling. *Joe* `~master-morzod` worked on integrating new `%eyre`. *Elliot* `~littel-ponnys` worked on an elaborate proposal for resolving the `@p` bug involving constraint solvers, which turned out to be unnecessary, but was quite impressive nonetheless!
20+
21+*David* `~rapfyr-diglyt`, *Robert* `~lodleb-ritrul`, and 23 students completed the first week of Hoon School. `~hadrud-lodsef` implemented automation for handling requests from the community. In the next few weeks we're looking forward to automating Urbit support, the Hoon School queue, and contributor onboarding, toward the end of allowing all of our community support systems to scale.
22+
23+*Anthony* `~poldec-tonteg`, *Jared* `~nidsut-tomdun`, and *Morgan* `~hidrel-fabtel` made progress on a plan to upgrade our open-source development processes. We’re moving toward making Tlon’s work more public and making it easier for contributors to get involved. As a first step, we’ve assigned maintainers for each of our repositories, and both repository guidelines and a new proposal system are in the works. *Morgan* `~hidrel-fabtel` also started working on re-implementing the website to make content updates and external contributions easier.
24+
25+Until next time.
26+
27+;br;
28+
29+*Morgan* `~hidrel-fabtel`
content/posts/2019-3-27-update.mdnew file+21
@@ -0,0 +1,21 @@
1++++
2+title = "~2019.3.27 Update"
3+date = 2019-03-27
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.3.27."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team as of `~2019.3.27`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.3.27-update-1.jpg)
12+
13+## Team
14+
15+*Philip* `~wicdev-wisryt` [finished](https://github.com/urbit/arvo/pull/1120) Aquarium, which runs a virtual fleet of ships inside a host ship, and pH, an integration testing framework. `~rigdyn-sondur` [pushed](https://github.com/urbit/urbit/pull/1228) ncurses support. *Joe* `~master-morzod` and *Elliot* `~littel-ponnys` continued work on new `%eyre` (webserver) while Isaac `~novlud-padtyv` [integrated](https://github.com/urbit/arvo/pull/1119) Landscape. Finally, `~pilfer-pandex` and *Benjamin* `~pitmug-roptec` made progress on a reimplementation of the compiler.
16+
17+Until next time.
18+
19+;br;
20+
21+*Morgan* `~hidrel-fabtel`
content/posts/2019-3-4-update.mdnew file+48
@@ -0,0 +1,48 @@
1++++
2+title = "~2019.3.04 Update"
3+date = 2019-03-04
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.3.4."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team for the week of `~2019.3.4`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.3.4-update-1.jpg)
12+
13+## Network
14+
15+We breached successfully. You can read about [what we fixed](https://github.com/urbit/arvo/pull/1101). Issues ocassionally crop up as people join the network, but it looks to be smooth sailing as we make our way toward [cc-release](https://github.com/urbit/urbit/tree/cc-release) and new %ames.
16+
17+## `@p` Bug
18+
19+The nice folks behind [@urbitlive](https://twitter.com/urbitlive) discovered a bug in `@p` leading to planet name-collisions. Due to a subtly incorrect implementation of the cryptographic algorithm we use to scramble planet names – used to dissociate them from their parent stars – a small percentage of people with different Azimuth points could end up with the same planet name. For example:
20+
21+```
22+> `@p`3.108.299.008
23+~morlyd-mogmev
24+> `@p`479.733.505
25+~morlyd-mogmev
26+```
27+
28+We [announced the bug on Twitter](https://twitter.com/urbit/status/1105850450559918082) today, and [a conversation](https://github.com/urbit/arvo/issues/1105) has been ongoing on Github. It appears we've settled on a solution, outlined in [this 3-line suggestion](https://github.com/urbit/arvo/issues/1105#issuecomment-472585937) from @max19, which elegantly corrects the implementation of the algorithm while preserving all existing planet names – a truly miraculous solution that came out of nowhere. Thank you Max!
29+
30+Stay tuned for a post with a full report.
31+
32+## Team
33+
34+*Jared* `~nidsut-tomdun` spent the week on the `@p` debacle and more than once generated all four billion planet names to check for collisions. *Ted* `~rovnys-ricfer` spent much of the week thinking about redesigning the PKI only to realize that the existing design is quite good. *Logan* `~tacryt-socryp` and *Isaac* `~novlud-padtyv` started working on the next major revision to Landscape. *Ben* `~pitmug-roptic` quietly [started working on](https://github.com/urbit/urbit/pull/1221) 64-bit Vere. `~pilfer-pandex` [brought the hammer down](https://github.com/urbit/docs/pull/399#issuecomment-472667240) on the pronunciation debate.
35+
36+Tlon is at the beginning a new batch of work for 2019, so new proposals are popping up almost daily. *Morgan* `~hidrel-fabtel` is working on revamping our proposal (“UP”) system so that the outside world can more easily participate in all of the work that’s going on. *Anthony* `~poldec-tonteg` and *Jared* `~nidsut-tomdun` are also working on standards for our repository documentation and open-source development process.
37+
38+## Community
39+
40+Our Austin meetup and San Francisco AMA were a blast. You can watch [the recording of the latter](https://www.youtube.com/watch?v=ndk2b69fA9A) on Youtube. Thank you for coming and for all of your questions!
41+
42+Out there on the Internet, people are starting to build their own platforms around Urbit and Azimuth. There are now multiple planet stores and at least one active online community. It's exciting to watch the community start to grow all by itself.
43+
44+Until next time.
45+
46+;br;
47+
48+*Morgan* `~hidrel-fabtel`
content/posts/2019-4-11-update.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "~2019.4.11 Update"
3+date = 2019-04-11
4+author = "~hidrel-fabtel"
5+description = "A short update from the Tlon team for the week of ~2019.4.11."
6+[taxonomies]
7+posts = ["Updates"]
8++++
9+Here’s a short update from the team as of `~2019.4.11`:
10+
11+![](https://media.urbit.org/site/posts/updates/~2019.4.11-update-1.jpg)
12+
13+## Team
14+
15+*Philip* `~wicdev-wisryt` made progress on `%aqua`, simulated Arvo instances running in Arvo, and getting individual continuity breaches working, which will enable resetting of sunk ships. *Elliot* `~littel-ponnys` and *Joe* `~master-morzod` have been [readying](https://github.com/urbit/urbit/pull/1232) `cc-release` for release. *Ted* `~rovnys-ricfur` has been [laying the groundwork](https://github.com/urbit/arvo/pull/1135) for future error handling and making progress on new `%ames`. *Ben* `~pitmug-roptec` and `pilfer-pandex` continued work on Hoon's type system. Finally, *Jared* `~nidsut-tomdun` is revamping `%gall`, currently `+mo` and `+ap`.
16+
17+## Community
18+
19+We conducted an Azimuth AMA and an "IDEA BLITZ" on Landscape. Excerpts from the IDEA BLITZ are collected in [a Github issue](https://github.com/urbit/proposals/issues/4), and archives are available at `~dopzod/azimuth-ama` and `~dopzod/idea-blitz`.
20+
21+## April Fools
22+
23+*Ted* `~rovnys-ricfur` shared a [convincing argument](https://github.com/urbit/arvo/pull/1129) for uppercasing Hoon and someone launched [Urbit Classic](http://urbit-classic.org/), running 2016-era Arvo. To be clear, we don't recommend sending them Bitcoin.
24+
25+Until next time.
26+
27+;br;
28+
29+*Morgan* `~hidrel-fabtel`
content/posts/_index.mdnew file+4
@@ -0,0 +1,4 @@
1++++
2+render = false
3+sort_by = "date"
4++++
content/posts/a-founders-farewell.mdnew file+613
@@ -0,0 +1,613 @@
1++++
2+title = "A Founder's Farewell"
3+date = 2019-01-14
4+author = "Curtis Yarvin"
5+description = "My goal was always to fire myself at the first possible opportunity. I'm super happy to reach it."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+
10+![Curtis Yarvin portrait](https://storage.googleapis.com/media.urbit.org/site/farewell.png)
11+
12+After 17 years, I've left the Urbit project.
13+
14+I've resigned as CTO, board member, and voting shareholder of
15+Tlon (Urbit's corporate sponsor). I've also reassigned my
16+personal galaxies to urbit.org (Urbit's embryonic foundation,
17+still in Tlon's custody).
18+
19+My family still has a few thousand Urbit stars (in long timelock
20+contracts), plus a nonvoting minority in Tlon. This isn't
21+authority, just compensation: I have zero central power over
22+either Urbit or Tlon. Nor will I contribute code to Urbit, nor
23+write nor speak publicly about it. I am actually done here.
24+
25+From the very start, I knew Urbit could not succeed until it
26+ceased to be mine and became the world's. Urbit works; its PKI
27+is on the Ethereum mainnet; it's open source; in every way,
28+technical, legal, and mathematical, it is the world's.
29+
30+(What _is_ Urbit? Please read the [primer](/primer).)
31+
32+Let's talk about: why I've left; the state of Tlon; and the state
33+of Urbit. If there's any time left, we'll read some poetry.
34+
35+## Why I left
36+
37+No one had the power to fire me. (If anyone wanted to, they kept
38+it to themselves.) I wanted to quit; I could; I should have; I did.
39+
40+I'm a thinker, not a doer; an explorer, not a leader; an author,
41+not a maintainer. My goal was always to fire myself at the
42+first possible opportunity. I'm super happy to reach it.
43+
44+Any creator is a sort of parent – where control is dependence,
45+powerlessness is independence, and independence is victory.
46+There are a lot of ways to light a fire. The last step is just
47+getting out of the way – which must be done not too late, not
48+too soon, and just right. No one can beat Satoshi in this act;
49+anyone should be delighted to follow him.
50+
51+I worked full-time on Urbit, alone and self-funded, for eleven
52+years. From 2002 to 2013, I wrote an end-to-end clean-slate
53+system-software stack: an axiomatic interpreter that fits on a
54+T-shirt, a typed functional language that doesn't use abstract
55+math, and a purely functional operating system. I didn't patent
56+any of this; I put it all in the public domain. (Not a valid
57+open-source license; Urbit is now MIT licensed.)
58+
59+By 2013 I had a stack that worked well enough to make [a
60+video](https://vimeo.com/75312418), then raise a 1.5M seed round. Urbit in 2013 was a
61+working product – in fact, Urbit has had a live global network
62+since November 2013. But in a new platform, the distance between
63+_working_ and _compelling_ is nontrivial. Especially for a seed
64+company with just a few young engineers, building something like
65+nothing ever built before.
66+
67+Urbit in 2013 had roughly the same feature set as Slack in 2013,
68+but less polished, and decentralized. It was pretty buggy and
69+slow. But had we put all our resources into debugging and
70+optimization, it would not have taken five years.
71+
72+My instinct was always that Urbit's delivery schedule should be
73+as long as possible. For me, there are always two Urbits: the
74+Urbit that exists, and the Urbit that should exist. To invent
75+the latter I have to inhabit it. When I look at the present,
76+I try as hard as possible to look at it from the perspective of
77+the future – that's where my head should be.
78+
79+This always makes me think Urbit sucks. And the last thing you
80+want to do is evangelize anything that sucks. This is a bias,
81+but that doesn't make it wrong. For instance: the 2013 Urbit had
82+a shell and a persistent distributed chat – but the shell was
83+mixed in with the kernel, and the chat with the network protocol.
84+As seen from the 2019 Urbit, this is very lame indeed.
85+
86+The conventional wisdom is to ship your embarrassing "MVP." For
87+several reasons, Urbit occupies a unique strategic position.
88+Urbit just isn't relevant until Urbit is, if not perfect,
89+uniformly excellent. It can't just work. It has to work right.
90+Urbit has to be amazing – which is hardly a useless discipline.
91+
92+I still did not think it would take five years to make Urbit
93+work right – or to get the resources to make it work right
94+(which only happened in 2018). But founders always delude
95+themselves, or no one would do it.
96+
97+Urbit is not uniformly excellent quite yet. There are a few
98+medium-sized cleanups in the near-term pipeline. But this is a
99+matter of months, not years. I don't see any unknown unknowns.
100+The adventure isn't over – but the exploration is over.
101+
102+A clean-slate system software stack, from fundamental interpreter
103+to social network, through typed functional language and
104+deterministic OS, is an enormous architectural journey – so
105+long and winding that it's easy for anyone to get lost in any
106+detail. Isn't that any explorer's first job: not getting lost?
107+
108+But once the route is marked, there is a second duty: getting out
109+of the way. It's time for surveyors, not explorers, to map,
110+measure and smooth every wrinkle on the map. That's how system
111+software matures. Lines first ripped in one long slash are
112+polished, straightened and refined across years and decades.
113+
114+And Urbit is too deep and interesting for one technical leader.
115+Every part of it needs its own owner. But others can't build a
116+real sense of ownership while the founder is still around. I'm
117+not even the best engineer on the project; I just got here first.
118+
119+This codebase is very young and very general; there is a lot of
120+fun left to be had with it; others deserve to have that fun.
121+
122+I have no successor as "BDFL." Technical leadership passes to
123+Tlon as a company. Urbit is open source and anyone may play, but
124+anyone who wants to catch up to Tlon still has a lot to learn.
125+Not that that should stop them!
126+
127+I can't make Urbit technically transparent in one speech. But
128+maybe I can shed a little light on the strategy, organization,
129+history and future of the company and the project. It's easier
130+to be frank on the way out.
131+
132+## Tlon, boiling oceans since 2013
133+
134+First of all: why did we do what we did?
135+
136+An ambitious system software project can inhabit one of four
137+institutional forms: bigco, startup, academia, or community.
138+
139+None of these is a fit for a clean-slate system software stack.
140+The startup is the least worst. I'd do it again.
141+
142+A normal startup lifecycle (Tlon actually got into YC, but
143+declined – this was either cool or lame) looks nothing like a
144+normal system-software lifecycle. Nor is Urbit normal. But
145+while Silicon Valley is absurd, it still fits Marianne Moore's
146+line: "with a perfect contempt for it, one discovers that there
147+is in it after all a place for the genuine."
148+
149+The less said about big companies and big science, the better.
150+But the choice between startup and community is interesting.
151+Let's talk a little about why Tlon, this corporation, exists,
152+then a little more about what it actually is.
153+
154+### Tlon, from cathedral to bazaar
155+
156+I used to think I could give Urbit directly to the world – that
157+I could just post the code and an open-source community could
158+take it from there. That'd probably work now, but it's not yet
159+the right thing – and not because nobody wants a revolution.
160+
161+I've never been an open-source person myself. But the model has
162+fascinated me since I encountered Nethack in the '80s. Now that
163+open-source software is a mature field, we can see what kinds
164+of problems the open-source "bazaar" mode is and isn't good at,
165+versus the corporate "cathedral" mode.
166+
167+One problem open source isn't good at is creative collaboration
168+on large and novel systems. For example, if we consider the set
169+of people creating Google's new Fuchsia OS, and the set of people
170+contributing npm modules, we see that it's almost impossible to
171+imagine something like Fuchsia as a community effort – but this
172+is not for lack of talent-hours. Imagine a bazaar creating a
173+feature film, and you'll get the picture. (And Fuchsia seems
174+like a fairly traditional OS.)
175+
176+Why is creative work so hard for bazaars? We could take this as
177+an axiom – but it's worth understanding.
178+
179+The path from concept to product is an annealing process. Your
180+code starts as a gas and ends as a metal. It must cool gradually
181+under precise control. When parts cool too fast, flaws appear.
182+Where flaws appear, the code must be reheated: ie, rewritten.
183+
184+Except for ASCII and a few algorithms, Nock, Hoon and Arvo didn't
185+really rely on anything from 20th-century CS. We didn't drop any
186+off-the-shelf parts into the oven; the whole stack is made from
187+gas. So the code in Urbit has been rewritten at least once; the
188+best code has been rewritten four or five times; perhaps some has
189+been rewritten ten, fifteen, even twenty times.
190+
191+In 2002, I started out with no idea what I was doing. Urbit was
192+interstellar vapor. I did have a decent grounding in 20th
193+century CS, academic and practical. In the '90s I was a grad
194+student in OS at Berkeley, then spent eight years on system
195+software projects (a language, an OS and a browser) in industry.
196+What I wanted, I did not know; what I knew, I did not want.
197+
198+In a long annealing process, it's important to triage the order
199+in which you solve problems. There are three kinds of problems:
200+problems you can't solve now, problems you don't have to solve
201+now, and hard problems. Unless you postpone anything that isn't
202+a hard but solvable problem, your gas will never turn into steel.
203+There are lots and lots and lots of ways to go nowhere fast.
204+
205+Somehow it's 2019. Urbit is hot iron under the hammer. It is
206+solid, but not yet hard. It has shape, but can yet be shaped.
207+It is done, but ought to be finished. It is a sword; you don't
208+want to get stabbed with it; it is not Excalibur, the blade to
209+end all blades.
210+
211+The bazaar is great. But cathedrals still exist for a reason.
212+The challenge for an ambitious system-software project is not
213+whether to choose the cathedral or bazaar model, but when and
214+how to transition from cathedral to bazaar.
215+
216+A cathedral – the same classic pyramid org-chart no doubt used
217+by the builders of the actual pyramids, or the actual cathedrals
218+– is economically less efficient than a bazaar. Why?
219+
220+Even on the world's most fun project, working for some dumb boss
221+is no fun. The bazaar succeeds because the project extracts free
222+labor from contributors – not by cheating them, but in exchange
223+for fun, status, experience, etc. But mainly fun, honestly.
224+
225+Whereas a cathedral costs a giant ton of money. But in exchange,
226+the cathedral gets _cohesion_ – the capacity for intelligent
227+coordinated action. Bazaars can coordinate, but not easily.
228+
229+Because a cathedral can coordinate, a cathedral can _create_ –
230+acting at a scale above individual action. A bazaar is very
231+useful, but a bazaar does not create. It can grow; it can heal,
232+harden, extend, and expand; but creation requires an individual
233+or a coordinated group.
234+
235+But a bazaar can get a lot more done, a lot faster and a lot
236+cheaper. So the right starting point for a bazaar is an existing
237+system which is very clear, very final, and very simple. So any
238+new system should be created by a cathedral and perfected by a
239+bazaar. Since these institutions share little or no structure,
240+the transition is by no means straightforward.
241+
242+### Tlon, just a little startup
243+
244+Tlon is Urbit's little corporate cathedral. It's about 20
245+people, about 15 of them engineers. Everyone is working on
246+Urbit, but not everyone is writing Hoon; there is client-side
247+work, Ethereum work, etc.
248+
249+The team is comfortably funded and more than competent. One Tlon
250+engineer is a 10-year, level 6 Google veteran; another is a YC
251+alum; these people are great, but not really outliers. And not
252+to be credentialist – there are plenty of dropouts, too.)
253+
254+Today, there's almost no part of the Urbit codebase that I still
255+know better than anyone else. There are even design areas that
256+others know better. When we transitioned from Nock 5 to Nock 4,
257+all I contributed was a suggestion. The same for our Ethereum
258+address collection, which our customers absolutely loved.
259+
260+Who's responsible for growing and maintaining this team? Who's
261+the stone at at the top of the pyramid? Not me: if you gave me a
262+goat to feed, the goat would die. The stone that holds the arch
263+together is Tlon's CEO and my cofounder, Galen Wolfe-Pauly.
264+
265+Tlon was founded in 2013; Galen led it through its long seed
266+stage, with only a few engineers, to 2018, when he finally
267+secured the resources to do the project justice. (Although way
268+too much of Tlon's energy in 2018 had to go into Ethereum.)
269+
270+Galen's previous project was the social meta-network Ost. He has
271+an architecture degree from Cooper Union; he is a great designer,
272+a good front-end engineer, and a pretty good surfer. (He also
273+runs the @urbit Twitter.)
274+
275+Galen sets Tlon's product vision and is responsible for both
276+visual appearance and human experience. Basically, Galen is the
277+Steve Jobs of Urbit, with only two differences: Galen's not an
278+asshole, and Steve wasn't short.
279+
280+Galen is joined in the new leadership team by Erik Newton
281+(operations, legal) and Anthony Arroyo (product, engineering).
282+Erik used to run a divorce-law firm and still is a relationship
283+coach. Anthony was a grad student in comparative literature and
284+managed engineering prototypes at Applied Minds.
285+
286+With my departure, Galen is in exclusive control of Tlon and
287+holds the only board seat. Tlon did take seed funding from VCs.
288+But outside investors have never held any management role.
289+
290+## Urbit, in the rear-view mirror
291+
292+Since I'm not going to talk about Urbit again, let me say a few
293+words that might otherwise go unsaid.
294+
295+### Urbit, a level and neutral platform
296+
297+Urbit's distribution and sponsorship hierarchy of galaxies,
298+stars and planets is *not* designed as a political structure,
299+or even a social structure. The actual social layer is in
300+userspace -- one layer up.
301+
302+Socially and politically, Urbit is a flat network of planets.
303+Galaxies and stars are plumbing. No one cares which star is your
304+sponsor, any more than your Facebook friends care who your ISP
305+is, or you care what data center Facebook is in.
306+
307+The sponsorship hierarchy and the senate of galaxies (which can
308+amend Urbit's Ethereum constitution) are _technical_ governance
309+mechanisms. They exist to react to unanticipated technical
310+issues or conflicts (like denial-of-service attacks). Because
311+sponsorship has an escape mechanism, it is not a _feudal_ bond
312+(like your relationship to Facebook).
313+
314+Urbit is a decentralized network of social networks. No one can
315+regulate it. Urbit is made to blossom into an endless garden
316+of human cultures, each of which must regulate itself, none of
317+which can bother the others. The soil in which these flowers
318+grow must be level and neutral.
319+
320+### Urbit, anything but a fair distribution
321+
322+Who got those galaxies, anyway?
323+
324+Urbit has no mining mechanism and needs none. My model was: I
325+own the whole space, since I made it; on the other hand, it's
326+worthless until I find a way to give it away.
327+
328+In the end, I am probably the only individual with a fair amount
329+of Urbit address space (no galaxies, a few percent of all stars).
330+Tlon plus urbit.org also have about the right amount (slightly
331+less than half). The rest are held by third parties – all of
332+whom have either much more, or much less, than they deserve.
333+
334+But although the distribution of Urbit space was thoroughly
335+unfair, it was always _honest_ and never _corrupt_. Everyone
336+who has galaxies or stars did _something_ for Urbit. Some gave a
337+lot of money, some gave a little; some contributed a lot of code,
338+some just showed up. We paid a lawyer by bartering a pair. A
339+bunch went to contest winners who solved a trivial Nock problem
340+in 2010.
341+
342+What's unfair: the standards changed wildly across time. What's
343+honest: they were always the same across _people_. Granted, you
344+often had to be in the right place at the right time. This is
345+another problem with life that we can't fix.
346+
347+Every real system of property is unfair. Who deserves to own
348+Manhattan? Who does own it? If property be not unfair – if it
349+is not the result of respecting past accidents – it is not
350+property at all, but something else. I certainly would not do it
351+this haphazardly again, but the outcome is no tragedy.
352+
353+When you live in Manhattan, you simply don't worry about who
354+owns it or why; and nor does it matter. Are they Jews? Muslims?
355+Christians? Communists? Italians? You don't care and you don't
356+have to. You know it's basically random and probably unfair.
357+Randomness, even blatant unfairness, creates a kind of neutral,
358+peaceful, even promising urban anonymity.
359+
360+Property is always and everywhere a kind of amnesty. It says:
361+whatever happened in the past, this is now what is. When we all
362+agree that everyone has what they now have, however they got it,
363+we have a formula for peace. When we say that everyone should
364+have what they deserve, we can never expect everyone to agree –
365+which means we have planted permanent seeds of discord.
366+
367+And randomness is a virtue – it disrupts hidden patterns. The
368+galaxy owners include famous VCs and total nobodies; a Zen monk
369+and a former Orthodox nun; a blockchain industry leader and a
370+permaculture farmer. If they do have to all agree on something,
371+they should have little to agree on but the truth.
372+
373+## Urbit, a technical report card (January 2019)
374+
375+As a system-software stack, the fundamental thesis of Urbit is
376+that technical simplicity can flow all the way up to the top of
377+the stack, where it becomes human usability. If we can build a
378+purely functional OS, we can build a zero-maintenance server,
379+which is easy to understand because how it works is simple.
380+With this problem solved – nothing else matters.
381+
382+Unfortunately, I still have to give Urbit an "incomplete" here.
383+No grade is available, because usability depends on a lot of
384+fit-and-finish issues that are naturally back-loaded. I would
385+still much rather run an Urbit ship than a Mastodon instance.
386+But still, Urbit today can't quite promise zero maintenance.
387+
388+So we have to look at smaller indicators. One way to get anyone
389+to grade their own work is to ask them for three ways they've
390+succeeded, and three ways they've failed.
391+
392+### Urbit, three battles won
393+
394+I did once want to be a real computer scientist. Before my
395+expulsion for sordid & disturbing behavior, I was once a
396+19-year-old PhD student in CS at Berkeley. I even made an
397+embarrassing bet with Raph Levien as to which of us would win the
398+Turing Award – my money is definitely on Raph at this point.
399+You can even go and read my Usenix '93 paper on ASLR-secured
400+RPC, which won Best Student Paper and has like 50 citations.
401+
402+Well. That whole scene is a bad trip, kids. Avoid it. Also, if
403+you start out as Rimbaud, you might end up as Lebowski. On the
404+other hand, to have any excuse for boiling the ocean, you do have
405+to make some serious CS problems just go away. Here are three.
406+
407+#### Validation
408+
409+20th-century languages underrate the centrality of communication
410+to computing. Their type systems expect all data to live in a
411+single memory forever. They don't consider data serialization
412+and validation to be core competencies of a programming language.
413+
414+So serialization/validation is handled either ad hoc, or by
415+intermediate data description systems which have inherent
416+impedance mismatches with the language proper. Not only is work
417+done over and over – but most network security breaches exploit
418+seams in custom or complex deserialization and validation code.
419+
420+In Urbit there is one kind of data, a noun, which is an atom
421+(unsigned integer) or a cell (ordered pair of nouns). There is
422+one serialization model, which maps noun to atom to noun, in a
423+page of code. And a type defines a set of nouns by defining a
424+function of an arbitrary noun, whose range is that set – which
425+means any data type is also its own data validation function.
426+
427+#### Idempotence
428+
429+20th-century computers have two brains: one fast and temporary,
430+the other slow and permanent. When one of these two-brained
431+computers hears a packet, and sends an acknowledgment, that only
432+means the temporary brain heard it. Acks are not end-to-end
433+transactions.
434+
435+This means you can't write a command protocol where your commands
436+get executed exactly once. You can only choose "at least once"
437+or "at most once." This problem is as ridiculous and frustrating
438+as it sounds.
439+
440+You can address it in three ways: (a) make all your commands
441+formally idempotent, so that repeating them has no additional
442+effect; (b) insert a layer of stateful middleware — a message
443+queue; (c) be fine with "almost always once." Guess which
444+approach is most popular?
445+
446+Your Urbit ship has one permanent brain. Its acks are end-to-end
447+transactions — no packet is acknowledged until all its direct
448+effects are finalized. Every message channel is its own message
449+queue. And every message is executed once.
450+
451+#### Dependencies
452+
453+20th-century languages are all at least vaguely based on a
454+formalism from the '30s called the "lambda calculus." The
455+fundamental operation in lambda calculus is variable reduction
456+from name to value. So lambda languages all have a symbol table
457+or environment which binds names to values.
458+
459+Modern build systems assemble large programs out of small files
460+by reusing this symbol table for global function names, a process
461+called "linking." Unfortunately, linking causes a problem known
462+as "dependency hell," involving baffling, unpredictable upgrade
463+failures. The fundamental problem is the "diamond dependency" —
464+when a build requires two different versions of one symbol.
465+
466+Urbit does not use the lambda calculus, an environment or symbol
467+table, or linking. Because it pushes name resolution out of the
468+fundamental interpreter and up into the language, it can play
469+many more namespace juggling tricks. And its build system has no
470+trouble including multiple versions of the same library.
471+
472+### Urbit, three battles unwon
473+
474+As I mentioned earlier, triage is essential on any long journey.
475+You have to keep moving forward, even when you have no idea where
476+you're going – which means attacking the hardest problems you
477+can solve right now.
478+
479+Unfortunately, this is a different standard than the usual rule
480+for shipping a product: solve the most important problems first.
481+This principle of triage is a general case of Knuth's apothegm
482+against premature optimization. Urbit, in fact, was absurdly
483+slow for a long time, but after a couple of engineer-months of
484+focused optimization it seems fine now.
485+
486+But there are other areas where Urbit today is surprisingly weak.
487+All look careless, but all are the result of careful triage.
488+When you find a weakness due to triage, you may think you are
489+judging Urbit's quality. You are just judging its maturity –
490+which doesn't make your judgment wrong, of course.
491+
492+#### Opacity
493+
494+Urbit's notorious opacity is the problem that makes people
495+complain the most. It's not an unwarranted complaint.
496+
497+At least, it's not all an unwarranted complaint. Part of the
498+complaint is just about novelty. Novelty is of course inherent
499+in any clean-slate stack. I do regret making 0 true and 1 false.
500+On every other count, however, I offer all critics of Urbit's
501+novelty none but the most vulgar gesture.
502+
503+But novelty is not the only problem. Urbit's external
504+documentation has gotten much better in 2018 – in particular,
505+it's now much easier to learn the language. Its _internal_
506+documentation, and general code quality, remains at best poor to
507+average. Worse: the worst code is the oldest, deepest code,
508+which is also the most fundamental. Not only is it not
509+commented, it is full of cryptic, meaningless names.
510+
511+There is now a new style guide, which should enable all reference
512+documentation to migrate into the codebase. But this style guide
513+is so new that none of the codebase complies with it. The guide
514+demands "space-rated" code that documents every variable and
515+every line – and almost none of the codebase is space-rated.
516+
517+Urbit's internal opacity persists for two reasons, one good and
518+one bad. The bad reason is just laziness. The good reason is
519+justified fear of _premature explanation_, which like premature
520+optimization ruins the annealing process.
521+
522+When you don't know exactly what you're doing, preserve as much
523+ambiguity as possible. For example, a name that means something
524+is a commitment to one specific explanation; a name that means
525+nothing is no commitment at all. A cryptic name is productive
526+procrastination; it lets the hard problem of naming get solved
527+later, and hence better.
528+
529+#### Impermanence
530+
531+Your Urbit ship needs to be _permanent_. That means it doesn't
532+lose data, sink, or get wedged, or rot. It's not complicated.
533+I wish Urbit today could make this promise, but it can't.
534+
535+There are are two problems here: short-term permanence and
536+long-term permanence. Short-term permanence means your ship
537+can't fail or lose data except via OS or hardware failure.
538+Long-term permanence means you can put your ship on a USB stick
539+in a box for 50 years, or 100, or 500, and when you turn it on
540+in a modern interpreter it will upgrade itself and work fine.
541+
542+There aren't any significant structural obstacles to each of
543+these milestones. But we can't claim them yet. We haven't
544+really even worried about them. This is another triage case:
545+in this case, the issue is _premature reliability_.
546+
547+Permanence also includes security. Except for the on-chain PKI,
548+in which case you're trusting Ethereum, you shouldn't yet trust
549+Urbit's security at all. Sorry!
550+
551+#### Duplication
552+
553+Triage can procrastinate in the other direction. It can skip
554+problems that are too hard to solve. When you procrastinate,
555+always come back – in this case, when the problem is easier.
556+Here's one way Urbit has skipped a problem that was too hard.
557+
558+Urbit, as you may recall, is a single-level store. It has only
559+one brain. And yet, we resisted the natural unification of
560+_documents_ and _applications_ and _secrets_ that a one-brained
561+computer obviously suggests.
562+
563+Instead, Urbit today is built more the Unix way (if not the
564+Windows way). It has separate subsystems for tracking and
565+updating these three kinds of data. This was my design. Like
566+Urbit's opacity or impermanence, this was always obviously lame.
567+
568+Why do it the lame way? Because, before understanding the union
569+of these problems, we had to understand each problem by itself.
570+We didn't – not even close.
571+
572+No one else ever built a purely functional operating system. No
573+one is going to go straight from zero to the right thing. You
574+have to solve a hard problem, learn from it, and do it again.
575+
576+Now that the team has built and used the specialized subsystems,
577+it's probably time to go ahead and generalize. The problem now
578+strikes me as almost straightforward. The constraints are clear
579+and so are the tools. None of this was true a year ago.
580+
581+On the low end, triage keeps you moving forward by stopping you
582+from wasting time on easy problems. On the high end, triage
583+keeps you moving forward by keeping you from leaping too far
584+ahead, and falling down an impossible rathole.
585+
586+## Further reading
587+
588+What will I do personally? I'll spend more time with my kids.
589+I'll finish reading my 1911 Britannica – I am only on the B's.
590+I have no other long-term plans.
591+
592+But I won't be back to Urbit. I am leaving not just the project
593+but the field – no less than Satoshi, or Everett, or Rimbaud.
594+Will Satoshi weigh in on the next Bitcoin Cash fork? Did Rimbaud
595+fly back from Ethiopia for his book-release tour? (Did anyone
596+want him back?) It's not so bad to be a middle-aged Rimbaud.
597+
598+Is there more to say? Of course, but not in prose. Read
599+Bunting's _Chomei at Toyama_ and _Notes on a Fly-Leaf_; Cavafy's
600+_Il Gran Rifiuto_, Keeley & Sherrard translation; Canto XV of the
601+Inferno, Pinsky translation. You might learn something.
602+
603+## Apologies and acknowledgments
604+
605+I apologize to anyone who has too little Urbit space. I refuse
606+to guilt-trip anyone who has too much.
607+
608+I appreciate my friends by not naming them. I disarm my enemies
609+by inviting them to lunch – but only if they come unarmed.
610+
611+I thank everyone who has ever worked on Urbit and everyone who
612+will work on it in the future; our backers, great and small; my
613+cofounder, Galen, and his family; my parents, wife and kids.
content/posts/an-urbit-overview.mdnew file+208
@@ -0,0 +1,208 @@
1++++
2+title = "An Urbit Overview"
3+date = 2016-05-11
4+author = "Galen Wolfe-Pauly"
5+description = "A high-level overview of Urbit."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-0.jpg)
10+
11+## What Urbit is
12+
13+Urbit is a virtual city of general-purpose personal servers.
14+
15+## Your old personal server
16+
17+What's a personal server? In a sense, you already have one. Your
18+personal server is the combination of all the cloud services you use
19+now.
20+
21+This "server" is a mess. It's broken into 17 different fragments
22+which are scattered all over the planet. You have no control at all
23+over any of the pieces. The more we depend on Web services, the more
24+we realize how unsustainable this situation is.
25+
26+Can you remember all the services you have accounts for? How about
27+the username and password for each? Some of them will let you pull
28+your data out somehow, some won't. Sometimes you can move your data
29+between them, sometimes you can't. But they're all good at
30+showing you ads.
31+
32+## Your new personal server
33+
34+Your urbit is your own general-purpose server. It holds your
35+data; runs your apps; wrangles your connected devices; and
36+defines your secure identity. If you still need your old
37+services, it drives them with APIs.
38+
39+Your urbit presents your whole digital life as a single web
40+service. And since it's yours, open source and patent-free, it
41+never shows you ads. Or loses your data. Or updates without
42+your consent.
43+
44+Technically, Urbit is a new kind of OS that has a precise formal
45+definition. (Urbit is actually a [single mathematical function](http://media.urbit.org/whitepaper.pdf).) One advantage of a math-based OS is that Urbit is perfectly
46+portable. It can't tell whether it's in a cloud data center or on
47+your home PC.
48+
49+Concerned about mass surveillance? Download your urbit and restart it
50+on your laptop, or move to a new host in Iceland. Urbit's formal
51+simplicity makes managing it as easy as managing an iPhone: all you
52+have to decide is what apps to add.
53+
54+Each urbit is a node on a global, encrypted P2P network. Your Urbit
55+name, a generated pseudonym like `~talsur-todres`, is also your
56+network address. Like Bitcoin, Urbit address space is a cryptographic
57+asset with a limited supply.
58+
59+By keeping addresses scarce, we make spam and abuse expensive. Urbit
60+is a "friendly network," like the Internet in 1986, where a stranger
61+is nice until proven nasty. As it matures, Urbit will grow into a
62+decentralized, self-governing virtual city both safe and free.
63+
64+## The Urbit future
65+
66+In an Urbit world, your data is no longer trapped in a jumble of
67+proprietary servers. Your urbit is a permanent, versioned, typed
68+archive the size of your digital life. Even before you move your data
69+from a Web service to a local Urbit app, your urbit can drive your
70+account with an API or scraper.
71+
72+And within Urbit, data is never locked inside apps. Imagine if you
73+could painlessly switch between Facebook and Google+, Asana and
74+Trello, Tumblr and WordPress. Not only does your urbit upgrade itself
75+and its apps automatically, you can "sidegrade" a running app to
76+another vendor without losing data.
77+
78+Your urbit is also your digital identity. Along with your data
79+lifestream of media, messages and documents, it has the keys and
80+tokens to manage all your legacy Web services. It holds the keys
81+for your cryptocurrency wallets, so it can buy and sell for you.
82+(With one personal server to secure, not 17 different accounts,
83+you actually have the bandwidth to take security seriously.)
84+
85+You still use network services. But instead of interacting with
86+the service provider's HTML UI, which phones home using
87+proprietary HTTP APIs, you interact with a third-party app on
88+your urbit, which talks to multiple service providers using
89+public, typed Urbit protocols. For example, your urbit runs a
90+single shopping app, which downloads catalogs and uploads orders.
91+This app is one store which sells everything in the world, with a
92+salesman who's 100% on your side and always has the best price.
93+Every computing experience is different when the UI is working
94+exclusively for the user.
95+
96+Finally, your urbit is the hub for your network of connected
97+devices. Your smart thermostat, your wristband, your phone and
98+tablet, all run satellite urbits which talk securely to your main
99+urbit in the cloud.
100+
101+## A chance for digital freedom
102+
103+The promise of the personal server isn't just convenience.
104+General-purpose computing is magic. This magic must be in the
105+hands of all, not just those who can master Unix. The computer
106+is a bicycle for the mind. It's an open vehicle for exploration
107+and discovery. It's not a way to optimize ad delivery.
108+
109+Urbit, as virtual city, is a platform that brings together all our
110+datastreams -- from emails to heartbeats -- in a way that we ourselves
111+control. Can we work together to match faces in photos, without
112+submitting to some panopticon in Mountain View? While the first step
113+in freedom is the right to be left alone, the second is the power to
114+form new intentional communities, to create and evolve a voluntary
115+definition of public space. We have no idea at all what people will
116+do with this power.
117+
118+General-purpose computing is digital freedom. And today, a cloud data
119+center is the technically optimal locus of computation. The cloud is
120+always on, always available, never loses data. Hosts are sometimes
121+attacked; but they never intentionally tamper with their virtual
122+computers. The cloud can never be secure against a global adversary;
123+but most people don't have a global adversary. A single portable
124+platform provides "herd immunity" for the few who do need direct
125+physical control over their main computers.
126+
127+Though even laptops are atrophying into mere browsers, mass-market,
128+general-purpose computing on the client side remains an endangered
129+species that must be protected. But on the server side, this species
130+has never even _existed_. There has never been anything like a
131+mass-market personal server. Why not?
132+
133+## Freedom is an engineering problem
134+
135+Urbit is not a difficult idea. Urbit is like a flying car: the idea
136+is not the hard part. Almost everyone we talk to about Urbit turns
137+out to have had pretty much the same idea themselves. The problem is
138+building it.
139+
140+A server is a computer. It's running some operating system. This OS
141+is a flavor of Unix. There are no alternatives. It's connected to
142+some network. This network is the Internet. It has no competitors.
143+You can have a personal server, if it's a Unix server on the Internet.
144+
145+Almost no one thinks being a Unix system administrator is fun. Not
146+even Unix system administrators think running an Internet server is
147+fun. So the personal Unix/Internet server is like the personal
148+bulldozer. This is not a consumer product. Any number of engineers
149+can't turn a bulldozer into a bicycle.
150+
151+How did we build the personal bulldozer? We didn't. We started
152+from scratch. (The people who built the first PCs didn't start
153+with a mainframe OS, either.) We created a new platform: Urbit.
154+
155+Urbit doesn't compete with Unix and the Internet. It's a new,
156+opaque layer on top of them. Your browser runs on a native OS,
157+but it doesn't give Web apps any way to talk to the native OS.
158+Urbit is like a browser for the server side: code within Urbit is
159+formally isolated from the platform it runs on top of.
160+
161+Your urbit is a Unix process, in a data center or your PC. It sends
162+UDP packets over the Internet. It can both load and serve web pages
163+over HTTP. Except for character sets and crypto, nothing in Urbit
164+reuses or depends on any 20th-century code.
165+
166+Urbit is a complete, clean-slate system software stack: a
167+non-lambda interpreter (Nock), a functional language (Hoon), and
168+an event-driven OS (Arvo), with its own encrypted protocol
169+(Ames), typed revision control (Clay), reactive web server (Eyre)
170+and functional build system (Ford). The full system, including
171+basic apps, is only 30,000 lines of Hoon.
172+
173+The first end-to-end prototype of Urbit took one engineer eleven
174+years. The current beta took three more years, with about three
175+engineers on average.
176+
177+How does it take 14 years to write 30,000 lines of code? The code
178+wasn't the hard part. The hard part was rewriting it until it was
179+right. We think we've solved all the real CS problems, and we're
180+certainly done changing major interfaces. But it will take more than
181+our small team to deliver a polished Urbit user experience that can
182+actually challenge modern web apps.
183+
184+## Where we are, what we're doing
185+
186+Urbit is in feature freeze. It's a minimum viable product in
187+early beta. It still needs quite a bit of fit-and-finish work.
188+We certainly don't recommend it for end users or consider it in
189+any way secure. But it's fun to play with, if you're a hacker.
190+
191+This summer, we're making the switch to an open and transparent
192+development and specification process. A system as unusual as
193+Urbit can't be invented in public. But it has to be finished and
194+maintained in public.
195+
196+Additionally, we're creating an open political and economic process,
197+with a small, fixed-price public presale of Urbit address space. Join
198+us and help make this future actually happen.
199+
200+To keep reading, learn more about [Urbit's address
201+space](../the-urbit-address-space); share our vision of the Urbit user
202+experience, from the [top down](../what-is-urbit-for) or the [bottom
203+up](../magic); check out the [development roadmap](../roadmap);
204+evaluate Urbit's [beliefs and principles](../beliefs-and-principles) or its
205+[interim constitution](../interim-constitution).
206+
207+(For technical readers, check out our [documentation](https://urbit.org/docs/) or
208+the [whitepaper](http://media.urbit.org/whitepaper.pdf)).
content/posts/azimuth-is-on-chain.mdnew file+108
@@ -0,0 +1,108 @@
1++++
2+title = "Azimuth is On-Chain"
3+date = 2019-01-14
4+author = "Galen Wolfe-Pauly"
5+description = "The Urbit address space, now called Azimuth, is on the blockchain. And too many other things to fit into a single post."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](https://storage.googleapis.com/media.urbit.org/site/arvo-4.svg)
10+
11+The Urbit address space is now live on the Ethereum blockchain. We’re calling the PKI ‘Azimuth’ and you can find it at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). Owners of Azimuth ‘points’ (galaxies, stars or planets) can use [Bridge](https://github.com/urbit/bridge/releases) to manage them and view their balance now.
12+
13+
14+Sometime in the next few days, owners of Azimuth points will be able to boot Arvo, the Urbit OS, from their Azimuth point and request access to one of our 'cities': private communities for chat and discussion. These new cities use Landscape, a brand new UI for using Urbit in the browser.
15+
16+This means you can boot a deterministic OS from an identity you own, join a totally independent, decentralized and self-governing network and run a clean, simple UI. Pretty exciting. Is it ready for ordinary users? Definitely not.
17+
18+Since 2013, you've been able to boot an Urbit and join our test network. And, since 2013, we've always had our sights set on building a personal server that can both last 100 years and be delightful to use. Urbit isn't meant just to be as good as the MEGACORP software we use today. It's meant to be much, much better.
19+
20+But Urbit is not a 'product' in the conventional sense. Urbit is a public thing. It's meant to belong to everyone. For the past six years, much of our work was research and design work. Which means lots of weird ideas thrown away, and others rewritten or redesigned many times over. Our work has always been open source, but we tend to be pretty quiet about it.
21+
22+With Azimuth on the blockchain, it's time for us to start engaging with the world more directly.
23+
24+We aren't calling this a launch. There's no keynote. There's no dancing on stage. I mean, it's 2019. You must be pretty sick of being marketed to. We'll try to stick to the specifics here. What's new, what we've been up to and what works. There's too much to fit into a single post, so we'll keep it pretty light for now. Each of these sections will probably get its own post in the near future.
25+
26+> Note: As of `~2019.1.14` we're in the process of rebooting the Arvo network. We expect it to be back online before the end of the week. We'll update this post and [tweet](https://twitter.com/urbit) when the network is online and stable.
27+
28+
29+## Rethinking the stack
30+
31+We've started to talk about Urbit as a stack of three parts: Azimuth, the address space and identity layer on Ethereum; Arvo, the OS and overlay network; and Aegean, a pattern for building decentralized communities on the Arvo network.
32+
33+We tried to capture this separation in [the primer](/primer), a new overview of Urbit. Explaining Urbit has always been challenging. A monolithic project that is OS, network, language, VM and UI barely makes sense. Separating the layers helps, we think.
34+
35+Let's step through them to see what's new.
36+
37+
38+## Azimuth
39+
40+![](https://storage.googleapis.com/media.urbit.org/site/bridge-0.png)
41+
42+As a quick refresher: Urbit addresses, now called Azimuth 'points', are short names like `~diblun-tidduc`. You own your Azimuth point with a private key and can use it as a routable network address on the Arvo network. You can read more about Azimuth in [the primer](/primer#what-azimuth-is). If you're curious who owns all this address space, you can find that [in there too](/primer#azimuth-distribution).
43+
44+In late 2017 we decided to migrate the yet-to-be-named Azimuth to a system of Ethereum contracts. After a year of coding, testing, auditing and migrating — they're now fully deployed to the Ethereum mainnet.
45+
46+Azimuth is basically two parts, a database of who owns which points, and a set of rules about what points and their owners can do. That set of rules is called Ecliptic, and can be found at [`0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d`](https://etherscan.io/address/0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d) or [`ecliptic.eth`](https://etherscan.io/address/ecliptic.eth). The top-level Azimuth points, the galaxies, can vote on upgrades to the Ecliptic contract, but they can't edit the database of who owns what.
47+
48+The ownership database contract is called Azimuth, which you can find at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). For those of you who own address space, you can use the `getOwnedPoints` function in the 'Read Contract' tab to check your balance. The function returns the number (not the phonemic string like `~ravmel-ropdyl`) of your points. Each Azimuth point is an ERC-721, non-fungible piece of digital property.
49+
50+To manage your points, we built [Bridge](https://github.com/urbit/bridge/releases), a completely custom interface for interacting with our Solidity contracts. Interface quality is really important to us, and we couldn't find anything in the 'crypto' world that met our standards. Bridge is good, but crypto UX is a hard problem. We've already got some ideas for improvements.
51+
52+If you're curious, you can find the source for the contracts in the [`urbit/azimuth`](https://github.com/urbit/azimuth) repo. The Bridge source is in the [`urbit/bridge`](https://github.com/urbit/bridge) repo.
53+
54+We had the source for our contracts audited by Open Zeppelin, Blockchain at Berkeley and Blocktrax. Did we miss something? We sure hope not — but we'd happily compensate anyone who can find bugs. Please reach out to security@urbit.org if you find something of concern. We'd be happy to hear from you.
55+
56+![](https://storage.googleapis.com/media.urbit.org/site/sigils.svg)
57+
58+Azimuth names have always had a pronunciation system. `~ronryd-nidseg` is 13,695,781, for example. Now, they also have a visual system. We call these strange crests from another planet 'sigils', and you'll notice them used throughout all our new interfaces. You can find the source in the [`urbit/sigil-js`](https://github.com/urbit/sigil-js) repository. Building these was a lot of fun — we'll save the details for a future post.
59+
60+So, how do you get an Azimuth point? We've left that question unanswered intentionally. Azimuth points are meant to be like digital land, not currency. They should change hands slowly. In order to get an Azimuth point, you'll need to find someone who already has one and is willing to part with it.
61+
62+
63+## Arvo
64+
65+![](https://storage.googleapis.com/media.urbit.org/site/fast-lux-3.gif)
66+
67+Arvo boots from Ethereum, is no longer embarrassingly slow, and has a brand new build system. [Our documentation](https://urbit.org/docs/learn/arvo/hoon) has also improved quite a lot. Hoon, Arvo's programming language, has had a lot of work done to its type system and compiler. We built new tooling for generating static sites (you're probably reading this on one right now) that are much, much faster and easier to use.
68+
69+It's tough to talk about the progress we've made on Arvo without writing a long technical post. We'll save that for later. In a way, what's remarkable about Arvo is that it has become *less* remarkable. It's more stable, faster, and the code quality has improved.
70+
71+There's plenty of work to do, though. Should you be building on top of Arvo? Probably not yet. The kernel and kernel modules are really where the work still lies. We build things on top of Arvo, and in doing so it's pretty clear that the system can be better. Clay (the filesystem) and Gall (the application model) are due for a rewrite. A complete rewrite of the web server, Eyre is almost finished.
72+
73+
74+## Aegean
75+
76+![](https://storage.googleapis.com/media.urbit.org/site/landscape-inbox.png)
77+
78+Aegean is a pattern for building 'cities': groups of people running the same 'agent' on their Arvo servers. Agents aren't just 'apps' or programs. An agent rolls together the tools that a community needs. Today, our companies, communities, cults, cliques all have to duct tape together separate MEGACORP apps and services to compute together.
79+
80+Aegean reverses this pattern. A community on Arvo is a city: just a bunch of people running the same agent. Each city is in control of its own codebase: the interface, application code _and_ data storage. This means a community can have complete agency over how to compute together.
81+
82+Aegean cities can be completely different without impacting one another at all. Cities share the neutral infrastructure of Arvo and Azimuth — but they may never even know others exist. An archipelago of hypercultures.
83+
84+It's important to note: the pattern of these cities is _not_ the pattern of Azimuth. The network hierarchy should impact the society of Urbit as much as the electrical grid impacts the life of the street in Manhattan. It matters when the power goes out — but most of the time groups form and dissipate continuously.
85+
86+Before we can let the ocean of cities grow we have to homestead a few of our own.
87+
88+Our first agent is called [Landscape](https://github.com/urbit/landscape), an agent for chat and longform discussion. We are using Landscape to run a few experimental cities over the next month or so. If you have an Azimuth point, you'll need to [request access](mailto:support@urbit.org) to join.
89+
90+Anyone can create their own city, of course. The source is open. But we're not going to encourage you to just yet. Feel free to explore, but also be patient. We've got a lot planned around this. If Azimuth is done and Arvo is young, Aegean is just being born.
91+
92+
93+## Tlon
94+
95+![](https://storage.googleapis.com/media.urbit.org/site/office-1.jpg)
96+
97+So who is behind all of this? A team of collaborators and contributors. Many of us work at [Tlon](https://tlon.io) — the company we started in 2013 to advance Urbit platform development. Tlon has attracted an incredible group of smart, talented people who want the world to be able to own and control their computers. I'm proud to work alongside them.
98+
99+One important omission on `tlon.io` is Curtis. As of today, he's no longer working on Urbit. [His own words](/posts/essays/a-founders-farewell) are the best way to understand his thinking. It's an achievement for the team, I think, that he can depart with confidence.
100+
101+One major reason for that confidence is that Erik and Anthony have now become COO and CPO respectively. Having thoughtful, organized people leading the project is a huge benefit to the whole team. I'm very glad to have them on board.
102+
103+
104+## Looking ahead
105+
106+I certainly forgot at least a thing or two. We'll dive in to more detail in the coming weeks.
107+
108+There's a lot for you to explore. Have fun!
content/posts/beliefs-and-principles.mdnew file+126
@@ -0,0 +1,126 @@
1++++
2+title = "Beliefs and principles guiding the Urbit project."
3+date = 2016-05-11
4+author = "Galen Wolfe-Pauly + Curtis Yarvin"
5+description = "We believe."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-2.jpg)
10+
11+## Beliefs
12+
13+We believe that general-purpose computing is an essential tool to
14+unlock the power of individual creativity.
15+
16+We believe that ownership, privacy and control don't need to be
17+sacrificed in exchange for usability, accessibility and reliability.
18+
19+We believe in the power of the informed crowd to develop and maintain
20+software, through the IETF principles of sincerity and rough consensus.
21+The ability of the engineering community to govern itself through
22+republican forms is not an abstract theory; it's a proven fact.
23+
24+We believe in both free speech and individual accountability. We
25+believe that a healthy network is one with diverse and well-defined
26+communities, and clear, user-controlled, boundaries between public and
27+private space.
28+
29+We believe that no software system can replace human trust and
30+communication. Dialogue, judgment and governance are essential to
31+communities of all scales. Code and law can reduce conflict in the
32+common case; they can never handle all exceptions.
33+
34+## Principles
35+
36+Here are some principles of Urbit. Where principles conflict,
37+the first stated takes precedence.
38+
39+### Digital independence
40+
41+Digital independence is independent control of your own
42+general-purpose computer which holds your own primary data.
43+Urbit's ultimate purpose is to make practical digital
44+independence a useful and widely available product.
45+
46+### Code is law
47+
48+Wherever possible, the rules of Urbit must be executable as code.
49+Wherever possible, code must be self-enforcing. If not, it must
50+be perfectly defined. If not, it must not be stated.
51+
52+### Sovereignty is conserved
53+
54+Even where code is law, exceptional situations demanding
55+effective collective action will always arise. There must
56+always be a collective authority to solve these problems.
57+
58+Two known problems in Urbit that require central authority are
59+approval of software updates and activation of the network. But
60+there will certainly be others.
61+
62+### Purpose of collective authority
63+
64+Urbit, as opposed to the Tlon corporation, is a republic. Its
65+government has one task: promoting, preserving and protecting Urbit.
66+It may take any legal action which advances this goal. Any other
67+actions are *ultra vires*, out of scope. Urbit is not a
68+general-purpose charity.
69+
70+### Decentralized control
71+
72+Urbit should never fall under any kind of central control. All
73+transitions in galaxy ownership should divide positions, not
74+unite them.
75+
76+Galaxy and star ownership should also be separated. It is
77+harmful for a single entity to hold both galaxies and stars.
78+
79+### Property is contingent
80+
81+Property rights are contingent and accidental, not moral or
82+meritorious. A property register does not record why an owner
83+deserves some property. Ownership is neither a reward nor a
84+right; it is a fact.
85+
86+### Governance is by stake
87+
88+Ultimately, Urbit must be governed by those who own it. In each
89+tier, equal stakes must hold equal authority.
90+
91+### Content-neutral
92+
93+Urbit does not admit a tradeoff between anarchy and tyranny,
94+order and liberty. Urbit has zero tolerance for abuse, nor does
95+it facilitate censorship.
96+
97+Urbit will do everything possible to help you block content you
98+don't want to see. It does nothing to help you block content you
99+don't want others to see.
100+
101+### Trolling considered harmful
102+
103+If you post content on Urbit which may offend or disturb any
104+significant group of users, it is your responsibility to mark it
105+properly for automatic blocking.
106+
107+### Sockpuppets considered harmful
108+
109+The only legitimate reason for one individual to use multiple
110+identities is to maintain multiple active pseudonyms. But
111+multiple identities must never interact in the same context.
112+
113+### Not a darknet
114+
115+Urbit is not a darknet. It does not break real-world laws. It
116+is not designed to facilitate the breaking of real-world laws.
117+For any problem that lawbreakers have, there must always be a
118+better solution that is not Urbit.
119+
120+### Responsibility to route
121+
122+As long as they are not facilitating violations of any of these
123+principles, or laws in their own jurisdictions, stars and
124+galaxies are responsible for routing their children. They are
125+also collectively responsible for escape-routing the children of
126+stars and galaxies which fail in their responsibility.
content/posts/blockchannel-episode-19-virtual-land-in-the-clouds-with-urbit.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Episode 19: Virtual Land in the Clouds, with Urbit"
3+date = 2017-04-16
4+author = "Tlon"
5+description = "Galen and Curtis talk Urbit on the BlockChannel podcast."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ soundcloud(url="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/318017856&color=%23ff5500&auto_play=false&hide_related=false&show_comments=true&show_user=true&show_reposts=false&show_teaser=true&visual=true") }}
10+
11+[Episode 19: Virtual Land in the Clouds, with Urbit](https://medium.com/blockchannel/episode-19-virtual-land-in-the-clouds-with-urbit-1428ba98243a)
content/posts/blueprint-2017-galen-wolfe-pauly-on-the-distributed-web.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Blueprint 2017 Talks: Galen Wolfe-Pauly on the Distributed Web"
3+date = 2017-11-20
4+author = "Tlon"
5+description = "Galen presents to IDEO on Urbit and decentralized systems."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ youtube(id="9cXTGW9J9a0") }}
10+
11+[Blueprint 2017 Talks: Galen Wolfe-Pauly on the Distributed Web](https://www.youtube.com/watch?v=9cXTGW9J9a0)
content/posts/bootstrapping-urbit-from-ethereum.mdnew file+387
@@ -0,0 +1,387 @@
1++++
2+title = "Bootstrapping Urbit from Ethereum"
3+date = 2017-09-20
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "We've decided to launch Urbit's constitution as a system of Ethereum contracts."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+*TL;DR:*
10+
11+We've decided to launch Urbit's constitution as a system of Ethereum contracts.
12+
13+We'll instantiate a land registry for Urbit address space; an ERC20 "spark"
14+token which is burned to create a generic star; and a voting system for
15+self-governance. We'll also create template contracts which galaxies can use to
16+auction stars, and stars to distribute planets.
17+
18+## A bit of background
19+
20+One thing we realized after the last sale was, 'oh hey, the network has been up
21+for about a year.' Not bad! It wasn't that long ago that we were rebooting the
22+universe every few weeks. We still have plenty of work to do — but Urbit has
23+matured to the point where public ownership of the network really should be
24+cryptographically real.
25+
26+But even when the servers stay up, Urbit is still a testnet and remains
27+centralized in practice. We (Tlon) retain the ability to reset the network keys
28+at any time. This just isn't very 2017.
29+
30+In theory, Urbit doesn't need a blockchain, because real estate moves slowly.
31+In digital real estate, as opposed to digital currency, a low-friction,
32+zero-trust solution to the double-spend problem isn't an economic necessity.
33+
34+In practice, though, we have a hard chicken-egg problem. In the current design,
35+the key you use to secure your urbit is the same key that you use to sign your
36+network packets. Abstractly, this is the right design -- you want one
37+definition of who owns an identity.
38+
39+But concretely, since Urbit keys are valuable, you don't want to put them in an
40+operating system that isn't generally recognized as systematically secure. It's
41+hard to achieve this status while you're a testnet. So the virtuous cycle never
42+gets started.
43+
44+Moving the Urbit land registry to Ethereum is an easy and obvious solution to
45+this problem. If your urbit is owned by an offline Ethereum key, there's now a
46+mature ecosystem for protecting this property. And its security doesn't depend
47+on the security of Urbit. So, we realized, maybe Urbit actually does need a
48+blockchain for its land registry. While the system matures, we can bootstrap
49+off of Ethereum, without changing the design of the Urbit cryptosystem.
50+
51+And best of all, you can get your Urbit star or planet entirely through the
52+blockchain, without interacting with any centralized database or payment
53+mechanism. So we're really living in 2017.
54+
55+Sounds good, right?
56+
57+It does sound good. Although, as usual, we care about making things that *work*
58+above all else. So, rather than a 'announcing the Urbit token sale' post, this
59+is going to get fairly technical. We want to start the discussion about how
60+this change is going to work, and how it's going to get implemented. We'll save
61+the hype for later.
62+
63+First, we'll walk through the costs and benefits of using Ethereum. Then,
64+we'll refresh our memories on how the Urbit address space works, and finally
65+we'll walk through some of the details of how we plan on implementing this.
66+We've thought quite thoroughly about these things, but public criticism is
67+really important.
68+
69+## Weighing the choice of Ethereum
70+
71+Our engineering style is to build the whole stack, from axioms to UI, from
72+custom, super-minimal parts. When these parts don't fit perfectly, we rewrite
73+them until they do. With a few exceptions, such as crypto algorithms, Urbit
74+doesn't reuse existing code or designs, depend on existing tools, or expect
75+outside contributors to solve problems essential to a complete experience.
76+
77+Instinctive minimalism is essential in a custom full stack. The best solution is
78+always to not solve the problem. The natural engineering response to the
79+pre-blockchain difficulty of solving Byzantine consensus agreement was: do we
80+really need it?
81+
82+### The case against Ethereum
83+
84+Since Urbit network address space is a land registry, not a currency,
85+transactions are low-frequency. A low-frequency transaction system can succeed
86+economically even if it has high friction. The double-spend problem, which
87+consensus computing solves, becomes easy or at least tractable given high
88+friction.
89+
90+We reinvent the wheel if we have to, throw it away if we can. So depending on
91+Ethereum goes against all Urbit's instincts.
92+
93+Let's enumerate the problems, as critically as we can:
94+
95+And Ethereum's user experience is notorious; its governance is suspect and
96+unstable; its dilution rate is unconscionable; its dev environment is full of
97+bugs and misfeatures; in short, it's a classic MVP. It has only one real goal:
98+success. It seems to be doing pretty well with that.
99+
100+We prefer [SLC](https://blog.asmartbear.com/slc.html) to MVP. Urbit under
101+construction is fun to play around in. But we certainly won't ask real users or
102+real developers to set foot in Urbit until their experience is truly simple,
103+lovable and complete. The original iPhone set the bar for this, and we'll get
104+as close as we can.
105+
106+### The case for Ethereum
107+
108+It's obvious that Urbit has a practical problem in deploying a self-hosted PKI.
109+When does the testnet become a realnet? You wouldn't put real, valuable keys in
110+your urbit, until you know the system is mature and secure.
111+
112+But how does anyone know that Urbit is mature until more daring users have used
113+it with real, valuable keys? But who wants to be the first person to hop into
114+the box?
115+
116+There is no clear way to bootstrap past the testnet phase. Except, well, reboot
117+Urbit onto an existing blockchain, with a tested and reasonably-secure
118+key-handling infrastructure, that can also validate the Urbit PKI rules. Then
119+each user can decide on their own whether sensitive data is safe in their own
120+urbit.
121+
122+## An Urbit refresher
123+
124+Maybe some people are here because they know what Ethereum is, but not so much
125+Urbit.
126+
127+For those of you not familiar, let's try to refresh your memories.
128+
129+### What Urbit is
130+
131+One simple way to think about Urbit is as a "personal blockchain." Like a
132+blockchain, Urbit is a deterministic virtual computer. Its semantics are defined
133+by a frozen lifecycle function, which maps its event history to its current
134+state. But, unlike a blockchain, an Urbit instance is a private computer for one
135+user, not a public record for everyone.
136+
137+Urbit's lifecycle function is a nano-interpreter called Nock. A typed functional
138+language, Hoon, compiles itself to Nock. An event-driven OS, Arvo, is written in
139+Hoon. Everything above Nock can upgrade itself over Urbit's own overlay packet
140+network, Ames. Ames is live and stable with test keys.
141+
142+Our Urbit interpreter runs on any Unix machine. The Urbit server is a
143+single-level store -- both database and application engine. Every Urbit event is
144+a transaction. Urbit is semantically frozen and cannot call out to Unix.
145+
146+Your Urbit instance is your personal server. Your urbit should eventually
147+contain and manage your whole digital life. You may compute at home or in the
148+cloud, based on your security/privacy tradeoff, but Urbit's formal semantics
149+makes ships trivial to migrate. You'll never be locked in to one computing
150+provider.
151+
152+### The Urbit address space
153+
154+An Urbit address is called a "ship." A ship is a network address, a
155+cryptographic identity, a pronounceable name, and a permanent memory. A ship's
156+name is just its numeric address, written in a syllabic base-256.
157+
158+Smaller addresses mean shorter, more memorable ships. Ships are classified in a
159+hierarchy: 8-bit "galaxies" (like `~dyl`), 16-bit "stars," (`~ropdyl`), and
160+32-bit "planets" (`~ravmel-ropdyl`). Galaxies and stars are network
161+infrastructure. Regular users have planets. The tight 32-bit address space makes
162+names short enough to remember, and costly enough to deter Sybil attacks.
163+
164+Planets are created by their prefix star; stars are created by their prefix
165+galaxy; galaxies were created by the founders. Parents assist their children,
166+providing essential services like peer-to-peer packet routing, but don't own or
167+control them. The prefix is just an initial default -- a ship can switch to any
168+parent that's willing to adopt it.
169+
170+## Summary of the integration model
171+
172+In the new integrated model, every planet, galaxy or star is owned by an
173+Ethereum address. The secret that controls this address is the ship's "master
174+key."
175+
176+The master key is not needed to operate the ship and should not be stored on it,
177+at least not until Urbit is more mature. Master keys should be kept as "cold" as
178+possible. They are only used to perform lifecycle operations on your ship, by
179+signing Ethereum transactions which are sent to the Urbit constitution.
180+
181+We'll fork an open-source Ethereum browser and add a custom UI for Urbit
182+transactions. New users will acquire their urbits entirely on the blockchain.
183+
184+The most basic Urbit transaction is starting a ship you own. To start your ship,
185+you use Urbit to generate an Urbit keypair, and use Ethereum to register the
186+Urbit public key (a 512-bit pair of Curve25519 for encryption and Ed25519 for
187+signature) on the Ethereum blockchain.
188+
189+For users who want to hold generic stars without starting or even selecting
190+specific ships, we'll create a divisible "spark" (USP) ERC20 token. A spark is
191+the right to create one star. Sparks are a convenience tool: they leverage the
192+mature ERC20 infrastructure for holding and trading token utility rights.
193+
194+Instead of launching stars directly, galaxies can cede their unlaunched stars to
195+the Urbit constitution. The issuing galaxy receives one spark in exchange for
196+this star. Any Ethereum address can redeem one spark in exchange for the right
197+to start one star from the constitution's pool.
198+
199+Once all the galaxies are created, Urbit is fully decentralized. We retain no
200+ownership powers over the Urbit constitution.
201+
202+The Urbit galaxies will mirror the state of the constitution, distribute its
203+state and events within Urbit, and post any transactions created within Urbit.
204+Generally an Urbit ship trusts its parent -- if not, it should find a new one
205+fast. But a deeply paranoid ship can still listen to Ethereum directly.
206+
207+## Contract designs
208+
209+The Urbit constitution is four contracts: certificate storage, spark storage,
210+election storage, and logic controller.
211+
212+Following Ethereum best practice, we'll use separate storage and logic
213+contracts. The logic contract is stateless, and can upgrade itself without
214+replacing the storage contracts.
215+
216+We'll walk through how we have designed these contracts in detail here. You can
217+also view our in-progress source at the
218+[`urbit/constitution` GitHub repo](https://github.com/urbit/constitution).
219+
220+### Certificate storage contract
221+
222+For every galaxy, star or planet, the certificate contract holds a current
223+state: `%latent`, `%locked`, `%liquid` or `%living`.
224+
225+The default/empty state is `%latent` (nothing has happened to this ship). The
226+contract stores no data for a latent ship.
227+
228+A `%locked` ship has an owner and an activation date. It cannot be activated
229+until the given date. Until activated, the locked ship can't be transferred,
230+vote, liquidate or launch children.
231+
232+A `%liquid` ship is held by the Urbit constitution to be redeemed for a spark.
233+It has no other state.
234+
235+A `%living` ship is active. Its state: an Ethereum address which owns it; an
236+Urbit public key; a revision number, which increments on any lifecycle
237+operation; and (for planets and stars) both current and requested (for escaping)
238+parent ships.
239+
240+The certificate contract throws an event on every state change.
241+
242+### Spark storage contract
243+
244+The spark contract is a divisible ERC20 token (you can't hold half a star, but
245+you can hold half a spark). Only the logic contract can create and destroy
246+tokens.
247+
248+### Governance storage contract
249+
250+The governance contract records galaxies' votes on governance proposals.
251+
252+There are two kinds of proposals: concrete and abstract. A concrete proposal is
253+the address of a new logic contract for the constitution. An abstract proposal
254+is the hash of a document.
255+
256+Voting is one-bit -- the default vote is "no" -- and irreversible. A 256-bit
257+bitfield records the set of galaxies that have voted for each proposal.
258+
259+Only active galaxies may vote. A counter records the number of active galaxies.
260+A proposal passes if more than 50% of active galaxies support it. If the
261+proposal is concrete, the old logic contract is terminated and the new one
262+receives storage control. Abstract proposals have no further effects on the
263+blockchain.
264+
265+### Logic contract
266+
267+The logic contract is stateless and supports the following ops:
268+
269+#### Create a galaxy
270+
271+What: move a galaxy from `%latent` to `%locked` state.
272+
273+Who: the founders only.
274+
275+Comments: this is the only founder-privileged operation.
276+
277+#### Liquidate a star
278+
279+What: move a specific star from `%latent` to `%liquid` state, granting one spark
280+to the galaxy owner.
281+
282+Who: owner of the active galaxy which is the star's prefix.
283+
284+#### Claim a star
285+
286+What: move a specific star from `%liquid` to `%locked` state, with the
287+activation date set to the present, and the owner as claimer; remove one spark
288+from the owner.
289+
290+Who: any Ethereum address which owns a spark.
291+
292+#### Launch a star or planet
293+
294+What: move a specific star or planet from `%latent` to `%locked` state, with the
295+activation date set to the present, and set the Ethereum address which owns the
296+ship.
297+
298+Who: owner of the parent of the launched ship.
299+
300+#### Start a ship
301+
302+What: move a specific ship from `%locked` to `%living` state, setting its Urbit
303+public key.
304+
305+Who: owner of the locked ship.
306+
307+#### Transfer a ship
308+
309+What: change the owner of a `%living` ship, also resetting the Urbit public key.
310+
311+Who: current owner of the ship.
312+
313+#### Rekey a ship
314+
315+What: in a living ship, change the Urbit public key, without changing the
316+Ethereum address that owns the ship.
317+
318+Who: owner of the ship.
319+
320+#### Request adoption
321+
322+What: in a living ship, set the requested-parent field.
323+
324+Who: owner of the ship.
325+
326+#### Accept adoption
327+
328+What: in a living ship, set the current parent to the requested parent, and
329+clear the requested parent.
330+
331+Who: owner of the requested parent.
332+
333+#### Create a proposal
334+
335+What: create a proposal, which is either the hash of a document (abstract) or
336+the address of a new logic contract (concrete).
337+
338+Who: owner of any living galaxy.
339+
340+#### Endorse a proposal
341+
342+What: register support for a proposal. If the proposal is concrete and this
343+vote takes it over 50%, upgrade the contract.
344+
345+Who: any galaxy who has not yet voted on this proposal.
346+
347+### Planet sales and spark auctions
348+
349+We'll also write contracts that help galaxies and stars distribute their stars
350+and planets.
351+
352+#### An auction contract for spark sales
353+
354+The ERC20 spark token creates a liquid market in stars, or rather star
355+precursors. But a galaxy liquidating sparks may not want to just sell a large
356+block into this market, which may have weak depth, especially when the token is
357+initially launched.
358+
359+So we'll validate and deploy the Nick Johnson design for an
360+[off-chain second-price auction](https://www.reddit.com/r/ethereum/comments/6igsdq/a_proofofconcept_of_a_better_crowdsale_contract/)
361+
362+To run an auction, the seller liquidates a block of stars, then transfers the
363+spark tokens to a seller-owned copy of the auction contract. The Urbit
364+constitution is not involved with the auction.
365+
366+#### A distribution contract for planet sales
367+
368+There is no generic token for planets. To start a planet, you need a star to
369+launch it with your Ethereum address as the owner.
370+
371+To distribute planets on the blockchain, a star instantiates a private copy of
372+the planet sale contract. Since the star is the contract's owner, the contract
373+can send launch operations to the Urbit constitution.
374+
375+The star owner configures the planet sale contract with two parameters: the
376+price in ether of a planet, and the number of planets available.
377+
378+## Okay, so
379+
380+That was quite a lot of information! We've created a fora thread
381+[here](https://urbit.org/fora/posts/~2017.9.20..22.56.04..47ce~) for discussion,
382+and would be glad to hear your feedback. GitHub issues on the
383+[urbit/constitution repo](https://github.com/urbit/constitution) are also more
384+than welcome.
385+
386+There's a lot more to come on this front as our contracts get closer to getting
387+live, and we begin migrating toward an on-chain Urbit PKI.
content/posts/common-objections-to-urbit.mdnew file+722
@@ -0,0 +1,722 @@
1++++
2+title = "Common Objections to Urbit"
3+date = 2016-06-28
4+author = "Curtis Yarvin"
5+description = "Some common objections to Urbit, discussed."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-9.jpg)
10+
11+We love crowdsourced criticism. We've heard a lot of great
12+objections to Urbit. Surely there's more out there! If so,
13+comments are open at the bottom of the page. We'll revise this
14+document to include anything new and interesting.
15+
16+Here's our list right now:
17+
18+- [Urbit is not ready for prime time.](#prime)
19+- [Nock jets are a total hoax.](#jets)
20+- [Urbit needs an infinitely extending packet/event log.](#log)
21+- [Urbit is a total scamcoin. It's 100% premined.](#scam)
22+- [Urbit isn't even really decentralized! It has a government!](#gov)
23+- [Sandstorm/IPFS/Ethereum is way ahead of Urbit.](#sand)
24+- [Urbit doesn't have enough planets for every human being.](#planet)
25+- [Cloud computing is inherently non-private.](#pwned)
26+- [Urbit will never be able to call any existing code.](#code)
27+- [Hoon is too weird. No one will be able to program in it.](#program)
28+- [Urbit programmers are stuck with Hoon.](#stuck)
29+- [Ordinary users will never be able to manage an Urbit server.](#user)
30+- [Urbit has no killer app.](#killer)
31+- [Urbit is sniffed at by Houyhnhyms.](#horse)
32+
33+_"We choose to go to the moon, not because it is easy, but because it is hard."_
34+— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)
35+
36+## <a name="prime"></a>Urbit is not ready for prime time.
37+
38+*TLDR*: we agree.
39+
40+Urbit right now is a fun toy. It is fun to learn Hoon. It is
41+even fun and quite practical to make actual contributions.
42+(Hoon's IEEE floating-point was written by someone we've never
43+met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never
44+seen anyone _not_ have fun with Urbit.
45+
46+But there is all kinds of stuff wrong with the codebase. Urbit's
47+documentation is much improved, but remains incredibly weak --
48+Arvo is almost totally undocumented. Scaling is poor at best.
49+Urbit's reliability is dubious. Its security is nil.
50+
51+Urbit is feature-frozen. The only thing we're working on now,
52+and for the rest of 2016, is doc, debugging and and self-hosting.
53+In that order of importance -- teaching Urbit is more important
54+than fixing it, which is more important than making it useful.
55+But we're quite confident that these are all solvable problems.
56+
57+The most important milestone about Urbit today is that it's ready
58+for technical decisions to be made collectively. A system like
59+Urbit can only be invented by a mad auteur. It can't be
60+maintained or stabilized by a mad auteur. Our primary goal today
61+is expanding the number of people who understand Urbit, and we
62+expect these pioneers to participate in technical governance.
63+
64+## <a name="jets"></a>Nock jets are a total hoax.
65+
66+*TLDR*: all of computing is a hoax. You can't compare a hoax
67+to nothing. You can only compare it to all the other hoaxes.
68+
69+A "jet" is a sort of software device driver in Urbit. Urbit is
70+precisely defined in terms of an interpreter that fits on a
71+T-shirt, Nock. But a naive implementation of Nock is nowhere
72+near practical, because Nock has only one integer operation:
73+increment. For example, to decrement a number in Nock, you
74+increment a counter up to the number under it.
75+
76+The only way an efficient Nock interpreter can work is to
77+recognize algorithms like decrement, and implement them
78+non-naively. By far the easiest way to do this is not to analyze
79+arbitrary code as it's being executed, but to register and match
80+well-known implementations in the standard library. No one
81+should be writing their own decrement.
82+
83+But the semantics of the interpreter, _so long as the jet and the
84+jet harness are defined correctly_, are exactly those of Nock.
85+We are not extending or changing Nock in any way. We are just
86+taking a shortcut in certain cases we understand perfectly.
87+
88+It's not at all unprecedented to have implementations much more
89+complex than the corresponding specification. The x86
90+instruction set is relatively simple; the complexity of its
91+decoding and execution path in a modern CPU is enormous. This
92+path may well have "peephole optimizations" that replace matched
93+algorithms, and if it doesn't the modern compiler does. People,
94+_bad_ people, use "jets" to cheat on benchmarks all the time.
95+
96+Nock is designed as a standard. It's built like a standard.
97+Typically what causes real problems in standards is ambiguity.
98+Two implementations are incompatible, but each swears it has the
99+right interpretation of the natural-language spec. This simply
100+cannot happen in the Nock world. If two implementations
101+disagree, at least one of them is incorrect. This puts us firmly
102+in "with enough eyeballs, all bugs are shallow" territory.
103+
104+The fact remains, however, that a Nock interpreter without jets
105+is completely useless. And there is not even an informal
106+document that tells you what jets you need for a reasonably
107+efficient Urbit. (There should be such a document.)
108+
109+The correct way to think about jets is not to compare them to a
110+perfect interpreter created by unicorns. Jets are a combined
111+replacement for two other techniques in language implementation:
112+intrinsics and a foreign-function interface.
113+
114+Compared to both intrinsics and an FFI, your jets have one key
115+disadvantage: they need to be specified in pure code. You may
116+not have this executable specification, which means you need to
117+write it. Is this really so bad for your development process?
118+An executable specification? Which can be trivially tested
119+against the efficient implementation?
120+
121+Compared to intrinsics, jets give you true separation between
122+mechanism and policy; only the interpreter, not the programmer
123+and not the compiler, needs to know what's accelerated.
124+
125+Compared to an FFI, jets preclude I/O, so can be trivially
126+sandboxed. Except that the programmer needs to mark routines
127+which may benefit from optimization with a hint, here too we
128+separate mechanism (efficient implementation) from policy.
129+
130+Yes, formal verification of jet equivalence is desirable.
131+However, in the real world, many specifications, including quite
132+complex ones, are tested into equivalence by brute force.
133+
134+Urbit has some jet abuses. The equivalence between our markdown
135+parser in Hoon and the CommonMark C library is super dubious. It
136+should be revisited.
137+
138+But the miscomputation resulting from a minor jet discrepancy is
139+not a security hole or even fatal. It effectively means the
140+event history, computed correctly, does not match the current
141+state. The way to resolve this conflict is for the current state
142+to win, and the event history to be discarded -- not abnormal
143+anyway. See the next question.
144+
145+## <a name="log"></a>Urbit needs an infinitely extending packet/event.
146+
147+*TLDR*: no, it doesn't. Urbit can prune the log.
148+
149+We can prune the event log because the Urbit transition function
150+doesn't have any access to the event history -- just the current
151+state and the current event.
152+
153+Urbit defines the semantics of a complete event log. It doesn't
154+and can't require an implementation to maintain the whole log.
155+It can maintain a checkpoint and the log since that checkpoint.
156+
157+However, any practical urbit maintains a periodically updated
158+checkpoint. Our present implementation doesn't provide a way to
159+prune the event log. But that's just a missing feature. We have
160+one or two of those!
161+
162+## <a name="scam"></a>Urbit is a total scamcoin. It's 100% premined.
163+
164+*TLDR*: yeah. But at least it's not the DAO.
165+
166+Like a cryptocurrency, Urbit is a digital title. But Urbit is
167+digital land, not digital money. If you assess it as a currency,
168+it's a lousy currency. If you assess a cat as a dog, it's a
169+lousy dog.
170+
171+In real-world economics, the crucial distinction between land and
172+money is that land (a) has intrinsic utility and (b) is
173+non-fungible.
174+
175+Because of (b) alone, frictionless transactions in land are
176+impossible. A blockchain is only needed to ensure zero-cost
177+high-frequency transactions. So digital land doesn't need a
178+blockchain. Which means it doesn't need mining.
179+
180+Of course, just because a digital title system doesn't need
181+mining, doesn't mean it can't distribute an initial allocation by
182+proof-of-work -- or by any other arbitrary method which is
183+careful not to benefit the system's own developers. Could we
184+give away the Urbit address space randomly? Sure. But why?
185+
186+Probably the purest design is the "proof-of-burn" initial
187+allocation used by some coins. By any standard, proof-of-burn is
188+technically beautiful and results in an extraordinary level of
189+ethical independence. We can't help but admire it.
190+
191+But any altcoin or metacoin is just way less work than Urbit. An
192+altcoin can afford to burn even its creation energy, capturing no
193+value at all from its seigniorage. Your altcoin doesn't have a
194+clean-slate system software stack to drive. If your rocket has
195+to go to the moon, it's going to leave a little bit of smoke in
196+the air.
197+
198+Ethically, what makes "premining" feel wrong is that the creators
199+of the currency are rewarded disproportionately for their effort.
200+The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.
201+Nothing about Urbit matches this pattern at all.
202+
203+Curtis invented Urbit. So by the [homestead
204+principle](https://en.wikipedia.org/wiki/Homestead_principle), he
205+started out owning all of it. But by now, Urbit's 8-bit galaxies
206+have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).
207+Curtis owns 20, or about 8%.
208+
209+Tlon, the corporation which still runs Urbit development, has 95.
210+(Without Tlon, there is basically no Arvo.) 50 are reserved for
211+a hypothetical Urbit Foundation. Tlon employees have another 16.
212+
213+The rest of the galaxies belong to donors, investors,
214+contributors, contest winners, and just random people who were in
215+the right place at the right time. One is a Silicon Valley
216+tycoon. Another is an Orthodox nun in a monastery in Greece. A
217+couple are ex-Tlon employees who might totally hate us. There is
218+nothing they all have in common, which is sort of the point.
219+
220+This property distribution looks a lot like land ownership in the
221+real world -- complex and asymmetrical. That's no accident. If
222+you have a problem living in New York because New York's real
223+estate is not distributed equally among its residents, you may
224+have a similar problem with Urbit. The reality is that Urbit,
225+like New York, wasn't born yesterday and comes with a complex
226+ownership history which we couldn't possibly change, even if we
227+wanted to.
228+
229+Decentralization is hard. The only real goal of a property
230+system in address space is to create and maintain
231+decentralization. The whole network has to exhibit centrifugal
232+force, not centripetal force. Proof-of-work systems certainly
233+seem to have unexpected centripetal qualities, producing
234+unanticipated concentrations of centralized hashpower. See the
235+next objection.
236+
237+## <a name="gov"></a>Urbit isn't even really decentralized! It has a government!
238+
239+*TLDR*: it's technically impossible for Urbit to be
240+decentralized at this stage of its life. Urbit is designed to
241+achieve decentralization, not be born with it.
242+
243+A young network can't afford to be decentralized. It has to act
244+as a unit. Because it has no network effect, it needs every
245+scrap of efficiency it can get.
246+
247+A decentralized general-purpose computing network like Urbit can
248+_only_ be bootstrapped by a central government. For example, by
249+default your urbit upgrades its OS automatically (like an
250+"evergreen" browser) with signed network updates. Whoever signs
251+these updates is a government by definition.
252+
253+When it's impossible to eliminate centralized power, it becomes
254+necessary to tame, stabilize, and limit it. This should not be
255+surprising to anyone living under a constitutional government.
256+
257+As we found out with the DAO, if a network isn't ready to be
258+decentralized, its developers shouldn't even try. If Ethereum is
259+hard-forked to roll back the DAO (which looks like the most
260+probable result), it acknowledges that it both has a central
261+government, and needs a central government. Decentralization is
262+good. Pretend decentralization -- "decentralization theater" --
263+is harmful, and not a effective path to actual decentralization.
264+
265+A key test of a free software project's health is whether it can
266+fork. So long as the unity of the public-key hierarchy and the
267+network protocol is maintained, the Arvo kernel and Urbit system
268+can fork in all kinds of ways without disrupting the network.
269+Any stress will fragment the "government" that develops the
270+kernel, and as it fragments it grows more limited and stable.
271+
272+Urbit is designed to govern itself collectively by address space
273+ownership -- effectively, "proof of stake." Any arbitrary power,
274+will tend to fracture along these property lines. For instance,
275+our hot updates are sent through the galaxy hierarchy; in a
276+development fork, active galaxies would pick upstream sources.
277+Two implementations of a standard are better than one.
278+
279+And by fragmenting the galaxy space into 57 separate partitions,
280+we've created a global property map which is much more likely to
281+splinter further, than reunite.
282+
283+In the long run, every galaxy should have a separate owner, who
284+is a human being rather than a corporation. Combining galaxy
285+holdings will damage the reputation of both galaxies. The only
286+reason to merge ownership is to move toward incipient monopoly.
287+Whether a galaxy admits this openly or denies it dishonestly, its
288+reputation will suffer.
289+
290+The technical goal of Urbit is to create a network which, _if it
291+actually takes over the world_, inevitably becomes decentralized.
292+Even if Urbit takes over the world, no individual or coherent
293+organization takes over the world. There is nothing even close
294+to a single point of failure in a mature, successful Urbit.
295+
296+This is the goal of all the new "web3" decentralized systems. If
297+IPFS, Sandstorm or Ethereum takes over the world, nobody takes
298+over the world. (The same is almost true of the Internet --
299+though it wouldn't be that surprising if a time traveler from
300+2116 revealed that ICANN had become a planetary government.)
301+
302+Urbit, by starting out as a centralized network, just reduces the
303+technical problem to match the actual goal. Only long-term
304+decentralization matters.
305+
306+It's very important that Urbit in 2116 be fully decentralized.
307+For Urbit in 2016, pretending to be decentralized would be a joke
308+at best, and a hoax at worst. And of course, no one can DAO us
309+-- since the property system is still just a central registry.
310+Among other things, we check it into Github. Github is not a
311+blockchain -- but still, good luck with that.
312+
313+## <a name="sand"></a>Sandstorm/IPFS/Ethereum is way ahead of Urbit.
314+
315+In general, web3 (next distributed web) solutions don't compete
316+with each other. They support each other. Concretely, they are
317+all part of each others' network effect.
318+
319+IPFS, Sandstorm, Ethereum, and Urbit can all take over the world
320+at the same time. None of them competes with the others. They
321+enable each other.
322+
323+For instance, IPFS and Urbit are both global immutable
324+namespaces. IPFS is a chord-routed, content-addressed namespace.
325+Urbit is a direct-routed, identity-addressed namespace. Urbit is
326+a typed revision-control system; IPFS is a blob store. IPFS
327+isn't a computer; the work hasn't been done, but Urbit can easily
328+mount the IPFS namespace and compute functionally against it.
329+
330+So the better IPFS does, the less Urbit needs to struggle against
331+its lack of network effect. The better Urbit does, the easier it
332+is for IPFS to point to a functional language that can actually
333+use its referential transparency directly. So their relationship
334+is symbiotic, not competitive at all.
335+
336+The closest thing to a general-purpose competitor that Urbit has
337+is Sandstorm. Sandstorm, which by the way rocks, is also a
338+personal server built around a network protocol.
339+
340+But Sandstorm and Urbit compete in the way that, on the PC, the
341+OS and the browser compete. In theory, the OS could solve the
342+problems that the browser solves; or the browser could be the OS.
343+In practice, Windows is a great OS to run a browser on.
344+
345+Similarly, a world in which Sandstorm takes off is an awesome
346+world for Urbit, because everyone who has a Sandstorm instance
347+has a great platform for running Urbit on. Urbit on Sandstorm
348+will be a sort of "double-hulled" personal server, safer and more
349+friendly than either system alone.
350+
351+Sandstorm and Urbit have very different approaches to network
352+identification; Sandstorm uses capabilities, Urbit identity.
353+Broadly speaking, we believe, capabilities are optimal for
354+expressive power; but identity is optimal for the UI of the
355+common case. We'd need to see the Powerbox, Sandstorm's UI, more
356+fully fleshed out to understand its UI approach better.
357+
358+;=
359+ ;h2
360+ ;div(id "planet"): Urbit doesn't have enough planets for every human
361+ ==
362+==
363+
364+A 32-bit planet is a tool, not a toy. Like a car, it's a device
365+for a responsible and independent adult. There aren't 4 billion
366+cars in the world, nor 4 billion independent adults.
367+
368+If you aren't an independent adult, and you don't need or even
369+shouldn't have unconditional digital freedom (no one's 8-year-old
370+daughter needs unconditional digital freedom), a moon from
371+someone else's planet is fine. (Even most of today's independent
372+adults don't complain enough about being Facebook's moons.)
373+
374+And limiting the supply of anything doesn't create a shortage.
375+It sets a price. Ideally, in the long run, we think a planet
376+should cost about $10. This could be off by an order of
377+magnitude either way, and it wouldn't be the end of the world.
378+
379+If a planet costs $10, that means you paid $10 to get a planet.
380+A planet with no reputation has a positive reputation, because
381+someone paid $10 for it and hasn't yet done anything wrong.
382+Positive default reputation is the single quality that makes a
383+social network social.
384+
385+There is always a tradeoff between free speech and free beer.
386+Urbit will always choose free speech.
387+
388+## <a name="pwned"></a>Cloud computing is inherently non-private.
389+
390+*TLDR*: a general-purpose cloud computer is much, much more
391+private than a special-purpose cloud computer. In general, a
392+cloud VM is secure against corporations but not governments.
393+With a global adversary, compute in your closet -- or even on
394+your body.
395+
396+One reason we want the decentralized Internet is that we're tired
397+of giant corporations spying on us. Think about it this way:
398+Amazon is Netflix's main competitor. And yet, Netflix runs its
399+whole operation on AWS. Why is Netflix sure that Amazon won't
400+spy on it?
401+
402+A general-purpose virtual machine is special from a privacy
403+standpoint, just because it's commercially realistic to design
404+terms of service that prevent the host from peeking and poking at
405+the customer's machine. Crossing this moat is technically
406+nontrivial and can't possibly happen by any reasonable accident.
407+No hosting contract could contemplate it.
408+
409+Whereas when your cloud computer is a special-purpose machine --
410+just a database row on some corporation's mainframe -- there is
411+no way these services can promise not to handle your data.
412+Handling your data is _what they do_. On a special-purpose
413+server, the concept of privacy is not even defined.
414+
415+Where even a general-purpose server falls down is where the user
416+has a sovereign adversary, which can secretly violate explicit or
417+implicit hosting contracts. Users with a sovereign adversary
418+must rely only on their own physical security.
419+
420+However, most users don't have a sovereign adversary. And those
421+who do maximize their "herd immunity" if they can use the same
422+protocols as those who don't. Otherwise, the adversary could
423+simply focus on everyone who uses the secure protocols.
424+
425+Also, the portability of a cloud server image is critical. Of
426+course, since Urbit is formally specified, it's trivially
427+portable. In fact, one strategy against sovereign adversaries
428+may be continuous rotation between hosts, like an MX missile.
429+
430+## <a name="code"></a>Urbit will never be able to call any existing code.
431+
432+*TLDR*: neither will Javascript. And dear Unix, the browser
433+does not miss interacting with your `$LD_LIBRARY_PATH` at all.
434+
435+You can't talk to the OS or use system libraries from Javascript.
436+Therefore, there is no point in having any kind of gateway,
437+compatibility bridge, native methods, or other interface between
438+Javascript and C.
439+
440+When in doubt, remember that Urbit is "the browser for the server
441+side." It plays by the same general rules. Isolation means
442+isolation.
443+
444+## <a name="weird"></a>There's no way Urbit will ever be adopted. It's too weird.
445+
446+*TLDR*: Urbit adoption is designed to be driven by ordinary end
447+users. Urbit isn't ready for ordinary end users yet. We're
448+working on it -- come help.
449+
450+Right now, Urbit is a developer tool. Or rather, a developer toy
451+-- since the only thing it's useful for is developing Urbit. It
452+also could be a much better toy. We're working on that too.
453+
454+But it's absolutely wrong to think of Urbit being adopted as a
455+developer tool in the conventional sense. If you think this is
456+almost impossible, you're right.
457+
458+If we look at the way most successful platforms are adopted,
459+they're not adopted for their own virtues. They're adopted
460+because they're part of a larger solution. It's very hard to
461+displace a native component of an existing platform. Urbit is
462+not trying to do this.
463+
464+C is a better language than Pascal, but it didn't beat Pascal
465+because it's a better language. C beat Pascal because C was the
466+native language of Unix, and people wanted to program in Unix.
467+People don't use Javascript because Javascript is a great
468+language, but because it's the native language of the browser.
469+Replacing the native language of a platform may be doable -- but
470+it's incredibly hard.
471+
472+Hoon is not competing with C, or even Haskell, as a Unix
473+programming language. The only reason to program in Hoon is that
474+it's the native language of Urbit. Urbit is not competing with
475+node.js or Rails as a Web backend. The only reason to run Urbit
476+is to run a personal server.
477+
478+Nock is cool, but it only gets adopted if Hoon gets adopted.
479+Hoon is cool, but it only gets adopted if Urbit gets adopted.
480+Urbit only gets adopted if it's useful as a personal server for
481+human beings -- most of whom won't be Hoon programmers, or
482+programmers at all.
483+
484+## <a name="program"></a>Hoon is too weird. No one will be able to program in it.
485+
486+*TLDR*: Hoon is ridiculously simple. Our documentation and
487+tooling are just immature.
488+
489+It's pretty fair to assume that (a) functional programming is
490+hard and weird, (b) Hoon is weird even for a functional language,
491+so (c) Hoon must be hard-squared.
492+
493+Actually, Hoon is weird even for a functional language because
494+it's an attempt to remove the hardest things about functional
495+programming: category theory, lazy evaluation, and gratuitous
496+abstraction. To know a language is to know what the compiler is
497+doing; all the semantics of the Hoon compiler fit in 2000 lines
498+of code.
499+
500+It's too easy for us to wind up living in Isaac Asimov's Trantor,
501+a world in which everything got invented thousands of years ago
502+and the idea of new technology is just weird and scary. History
503+isn't over yet, and nor is technical history.
504+
505+New things are harder to learn than old things. We ask smart
506+high-school students to learn calculus. Think about how much
507+harder it was for Newton and Leibniz to invent calculus, or for
508+their first students to pick it up. Hoon is nowhere near as hard
509+as calculus.
510+
511+Most of the difference is just the collective certainty that our
512+society conveys to a high-school student that calculus is
513+learnable. When you're learning Urbit, you don't have this
514+collective knowledge; so you don't have the confidence that the
515+problem is solvable. Confidence makes a huge difference.
516+Moreover, any bug or glitch in the developer experience destroys
517+this confidence and takes a long time to heal.
518+
519+Yes, we know: Hoon remains quite hard to learn. Again, we have
520+no reason to think this problem isn't solvable. Public
521+enlightenment remains our main priority.
522+
523+## <a name="stuck"></a>Urbit programmers are stuck with Hoon.
524+
525+*TLDR*: patience, grasshopper.
526+
527+There's quite a straightforward way to implement any perfectly
528+specified language with a reliable interpreter in Hoon. First,
529+write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.
530+
531+It is not clear that Javascript is _quite_ well-defined enough
532+for this treatment. But Lua probably is.
533+
534+## <a name="user"></a>Ordinary users will never be able to manage an Urbit server.
535+
536+*TLDR*: Urbit's technical simplicity has always been designed
537+to drive human usability. But the polish is the last thing that
538+goes on. So we can't evaluate this claim right now.
539+
540+Right now, Urbit is only for geeks. You already need to be able
541+to wrangle a Unix machine to run it. What's the point?
542+
543+This Urbit isn't the real Urbit. It's an early milestone on the
544+way to the real Urbit.
545+
546+The real Urbit -- for normal human beings -- is a hosted service.
547+Getting a planet is as easy as signing up for Facebook. Probably
548+many users will think of it as another web account. They might
549+not even know it can run more apps than the ones they use.
550+
551+A deterministic, persistent cloud computer is something different
552+from a traditional server. Normally when we think of a server in
553+the cloud, we think of it like a live animal -- a creature that
554+needs to be cared for, fed, and herded. A file in the cloud is
555+more like a rock -- you can forget about it for ten years.
556+
557+An urbit is a general-purpose computer, but it doesn't even have
558+the concept of a reboot. It upgrades itself. If you don't feed
559+it any packets for ten years, then turn it back on, it will spend
560+a day or two upgrading itself, then be back to normal. Maybe
561+it's something in between a rock and an animal -- a cactus?
562+
563+Another huge difference versus an Internet server is that we're
564+confident that Urbit's limited supply of identities will make it
565+easy to keep abusers off the network. So far, so good -- but of
566+course, no one abuses a young network.
567+
568+The bottom line is that managing your urbit has to be as easy as
569+managing your iPhone. Normally, it consists of deciding what
570+apps you want to be running, and how much you trust them.
571+Resources can't be free, so sometimes you have to play memory
572+police. Humans have shown that they can handle these tasks.
573+
574+Our '70s OSes and networks, which were great designs in their day
575+and have matured into excellent industrial tools, give us a
576+totally misleading impression of how hard it should be to manage
577+a general-purpose computer. Computing isn't scary or dangerous.
578+Unix and the Internet are scary and dangerous. That's fine for
579+an industrial tool, but not a personal tool.
580+
581+## <a name="killer"></a>Urbit has no killer app.
582+
583+*TLDR*: the killer app is personal API aggregation.
584+
585+It's a truism that any new platform has to be fundamentally much
586+better at solving some problem than the mature platform it seeks
587+to replace.
588+
589+We can look at Urbit's killer app from two perspectives: as a
590+developer, and as a user.
591+
592+From the developer's perspective, Urbit's advantage is that it's
593+a network stack which provides exactly-once delivery of typed,
594+validated, transactional, encrypted and authenticated messages.
595+The difference between an Urbit API and a REST API is like the
596+difference between a paved road and a dirt road. On the other
597+hand, you do need to learn a new functional language.
598+
599+From the user's perspective, there's one task that any personal
600+server can perform, that can't be performed by any Web service:
601+unrestricted API aggregation.
602+
603+Well before Urbit is ready to _replace_ any conventional web
604+services, it should be ready to _command_ them in place by API.
605+(Or if needed, by scraping.) If all you care about is being in
606+control of your own data, it's fine to leave it in the hands of
607+these services, as you have the API secrets to get it out.
608+
609+Managing a set of security connections to your existing services
610+is one of the first important tasks of a modern personal server.
611+This is a stateful task that typically requires both a durable
612+API key and a temporary OAuth token. APIs change all the time,
613+so connection maintenance also requires evergreen updates.
614+
615+The origin of this API key will vary, but usually the best way to
616+set it is BYOK: the user registers their own urbit as an "app."
617+And the neat thing about having your own API keys, for multiple
618+services, on a single general-purpose computer, is that none of
619+these services really has any practical way to control what you
620+do with your own data.
621+
622+Terms of service which constrain the use of data (as opposed to
623+the abuse of the service) simply aren't realistic and will no
624+longer apply. This enables a variety of novel user experiences
625+which aren't implementable as traditional web services, and also
626+aren't available via conventional third-party API aggregators.
627+
628+Also, since Urbit is after all quite immature, it doesn't make
629+much sense to restrict this security state to code within Urbit.
630+The Urbit interpreter `vere` runs as a Unix daemon that
631+implements the FUSE user-level filesystem protocol, and maps the
632+data on your services into the Unix filesystem. For example, one
633+of our demos lets you `ls` your Github issues.
634+
635+So it's straightforward to build, for instance, a Python app that
636+uses Urbit as a gateway to mash up a bunch of web services. As a
637+Unix programmer, you might even just regard Urbit as a generic
638+Web API gateway daemon, without worrying about its internals.
639+
640+We have other ideas for initial killer apps. But this, we feel,
641+is the best one. API libraries for `npm` et al abound.
642+Stateful, self-updating, generic API aggregators with FUSE
643+integration, also integrated with a reactive web server, are
644+rarer.
645+
646+## <a name="horse"></a> Urbit is sniffed at by Houyhnhyms.
647+
648+It's difficult to categorize [this awesome
649+essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)
650+in a single bullet point. So I've saved it for last.
651+
652+When reading this essay, it's important not to forget the amazing
653+absence of genuine, mutually critical discourse in computer
654+science (as in most sciences today). You never hear what Swift's
655+designers think of Go, or vice versa. And critical public
656+discourse decreases, not increases, with increasing academic
657+legitimacy.
658+
659+The basic test of any field purportedly scientific in nature is
660+whether its researchers are genuinely interested in each others'
661+work, and willing to share these genuine responses publicly. If
662+this practice does not exist, the field may still be useful
663+and/or interesting. But it is not science.
664+
665+What's awesome about Fare's essay is that he's _doing it right_.
666+All the actual details are irrelevant. And mostly wrong. But
667+that's of very little importance compared to _doing it right_.
668+
669+Anyway, we've already addressed the idea that jets are a sham.
670+Some other points:
671+
672+### Event-sourcing and/or caching is a pattern, not a layer
673+
674+Fare' is perfectly right that "one size does not fit all" in
675+persistence. Generally, Urbit uses event-sourced persistence.
676+
677+But it has multiple layers of event-sourcing: in the definition
678+of Urbit itself; in the application sandbox vane (Gall), and in
679+the application itself. Urbit also has a completely orthogonal
680+revision control system (Clay).
681+
682+And there is not a single cache across the whole system, though
683+arguably there should be; for instance, the functional build
684+system (Ford, which Fare' the master of build systems might
685+appreciate) has its own internal cache.
686+
687+It is a common mistake to confuse a design pattern with a layer
688+or feature, and equally fatal whichever direction you fail.
689+
690+### Let's be clear about why DSLs suck
691+
692+DSLs suck not because they are difficult to newbies in the base
693+language. DSLs suck because every time a programmer, even one
694+_experienced_ in the base language, comes into a new codebase or
695+project, she has to learn a new custom language.
696+
697+You need enormous wins to justify this cost. It's the goal of
698+the base language designer to preempt these wins, creating a
699+language which is almost never so tiresome and full of
700+boilerplate that it requires a DSL or template layer.
701+
702+Hoon is almost entirely made of macros -- but they are internal,
703+fixed, built-in macros (with no gensyms). This fixed set of
704+macros is essentially enough. Occasionally we want to add one or
705+two. But we never, ever pine for context-dependent macros.
706+
707+### Determinism is not consensus, and is not constraining
708+
709+Fare' is totally right that an urbit's data is meant for itself
710+alone. In fact, an urbit has the right to compute incorrectly if
711+it wants. We go to considerable lengths to ensure that you can't
712+gain any particular advantage by incorrect computing.
713+
714+The whole point of Nock is that it's so low-level that there is
715+no conceivable advantage in upgrading it. Divergence is just
716+pointless. This is not a question of network integrity, just of
717+practical standardization.
718+
719+This consistency stops at Nock. Without anyone violating the
720+correctness of their lifecycle functions, anyone or everyone in
721+Urbit could replace Hoon with Javascript. Determinism does not
722+cramp Urbit's semantic style in any way, shape or form.
content/posts/epicenter-episode-205-urbit-a-digital-republic-reinventing-the-internet.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Epicenter #205: Urbit – A Digital Republic Reinventing the Internet"
3+date = 2017-10-18
4+author = "Tlon"
5+description = "Galen discusses Urbit with Brian Fabian Crain and Meher Roy on the Epicenter podcast."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ youtube(id="DFeN-TKZor0") }}
10+
11+[\#205 Galen Wolfe-Pauly: Urbit - A Digital Republic Reinventing the Internet](https://epicenter.tv/episode/205/)
content/posts/governance-of-urbit.mdnew file+37
@@ -0,0 +1,37 @@
1++++
2+title = "Governance of urbit.org"
3+date = 2019-01-11
4+author = "Erik Newton"
5+description = "On Stewardship of the Urbit project"
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](https://storage.googleapis.com/media.urbit.org/site/governance-1.svg)
10+
11+## Summary
12+
13+Long before Urbit first appeared as a prototype in 2013, we considered Urbit address space to be property. Granted, Urbit property ownership was only reflected as a text file in a github repository – but it was always designed to be cryptographically owned, and we've always taken that file seriously.
14+
15+If you've ever looked at that text file, you've probably noticed that there has been a pool of Urbit assets there marked "urbit.org" since the beginning. Now that we're moving our property registry out of that repository and onto the Ethereum blockchain, we wanted to be as clear as we can be about what the plan is for those urbit.org addresses.
16+
17+The TL;DR is that "urbit.org" will likely split into a separate entity from Tlon in the future. For now though, Tlon and urbit.org have the same mandate, so separating them doesn't make sense. For the time being, Tlon will continue to manage and use urbit.org assets directly for platform development. As a first step toward making urbit.org independent we've started to develop a board of advisors who we hope will one day manage those assets independently.
18+
19+## Background
20+
21+The history of a few lines in a text file doesn't give a whole lot of context. So, first, let's fill in a few more of the details.
22+
23+In 2013 Curtis and Tlon each contributed 32 galaxies to a pool newly called "urbit.org." The idea at the time was to set aside address space to fund "platform development" – in the spirit of the IETF or the Mozilla foundation. This was long before anyone had heard of a Swiss blockchain foundation or anything of the sort. Our view was that it was going to take a lot of resources to build a system as robust and far reaching as Urbit intends to be, and 64 galaxies (25% of the total network) seemed sufficient. It was thought at the time that urbit.org might eventually take the form of a separate foundation, but we were simply too small and under-resourced a team to figure out the right legal structure at the time.
24+
25+Tlon – as distinct from urbit.org – has always been imagined as a future service provider in the urbit ecosystem. But Urbit is still young, so those services aren't really needed yet.
26+
27+Instead, what is needed is platform development. So Tlon has acted, in a way, as urbit.org was supposed to, by taking on the bulk of platform development efforts. This work consists of everything from kernel development to interface design and documentation. Tlon has sold (and granted) both its own galaxies, and some of those originally designated as urbit.org galaxies towards this end. We'll continue to do this for the foreseeable future, since Urbit's development needs (though finite) remain ongoing. We can't predict exactly how long this will continue, although we wish we could!
28+
29+## Future plans
30+
31+As Urbit becomes more widely used, we expect to make the Tlon/urbit.org separation real.
32+
33+We've considered the foundation model, but have come to the conclusion that it doesn't really make sense. For one, it's quite expensive in terms both of administrative overhead, and the associated legal costs. For another, there just isn't anyone we trust enough to take over high level management of such an organization (see Tezos). Finally, our view is that foundations are not entirely effective in their mandates (see [this article](https://nadiaeghbal.com/foundations) from our friend Nadia).
34+
35+One step we're pursuing is the creation of a board of advisors to guide our use of the urbit.org assets at Tlon. We're in discussions with several potential board members now. Our goal with this structure is to include more voices outside of Tlon in the process of governing the urbit.org assets, and to make their advice transparent to the public.
36+
37+As with all of our projects, we think it's better to walk before we run. For now, Tlon will continue to act as urbit.org and use both pools of resources for ongoing platform development. Next, we'll create a board to advise on the use of those resources. Eventually, Tlon and urbit.org will likely become separate entities. We'll get there – one step at a time.
content/posts/governing-the-future-e09-urbit-a-user-owned-internet-on-top-of-the-internet.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Governing the Future E09: Urbit – A User Owned Internet on top of the Internet"
3+date = 2017-08-10
4+author = "Tlon"
5+description = "Galen talks with Hampus Jakobsson about Urbit on the Governing the Future podcast."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+> What happens when users get to control a piece of the internet. What does this browser of servers mean when we can use own client and still communicate? Can we create a new Internet owned by the people, an internet designed like a city by an architect and not only engineers?
10+
11+[E09: Galen Wolfe-Pauly, Urbit - a user owned internet on top of the internet](http://podcast.hajak.se/104117/548011-e09-galen-wolfe-pauly-urbit-a-user-owned-internet-on-top-of-the-internet)
content/posts/interim-constitution.mdnew file+141
@@ -0,0 +1,141 @@
1++++
2+title = "Interim Constitution"
3+date = 2016-05-16
4+author = "Tlon"
5+description = "The governing rules for the early days of the Urbit network."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-7.jpg)
10+
11+## Declaration of purpose
12+
13+Urbit is a new network created by the Tlon Corporation. Tlon's
14+broad intention is to surrender governance of Urbit to its users,
15+as soon as the community is collectively ready to receive it.
16+
17+This constitution (which is not a legal contract, just our present
18+intent, which may be updated arbitrarily) describes our governance
19+process during this interim period. Its design borrows from validated
20+historical structures, mainly Roman and Anglo-American.
21+
22+The last and most important task of the interim government is to
23+write the next version of the constitution. This document may or
24+may not incorporate any or all of the interim structures.
25+
26+## Beliefs and principles
27+
28+See our document of [beliefs and principles](../beliefs-and-principles).
29+
30+## Governance structures
31+
32+The interim republic has four branches: an executive consulate, a
33+galactic senate, a stellar congress and a planetary assembly.
34+
35+For the interim, full authority is held by the (Roman style)
36+consulate. The legislature (senate, congress, assembly) is
37+advisory. The senate is never consulted and the congress is
38+almost never consulted.
39+
40+In the future, the assembly of planets specializes in technical
41+governance. The congress of stars specializes in internal, but
42+nontechnical, governance. The senate of galaxies selects the
43+consuls and holds them accountable, and specializes in compliance
44+with external powers. All votes, elections and other public
45+actions are logged in the Urbit global namespace.
46+
47+As in most parliamentary systems, each of these structures sets
48+and enforces its own internal rules of operation.
49+
50+### Consulate
51+
52+A consulate is a two-person executive. The consuls must work out
53+their own organization and division of labor. Disagreements
54+between consuls are resolved by the senate.
55+
56+A consul must be a senator. The senate, voting per galaxy,
57+replaces the consulate whenever either a vacancy exists, or a
58+vote of no confidence gains a majority. When electing consuls,
59+first a plurality selects one consul; then the plurality of those
60+who voted for anyone but the winner selects the second.
61+
62+### Senate
63+
64+The _senate_ is the set of all galaxy holders, voting per galaxy.
65+It does not convene except to replace the consuls. Its
66+proceedings are in private.
67+
68+To avoid growing the network too quickly, galaxies are activated
69+gradually. Initially, only one galaxy is active, the root `~zod`
70+(galaxy 0).
71+
72+Further activation is at the discretion of the consuls, who
73+control `urbit.org` and will only bind activated galaxies to
74+`galaxy.urbit.org`. Routing at the galaxy layer is by DNS, so
75+unbound galaxies, and any stars or planets they launch, hear no
76+packets.
77+
78+When any galaxy, activated or not, creates its initial
79+certificate, the consuls add its fingerprint to the galaxy table.
80+Non-activated galaxies can still be rekeyed.
81+
82+### Congress
83+
84+The _congress_ is the set of all active independent stars.
85+voting per star. An _independent star_ is any star _not_ owned
86+by anyone who is either a senator, or has some connection to one
87+that would pose a conflict of interest.
88+
89+The congress of stars is designed to exercise project and
90+community governance. Its proceedings are in private. The
91+consuls convene it at their pleasure, and keep it informed.
92+
93+### Assembly
94+
95+The _assembly_ is the set of all active primary planets, voting
96+per planet. A _primary planet_ is the main planet of a unique
97+human (no sockpuppets).
98+
99+The assembly is responsible for technical governance. Its
100+proceedings are in public.
101+
102+### The next constitution
103+
104+The congress proposes, and the senate approves, the next version
105+of this constitution. Future constitutions should be defined in
106+a smart contract platform, such as Ethereum.
107+
108+## Galaxy table
109+
110+95 galaxies are held by the [Tlon Corporation](https://tlon.io/). 50,
111+reserved for urbit.org, the future community foundation. 40, by
112+Tlon employees and their family members (24 by Curtis, who
113+started in 2002; 16 by everyone else, who started in 2014). 34,
114+by outside investors in Tlon. 37, by 33 other individuals, who
115+donated to the project, contributed code or services, won a
116+contest, or were just at the right place at the right time.
117+
118+Note that while Tlon and its employees still control a majority
119+of galaxies, the senate is a ceremonial body; the consulate is
120+effectively equivalent to Tlon.
121+
122+## Inception
123+
124+This constitution takes effect as soon as the initial public
125+presale of Urbit address space is complete.
126+
127+## Endowment
128+
129+The 50 galaxies marked "urbit.org" in the galaxy table are
130+intended as property of the republic, and will be used only in
131+the interests of the republic and Urbit as a whole.
132+
133+Externally, these galaxies are held by Tlon; internally, they are
134+managed and voted by Tlon. Once the republic acquires a legal
135+identity and an independent human organization, Tlon pledges to
136+donate the `urbit.org` galaxies, the DNS domain, and the Github
137+`urbit` account to it.
138+
139+## First consuls
140+
141+The first consuls are Galen Wolfe-Pauly and Raymond Pasco.
content/posts/lambdaconf-2016-curtis-yarvin-urbit-a-clean-slate-functional-operating-stack.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "LambdaConf 2016: Curtis Yarvin - Urbit: A Clean Slate Functional Operating Stack"
3+date = 2016-09-28
4+author = "Tlon"
5+description = "Curtis presents a comprehensive technical overview of Urbit at LambdaConf 2016."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ youtube(id="bTisf4oxIFo") }}
10+
11+[Curtis Yarvin: Urbit- A Clean Slate Functional Operating Stack - λC 2016](https://www.youtube.com/watch?v=bTisf4oxIFo)
content/posts/lambdaconf-2018-ted-blackman-ford-urbits-build-system.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "LambdaConf 2018: Ted Blackman - Ford: Urbit's Build System"
3+date = 2018-12-20
4+author = "Tlon"
5+description = "Ted presents a technical overview of Ford, Urbit's build system, at LambdaConf 2018."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ youtube(id="5ZAFEylHdiU") }}
10+
11+[Ted Blackman Ford - Urbit's Build System - λC 2018](https://www.youtube.com/watch?v=5ZAFEylHdiU)
content/posts/magic.mdnew file+201
@@ -0,0 +1,201 @@
1++++
2+title = "Magic"
3+date = 2016-05-16
4+author = "Curtis Yarvin"
5+description = "A thought-experiment to explain the Urbit user experience."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-7.jpg)
10+
11+It's easy to get too obsessed with Urbit's alien technology. We
12+didn't build Urbit for its tech. We built it for people to use.
13+
14+It's also hard to understand the power of Urbit, because it's
15+still quite immature. Unless you understand it already, it's
16+just a weird OS that doesn't work all that well.
17+
18+And this OS is supposedly designed as a new kind of product: a
19+personal server. What is a personal server? If you had one,
20+you'd know. Since you don't, you don't. So both your problem
21+and our solution are totally unclear.
22+
23+One way to understand Urbit is to forget the technology totally.
24+Instead, let's build the same product out of magic. Technology
25+is hard and imperfect and slow. Magic is easy and perfect and
26+fast. Why not use it? At least for a demo?
27+
28+## Magic step one: total integration.
29+
30+Make a list of all the cloud apps which have your personal data.
31+OK, just imagine making a list. OK, use magic.
32+
33+By magic, we make some giant company buy all these apps. It
34+could be any of them, but let's say it's Facebook. Facebook buys
35+_all the apps_. As of now, _all your cloud computing happens in
36+your Facebook profile_.
37+
38+Your Facebook is now your Dropbox and your Evernote and your
39+Wordpress and your Gmail. And it's not just Web apps; all your
40+servers move to Facebook. Your Nest talks to a Facebook server.
41+Your iPhone talks to Facebook instead of iCloud. Your Fitbit
42+records your heart rate in a Facebook log. Your Facebook
43+manages your finances and pays your bills. Got bitcoin?
44+Facebook is your wallet. Shop online? Check out the Facebook
45+Store -- it sells everything!
46+
47+In short, you can just lock your browser to `facebook.com`. The
48+Web is dead. Or more precisely, it's an obsolete protocol which
49+you use to log in to Facebook.
50+
51+Does this sound creepy? Sure. It's incredibly creepy. But look
52+on the bright side: it's also incredibly convenient. (And
53+incredibly secure, at least with a 2-factor key.)
54+
55+For the first time ever, _all your data is in one place_. For
56+example, the engineers at Facebook, who are awesome, would never
57+leave Dropbox, Instagram and iCloud as three separate things.
58+You don't need an "integration" between them. Your profile is
59+one thing: you. Your entire digital life.
60+
61+(In fact, if you're a geek and have Unix boxes, your Facebook is
62+magically integrated with Unix. You can just open your laptop
63+and type `ls /photos/2016/May/` -- as if your digital life was a
64+chip in a box in your backpack, not redundant servers in multiple
65+secure data centers.)
66+
67+Imagine we all lived in hotels, all the time, even in just one
68+city. Imagine you don't even have one room with a long-term
69+lease. You sleep in one pod Mondays, another on Tuesdays...
70+then, someone offers you a home. Your own house. With your own
71+furniture, your own books in your own bookcases...
72+
73+## Magic step two: free your data.
74+
75+The good news is, you get your own house. The bad news is, it's
76+in North Korea.
77+
78+Having your whole life owned by Facebook is still creepy. Or so
79+most people would think. It's not actually clear that it's more
80+creepy to be owned by one corporation, than nine corporations.
81+But it _feels_ creepier.
82+
83+By magic, Facebook cares. So it decides to free you. Actually,
84+Facebook's business is owning you. So freedom will destroy its
85+business. But magically, Facebook doesn't mind.
86+
87+Right now, the software behind your Facebook experience is a
88+million lines of Facebook goo. It solves your problems and shows
89+your ads and does whatever the heck it wants with your data.
90+(Not that it's "your" data. It's Facebook's data, about you.)
91+
92+Without changing the functionality of your Facebook experience,
93+Facebook replaces every component of this goo with an "agent."
94+(You have about as many agents as you used to have apps.) If you
95+don't care about being free, you won't notice the change. If you
96+do care, everything changes.
97+
98+One, you don't have to run Facebook's agents. You can replace
99+them with anyone else's software, free or paid. Agents upgrade
100+themselves automatically, but you are never locked in; you can
101+always switch agents and/or vendors without damaging your data.
102+
103+Don't like your email UI? Change it. Don't like to see ads?
104+You no longer see any ads -- why would someone use an agent that
105+showed them ads? Ick. Unless it's something ridiculously
106+specialized, an agent is either free software or costs $3.99.
107+
108+Two, agents _act as you_. Facebook is no longer the Panopticon.
109+It is not a giant mainframe where all the code can access all the
110+data. An agent can use as much of your own data as you give it;
111+it cannot use anyone else's data. At least not without asking.
112+
113+When anyone can write an agent, only code can be law. Privacy is
114+no longer enforced by the informal decisions of Facebook product
115+managers. It must be enforced by formal security policies.
116+
117+This might constrict the services Facebook can offer, but only a
118+little. Since privacy is a human universal, apps that don't
119+respect it (for instance, image face tagging) feel weird. A
120+service like this can't be broken up into personal agents; it
121+still requires a Big Data mainframe somewhere. But it's okay;
122+the agents can still talk to it.
123+
124+For the most part, Big Data (everyone's) has become little data
125+(yours). You no longer have a Facebook profile -- a fancy UI
126+backed by a million lines of Facebook goo on one big mainframe.
127+Now what you have is a Facebook _server_: a real computer. Or at
128+least, a virtual computer (which is much more reliable than any
129+one physical computer).
130+
131+Is this computer hard to manage? You have the same basic job as
132+someone who owns an iPhone: deciding what software to run. If
133+you skip this job, your iPhone or your Facebook is still pretty
134+useful. You also need to decide what data to keep. An iPhone
135+has finite, free storage; the cloud has infinite, non-free
136+storage. You still want a warning when your server gets fat.
137+But at least it keeps working.
138+
139+## Magic step three: free your server.
140+
141+This agent-oriented Facebook can't show you ads. But this is not
142+actually a huge business problem. Since Facebook owns everyone's
143+life, it has the mother of all monopoly lockins. It can just
144+bill you $9.99 a month for running your Facebook server. This is
145+a great deal, for you and for Facebook.
146+
147+But you're still a slave, Neo. A Facebook server still isn't a
148+personal server. Monopolies suck.
149+
150+Magic works, so Facebook feels guilty. It goes all the way
151+toward freeing you, and ruins its own business.
152+
153+Now, your server is just a big file whose format is precisely
154+defined. You can move it to any hosting service, or even run it
155+on a home PC. Since hosting is now a commodity, it costs almost
156+nothing and has zero profit margin. It may even come bundled
157+with your Internet service.
158+
159+Every data center is owned by the local government. If you have
160+data to hide from the authorities, compute at home. Most people
161+don't have anything to hide and should run in the cloud, because
162+the cloud works better. But using the _same platform_ as those
163+who do have something to hide creates "herd immunity". You don't
164+have to choose between a secure platform with no network effect,
165+and a non-secure platform that everyone else uses.
166+
167+## Magic step four: free your name.
168+
169+Freeing your server also means freeing your identity. It's no
170+longer true that Facebook decides who you are. Facebook just
171+wrote the algorithm. Your server contains cryptographic secrets
172+that control your identity. If your identity was a bitcoin, your
173+server would be a giant bitcoin wallet.
174+
175+The bad news: lose the file, lose the identity. The good news:
176+your server is genuinely personal now. It's yours in every way.
177+It's so personal that if you destroy it, it's gone.
178+
179+Facebook doesn't even keep its power to create new servers. The
180+"real name" policy has done great things to control spam, because
181+spam always depends on disposable accounts. But it implies a
182+central authority.
183+
184+Instead, Facebook borrows an idea from bitcoin and just limits
185+the number of identities. If you need one, you have to buy one.
186+They don't cost that much; just enough to deter spammers.
187+
188+(Is your real name still linked to your identity? Maybe, maybe
189+not. There's a role for name validation, but not everyone needs
190+to have a real name, and not everyone else needs to know it. A
191+dissident, or anyone who wants to speak out and let the words
192+speak for themselves, might want a second anonymous identity.
193+But sock puppets remain evil -- two names for the same person
194+should not interact in the same place.)
195+
196+## Magic step five: call it Urbit.
197+
198+And, with magic, we've succeeded in turning Facebook into Urbit.
199+Technically, Urbit is pretty close to magic, but there is no way
200+it's going to happen this way. See the [roadmap](../roadmap) for how it
201+actually happens.
content/posts/the-dao-as-a-lesson-in-decentralized-governance.mdnew file+320
@@ -0,0 +1,320 @@
1++++
2+title = "Magic"
3+date = 2016-06-24
4+author = "Curtis Yarvin"
5+description = "What's the right lesson for the decentralization community to learn from the collapse of the DAO?"
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+What's the right lesson for the decentralization community to
10+learn from the collapse of the DAO?
11+
12+Perhaps the simplest lesson is that even decentralized networks
13+need governments, and have governments. Every network is a
14+state. Every state has a government.
15+
16+## Decentralization theater considered harmful
17+
18+In Dijkstra's terms: decentralization theater [considered harmful](https://en.wikipedia.org/wiki/Considered_harmful).
19+
20+_Decentralization theater_ means any system that produces not
21+decentralization, but the appearance of decentralization.
22+[Security
23+theater](https://en.wikipedia.org/wiki/Security_theater) is the enemy of real security; decentralization
24+theater is the enemy of real decentralization.
25+
26+A network without decentralization theater is one that admits:
27+
28+- any network is a digital state with a central government.
29+- any new state is born at war with full emergency powers.
30+- limiting and/or eliminating governance is a slow, hard task.
31+
32+TLDR: true decentralization isn't just a technical problem. It's
33+also a political problem, and not an easy one. Believing you've
34+solved it, before actually solving it, is not a way to solve it.
35+
36+## Decentralization and legitimacy
37+
38+Steve Randy Waldman is not alone in pointing out that [a
39+blockchain is a
40+parliament](http://www.interfluidity.com/v2/6581.html). It's
41+just the technical reality that a majority of miners in a
42+proof-of-work blockchain, or stakeholders under proof of stake,
43+have the mathematical power to govern the network absolutely.
44+
45+But this power does not give them the legitimate authority to do
46+whatever they want. Mathematically, the Ethereum miners can
47+easily roll back the DAO. Do they have the _right_ to roll back
48+the DAO? As we write, this question is one much debated.
49+
50+We have an easy answer: no. The most basic principle of law is
51+that _pacta sunt servanda_, agreements must be respected. A good
52+clue is that before the DAO hack, everyone swore great oaths to
53+"the steadfast iron will of immutable code." Methinks the lady
54+did protest too much. But these oaths make rolling back the DAO
55+blatantly illegitimate.
56+
57+From a governance perspective, the line of lawlessness isn't the
58+line between soft and hard forks. It's any fork which makes an
59+exception for a specific address. Ethereum has already done this
60+by freezing the DAO contract. At this point, it might as well be
61+hanged for an ox, and go through with the full rollback.
62+
63+## Illegitimacy and belligerency
64+
65+Within the ethos of Ethereum (we are obviously not qualified to
66+comment on "real" law), a rollback is a _lawless act_. This does
67+not make it a wrongful act. It simply cannot be judged as an act
68+of law. Rather, it is an act of war.
69+
70+And judged as an act of war, a DAO rollback is _exactly right_.
71+Ethereum is not dealing with a "participant." It is dealing with
72+a pirate, a thief, _hostis humani generis_.
73+
74+As a state at war with an external enemy, the Ethereum network
75+shouldn't just zero the DAO hacker's booty. It must do all it
76+can to destroy her. If possible, it must dox and report her.
77+The right place for this fool is the supermax, not the Riviera.
78+
79+But does Ethereum really want to be at war? And if Ethereum is
80+at war -- and this certainly isn't the only pirate in the sea --
81+how does it become decentralized? If Ethereum is at war, where
82+there is no law, how can it achieve its goal of creating a world
83+where code is law?
84+
85+But we really shouldn't panic. It is actually possible to go
86+from wartime government to peacetime government, from absolute
87+martial law to absolute rule of law. It is just nontrivial.
88+It's a political engineering problem that can't be ignored.
89+If it has to be solved, it should be solved properly.
90+
91+What really doesn't work is to declare martial law, execute all
92+traitors, terrorists and enemies of the state, then declare that
93+elections will proceed as scheduled next week. If the goal is
94+the decentralized rule of code as law, a rollback takes an
95+enormous step backward. Reversing this setback isn't trivial.
96+
97+Should Ethereum actually go to war? Or should it just let the
98+hacker win? Clearly, from a pure blockchain perspective, the
99+only correct thing to do is let the DAO burn -- as a painful
100+warning to all future contract authors and participants.
101+
102+At present, it seems that Ethereum's leadership has chosen war.
103+Certainly, neither choice is obviously imprudent. Ethereum is a
104+winner and probably has a bright future either way. But who
105+chooses war needs a plan to win that war, and return to peace.
106+
107+## Sovereignty is conserved
108+
109+For a government to even have the power to consider wartime
110+measures, a government has to exist in the first place.
111+
112+Again, we can't remind ourselves too often that a blockchain just
113+puts absolute authority in the hands of the miners. We just
114+think of this power in terms of the law it's supposed to enforce.
115+But the two are different -- at least in wartime.
116+
117+Why is it so hard to eliminate unaccountable power? Who watches
118+the watchmen? The German legal scholar [Carl
119+Schmitt](https://en.wikipedia.org/wiki/Carl_Schmitt) defined the
120+problem well when he wrote: "the sovereign is who decides the
121+exception."
122+
123+In the American regime, the Supreme Court is sovereign by
124+Schmitt's definition. We have a complex system of laws, which
125+are not formal code but in some ways aspire to be; above it, we
126+have a judiciary system that can decide arbitrary exceptions to
127+those laws. Pure rule of law, Schmitt tells us, is always and
128+everywhere an illusion. We can and should strive to approach
129+this limit, but it's an infinity that we can't actually reach.
130+
131+Schmitt's exception principle can be rephrased as "sovereignty is
132+conserved." There is always someone who answers to nobody. We
133+cannot eliminate government; the best we can do is tame it.
134+
135+One way to think of the problem of reducing exceptional force to
136+zero is to compare it to a simple unstable equilibrium, like a
137+pencil standing on its point. The pencil on its point needs
138+almost no force to stay upright. But the farther it deviates
139+from this orderly, self-sustaining equilibrium, the more energy
140+must be applied to return it to vertical.
141+
142+Vitalik seems to have grasped more or less Schmitt's point:
143+"_Intent is fundamentally complex_... we believe that we value
144+things like 'fairness', but it's hard to define what fairness
145+even means."
146+
147+If we could define fairness, we would have a rule to which there
148+were no exceptions. We would need no judges, or governments, or
149+even soldiers. We would need no sovereignty. But since we can't
150+define fairness -- yet need to enforce some clear vision of
151+fairness -- sovereignty remains conserved.
152+
153+## Bitcoin, a blockchain at peace
154+
155+Bitcoin has done an excellent job of freezing the war power of
156+its own "parliament." Ironically, mining power in Bitcoin is
157+quite centralized -- a small number of Chinese mining-pool
158+managers, who have every opportunity to collude, could roll back
159+anything. But they never have and they probably never will.
160+
161+Even if a single pool controlled 51% of Bitcoin mining power,
162+they'd have no incentive to break the rules -- quite the
163+converse. We equate physical decentralization with limited
164+governance, perhaps because we think of the physical difficulty
165+of coordination as the main protection against arbitrary power.
166+
167+Bitcoin shows that this isn't true. As far as we can tell,
168+Bitcoin would keep working fine if there was only one miner.
169+This uni-miner would have still have no incentive to corrupt the
170+network -- though another party, such as a real government, might
171+have an incentive to coerce the miner.
172+
173+The important success of Bitcoin is the collective acceptance --
174+mathematically false, but politically true -- that rollbacks in
175+Bitcoin are inconceivable. Bitcoin has governance problems, but
176+they're confined to relatively unimportant questions, like the
177+blocksize debate. "Decentralization" may not be quite the word,
178+but somehow Bitcoin has achieved limited government. The pencil
179+is standing on its point. For now.
180+
181+## Ethereum's dilemma
182+
183+A rollback creates a scary precedent. It's a sort of military
184+coup. Just as the miners have the power to rule any blockchain,
185+the military has the power to rule any country. Do they want it?
186+The first coup makes the next coup much easier. Same with the
187+first rollback.
188+
189+In retrospect, the great mistake here was that Ethereum didn't
190+know it needed a government, and did its best to pretend it
191+didn't have one. After a rollback, Ethereum doesn't just have a
192+government. It has a military dictatorship.
193+
194+Ethereum and Bitcoin are qualitatively different. Bitcoin has a
195+simple UI metaphor: cash. Everyone knows how cash works. A
196+smart contract has its own UI metaphor: law. But as we see,
197+mechanically administered law, law without judges, is a very
198+different thing from ordinary human law.
199+
200+What the DAO shows is that Ethereum just wasn't ready to be
201+decentralized. It was not ready to allow a $150 million contract
202+with no supervision or appeals process. The problem was not
203+Ethereum's code per se -- although Solidity doesn't seem terribly
204+well designed for preventing these pitfalls -- but the human
205+understanding of its capabilities and limits.
206+
207+A rollback acknowledges this. It acknowledges that Ethereum
208+wasn't ready for complete self-government, and _someone_ needed
209+to have stopped the DAO from trading. It's not quite clear what
210+the principle behind the rollback was.
211+
212+Perhaps the best kind of DAO rollback would be a rollback which
213+understood this error fully, and acknowledged that -- for the
214+moment -- Ethereum needs a sovereign government, with the power
215+to restrict and/or steward contracts.
216+
217+Contracts are not payments. They are infinitely more complex.
218+They will keep blowing up. Ethereum is full of buggy contracts,
219+scammy contracts, ponzis and casinos, etc. A governed Ethereum,
220+in the present state of the technology, might well choose to vet
221+all contracts centrally _before_ they started trading.
222+
223+Would this be a permanent feature? Certainly not -- it would be
224+a way for the community to collectively define a good contract.
225+Once we know what a responsible, well-tested, non-scammy Ethereum
226+contract looks like, it's much easier to return to the principle
227+of _caveat emptor_ and let good contracts outcompete bad ones.
228+
229+But after the DAO hack, how does anyone trust any contract?
230+Arguably, Ethereum is ready to be decentralized only when users
231+are able to make this decision rationally, and get it right.
232+This work simply hasn't been done.
233+
234+Perhaps the worst-case scenario is one in which Ethereum approves
235+the hard fork, on the "just this once" principle. To save the
236+country, we need a military coup. But don't panic! "After
237+executing all traitors and enemies of the people, the generals
238+will immediately restore democracy and the rule of law."
239+
240+The "just this once" fork takes us back to decentralization
241+theater, where Ethereum pretends not to have a government. But
242+now, this pretense is even more threadbare. The next hack, which
243+will certainly happen, will produce yet another coup -- or at
244+least a food fight over whether to have a coup. This is the path
245+to a "digital banana republic," where the tattered illusion of
246+law barely conceals the real law of nature.
247+
248+The bottom line is that if a rollback happens once, we can expect
249+it to happen again. This time, the rollback can be treated as an
250+act of war, and no process is necessary. Next time, there needs
251+to be a process -- or the dream of code as law will drift further
252+away.
253+
254+Having a central government isn't inconsistent with the ultimate
255+objective of eliminating central government. Certainly, before
256+Ethereum was released, its developers were its government. Every
257+government is born in a state of chaos and war.
258+
259+The mistake is just in thinking something as complex as Ethereum
260+can jump directly to decentralization in a single step. The
261+pencil is not standing on its point, or anywhere close. Before
262+anyone can think about letting go, someone needs to actually lift
263+it. To reach law, first enforce peace.
264+
265+## Constitutional structure
266+
267+One of the governance problems of blockchains, related to the
268+fundamental error of decentralization theater, is the failure to
269+build deliberative institutions on top of the "parliament of
270+miners." Voting by proof of work is great, especially if the
271+majority is well above 51%, and can demonstrate its strength
272+without an actual hashing race. It's a good way to finalize
273+decisions. But not a good way to make them.
274+
275+But blockchain governance would be considerably improved if the
276+miners actually had a formal way to delegate their power to a
277+structured institution that represented them. Both Bitcoin and
278+Ethereum have foundations and/or core teams, but authority in
279+these institutions isn't tied in any way to actual mining power.
280+Informal politics fills this void with personality cults and
281+eloquent blogposts, all hoping to create collective agreement
282+among the actual voting miners.
283+
284+History shows this is not a great way to run a railroad.
285+Misalignment between a fundamental power, like the miners, and a
286+group purporting to represent them, like the foundations, is
287+inherently dangerous.
288+
289+What's the alternative? An actual constitution. Perhaps the
290+first smart contract that Ethereum needs is not the DAO, not even
291+well-engineered, high-quality smart contracts like Augur and
292+Maker, but just its own equivalent of 1789. If Ethereum needs a
293+government, it must govern itself. It certainly has all the
294+technical tools it needs!
295+
296+Or, of course, it could just let the hackers win. This is the
297+easiest path. And in the end, it may still be the best. War,
298+who needs it?
299+
300+## A quick Urbit plug
301+
302+Technically, Urbit needs governance much more than Ethereum.
303+Decentralization remains our goal -- but it's a long-term goal.
304+Decentralization theater has never even been a temptation. It's
305+just technically impossible.
306+
307+For example, until the Urbit OS and language (Arvo and Hoon) are
308+frozen and perfect -- which, unlike Nock, will take a while --
309+Urbit is still "evergreen" -- it still needs automatic hotpatches
310+from the network.
311+
312+Whatever institution signs these updates is, by any standard, an
313+absolute government. It's as if the Ethereum Foundation could
314+push a hardfork of all clients by signing the new code on the
315+blockchain. Getting out of this situation is a long-term goal --
316+where "long term" means years. Decentralization is hard.
317+
318+Read our [interim
319+constitution](http://urbit.org/essays/interim-constitution) and our
320+[beliefs and principles](http://urbit.org//essays/beliefs-and-principles).
content/posts/the-ether-review-46-curtis-yarvin-and-galen-wolfe-pauly-on-urbit.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "The Ether Review #46: Curtis Yarvin & Galen Wolfe-Pauly on Urbit"
3+date = 2016-10-24
4+author = "Tlon"
5+description = "Curtis and Galen talk about Urbit on The Ether Review podcast."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+{{ soundcloud(url="https://w.soundcloud.com/player/?url=https%3A//api.soundcloud.com/tracks/289783332&color=%23000000&auto_play=false&hide_related=true&show_comments=false&show_user=true&show_reposts=false&show_teaser=false&visual=true") }}
10+
11+[The Ether Review \#46 - Curtis Yarvin & Galen Wolfe-Pauly on Urbit](https://soundcloud.com/arthurfalls/the-ether-review-46-smoking-dmt-with-mencius-moldbug)
content/posts/the-future-of-precision-agriculture-is-decentralized.mdnew file+9
@@ -0,0 +1,9 @@
1++++
2+title = "The Future of Precision Agriculture is Decentralized"
3+date = 2017-07-17
4+author = "Tlon"
5+description = "Anthony Arroyo writes on Urbit and decentralizing agriculture."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+[The Future of Precision Agriculture is Decentralized](http://www.anthonyarroyodotcom.com/blog/2017/7/17/the-future-of-precision-agriculture-is-decentralized)
content/posts/the-urbit-address-space.mdnew file+292
@@ -0,0 +1,292 @@
1++++
2+title = "The Urbit Address Space"
3+date = 2016-05-16
4+author = "Galen Wolfe-Pauly + Curtis Yarvin"
5+description = "An overview of Urbit's cryptographic address space."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-3.jpg)
10+
11+## Basics
12+
13+Urbit contains a lot of new technology. As an ordinary user, all you
14+need to understand is Urbit's identity model. If you're in a hurry,
15+just read these simplified basics.
16+
17+An Urbit identity, or "ship," is a string like `~firbyr-napbes`. It
18+means nothing, but it's easy to remember and say out loud.
19+`~firbyr-napbes` is actually just a 32-bit number, like an IP address,
20+that we turn into a human-memorable string.
21+
22+Technically, a ship is a secure digital identity that you own and
23+control with a cryptographic key, like a Bitcoin wallet. As in
24+Bitcoin, the supply of ships is mathematically limited. This keeps
25+the network friendly, by making spam and abuse expensive.
26+
27+A ship name is just a number; smaller numbers make shorter names.
28+Shorter names are easier to remember, so they're more valuable. So
29+ships are classified by the number of bits in their name. (A ship
30+name is just a scrambled base-256 representation of the number.)
31+
32+A 32-bit ship (like `~firbyr-napbes`) is called a "planet." A 16-bit
33+ship (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
34+"galaxy." A planet is an identity for an independent, adult human.
35+Stars and galaxies are network infrastructure.
36+
37+Each planet or star is launched by its "parent," the star or galaxy
38+whose number is its bottom half. So the planet `~firbyr-napbes`,
39+`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`
40+or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of
41+`~mun` and all galaxies is `~zod`, `0`.
42+
43+If Bitcoin is money, Urbit is land. Much as all real-estate titles in
44+England trace back to William the Conqueror, all certificates in Urbit
45+trace back to `~zod`.
46+
47+But this universe is worthless unless dispersed. It's already quite
48+well fragmented. And as it grows distributed, it grows decentralized.
49+The endpoint is a virtual city of 4 billion (`2^32`) citizens, all
50+owners of their own independent digital identities. The stars and
51+galaxies continue as a federated governance and service network.
52+
53+This city is a social network, a peer-to-peer packet network, and a
54+public-key infrastructure (PKI). In the social layer, your ship is
55+your name. In the packet layer, your ship is your network address.
56+In the PKI, your ship is your cryptographic identity. Perhaps more
57+intuitively, a ship is a sort of pronounceable phone number.
58+
59+And once Urbit is built, no one owns the city. No one can control it.
60+It does need governance; but it governs itself as a digital republic.
61+
62+## Details
63+
64+As an Urbit user, these basics are all you need to know. As a
65+developer, a few more details might interest you. (An even more
66+comprehensive treatment is in the [whitepaper](http://media.urbit.org/whitepaper.pdf)).
67+
68+### Design goals
69+
70+An identity system has three goals: a name wants to be secure,
71+human-meaningful, and decentralized. A principle called "Zooko's
72+triangle" says that a practical identity system can achieve any two of
73+these goals.
74+
75+The art of OS design is the art of using strategic tradeoffs to almost
76+solve unsolvable problems. Urbit's goals are to be secure,
77+human-_memorable_, and _eventually_ decentralized. We sacrifice
78+meaning (Urbit is not competing with the DNS), and postpone
79+decentralization. These tradeoffs buy us a simple system that can
80+actually be built.
81+
82+### Comparison to existing identity layers
83+
84+The Internet doesn't have anything like Urbit ships, so you may need
85+to stretch your brain a little here.
86+
87+There are three levels of naming on the Internet: raw, numeric IP
88+addresses (like `126.78.92.112`), domain names (like
89+`foobar.com`), and user identities (like `galen@tlon.io` or
90+`@galenwp`).
91+
92+Urbit (or more precisely, its Ames protocol) squeezes all three layers
93+into one. At the network level, Urbit is a P2P overlay network; your
94+ship is your network address. It's also the name of your server.
95+Finally, it's your secure digital pseudonym. And we map your ship
96+name into the DNS, at `ship.urbit.org`.
97+
98+(One way to use Urbit is as an identity for the Internet, which
99+doesn't have a standard system of secure authentication. Urbit has a
100+single-signon API which lets any Web server accept Urbit logins, like
101+a normal social login -- but not captive to any central mainframe.)
102+
103+### Cryptographic ownership
104+
105+You own an Urbit ship cryptographically, like a Bitcoin wallet. But
106+Urbit doesn't use a blockchain or mining.
107+
108+You transfer a ship by signing a new public key with the old private
109+key, then broadcasting the signature. Any urbit that receives this
110+new certificate will no longer trust the old key.
111+
112+Urbit is digital land, not digital money. A currency needs to support
113+high-frequency, zero-friction transfers. Real estate transfers are
114+low frequency and high friction, so the "double spend" problem (which
115+mining solves) is much less pressing.
116+
117+Don't expect urbits to be tradeable on cryptocurrency exchanges. A
118+trade adds at least one signature to the ship's certificate, or two if
119+the parties don't trust each other and an intermediary is needed. A
120+bulky certificate isn't free, since it slows down new connections.
121+
122+This isn't a serious problem if urbits are treated like land. But it
123+prevents Urbit from being a competent currency. This is a feature,
124+not a bug. Urbit has no need to compete with Bitcoin or Ethereum,
125+and every reason not to.
126+
127+## Moons and comets
128+
129+In the general case, a ship is actually a 128-bit number. A full
130+table of ship classes:
131+
132+```
133+8 bits galaxy router ~syd
134+16 bits star router ~delsym
135+32 bits planet human ~mighex-forfem
136+64 bits moon device ~dabnev-nisseb-nomlec-sormug
137+128 bits comet bot ~satnet-rinsyr-silsec-navhut--bacnec-todmeb-harwen-fabtev
138+```
139+
140+Moons are for clients and connected devices: a laptop, a phone, a
141+digital thermostat. A moon is not independent; its parent planet has
142+to sign its key updates. (We don't want rogue clients floating
143+randomly around the universe.)
144+
145+A comet's address is the hash of its initial public key. Anyone can
146+launch a comet. Nothing stops you from using a comet as your
147+identity, except that the name is a mouthful and everyone will assume
148+you're a bot.
149+
150+### Scarcity, reputation, friendliness and trust
151+
152+A crucial difference between Urbit and other networks is that planets
153+are scarce. Even when the network is fully populated, there are only
154+4 billion. Early in Urbit's life, most stars and galaxies are not yet
155+operating, so far fewer are available. No one will ever be able to
156+get planets trivially and for free.
157+
158+Urbit is a _friendly network_: a network on which you can assume that
159+a stranger is nice until proven nasty. Friendliness is a direct
160+consequence of scarce, individually owned identities. We're not
161+changing human nature, just creating the right economic incentives.
162+
163+Most forms of network abuse are "Sybil attacks": they rely on an
164+infinite supply of fresh identities. Scarcity makes reputation work.
165+Spam is a business; if the cost of a new planet exceeds the amount of
166+money you can make by spamming from that planet until its reputation
167+is trashed, there will be no spam.
168+
169+Shady stars and galaxies that sell blocks of planets to spammers will
170+also develop reputations as "bad neighborhoods," damaging the value of
171+the whole block. Abuse at any level is designed to be
172+counterproductive and economically self-terminating.
173+
174+Urbit has no reputation system at all at the moment, simply because
175+we're so small that friendliness is automatic. The clear and rigorous
176+structure of the address space is not a reputation system; it is a
177+platform on which any number of such systems can and should be built.
178+But we can't build one until we need one.
179+
180+### Initial allocation and rationale
181+
182+In cryptocurrency terms, Urbit is "100% premined." Why? Three
183+reasons.
184+
185+One, Urbit doesn't need mining. Two, Urbit is a much more ambitious
186+software project than Bitcoin or even Ethereum. To fund its own
187+development, the project needs to capture the potential value of its
188+own real estate.
189+
190+Three, most theories of property agree that anyone whoever creates or
191+discovers new property starts out by owning it. Because galaxies are
192+premined, Urbit starts as a centralized system. But it has two strong
193+motivations to decentralize.
194+
195+One, the more decentralized Urbit is, the more Urbit is worth. Two,
196+the only way for Urbit to fund its own development is to homestead its
197+own real estate.
198+
199+Urbit was created by Curtis Yarvin, who has distributed the 256
200+galaxies as follows (allocation as of June 1, 2016):
201+
202+95, to the [Tlon Corporation](../company). 50, to urbit.org, the future
203+community foundation. 40, to Tlon employees and their family members
204+(24 to Curtis, who started in 2002; 16 to everyone else, who started
205+in 2014). 34, to outside investors in Tlon. 37, to 33 other
206+individuals, who donated to the project, contributed code or services,
207+won a contest, or were just in the right place at the right time.
208+
209+What's critical is that the whole system is unlikely to collapse back
210+into a single landlord. This is why we've intentionally scattered
211+Urbit's ownership across a diverse set of entities.
212+
213+Furthermore, we've defined informal conventions designed to motivate a
214+healthy ownership structure by punishing violators with reputation
215+cost. Address blocks should only split, never merge; galaxies and
216+stars should be owned by different parties; galaxies should be owned
217+by true individuals, not corporations. Urbit does not live up to
218+these ideals at present, but must always progress toward them.
219+
220+### Federated services, adoption and escape
221+
222+Urbit is a peer-to-peer network. Urbits that live behind a firewall
223+or on a home network need "supernodes" to help them route packets.
224+The supernode is the parent. So a parent's work isn't done once it's
225+launched all its children.
226+
227+There's no way to enforce this responsibility. So a star or planet
228+can be _adopted_ by a new parent of the same class, letting it escape
229+from a bad default parent. If your parent stops serving you, and no
230+other parent is willing to adopt you, you're probably a bad actor.
231+
232+Supernode routing is just one example of why you need a parent. A
233+mature Urbit will naturally develop all kinds of other _federated
234+services_ -- from technical standardization and update approval, to
235+certificate update broadcast, to reputation and friend lookup. All
236+these services are delivered by cooperating stars and galaxies. Bad
237+actors at this level should be rare.
238+
239+Especially when Urbit is young, the level of trust that a child places
240+in its parent is high. The trust implied by automatic kernel updates
241+is almost infinite. You can disable updates, but that's nowhere near
242+practical yet. (Ideally we will be able to freeze the Arvo kernel,
243+like Nock, and turn off kernel updates; but this will take years at
244+least.)
245+
246+### Code is law: seeing like a pattern language of great cities
247+
248+Constitutional innovation is dangerous. Our vision of digital
249+governance isn't ours, but is synthesized as best we can from the work
250+of four great 20th-century thinkers: the legal scholar Lawrence
251+Lessig, the political scientist James C. Scott, the urbanist Jane
252+Jacobs and the architect Christopher Alexander.
253+
254+All decentralized computation systems rely to some extent on Lessig's
255+principle: "code is law." Where law uses human interpretation to
256+determine an outcome, code uses mathematics. It is code, not law,
257+that decides who owns a Bitcoin wallet.
258+
259+But all these systems, including Bitcoin, need governance. They need
260+as little as possible, but not none. In the digital world as in the
261+real world, _laissez-faire_ is always necessary, never sufficient.
262+Governance is a human universal.
263+
264+That's why we call Urbit a "virtual city." And as a city, it can't be
265+a corporate gated community. It might start as that, but it has to
266+grow up into a true city-state: a self-governing digital republic.
267+This pattern is not just blind clinging to Anglo-American tradition;
268+like every prudent constitution, it fits the actual virtues and vices
269+of its target population.
270+
271+Urbit's galactic hierarchy resembles the natural patterns we find in
272+many existing human political systems. As Alexander wrote:
273+
274+> Wherever possible, work toward the evolution of independent regions
275+ in the world, each with its own natural and geographic boundaries;
276+ each with its own economy; each one autonomous and self-governing;
277+ each with a seat in a world government, without the intervening power
278+ of larger states or countries.
279+
280+We adapt Alexander's vision to a digital republic as the pattern that
281+_authority is proportional to property_. This pattern already has a
282+name in the cryptocurrency community, which calls it _proof of stake_.
283+Urbit's launch hierarchy is a sort of built-in proof of stake.
284+
285+Another governance pattern, a political cliche but no less valuable
286+for it, is the system of checks and balances. The address space of
287+Urbit is covered by three independent tiers, galaxies, stars and
288+planets; which should govern? The obvious design is a three-chambered
289+legislature balanced against itself.
290+
291+For more on Urbit's governance design, see our [beliefs and
292+principles](/posts/principles/) and our [interim constitution](/posts/constitution/).
content/posts/toward-a-frozen-operating-system.mdnew file+253
@@ -0,0 +1,253 @@
1++++
2+title = "Toward a Frozen Operating System"
3+date = 2017-05-10
4+author = "Curtis Yarvin + Galen Wolfe-Pauly"
5+description = "Is it possible to freeze an entire OS?"
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+Is it possible to freeze an entire OS, so that its codebase never changes and
10+never has to change? Is the proposition even meaningful? Is it practical?
11+And if so, why would we want a frozen OS?
12+
13+Think about it intuitively. There's a reason we call an OS a "platform." It's
14+a piece of permanent infrastructure. Paul Graham wrote a
15+[great essay](http://www.paulgraham.com/hundred.html) about the
16+"hundred-year language," but the language is only one part of any complete
17+platform. And in infrastructure terms, a hundred years isn't that long.
18+
19+Why not think of structures that have lasted _thousands_ of years? An aqueduct,
20+a pyramid, a Parthenon? Why set our sights lower? Why isn't it time to aim for
21+perfect and timeless code? If not now, when?
22+
23+## Scope of the problem
24+
25+More prosaically, a frozen OS just means your OS never changes. A frozen OS
26+never gets any updates. Not because it can't update itself, just because it
27+doesn't need to.
28+
29+Is this even a meaningful concept? A frozen OS? First we'll have to decide
30+what "OS" even means. Certainly, if "OS" means "the code that your hardware
31+boots into," hardware always changes and so will the OS.
32+
33+A broader, more useful definition: the "OS" is _an opaque model of a persistent
34+general-purpose computer_. This definition allows for arbitrary levels of
35+virtualization. Linux on a droplet is an OS. A browser is an OS, because it's
36+persistent (sorta) and opaque. But `node.js` is not an OS, because it's not
37+opaque: it exports Linux system calls.
38+
39+Within this opaque model, we have to decide what's "system" and "user" software.
40+It clearly makes no sense to freeze userspace. Let's use the
41+[trusted codebase](https://en.wikipedia.org/wiki/Trusted_computing_base): code
42+is system software, if compromising it would compromise the whole system.
43+
44+## Infinite maturity
45+
46+It's important to remember that just because a system is designed to achieve
47+frozenness, doesn't mean it's useless until it's frozen. It doesn't even mean
48+it's immature. It just means that in the very long term, the system's maturity
49+goals are infinite.
50+
51+Systems designed to diverge infinitely (with normal X.X.X semantic versioning),
52+even those designed to converge infinitely (as with
53+[Knuth versioning](http://www.tex.ac.uk/FAQ-TeXfuture.html)), also achieve
54+maturity, often great maturity, without being quite frozen.
55+
56+For example, C is a very mature language. C has long since mastered backward
57+compatibility. We can be sure that any C program which compiles on today's
58+correct C compilers will compile on any future correct C compiler.
59+
60+But, since C is not frozen, we can't be sure that today's C compilers will
61+compile any future C program. So C has not yet achieved perfect _forward_
62+compatibility. By definition, a frozen system is compatible both forward and
63+backward. So C is mature, but it could still get more mature.
64+
65+The point of a frozen OS is to shoot for _infinite_ maturity. Obviously a
66+frozen platform is compatible forever in both directions.
67+
68+Infinite maturity does exist in the real world. But only in a few simple file
69+formats and protocols — IP, JSON, XML. And not all this maturity is the result
70+of perfection. Some is just the accident of a missing update mechanism.
71+
72+But IP, JSON, XML... this is how stable, how taken for granted, system software
73+should be. And can be. Certainly, any JSON parser today will parse any JSON
74+document made in the future.
75+
76+The dream of absolute zero is an OS whose core components are so simple, so
77+boring, and so mechanically straightforward that we can imagine them becoming
78+finished and never changing. We need to freeze not just a format or a protocol,
79+but a language, a kernel, a standard library. To succeed, we need to flush out
80+each quirk, complexity, and creeping feature, until the system is so boring and
81+obvious that no one even wants to change it.
82+
83+## Kelvin versioning
84+
85+"Kelvin versioning" is one way to track a project designed to be frozen.
86+
87+In Kelvin versioning, a version is an integer in degrees Kelvin. Absolute zero
88+is frozen — no further updates are possible. If your Kelvin versions don't
89+track your actual progress, you run out of integers. This danger is a concrete
90+incentive for the project to track its own progress accurately.
91+
92+(Kelvin versioning isn't useful only at lifecycle scale. It can be used for any
93+development process with an irreversible end — as build numbers for a release,
94+for example.)
95+
96+## The palm-tree dependency model
97+
98+A whole OS can't have a single Kelvin number. It has to consist of multiple
99+components which depend on each other. What's the right dependency model for
100+the parts of a frozen OS?
101+
102+One way to think about dependencies across a whole OS is the "palm-tree model."
103+Fundamentally, there are two kinds of components in a system: "exclusive"
104+components (where we have to choose one version of the code), and "inclusive"
105+ones (where different users can see different versions).
106+
107+The exclusive components are the trunk of the palm tree: a stack of layers, each
108+of which has one active copy. For instance, you are only running one kernel at
109+a time. Different apps cannot use different versions of the kernel.
110+
111+The inclusive components are the fronds, branching out in any direction they
112+want. Not only can two apps use different versions of the same library, in
113+many situations _one_ app needs to be able to use two different versions of the
114+same library.
115+
116+## The palm trunk: telescoping Kelvins
117+
118+Any subsystem that serves as any kind of platform is exclusive, since anything
119+that runs on top of the platform has to choose one version of the platform to
120+run on. Since layers are good, this creates a natural stack which can get quite
121+tall — and include components which are technically in userspace.
122+
123+The right way for this trunk to approach absolute zero is to "telescope" its
124+Kelvin versions. The rules of telescoping are simple:
125+
126+1. If tool B sits on platform A, either both A and B must be at absolute zero,
127+or B must be warmer than A.
128+
129+2. Whenever the temperature of A (the platform) declines, the temperature of B
130+(the tool) must also decline.
131+
132+3. B must state the version of A it was developed against. A, when loading B,
133+must state its own current version, and the warmest version of itself with which
134+it's backward-compatible.
135+
136+Of course, if B itself is a platform on which some higher-level tool C depends,
137+it must follow the same constraints recursively.
138+
139+The important effect of obeying rule 2: in a tall trunk, it's sufficient to
140+state your dependency on the platform directly below you. Suppose C sits on B,
141+which sits on A and exports features of A. C can state only the version of B
142+it's written against, because when A chills, B must also chill.
143+
144+If A could chill without B chilling, we could modify C to use new features of A.
145+Then our new C would silently fail to work on an A-B stack which had not
146+received the A update.
147+
148+## The palm fronds: total flexibility
149+
150+The goal of the trunk is to get to the fronds. In the fronds, no one should
151+ever worry about dependency conflicts. And nothing is ever frozen, or has to be
152+frozen.
153+
154+The right way to solve dependencies in userspace is: within an organization, use
155+a monorepo and link relative to its head. Between organizations, use pinned
156+version numbers that are as immutable as possible. Avoid programming
157+environments that create exclusion problems in userspace — for instance, that
158+compel a single process to choose one version of a library when a diamond
159+dependency exists.
160+
161+There is almost never any good reason to automatically update dependencies with
162+fresh versions of foreign code. In the case of a security update, the
163+maintainer of an app which depends on a patched library needs to catch the
164+patch and propagate the update in a new version of the app. An app shouldn't be
165+security-critical to begin with, and propagating updates is a basic function of
166+a modern OS. Also, if the app is security-critical, it could have its own bugs,
167+so it needs a maintainer and an update pathway anyway.
168+
169+## Urbit: status and prospects
170+
171+Yes, we do believe it's possible to write a freezable OS. In fact, we wrote
172+one. And it works. It's not yet frozen (except at the bottom layer), but it's
173+getting there.
174+
175+Urbit, a clean-slate functional OS, has been under development since 2002. It
176+took a decade (as a one-man project) just to build a prototype of a freezable OS.
177+The result in 2017 (now with a small company) is a telescoping Kelvin stack of
178+layers from VM to UI.
179+
180+At the bottom (the VM Nock), this stack is slightly warmer than liquid helium
181+(5K). It's easy for Nock to get this cold, because it's defined in a page of
182+axioms that gzips to 340 bytes. We are in no hurry to declare zero, but any
183+change at this point would be both very unlikely and very difficult to
184+implement.
185+
186+Urbit's typed functional language, Hoon, which compiles itself to Nock, is
187+closing in on liquid krypton at 143K. Hoon is defined in about 5,000 lines of
188+Hoon, or 10,000 if you count the deep standard library. Nock will never need to
189+change; Hoon is perfectly serviceable but has some well-known rough spots.
190+
191+Above Hoon, the stack rapidly gets much warmer. Arvo is an event-driven
192+microkernel that's 1,000 lines of Hoon. Above this are another 5,000 lines of
193+system library, then 12,000 lines of Arvo modules: a peer-to-peer network, a
194+PKI and private ledger, a revision-control system, an HTTP gateway, a functional
195+build system, and an application sandbox. A trivial working system needs
196+another 5,000 lines for basic chat and shell apps.
197+
198+We haven't had meaningful Kelvin numbers for the Arvo layer, but this release
199+will change that. About a third of Arvo has been or will be rewritten in the
200+last year; we'll assign Kelvins once this code (which now compiles) is tested
201+into existence, largely based on how close the last compiling draft was to the
202+first working draft. But you'll certainly be able to cook eggs on it.
203+
204+(Once again, not being frozen doesn't mean not working. Until all these layers
205+are finished, we'll be updating them over the air. To be exact, Urbit
206+distributes its own updates through subscriptions in its own revision-control
207+system.)
208+
209+The actual status of Urbit is that in 2017, we hope to make our last
210+discontinuous update — meaning that instead of your Urbit node updating itself
211+silently, you destroy and recreate it. Urbit works today, but it isn't really
212+alive until today's Urbit data lives forever.
213+
214+Even committing to continuity is a significant step toward the frozen OS,
215+because we're committing to never making another change that the present
216+platform can't install. Fortunately, the only layer that has to stay frozen for
217+this is Nock.
218+
219+## The style of convergent system software
220+
221+We're obviously in no position to declare victory at any layer above Nock, but
222+aiming at absolute zero creates a system design style we think works very well —
223+even if we never get to zero.
224+
225+Deep, onion-like layering is essential. A thin layer has no room to grow. A
226+good example of this principle is the difference between Urbit and Lisp
227+machines. Both Nock and Lisp are very simple axiomatic definitions of
228+computing. But practical Lisp systems expand by extending the model, whereas
229+Urbit layers over a frozen axiom system.
230+
231+Software that expands by extension is inevitable. But we need to be able to
232+kick it up to userspace. System software should be concerned with the
233+fundamental problems of computing, which don't change. The few cases in which
234+they do change — like crypto algorithms — are special cases, easily
235+encapsulated. And even these changes can be expected to slow down in the long
236+term.
237+
238+Perhaps the best example of the convergent style in existing, mature system
239+software is the relational database. The genius of the relational model is that
240+it's designed to never grow hair. Even SQL, with its COBOL-era syntax, is
241+essentially invulnerable to any significant non-cosmetic improvement.
242+
243+The lesson: when we see a system that seems to want to expand indefinitely, we
244+can and should look for a layer division within this system, separating an inner
245+layer that tends to converge from an outer layer that naturally diverges.
246+Layering is what distinguishes true system software from the giant balls of mud
247+that all deep codebases want to become.
248+
249+Are all balls of mud, or at least all the muddy parts of an OS, susceptible to
250+this transformation? We think so. But we'll see.
251+
252+As usual, comments are on fora. Check out
253+[this thread](https://urbit.org/fora/posts/~2017.5.12..20.30.11..0050~/).
content/posts/toward-a-new-clay.mdnew file+1004
@@ -0,0 +1,1004 @@
1++++
2+title = "Toward a New %clay"
3+date = 2016-07-14
4+author = "Curtis Yarvin"
5+description = "Urbit's revision-control system, %clay, is itself due for a (medium-sized) revision!"
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+TLDR: (a) Urbit's revision-control system, `%clay`, is itself due
10+for a (medium-sized) revision! (b) this time, you yourself can
11+really help! (c) please don't give away the buried spoiler!
12+
13+This explanation does not (or at least should not) require you to
14+know anything about Urbit.
15+
16+### But %clay is already pretty cool
17+
18+Of course, nothing in Urbit is allowed to be _lame_. `%clay` is
19+actually quite cool. It does need some work. But first, let's
20+talk about what it is and why it's cool.
21+
22+`%clay` is the Arvo vane (Urbit kernel module) for revision
23+control. It's an authenticated, human-memorable global immutable
24+namespace which is also a typed revision-control system. It's
25+also very good at subscription and synchronization. Urbit
26+currently uses `%clay` to distribute live hotpatches; we
27+transparently upgrade the whole network with one checkin.
28+
29+### Compared to other revision-control systems
30+
31+`%clay` is clearly a vanilla DVCS in the modern `git` style. Of
32+deployed DVCS these days, `%clay` is probably closest in spirit
33+to `bzr` or maybe `fossil`.
34+
35+Obviously, as a part of a larger whole, you would expect any
36+Urbit RCS to be brutally spartan. `%clay` is. It's even more
37+spartan than `bzr`.
38+
39+(In fact, it's really too spartan to fully use at the moment. We
40+ourselves still use `%clay` mainly as a distribution system, and
41+do all internal development on Github. This is because the
42+present `%clay` lacks a few little conveniences, like commit
43+messages. See upgrades, below.)
44+
45+There are lots of normal DVCS things in `%clay`. But there are
46+also cool and unusual ones. Let's take a brief tour of the
47+high-level system, then describe what we think should change
48+about it.
49+
50+### Anatomy of a DVCS
51+
52+A DVCS is a historical state graph. A point in this graph is a
53+snapshot of some tree-structured system, like a filesystem.
54+
55+These snapshots, including recursive internal nodes, are stored in
56+a content-addressable store. Pointers in this store are used to
57+construct a revision graph, whose edges are edit and/or merge
58+actions. Some sort of namespace attaches meaningful names to
59+current revisions in this graph.
60+
61+There are six big questions in the design of a DVCS:
62+
63+- how are snapshots named?
64+- what is the data structure within a snapshot?
65+- how does it map to the Unix filesystem?
66+- how is the system queried?
67+- how is the revision graph defined?
68+- how does the content-addressable store work?
69+
70+## Anatomy of %clay
71+
72+A good way to summarize `%clay` (at present) is that its answers
73+to the first four questions are interesting, and its answers to
74+the last two are boring. We'll talk about all six, though.
75+
76+### Global namespace: [ship desk case]
77+
78+The permanent global name of a `%clay` snapshot is a `++beak`. A beak
79+is a triple: `[ship desk case]`.
80+
81+The `++ship` is an Urbit ship. A ship is a network address, a
82+human-memorable name and a cryptographic identity. The address
83+width is variable; shorter addresses are more desirable. Most
84+users have 32-bit addresses, which we map to four-syllable
85+synthetic names like `~sorreg-namtyv`.
86+
87+The `++desk` is a 4-letter word meaning "branch."
88+
89+The `++case` is a version, one of three kinds: a version sequence
90+number, a named label, or a date.
91+
92+In the Urbit path syntax, the beak is the first three segments of
93+the path: `/ship/desk/case/my/cat/picture`.
94+
95+In most cases, a path parser has a default ship, desk and case,
96+each of which can be replaced by `=`. So `/=home=/my/cat/picture`
97+is the data at `/my/cat/picture` on your own ship, in the `%home`
98+desk, right now. Immutability doesn't have to be inconvenient.
99+
100+`%clay` has no concept of a mutable name or a magic `HEAD`. Use
101+the current date. If you're referring to remote data and you're
102+worried about clock skew, subtract a second or three, or be
103+prepared to block. (Or keep your clock unskewed, which shouldn't
104+be _that_ hard.) It's not like mutable-name schemes work any
105+better than this anyway.
106+
107+(Immutability is central to `%clay`. `git` merely adopted the
108+reflog. `%clay` was born in it, molded by it...)
109+
110+`%clay` is objective; each Urbit node hosts only one ship, but
111+treats domestic and foreign data (almost) the same way. If you
112+ask your `%clay` repository for someone else's data, it will
113+block the request until it gets the data, which it then caches.
114+At present, we always fulfill requests from the origin ship,
115+though in future we could certainly use it as a tracker.
116+
117+If `%clay` discards cached data, it keeps a hash, so that your
118+urbit can't violate the local illusion of immutability. We
119+can't, of course, prevent anyone else's ship from sending
120+conflicting claims in different directions. But we can prevent
121+programs on our own ship from hearing about them, meaning that we
122+retain local referential transparency.
123+
124+### Local structure: dome, arch, leaf and mark
125+
126+A `%clay` snapshot is called a `++dome`. A dome is the `%clay`
127+equivalent of a tree-structured filesystem.
128+
129+Each node in this tree is one uniform structure, an `++arch`,
130+which is both file and directory. A `++leaf` or data value in
131+this arch is a typed document.
132+
133+A logical document type is called a `++mark`. A mark is a
134+symbolic pointer to a Hoon source file, in the same dome, for an
135+engine that can validate, compare, and/or convert
136+documents of that mark.
137+
138+Let's go over arches and marks a little more closely...
139+
140+#### An arch is a uniform filesystem node
141+
142+Most filesystems and RCS have modal nodes. For instance, a git
143+data node can be a blob or a tree. `%clay` (and the Urbit
144+namespace in general) has one kind of node, an `arch`:
145+
146+```
147+ ++ arch (pair (unit leaf) (map knot arch))
148+ ++ leaf (pair mark noun)
149+```
150+
151+An arch has an optional typed-data leaf, and optional named
152+children. In Unix terms, it's a file, a directory, or both. It
153+can't be neither: an empty arch, with no data and no children, is
154+auto-pruned. As in `git` (but not in Unix), the hierarchy is a
155+pure function of its leaves. Paths exist only because of the
156+data they point to.
157+
158+The `++knot` names in an arch path are also a little special.
159+They're typed, in a sense; any knot can be parsed invertibly into
160+a typed atom. The atom is an arbitrary unsigned integer. Its
161+type (an `++aura` if you know Hoon) defines the semantics and
162+presentation of the atom: for instance, a symbol, a decimal,
163+a date, etc.
164+
165+Ultimately a filesystem is a database, and a path is a primary
166+key. It's very useful to be able to store simple data in this
167+key, in a standard and unambiguous way.
168+
169+Why uniform nodes? One, they map nicely to information trees
170+where a subtree may need some custom collective presentation,
171+not an automatically generated Apache style directory listing.
172+Two, non-uniform nodes introduce a whole pointless category of
173+node type conflicts -- for which life is far too short.
174+
175+#### A mark is an executable document type
176+
177+A mark is "like an executable MIME type." It's best defined as a
178+symbolic mapping from a filesystem to a schema engine.
179+
180+If you have a MIME type `text/html`, you need to watch the
181+Internets to track what the W3C thinks HTML is. If you have an
182+Urbit mark `%html`, you can functionally construct (using our
183+insanely powerful functional build vane `%ford`) a core which
184+can validate or normalize HTML, apply patch and diff logic, and
185+translate to and from other marks. `%ford` can even reason about
186+translation paths and construct multistep conversions.
187+
188+(Urbit does not actually have this super-smart `%html` mark right
189+now. But it probably should, huh. And this page was composed in
190+Markdown and translated to HTML by `%ford`.)
191+
192+Where does the source code of a mark live? Within the same dome
193+as the data it describes. `%html` files are described by the
194+Hoon source at `/===/mar/html`, which perhaps gets mapped into
195+your Unix filesystem at `$ship/home/mar/html.hoon`.
196+
197+This Hoon file is not self-contained. It has dependencies. The
198+`%html` mark may depend on various structures and libraries
199+elsewhere in Urbit. But the source code for all them is within
200+this dome.
201+
202+One constraint this puts on domes is that _all domes are
203+descendants of the base system dome_. Domes are versions of one
204+reality, not fragments of that reality. You can't create a new
205+empty dome -- you'd have no mark source, and be unable to install
206+any validated files.
207+
208+Enforcing the rule that all domes are congruent (if only in that
209+they all contain the base system files) costs us nothing in the
210+implementation, does not inconvenience the user, and ensures that
211+weird collisions between non-parallel things don't happen.
212+
213+### Unix mapping and mounting
214+
215+Every DVCS is its own filesystem in a sense. But every DVCS
216+works by mapping and mounting itself, in some sense, to Unix.
217+
218+#### Mapping arches to Unix
219+
220+How do we map arches into Unix? The arch structure maps 1:1 to
221+the Unix directory tree. When the arch has a leaf, we derive a
222+dot extension from the file's mark.
223+
224+So, supposing we have a leaf `foo` which is an HTML document
225+(mark `%html`), with two children `bar` and `moo`, also HTML
226+documents, in Unix we'll see:
227+
228+```
229+foo.html
230+foo/bar.html
231+foo/moo.html
232+```
233+
234+This maps invertibly back into `%clay`, and it looks perfectly
235+unremarkable from the Unix side. File completion sometimes gets
236+a little annoying.
237+
238+It would be if nice every possible Unix tree, even every
239+plausible Unix tree, mapped cleanly and completely to a `%clay`
240+dome. There are always horrid exceptions, even in common use --
241+like extensionless Makefiles. The trivial solution is that if
242+`%clay` finds a file mysterious, it won't track it.
243+
244+One often unquestioned assumption in new system software is that
245+compatibility with old content is important. It's nice, but not
246+that important. Most content in a new system is new content.
247+The important compatibility direction is export, not import. So
248+the new system should subset, not superset, the ancient formats.
249+
250+### Mounting desks to Unix
251+
252+If a `%clay` desk is _mounted_, it has a two-way live sync to
253+the Unix directory of the same name within the pier.
254+
255+When files in a mount directory change, `%clay` notices it
256+through `libuv` filesystem watching (ultimately `inotify()` or
257+`FSEvents`), computes diffs, and automatically commits them to
258+the desk. And if `%clay` creates a new version for its own
259+urbity reasons, it will revise the Unix files.
260+
261+Keeping all mounted files in the same Unix subdirectory makes it
262+easy to move the whole pier in a tarfile. Edits applied while
263+the `urbit` process isn't running will be detected and applied
264+the next time it starts.
265+
266+In conventional DVCS terms, `%clay` has a 1:1 static mapping from
267+branches to working directories. Why?
268+
269+Why not? Do we need that "what branches are checked out in what
270+directories" piece of state? Why force the user to worry about
271+which branches are mounted to which directories? Why not just
272+mount them under their own names? Is there some crippling global
273+shortage of disk space for source files? Our planet is running
274+out of inodes? Wut?
275+
276+### Queries, subscriptions and synchronization
277+
278+There are two ways to get data out of `%clay`: dereference the Urbit
279+namespace, or send a request/subscription. Sync is in userspace.
280+
281+#### Dereferencing the namespace
282+
283+`%clay` is just part of the full Urbit namespace. The full namespace
284+has a two-character prefix which expresses what vane to query
285+(always `%c` for `%clay`). The suffix is a mode flag; `%x` for
286+data, `%y` for a list of children, `%z` for the whole arch
287+subtree, `%w` for the version number. (Each vane has its own
288+modes.)
289+
290+For example, the full path to my cat picture is
291+
292+```
293+/cx/~sorreg-namtyv/home/[now]/my/cat/picture
294+```
295+
296+(where `now` is the current date).
297+
298+If the data model is `++image` (hypothetical -- we don't really
299+do image processing in Urbit right now), the normal way to load
300+this data in a Hoon program is
301+```
302+.^(image /cx/~sorreg-namtyv/home/[now]/my/cat/picture)
303+```
304+
305+This produces a statically typed value (which works by
306+dynamically checking `image` against the actual type of the
307+value, but this comparison caches well).
308+
309+Internally, an Urbit namespace request produces a `++cage`, which
310+has a mark, a `++span` (language-level type), and an actual noun.
311+The product is doubly optional, `(unit (unit cage))`; this is `~`
312+if we don't know the value of this name at present but might
313+learn it in future, `[~ ~]` if we know we'll never know it, or
314+`[~ ~ value]` if we know it now.
315+
316+In high-level shell programming (`:dojo`), we can make apparently
317+"blocking" requests to `%clay`. What actually happens: when `%clay`
318+produces `~`, we stop trying to compute this expression and wait
319+on one or more blocking requests. When we are unblocked, we
320+recompute again from scratch; the intermediate computation is not
321+saved at all.
322+
323+Urbit doesn't like to block. It likes to save coherent data
324+structures, not incomplete computation contexts. When Urbit
325+pretends to block for you, this is a courtesy service. You
326+can return the courtesy of not expecting miracles from it.
327+When in doubt, send an actual request.
328+
329+### Requests and subscriptions
330+
331+A true request (local or remote) has access to the same
332+namespace, but can (a) read across case (revision) ranges,
333+and (b) filter by subtree.
334+
335+If the revision range in a request stretches into the future, the
336+request becomes a subscription. Urbit messaging always regards a
337+single response as a special case of a subscription.
338+
339+Generally, the response stream created by a request starts with
340+all the data the server has available right now; updates will
341+follow when they become available; the subscription will be
342+closed when the request range is complete.
343+
344+#### Userspace synchronization
345+
346+Synchronization per se is done in userspace. In `%clay`, sync just
347+means an application (typically the `%kiln` module in the system
348+app `:hood`) subscribes to a remote desk, and saves its change
349+stream locally. So sync is really an emergent feature of `%clay`.
350+
351+### Revision graph
352+
353+`%clay`'s revision graph is completely uninteresting at present.
354+Some changes are proposed below, however.
355+
356+As in any DVCS, a dome is the child of one parent dome (an edit)
357+or more parents (a merge). Often the parent of any revision is
358+the previous version in the sequence, but it can be anything.
359+
360+### Storage model
361+
362+`%clay`'s storage model is completely uninteresting. It's also a
363+little funky and I want to change it, so I'll be super vague.
364+
365+A `++lobe`, a 128-bit atom, is the Merkle hash of a `blob`, which
366+is essentially a leaf. All blobs are stored in a hash table
367+(`(map lobe blob)`), and reference each other through lobes.
368+
369+At present we don't GC this space at all, because we don't
370+actually delete any roots.
371+
372+A `blob` may be `%direct`, meaning it's defined as the data
373+itself, or `%delta`, defined as a change against another blob.
374+This is motivated by the desire not to store a full snapshot
375+on every file change. But it may be misguided (see changes #0
376+and #1 below).
377+
378+We cache the full arch tree (`++ankh`) of the latest state in
379+each desk. For current queries, this mitigates a lot of the
380+opportunities for slowness that this data model creates. But the
381+disparity between the speed of the current version and the
382+speed previous version is an undesirable glitch in the API.
383+
384+## Our motivation for change
385+
386+We actually have _three_ motivations for change...
387+
388+### We need to develop on %clay
389+
390+At present, we're still using `git` as a development platform.
391+`%clay` is certainly used, but just for its strength --
392+deployment. This is starving Urbit of essential experience and
393+basically keeping it lame. So, change is necessary.
394+
395+### Change must come from the community
396+
397+"Why?" you ask? "Why must change come from the community?" Well,
398+one, duh. Change always comes from the community.
399+
400+But two, a great force for change has departed. Philip Monk,
401+late maintainer of `%clay` (`~wictuc-folrex` in the old era,
402+`~wicdev-wisryt` in the new), is tired of types and typing. He
403+spent September roaming with the bison in Montana, and is now
404+literally on his way to Patagonia. On the one hand, Phil still
405+exists and is not at all unwilling to answer questions, even dumb
406+questions. On the other hand, _Patagonia_.
407+
408+So %clay needs a new owner, or owners. At this point, we think
409+the community might be indoctrinated enough to take a stab.
410+
411+Alas, `%clay` already has a pretty checkered ownership history.
412+Long ago I built a `%clay` that was really the only serious
413+design failure in Arvo. Then Jared Hance, a brilliant summer
414+intern, took my broken `%clay` and reformed it into a minimal `git`
415+in about a week. Then Philip modified Jared's `%clay` to be a
416+_typed_ revision-control system, which is a pretty cool thing.
417+
418+But... in none of these transitions did `%clay` actually get
419+_rewritten_ per se. While it's a reasonably good vane, it
420+does contain one or two historical decisions.
421+
422+We know a lot more about Arvo than we used to, and I think we can
423+revisit many of these decisions. The point of this post is to
424+start a `%clay` design discussion that will evolve into actual
425+collective action.
426+
427+### Pioneers may find it worth their time
428+
429+We're planning a rewards program for contributions to `%clay`.
430+It'll simply involve setting a time period and a pool of real
431+estate, and allocating the pool by judged contribution.
432+
433+This is an experimental program. We'll say more about it later.
434+It may not even happen. It may happen very differently. When in
435+doubt, don't talk about Fight Club.
436+
437+## Some openings for change
438+
439+Change, of course, must come from the community. No one can
440+dictate change from the top down. We _know_ this. But...
441+
442+This list of suggested changes for the next `%clay` is not in any
443+sort of order: priority, structure, difficulty, etc. Let's talk
444+about the changes first; make actual plans second. The numbers
445+here are just for convenience.
446+
447+*All changes in this program will happen on the next-generation
448+(`cc-release`) branch.*
449+
450+### Change #0: state reform
451+
452+As mentioned above, the storage model in `%clay`, as the code is
453+at present, feels a little funky to me. There's nothing terribly
454+awful about it, but it doesn't feel quite right and its scaling
455+properties are very questionable.
456+
457+Briefly, `%clay` today actually derives the hierarchy from its
458+leaves -- rather than _logically_ so deriving it. Only leaves
459+are in the object store. This is just weird, and you can feel
460+`%clay` trying to be something other than what it is. (I blame
461+Jared, though it's actually my fault.)
462+
463+To store a dome snapshot (`++yaki`), the present code keeps a
464+`(map path blob)` at the root of the dome. This is enough to
465+reconstruct the `++arch` structures the namespace exports.
466+However, all kinds of basic arch operations, like basically `ls`,
467+become `O(n)` in the number of leaves in the dome. This is
468+obviously not quite right.
469+
470+I believe the storage structure should be (removing everything
471+that isn't needed to serve the namespace):
472+
473+```
474+ ++ clay (pair safe (map term desk))
475+ ++ desk (pair numb (map numb root))
476+ ++ dome (pair date root)
477+ ++ leaf (pair mark noun)
478+ ++ lobe @uvH :: 128-bit base32
479+ ++ numb @ud :: decimal version number
480+ ++ root (pair (unit leaf) (map knot lobe))
481+ ++ safe (map lobe root)
482+```
483+
484+Here a `++root` is the universal node, with children addressed by
485+hash, but logically representing the abstract `++arch`.
486+
487+Users of hierarchical filesystems basically expect performance
488+qualities that match the filesystem structure. A huge directory
489+in one place shouldn't affect search speeds somewhere else. And
490+of course, `ls` can't be O(n) in the size of the filesystem.
491+
492+### Change #1: store edges, cache snapshots
493+
494+The current `%clay` is snapshot-oriented, like `git`. The actual
495+changes are discarded. I think this is a bad choice.
496+
497+`%clay` is not a research project, and has no idea of going as
498+far as `darcs` in the "set-of-patches" direction. However, at
499+present we actually throw away the patch (`++nori`).
500+
501+I think the right DVCS design for `%clay` is a snapshot-oriented
502+system which also keeps the patches. The revision graph has the
503+same general shape as in the old `git` style. But rather than
504+just deriving the diffs from the snapshots, we can also derive
505+the snapshots from the diffs. When in doubt, we save space by
506+dropping the snapshot, not the diff.
507+
508+For an RCS which is also a general-purpose typed filesystem, it's
509+clear that considering edges (deltas, diffs, changes, etc) as the
510+primary state is optimal. You can use diff functions to derive
511+deltas from snapshots, but in many data models this will always
512+risk losing information from the original action. When in
513+doubt, save what the user did.
514+
515+This is even more true for operations on the tree structure, not
516+on individual leaves. Consider the heuristic energy that `git` has
517+to go through to figure out when `mv` has been used -- even when
518+`git mv` has been used! (According to the `git` faq, this is
519+because the lowest common denominator remains Linus' style of
520+working with emailed patches.)
521+
522+Edges probably don't even need to be deduplicated. They also can
523+contain metadata such as commit messages (which `%clay` has no
524+place for at present).
525+
526+Once edges are recognized as unreclaimed primary state, snapshots
527+can always be derived from the edges. So we can reclaim memory
528+being used for snapshots.
529+
530+It's also straightforward to have a kind of edge which is a list
531+of edges, letting us collapse feature branches trivially.
532+
533+Finally, I think references in edges should wherever possible
534+indirect through the namespace, rather than directly to the
535+content address. The user has strictly more information if you
536+say you merged `/~sorreg-namtyv/base/987/`, than if all you have
537+is the hash that this reference refers to.
538+
539+### Change #2: unconfuse merge and rebase
540+
541+The dispute between merge and rebase has all the bad smells of
542+a historical wart. But here I'm just not sure what's right.
543+
544+The user has one _intent_ whether merging or rebasing, which is
545+to combine changes on one desk into another. The _algorithm_
546+used to construct this change, whether operational transformation
547+(rebasing) or a 3-way diff (merging) has one goal: use all
548+available information to model the authors' editing intent as
549+realistically as possible. If we save edges, we should use
550+edges.
551+
552+Whether to define the resulting change graph with the typical
553+structure of a merge, or the typical structure of a rebase,
554+strikes me as quite arbitrary, and well into the land of "pick
555+one and force everyone to stick with it." But this call demands
556+a real expert on RCS workflow, which I'm not.
557+
558+Since `%clay` is a humble part of a larger system and needs to
559+keep its weight down, "do it both ways because people have
560+different preferences" is not usually the right answer.
561+
562+### Change #3: comment jihad
563+
564+`%clay` needs to be brought up to the documentation standards of
565+`%jael`. This means (a) the formatting matches; (b) the comments
566+are at the same level of quality and ubiquity.
567+
568+The basic commenting standards are: (a) every core (class) needs
569+a block comment explanation; (b) every gate (function) needs a
570+line comment; (c) every face (variable) needs a line comment.
571+
572+This is obviously not just a clerical task. To write these
573+comments, you need to actually understand the code. This is a
574+nontrivial but extremely rewarding task, even if the code you're
575+commenting will get replaced.
576+
577+Also, the _symbols_ in `%clay` must be brought up to `%jael`
578+quality. There is still far too much four-letterism here.
579+
580+NB: `%clay` is about 3000 lines of pretty clean Hoon, which is
581+certainly not at all undocumented. We're not exactly looking at
582+a Matterhorn of reverse engineering here.
583+
584+### Change #4: knot to coin internal paths
585+
586+One feature of Urbit paths, briefly mentioned above, is that a
587+path segment or `++knot` (which is just a `@tas` text string, an
588+ASCII symbol as an atom) must be within the range of the
589+invertible noun printer, `++co`.
590+
591+`++co` maps a described data value, a `++coin`, to an ASCII
592+string which is a valid URL segment and Unix filename. Its
593+friend `++so` inverts the function, perfectly.
594+
595+Almost every knot is the simplest kind of `coin`, a `dime.` A
596+dime is a single atom with a rendering type (`aura` if you know
597+Hoon). Auras include `@tas` for symbolic text, `@ud` for
598+unsigned decimal, `@p` for Urbit ship, etc. `++co` can also
599+print arbitrary cells, though less prettily.
600+
601+This feature is cool because it lets us stuff data into names in
602+a precise and predictable way. Usually the names in a namespace
603+are human-meaningful and human-originated, and are therefore
604+symbolic, but there are exceptions. For example, blogposts may
605+want to be named by date.
606+
607+However, it is slightly retarded for the fundamental state of our
608+arches to store the _rendered_ string (`++knot`), not the source
609+data (`++coin`). It leads to all kinds of inefficiencies where
610+we're doing way more parsing than we want to. (Parsing also
611+should be jet-propelled, but is not.) It also makes it way too
612+easy to sneak in bad data and make it `%clay`'s problem.
613+
614+So, logically, we'd be shifting from
615+
616+```
617+ ++ arch (pair (unit (pair mark noun)) (map knot arch))
618+```
619+
620+```
621+ ++ arch (pair (unit (pair mark noun)) (map coin arch))
622+```
623+
624+Also, a vanilla `++map` might not be quite the right data
625+structure at this point -- we probably want a custom sorted tree,
626+which separates auras and imposes a custom order on each. This
627+would let us serve simple range queries quite efficiently, so
628+long as they match the standard aura order (eg, alphabetical
629+order for symbols).
630+
631+### Change #5: dome semantics by reference
632+
633+While the principle that a dome contains its own mark source is
634+elegant, it's a pain in the ass to implement properly. `%clay`
635+certainly does not do it justice at present.
636+
637+The complexity is in checking every change to see whether it
638+includes a change to the mark source (which is very unlikely),
639+or a dependency of the mark source (slightly less unlikely).
640+And if so, do we have to update all the leaves in the dome?
641+This is also very unlikely. And yet, it happens.
642+
643+Instead, we could simply designate, by beak (ship, desk, and
644+case) a dome which contains the canonical mark source. This
645+would rarely change -- you could upgrade a desk to a new mark
646+dome, but it would be a manual operation and probably a rare one.
647+
648+The common case would just be that everyone uses the current
649+version of the `%base` desk when a desk is created, and never
650+changes it. In practice, this means not every two-byte edit
651+needs to get involved in detecting and/or applying schema
652+evolution, a welcome simplification.
653+
654+### Change #6: mark containers
655+
656+Marks in present `%clay` are atomic and symbolic (like `%html`).
657+Since they're also used for network protocols, and the proper
658+design is one mark per message structure, the mark namespace gets
659+overloaded fast.
660+
661+So we added an app hierarchy within the mark namespace, using hep
662+`-` as a divider. The `:talk` app expects messages with the mark
663+`talk-message`, whose sources is in `/===/mar/talk/message`.
664+
665+This helps, but it doesn't solve another two problems: trivial
666+nouns and containers.
667+
668+It's retarded to have to add a source file to send a `@ud` or a
669+`*`. An aura (see above under `coin`) should be a trivial mark.
670+
671+Also, we need to be able to construct standard containers of
672+marks: lists, maps, sets, and tuples (or, as a database person
673+would say, "rows").
674+
675+### Change #7: meta-marks
676+
677+Another kind of complex mark that needs to exist: conflict,
678+difference, and invalid marks.
679+
680+Conflict data and difference data are two types of noun that are
681+generated in normal RCS operation. If we have the concept of an
682+`%html` noun, we also need the concept of an invertible change
683+from one `%html` file to another; a merge conflict between two
684+`%html` files; and even a conflict between two marks.
685+
686+There are two kinds of changes to a dome: manual and automatic.
687+Manual changes are initiated by the user and should crash, unless
688+manually overridden. Automatic changes should not crash, ever,
689+and should not lose data. If they create problems, which they
690+shouldn't, these problems will need to be cleaned up manually.
691+
692+This is a complex space to navigate, but it requires a conflicted
693+merge to be able to resolve to a valid dome containing conflict
694+leaves, not crash. The present `%clay` goes halfway there and
695+resolves to a scratch desk, but we can go farther: the whole `git`
696+dumpster-fire of "merge state" deserves destruction. One change
697+is a merge that produces conflicts, the next is an edit that
698+resolves them.
699+
700+Similarly, all sorts of errors can produce invalid leaves. One
701+particularly rare case which is nonetheless important is schema
702+evolution: what happens to files in a mark, when the mark source
703+code changes. They all need to be re-normalized. And this
704+operation can fail, producing an invalid value. (We don't do any
705+of this now, BTW, although `%ford` has the dependency mechanism to
706+make it possible.) Again, in some cases this should crash the
707+update to the mark source; in other cases, there is no local way
708+to handle the crash.
709+
710+So there must be a way to preserve invalid nouns that can be
711+repaired by repair tools that expect invalid content, while not
712+actually marking them as valid so that innocent code is deluded
713+into using the bad content.
714+
715+The bottom line: a mark needs to be split into two models:
716+`++mark`, the original symbolic mark with its source engine, and
717+something like `++logo`, the meta-mark or mark container. The
718+mark is the building block; the logo is the building.
719+
720+### Change #8: filesystem hierarchy standard
721+
722+While all filesystems remain forks of one ur-filesystem, the
723+standard tends to enforce itself. But not define itself.
724+
725+I've always hated the current `/mar` for marks, for instance. I
726+prefer `/mac`. But others hate this. And so on. Also, by
727+necessity, our nascent "FHS" is heavily biased toward system
728+data, away from user data. This is retarded.
729+
730+Please focus all bikeshedding energy on this problem! Better to
731+bikeshed about what color to paint the bikeshed, then what shape
732+the bike gears should be.
733+
734+### Change #9: security and access control
735+
736+Oh, yeah, that! They always say not to design security in at the
737+last minute. Unfortunately, this is exactly what we did. There
738+is no security at all in present `%clay`. (There is also no push
739+operation in `%clay`, so it's not as mad as you think -- anyone
740+can read anything, no one can write anything, which is fine in a
741+young network where there are no secrets.)
742+
743+Fortunately, we don't have anything super fancy planned in this
744+area, just basic access-control lists. These obviously need to
745+be designed along with the filesystem-hierarchy standard (see
746+elsewhere).
747+
748+Is it even possible to do ACLs properly in `%clay`? At this
749+point, yes. There is an event-oriented security model in Arvo,
750+though it isn't really hooked up to anything at the moment.
751+There is also a privilege badge system in `%jael`. The
752+combination of these two features is quite sufficient for a
753+decent ACL model.
754+
755+The idea of event-based security is that every event passed to
756+`%clay` has a security `++mask`. The mask tells us:
757+
758+- the set of ships that has _contaminated_ this event
759+- the set of ships that has _endorsed_ this event
760+- the set of ships that this event may be _released_ to.
761+
762+To simplify this system a little and maybe explain it, the
763+security question in any event is: (a) who has _caused_ this
764+event? (b) who may receive its _effects_? (These sets never
765+include your urbit itself, of course, only neighbors.)
766+
767+For example, if we're doing something because ship X sent us a
768+packet, and we're going to leak the results of this something
769+back in a response to ship X, once `%clay` knows what our ship
770+thinks of its neighbor X, we should have a good picture of what
771+effects this event should be allowed to cause. If `%jael` knows
772+that X is our friend, `%clay` can know that X can see our cat
773+picture.
774+
775+Causality is separated out into contamination (data from ship X
776+got into the event) and endorsement (ship X signed the whole
777+event). (This may be overdesign.) All these sets can be defined
778+as the empty set (eg, releasing to the empty set means no output)
779+or the universal set (input from the universal set could be from
780+anyone, ie, is unauthenticated).
781+
782+### Change #10: stop using mark-extended paths
783+
784+When you read a leaf from a `%clay` dome, `%clay` is happy to
785+perform any necessary mark conversions (the actual work is done
786+by the `%ford` build vane). You can also just ask for the leaf
787+in whatever mark `%clay` has it.
788+
789+It's confusing to think of this mark extension as part of the
790+path. You shouldn't say `+cat /===/app/talk/hoon`. You should say
791+`+cat /===/app/talk`, or maybe `+cat %hoon /===/app/talk`.
792+
793+A mark-extended namespace may be added to `%ford`, to compensate.
794+But type-converting reads are the rare case, not the common case.
795+
796+### Change #11: real queries and indexes
797+
798+A filesystem should postpone being a database until it can no
799+longer do so. So, please don't think about this problem yet.
800+I'm joking, of course!
801+
802+### Change #12: meta-query
803+
804+Make it possible to query the list of desks in a ship :-)
805+
806+### Change #13: completely redesign Unix mounting
807+
808+This is actually a series of changes, described below. But
809+broadly...
810+
811+One of Urbit's experiments is live two-way synchronization
812+between the Unix filesystem and the revision-control store.
813+Dropbox style, as it were. I think this experiment is basically
814+a failure. It may be right for cat pictures, but I don't think
815+it's right for Urbit.
816+
817+The fundamental problem is that there are all sorts of weird,
818+flaky ways applications use a mutable filesystem. It's not at
819+all unusual for an editor to change a file by deleting the old
820+file, then writing the new one in its place.
821+
822+You really don't want this to produce a delete change. A simple
823+cooldown timer for the sync helps a lot with this, but causes
824+other weirdnesses. In theory, a sync can even cause another
825+change to the same version of the same desk. And so on.
826+
827+The thing we fear is just too funky to work (there is some
828+strange "reflux bug" still affecting it) is any sort of _two-way_
829+synchronization between Unix and Urbit.
830+
831+And what I think puts this feature into the deadpool, or at least
832+cold storage, is that there's no useful workflow that actually
833+uses it -- at least, when editing Urbit code.
834+
835+It's actually really nice to have files on a disk that nothing
836+will automatically modify. If you're using `git` and `%clay` in
837+parallel, it's nice to mount your `git` working directory. The
838+original Urbit workflow was to work out of a mounted directory,
839+but the two-way updates were just too weird and scary, so now we
840+tend to edit elsewhere and copy in -- which is lame.
841+
842+### Change #14: figure out what to do with FUSE
843+
844+We actually have two forms of filesystem access to `%clay`: read-only
845+FUSE (in a somewhat experimental state), and filesystem watching
846+(using `inotify()` and `FSEvents` under a `libuv` wrapper).
847+
848+The FUSE interface is a good one, though it needs more work.
849+Moreover, it exports the whole Urbit namespace to Unix, not just
850+`%clay`. For reading Urbit data, FUSE is basically ideal.
851+
852+The obvious impulse is to make a read-write FUSE. But I don't
853+think FUSE should be used for recording changes to an RCS, even
854+though the FUSE API sends you changes as events.
855+
856+There are three reasons for this. One, the actual filesystem
857+writes that Unix apps make are typically of low quality and
858+confusing. Some crack-brained editor will find it completely
859+normal and unremarkable to modify a byte in a file, by deleting
860+the file and rewriting it from scratch. You can use a cooldown
861+timer to wait for this nonsense to converge, but leaving data in
862+heuristic limbo seems like a very bad idea in FUSE-land.
863+
864+The second is that people derive a lot of comfort from seeing
865+actual files on an actual disk. The idea that your datas are
866+stuck in Urbit is slightly terrifying as a user experience.
867+We claim to be reliable. It's actually hard to imagine datas that
868+couldn't be recovered from either snapshot or log. But how can
869+you possibly believe us on this?
870+
871+So I think it's correct to lean all the weight of reading data
872+from Urbit on FUSE, and use filesystem watching for writing.
873+Heuristic timeouts are fine in filesystem watching, because at
874+least the data got written when the disk says it got written.
875+And at least it's on the disk.
876+
877+Also, FUSE is a daemon by definition, which forces us to think a
878+little harder about how to run the Urbit process as a daemon.
879+But this is a separate discussion.
880+
881+### Change #15: one-way, nonced working desk
882+
883+A one-way mount is a much less crazy thing. It works the same
884+way our two-way mount works today, but with only one writer: the
885+user, via Unix.
886+
887+Since a mount is one-way, it needs to have an absolute write lock
888+on the desk it's writing to. We cannot have a `%home` desk which
889+we are also editing with filesystem watching.
890+
891+Instead, we have a temporary and anonymous state that's connected
892+itself with your `%home` desk. Desk names have to be valid
893+symbols, but we can use `hep`, `-`. A reasonable choice is to
894+pick a random 32-bit name for each mount instance -- so the desk
895+name is not `%home`, but `%home-bosdut-sigder`. (Randomizing
896+instead of always using a fixed suffix, say, `%home-work`,
897+just makes all kinds of screwups less likely.)
898+
899+You create a mount simply by mkdiring the desk name in your pier.
900+Just the base name, Urbit will come up with the `%bosdut-sigder`
901+part and put it in a `.desk` file at the desk root. To forget
902+the mount, just delete this file. This avoids the ugly confusion
903+between unmounting a mount, and deleting all the data in it.
904+
905+(Urbit will keep a set of the mount desks it's used and
906+forgotten, not reuse them, and block all requests into them. By
907+blocking, we can delete without losing referential transparency.
908+Yes, Virginia, Urbit can forget!)
909+
910+Note that the auto-reload behavior of applications is extremely
911+useful when testing. When testing, you can either switch the
912+active application desk from `%home` to `%home-bosdut-sigder`,
913+or activate autosync from the latter to the former.
914+
915+### Change #16: commands as metafiles
916+
917+A new idea I'd like to play with is that, since the basic model
918+of the mount process is to read Unix files and suck their
919+contents into Urbit, you should be able to control a mounted
920+`%clay` desk through Unix filesystem operations alone.
921+
922+No Urbit command-line access, not even any `urb/` HTTP control
923+channels, should be required for the user to generate `%clay` data
924+through filesystem mount, or to set up the mount.
925+
926+An RCS experience that works entirely through Unix tools, in
927+which the only connection between content creation tools and
928+revision-control tools is shared access to the filesystem itself,
929+is essential if your RCS has something so repulsive as a daemon.
930+Otherwise, you're basically, like, reinventing Perforce.
931+
932+More concretely, the Urbit experience today requires `:hood`
933+pokes (Urbit shell commands, basically) for all nontrivial RCS
934+operations, from mounting to merging. Again, there are lots of
935+situations in which you can write into a mounted filesystem (the
936+protocol for Unix communication could be easily adapted to
937+communicate with a browser-based editor, for instance), but you
938+don't want the user to have to bother with an Urbit shell.
939+
940+Even commands like mounting and merging are easily communicated,
941+through filesystem writes that any Unix tool (including many
942+macro editors).
943+
944+This is very easy for a filesystem watcher. One such protocol:
945+if you want to send the daemon a command relative to some
946+directory, write a `.ur-command` metafile in that directory. The
947+daemon accepts the command by deleting it.
948+
949+The user experience is that you configure your mounts by simply
950+making the directories and configuring dotfiles in them. Unlike
951+in the present system, Urbit will never modify your datas
952+silently in the background.
953+
954+Here's what this looks like:
955+
956+Suppose you want to edit some data in the `%home` desk. Your
957+data is in `/=home=/mar/talk`. You also want a read-only view
958+of `/=home=/arvo`.
959+
960+From Unix, you do something like this:
961+
962+```
963+ $ cd $pier
964+ $ mkdir -p home/mar/talk
965+ $ touch home/mar/talk/.edit
966+ $ mkdir home/arvo
967+ $ touch home/arvo/.read
968+```
969+
970+Want to commit your changes? That means merging the working
971+desk, `%home-bosdut-sigder`, into the `%home`. Put a commit message
972+into `home/.commit` and it'll happen. If there's an error, it
973+will appear as `.error`.
974+
975+The mount has a .version file which simply contains the change
976+number (of the working desk) which any edits are relative to. If
977+the urbit daemon is running and watching, edits will be absorbed
978+quickly (probably after a heuristic timeout), and the version
979+incremented. But we always are confident that the edits are
980+against the latest version, or at least we can use this as a
981+sanity check. All kinds of insane things can happen to get a
982+filesystem out of consistency.
983+
984+This design obviously needs a little fleshing out, but I'm quite
985+confident it's a convenient and reliable way to drive `%clay`
986+from Unix.
987+
988+## In conclusion
989+
990+There's obviously a lot of fun here! There are two things you
991+can do right now.
992+
993+One, talk about `%clay` on [this forum
994+thread](http://urbit.org/~~/fora/posts/~2016.10.25..17.37.47..6937~/) or
995+on [:talk](http://urbit.org/stream). Both hosted on Urbit
996+itself!
997+
998+Two, poke around the
999+[code](https://github.com/urbit/arvo/blob/cc-release/arvo/clay.hoon).
1000+Make sure you're on the development branch (`cc-release`).
1001+
1002+Phasing in this work will be a fun and interesting challenge.
1003+(My suspicion is that the right first task is the Unix mount.)
1004+Let's talk...
content/posts/urbit-and-the-blockchain.mdnew file+264
@@ -0,0 +1,264 @@
1++++
2+title = "Urbit and the Blockchain Wars"
3+date = 2017-09-25
4+author = "Curtis Yarvin"
5+description = "A bit about the 'idea maze' of choosing to bootstrap from Ethereum"
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-1.jpg)
10+
11+One core principle of the Urbit network is that *Urbit doesn't take sides*.
12+This is true in all kinds of conflicts -- and especially blockchain wars.
13+
14+We're [moving the Urbit PKI onto Ethereum](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/)
15+not because we like Ethereum, but because it's the most practical thing for
16+Urbit right now. This is not a moral or aesthetic choice.
17+
18+Some have objected to this decision. Some of these objections are excellent.
19+The rest are understandable.
20+
21+Let's review our decision, responding to objections along the way. Not everyone
22+has to agree on everything. No one should stay confused. And we welcome
23+further comment.
24+
25+## Urbit is not endorsing or supporting Ethereum
26+
27+There are many technical criticisms of Ethereum. We agree with many of these
28+criticisms -- even most. But still more important: Bitcoin is the strongest
29+chain. If Bitcoin could directly enforce Urbit's PKI rules, we'd use Bitcoin,
30+for this reason alone. (That said, Ethereum may be less exposed to Chinese
31+politics.)
32+
33+We chose ETH because it is the strongest *computational* chain. It is certainly
34+stronger than the way we're storing the Urbit land registry now: Github, plus
35+internal records.
36+
37+Urbit is not endorsing Ethereum. Urbit is not creating any appreciable monetary
38+demand for Ethereum. Urbit is not even locked in to Ethereum: with a fully
39+self-governing constitution, the Urbit galaxies can decide to migrate to another
40+consensus engine, or no consensus engine, or even our own consensus engine, any
41+time we like.
42+
43+And even if the whole Ethereum network unexpectedly implodes, and stops
44+generating meaningful new blocks, we (or more generally: the set of active
45+Urbit galaxies) cannot abandon the social power to manually hard-fork the
46+network. Ultimately, the Ethereum contract is just a hardcoded address in a
47+piece of Urbit source code.
48+
49+Let's address each of these points at a little more length.
50+
51+## On moving to a blockchain
52+
53+The first point to remember: our choice wasn't between Ethereum and nothing. It
54+wasn't between a blockchain and nothing. It was a choice between 21st-century
55+tools and 20th-century tools.
56+
57+The current Urbit land registry is divided into parts stored in various places:
58+Github commits, database records held by Tlon Corporation, and insecure keys on
59+a test network. This might have been fine, for us, in 2015. In 2017, it's
60+borderline unacceptable.
61+
62+## On choosing a chain
63+
64+Our first decision point: whether the public chain enforces the rules of Urbit,
65+or just logs raw data that anyone can interpret.
66+
67+The simplest procedure, with the strongest blockchain, would be just to encode
68+each Urbit event as raw (OP_RETURN) data on the Bitcoin blockchain. Or we could
69+use another simple layer on top of Bitcoin; classic "colored coins," for
70+instance.
71+
72+The resemblance between Urbit land-registry titles and colored coins is one we
73+noticed a long time ago, of course. For a long time it wasn't that relevant,
74+because colored coins remained largely theoretical.
75+
76+The larger problem is just that a non-computational blockchain can't enforce the
77+specific rules of the Urbit land registry (like the right of a star to create
78+specific planets).
79+
80+You can put arbitrary data into a blockchain and enforce it off-chain. This
81+strikes us as unsatisfactory, though. For instance, you have to define the
82+semantics of erroneous or malformed operations. If this is not done perfectly,
83+it's a short road to major weirdness. Also, your interpretation tools are a
84+special-purpose one-off not shared with anyone.
85+
86+There are other second-order "virtualchains" (Blockstack is one example), which
87+build computation layers on top of arbitrary chains. These tools are interesting
88+and cool. They are also quite young. As is Urbit, so we need all the maturity
89+we can get.
90+
91+Also, our use case, as a land registry, is quite simple -- we don't have any
92+desire to pay (in complexity) for power we don't use. A two-layer solution
93+just seems to leave more room for bad weirdness.
94+
95+## As normal Urbit state?
96+
97+The original design was for Urbit to host its own primary copy of the PKI state,
98+not mirror some external master.
99+
100+As more people start believing in Urbit, this makes us extremely nervous. Being
101+the single source of truth implies a strong commitment to security and
102+continuity. Urbit needs to get there, but it isn't there yet.
103+
104+Trust in the security, continuity, and general maturity of Urbit needs to
105+develop gradually. An Urbit that isn't ready to store crypto-assets can still
106+be a great product. But it can't be a great product if its supposedly valuable
107+keys are in fact insecure, yet needed to operate on the network.
108+
109+In short: we can't follow this original plan. It has the same chicken-egg
110+problem we discussed [last time](https://urbit.org/blog/2017.9.20-bootstrapping-urbit-from-ethereum/).
111+
112+## An Urbit consensus engine?
113+
114+Urbit is itself a deterministic computer. Building a consensus computer within
115+Urbit, which is actually a general-purpose OS, is an attractive long-term
116+possibility.
117+
118+But Urbit lacks the principal feature of Ethereum: deterministic performance.
119+In both Ethereum and Urbit, the semantics of a computation are precisely
120+defined. In Ethereum, the computation's cost is also precisely defined.
121+
122+This would be quite hard to do in Urbit. We traded deterministic performance
123+off for semantic simplicity. Designing a consensus computer without a
124+performance definition is a research problem.
125+
126+We have solved a number of research problems here at Urbit. Could we build an
127+Urbit blockchain? This problem doesn't seem utterly intractable. For instance,
128+we could leverage the semi-trusted hierarchy in some direction resembling proof
129+of stake.
130+
131+One thing is certain, though: research problems don't solve themselves
132+overnight. If you have any ideas on this one, give us a holler.
133+
134+In any case, if Urbit got its own consensus engine, it's obvious that we'd
135+simply copy the state of the Urbit PKI on Ethereum, and shut it down. Or we
136+could migrate to another computational blockchain which works better than
137+Ethereum.
138+
139+## An existing computational blockchain
140+
141+So we need an existing, mature, computational blockchain. There are only two
142+major candidates: ETH and ETC (Ethereum Classic).
143+
144+It's no secret that we prefer the governance model of ETC. It's also no secret
145+that the whole Ethereum system, especially Solidity, isn't exactly put together
146+in the way we would do it.
147+
148+But an optimal governance model is just one virtue among many others we need to
149+consider. ETH's network capitalization is 25x that of ETC. Its hashrate is 15x.
150+Its tooling support -- in software, hardware, vaulting, exchanging, etc -- is
151+considerably stronger.
152+
153+ETC's governance model is Bitcoin's: code is law. For the network, this is
154+better. But we are considering threats to Urbit, not threats to the rest of
155+Ethereum.
156+
157+ETH has embraced discretionary human governance. It's quite plausible that this
158+will lead to total political collapse. But the human political structure of ETH
159+seems reasonably strong at the moment. It's relatively difficult to imagine
160+successful, near-term "proof of Vitalik" attacks via Ethereum on Urbit. Political
161+conflict tends to develop over longer periods of time, giving us room to migrate.
162+
163+Ultimately we decided that the minority power of ETC outweighs the governance
164+issues with ETH. This is of course how imperfect standards win. Betamax had
165+better resolution than VHS.
166+
167+## One reminder
168+
169+For Bitcoin maximalists in particular (some of our best friends are Bitcoin
170+maximalists), it's important to note that (besides the gas price of
171+transactions) putting Urbit on Ethereum *does not create any net monetary demand
172+for Ethereum*.
173+
174+Yes, you will get an Urbit ship through an Ethereum transaction. However, no
175+value stays in ether. If you want to buy a ship with bitcoin, you are just
176+going through a conversion layer. These conversion layers work pretty well
177+these days. If you have a religious objection to handling altcoins, have a
178+friend help.
179+
180+Bitcoin maximalists understand that all monetary energy should concentrate in a
181+single currency. But land isn't money. And the technical details of the
182+implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or Github
183+-- have no effect on Bitcoin supply and demand.
184+
185+## Another reminder
186+
187+Ethereum is not using Urbit. Urbit is using Ethereum. We know every cool
188+alternative band that gets signed to a major label says this, but we mean it.
189+
190+Urbit, as a land registry, is almost a textbook example of very weak, boring use
191+of a computational blockchain. We're not expecting a lot out of Ethereum.
192+Ethereum does not feel like a system whose technical envelope should be pushed.
193+We have no intention of pushing it.
194+
195+Moreover, the ability to vote formally in an Ethereum constitution will allow us
196+to migrate in a cohesive way to *any other formalization of the Urbit PKI*.
197+This could be another Ethereum contract. Or another blockchain.
198+
199+This "clean escape" implies that Ethereum is still operating normally, or at
200+least normally enough to conduct a galaxy vote. What could happen to Ethereum?
201+The blockchain could stop generating new blocks; it could fork; it could be
202+filtered by some kind of collective attacker; it could even start accepting invalid transactions. What seems implausible is destruction of all copies of the whole chain.
203+
204+When Ethereum ceases to be functional or trustworthy for any reason, a "dirty
205+escape" becomes necessary. The galaxy operators need to identify the last point
206+in the Ethereum chain at which the Urbit constitution remains valid, copy that
207+data to the new primary record, and resume from there.
208+
209+But unlike other blockchains that have wrestled with human-centric governance,
210+Urbit still has a formal procedure for making this decision. With the Ethereum
211+chain compromised, we no longer have an automated system that implements the
212+rules. The rules remain, though. Humans have spent thousands of years
213+following non-automated rules.
214+
215+Basically, we're just using ETH as a self-validating ownership record. So long
216+as the chain isn't destroyed and owners retain their secrets, Urbit retains the
217+power to migrate to any record that works better.
218+
219+## And one literally constructive criticism
220+
221+One excellent criticism (credited to `@sorpaas`) is that just having the Urbit
222+galaxies mirror the state of Urbit's Ethereum constitution is insufficient.
223+This design gives Urbit nodes a choice: either mirror the whole Ethereum
224+blockchain (which is ginormous and certainly not shrinking), or don't validate
225+the Urbit PKI at all.
226+
227+In Urbit, if your parent galaxy is sending you fraudulent reports about the
228+blockchain (any blockchain), you have a very serious problem which goes way
229+past blockchains. It's time to switch galaxies.
230+
231+The trust relationship between an urbit and its parent is like the trust
232+relationship between you and a gas station. For all you know, what's coming
233+out of the hose could be Welch's grape juice. But why have you never, ever worried about cheap surplus vegetable products destroying your engine?
234+
235+ExxonMobil has no business motivation to ruin its customers' engines. If it
236+did, it would just destroy its business, and gain… what? If you don't have an
237+attack motivation, you don't have a threat model. If you don't have a threat
238+model, you don't have a threat. This is why we don't tend to worry about
239+"parent attacks" in Urbit.
240+
241+But that said: there's no reason not to make Urbit's cryptographic structure as
242+strong as possible. If you don't want to trust your gas station -- you
243+shouldn't have to. We don't need to eliminate reliance on trust. We do prefer
244+to *minimize* it.
245+
246+Therefore, the Urbit Ethereum mirror needs to track all the Ethereum
247+transactions that touch the Urbit constitution, and propagate these raw
248+transactions into Urbit. Urbit nodes can check the transactions and their
249+signatures themselves, without relying on Ethereum. Then, anyone in Urbit can
250+validate the Urbit PKI without an Ethereum node.
251+
252+(We don't anticipate running a node *in* Urbit, eg an EVM in Hoon -- for now,
253+galaxies will just RPC to a local Unix node.)
254+
255+## And in closing
256+
257+We appreciate everyone's feedback and hope no one remains confused.
258+
259+We're happy to address any remaining concerns -- and happier still if someone
260+finds a mistake on our end. If you have a good counterargument, now is better
261+than later!
262+
263+Fora thread for discussion is here:
264+[urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~](https://urbit.org/fora/posts/~2017.9.25..20.34.38..8e27~).
content/posts/urbit-and-the-not-so-dark-future-of-the-internet.udonnew file+9
@@ -0,0 +1,9 @@
1++++
2+title = "Urbit and the Not-So-Dark Future of the Internet"
3+date = 2017-04-12
4+author = "Tlon"
5+description = "Isaac Simpson's high-level introduction to Urbit."
6+[taxonomies]
7+posts = ["Media"]
8++++
9+[Urbit and the Not-So-Dark Future of the Internet](https://medium.com/vandal-press/urbit-and-the-not-so-dark-future-of-the-internet-400c9b667e2)
content/posts/what-is-urbit-for.mdnew file+189
@@ -0,0 +1,189 @@
1++++
2+title = "What is Urbit For?"
3+date = 2016-05-11
4+author = "Galen Wolfe-Pauly"
5+description = "A vision of the Urbit-powered future."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-1.jpg)
10+
11+Open platforms don't beat closed systems just because they're open.
12+They win because you can do more exciting things with them. We
13+believe we're overdue for new infrastructure not purely on principle:
14+but because we think you can build better products on top.
15+
16+We look forward to a future where your fleet of Urbits run the devices
17+throughout your house, keep your biometric data in sync with the data
18+center and hold your secure medical and financial data. Today Urbit
19+is just a proof of concept — but we see a road from here to there.
20+
21+## Today
22+
23+These are things that work but are under development today. We expect
24+them to improve and stabilize in the coming months.
25+
26+### Making the web programmable
27+
28+The first thing your Urbit can do is act as a transparent layer to
29+your existing services. We'd like urbit to be usable as a self-hosted
30+IFTTT for geeks. Your urbit can hold your keys, store data, run
31+programs and seamlessly connect to your existing services. Plus, with
32+a global revision controlled filesystem it's easy to share API
33+connectors and keep them up to date.
34+
35+With an Urbit running on your machine you can `ls` your Gmail from
36+Unix. Write a short script to poll Twitter on a keyword and deliver
37+the results to your email or into a Slack channel. Send an SMS when
38+an HTTP request doesn't resolve. These are just a few examples. Your
39+Urbit is designed to make data trapped in your existing services feel
40+like an extension of your local programming environment.
41+
42+### Self-hosted publishing and communication
43+
44+Additionally your Urbit is a flexible platform for publishing data to
45+the web and communicating with others. Sort of like a self-hosted
46+Slack, WordPress and Wiki in one. It's more common to use many tools
47+for sharing our content and communicating. Urbit is designed to bring
48+those tools together; giving the individual control over their
49+creative output.
50+
51+Simply write markdown in your favorite editor and have an Urbit sync
52+them to the cloud. Use React components to control your layout and
53+extend our toolset. Host your own discussion channels and comment
54+threads. On a computer you own and control, whose source is 100%
55+open.
56+
57+### Cryptographic identity
58+
59+Your Urbit is your digital identity, cryptographically secured but not
60+controlled by any central authority. The Urbit PKI fills a gap that
61+remains unsolved on the web. We can send encrypted messages, securely
62+exchange digital currency, but how do I know who anyone is?
63+
64+Your Urbit can post public proof to your third party services and its
65+validity is easily auditable. Using Urbit as an identity scheme for
66+new services would be a great decentralized alternative to 'Sign in
67+with [company x]'.
68+
69+## Tomorrow
70+
71+Urbit's crypto isn't tested, the network still gets rebooted from time
72+to time. The next milestone comes when Urbit matures to the point
73+that it's as reliable as its SaaS counterparts.
74+
75+### Lifestreams, finally
76+
77+The combination of great API tools and great publishing tools means we
78+can finally build an integrated interface for today's social networks.
79+The web is full of streams of data. For the user there's not much
80+utility in bouncing from service to service. Instead, it'd be great
81+to have general-purpose tools for consuming and publishing data.
82+Imagine a Medium-quality interface that makes no distinction between
83+Facebook and Twitter; SMS and Skype.
84+
85+### Secret storage, web3
86+
87+Bitcoin and Ethereum are both part of a new era of decentralized
88+infrastructure that's just beginning. For the blockchain to realize
89+its potential individuals need ought to have a way to host their own
90+nodes. At the very least, individuals need a reliable place to keep
91+their secrets. What's more, the blockchain isn't designed for
92+computation. It's great for contracts and currency, but too slow for
93+practical computing.
94+
95+Urbit is a great complement to the blockchain. Your Urbit can safely
96+store your keys, providing an always-available keychain on the
97+network. Even better, your Urbit can hold your blockchain assets and
98+provide an off-chain computation layer. Urbit's computation doesn't
99+provide any kind of distributed consensus, but our computation model
100+is very simple and lends itself well to auditing. This makes it a
101+very blockchain-friendly platform.
102+
103+## Over the horizon
104+
105+If there's one thing we know from the history of personal computers
106+it's that computers are always expanding into more and more of our
107+lives. The more _personal_ our computers get the more they need to
108+reflect our thinking and our relationships. We don't know exactly
109+what this will look like, but we can certainly speculate on the areas
110+that deserve the most attention.
111+
112+### Data permanence and software competition
113+
114+Right now applications and data are practically the same thing.
115+There's no practical way for the user to separate them. Apps come and
116+go, either by falling out of fashion or actually shutting down. In
117+both cases our data becomes orphaned. There's no practical way for us
118+to get it back. The raw data from your LiveJournal is as good as a
119+floppy disk from the 80s. Computers hold the records of our lives.
120+Losing the history of the world to bitrot is a preventable problem.
121+
122+Since each person owns their own Urbit there's no way to separate the
123+user from their data. When you run software on your Urbit you
124+_actually run it_ and your programs manipulate data that _you own_.
125+The individual has permanent access to their data by design. Ensuring
126+its durability is a technical problem, not a license agreement
127+problem.
128+
129+When individuals are running their own software it's no longer
130+possible to lock them in by controlling their data. Instead, software
131+has to actually compete on utility. If one could trivially replace
132+the interface for Evernote with one from another developer for $10
133+wouldn't it be worth it? Even more so with Urbit, since after
134+installing software you're not dependent on the developer staying
135+alive. You're running a local copy. This model puts pressure on
136+applications to interoperate better and become more modular.
137+
138+### Reputation
139+
140+With a working identity system it's possible to build up contextual
141+reputation systems that aren't held hostage by their applications.
142+Just like the marriage of applications and data, reputation is
143+permanently tethered to and jealously guarded by the services we use.
144+
145+For example, today we have karma systems on a per-site basis, like
146+Reddit. Is there any reason that individuals shouldn't have karma
147+scores per-topic? An individual's authority on a certain topic could
148+be verified by other experts while still denied by detractors. It's
149+easy to extend this to services like Yelp. With a strong identity
150+system it's possible for pseudonymous reviews to be counted with real
151+value. We'd no longer need a central authority for deciding on the
152+reputation of a restaurant, but just a way to pseudonymously aggregate
153+individual opinions. There's a broad swath of territory ripe for
154+exploration here.
155+
156+### Privacy
157+
158+With a reliably secure place to store your data on the network,
159+wouldn't you want to store even more personal information yourself?
160+Why is it that we don't store our own medical records, biometric data
161+or financial data? In a world where we have a safe place to keep them
162+we wouldn't require anyone else to keep them for us.
163+
164+Furthermore, we'd be able to share them pseudonymously. One could
165+imagine medical research or census-like polling being done without
166+compromising the privacy of those involved. This also lowers the
167+barrier to entry for fintech and medical software developers. If I
168+can run my own personal health and finance software that can reliably
169+access my own transactions and medical records, what would developers
170+come up with?
171+
172+### IoT
173+
174+What needs a network _and_ computation? Devices. Turning a unix box
175+into a usable platform for hardware isn't something that any
176+individual manufacturer is incentivized to do. For the internet of
177+things to actually work we need a platform for devices to interoperate
178+simply and securely. Urbit is up to the task. Your Urbit isn't just
179+a single instance, it can sign the keys for a whole network of Urbits
180+intended to be used for your devices, sensors, appliances, machines,
181+robots, VR helmet, etc.
182+
183+The future of the individual's computing experience may very likely be
184+among many different devices. Bret Victor's 'Seeing Spaces' is a
185+great exploration of what this future may look like. For the
186+industrial enterprise there's a whole other set of parallel problems:
187+tracking inventory, controlling a vast array of machines, and managing
188+logistics. In both cases we need a decentralized network and
189+computing platform. Urbit is up to the task.
content/posts/why-urbit-probably-does-not-need-a-blockchain.mdnew file+615
@@ -0,0 +1,615 @@
1++++
2+title = "Why Urbit Probably Doesn't Need a Blockchain"
3+date = 2016-07-14
4+author = "Curtis Yarvin"
5+description = "Urbit (probably) doesn't need a blockchain, because the Urbit address-space PKI is a special case of a consensus ledger."
6+[taxonomies]
7+posts = ["Essays"]
8++++
9+![](http://media.urbit.org/site/blog-1.jpg)
10+
11+TLDR: Urbit (probably) doesn't need a blockchain, because the Urbit
12+address-space PKI is a special case of a consensus ledger (itself a
13+special case of Byzantine agreement).
14+
15+Special cases are often easier to solve than general problems. The
16+"New Jersey" or "worse-is-better" school of systems design emphasizes
17+solving any problem with the weakest possible tools.
18+
19+## The worse-is-better school
20+
21+Culturally, Urbit is best described as a functional stack built in the
22+"New Jersey" school of system software design, as described in Richard
23+Gabriel's famous
24+["worse is better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.
25+
26+There are two kinds of mindsets when approaching hard technical
27+problems. The "MIT" mindset, more typical among mathematicians and
28+scientists, wants to attack the problem as its simplest and broadest
29+case, producing the most general and powerful solution available. In
30+short: better-is-better.
31+
32+The "New Jersey" worse-is-better mentality, more typical among
33+programmers and engineers, wants to do everything possible to _not_
34+attack the problem. Can I produce a serviceable approximation to a
35+true solution? Do I actually have to solve the general problem, or
36+can I reduce it to an easier special case? Can I change the product
37+so it doesn't have this problem?
38+
39+Ideally, anyone building anything has both these mindsets in their
40+toolbox. But it's worth noting that (a) Jersey designs (meaning the
41+Bell Labs school that produced Unix, C, and Go) tend to beat MIT
42+designs in the marketplace, and (b) there are very few pure-functional
43+systems built with the true Jersey spirit.
44+
45+## Why Urbit (probably) doesn't need a blockchain
46+
47+Nakamoto consensus is an example of better-is-better. The blockchain
48+design is actually more powerful than it needs to be. It's not just a
49+trustless decentralized ledger; it's a trustless decentralized
50+database and (as Ethereum has realized; but this idea is clearly
51+present in Bitcoin's scripting language) a general-purpose, zero-trust
52+decentralized computer.
53+
54+Again, Urbit is not a general-purpose decentralized database or
55+consensus computer. It's a special case of the former, which is a
56+special case of the latter. Urbit is nothing but a digital title
57+chain for network addresses. Our belief is that the special case is
58+much easier than the general case, which is why Urbit (probably)
59+doesn't need a blockchain.
60+
61+The rest of this essay describes what makes this special case special,
62+and how we can use that to not need full Nakamoto consensus, or any
63+kind of general-purpose Byzantine agreement.
64+
65+## The double-sell problem
66+
67+Urbit has the same basic "double-spend" issue as Bitcoin. As Satoshi
68+puts it: "The problem of course is the payee can't verify that one of
69+the owners did not double-spend the coin." But Urbit is not a
70+currency, so we say "double-selling."
71+
72+"Double-selling" means signing over an Urbit address (_ship_) to two
73+different parties at the same time, presumably with the intent to sell
74+it to both and skip town with the loot.
75+
76+Again, the logical problem is the same. Bitcoin attacks it as a broad
77+theoretical breakthrough: better-is-better. Urbit attacks it as a
78+narrow special case: worse-is-better.
79+
80+Intuitively, Urbit's answer is that a real-estate transaction is
81+substantively a very different thing from a credit-card payment. No
82+real-estate agent ever has ever leaned over the desk, quickly grabbed
83+_both_ the check and the keys, and run laughing out the door.
84+
85+To understand more rigorously how Urbit is a special case, let's take
86+a quick look at the Urbit address space and PKI.
87+
88+## The Urbit address space and PKI
89+
90+(NB: this description differs in minor ways from the running code.
91+Where they differ, the description is right. Urbit is not at present
92+secure: use for entertainment purpose only.)
93+
94+An Urbit ship is an unsigned integer that serves four purposes: a
95+cryptographic identity, a packet routing address, a stateful virtual
96+computer, and a unique, human-memorable name.
97+
98+Each ship is owned by a private key. To transfer a ship to a new
99+keypair, sign the new public key with the old private key. This
100+revokes the old key and activates the new key. Propagating this
101+update globally makes the revocation global. This is essentially the
102+digital title system a smart 12-year-old would design.
103+
104+### Ships and wills
105+
106+Ships are 128-bit numbers classified into tiers by bitwidth. An 8-bit
107+ship (a number less than 256) is a _galaxy_. A 16-bit ship is a
108+_star_. A 32-bit ship is a _planet_. A 64-bit ship is a _moon_. A
109+128-bit ship is a _comet_.
110+
111+The chain of signatures for each ship is called a _will_. Unlike most
112+certificate systems, there is no metadata in an Urbit will. Nothing is
113+signed but the public-key fingerprint. The length of the will is the
114+keypair version that owns the ship. This version is called its
115+_life_. Each new signed fingerprint in the will is a _deed_.
116+
117+Who gets to create a ship? Comets are fingerprints of a random
118+keypair. Moons, planets and stars are created by their _prefix_, the
119+ship whose bits are the bottom half of their formal width. For
120+instance, the star `0xbeef` is the prefix of the planet `0xdeadbeef`.
121+Galaxies have their fingerprints hardcoded in the official kernel.
122+
123+Ship numbers are not generally written in hex. They're written in
124+Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes within
125+tiers, to superficially conceal prefix structure; for instance,
126+`0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef` is
127+`~nissep-sopnub`.
128+
129+### Parent hierarchy
130+
131+The prefix of a moon, planet, or star also becomes its _parent_. The
132+parent of a ship is its natural locus of federated services. The most
133+basic such service is to mediate P2P routing, as a so-called
134+"supernode." But the set of potential federated services is
135+unbounded.
136+
137+For moons, each new key update is signed by the parent. Planets and
138+stars sign their own updates, making them independent. To prevent
139+denial-of-service attacks by parents against children, stars and
140+planets can _exit_, choosing a new parent. An exit deed is a key
141+update also signed by the new parent.
142+
143+The full public cryptographic record of a ship is its _dossier_. The
144+dossier is the set of ship-will pairs, including all parents and
145+prefixes recursively, needed to validate the ship's current key. A
146+ship can process a dossier from an untrusted source.
147+
148+The full set of ship-will pairs a ship knows is its _cabinet_. So the
149+crucial question for PKI propagation is whether a submitted dossier is
150+accepted into a ship's cabinet.
151+
152+### Propagation race
153+
154+The rule is simple: any deeds in the dossier which are new (not
155+already in the cabinet) must not use keys superseded in the cabinet.
156+Otherwise revocation doesn't work. But revocation affects only
157+dossiers received in the future; nothing already in the cabinet can be
158+revoked.
159+
160+Intuitively, this algorithm creates a propagation race. Life `2` of
161+`~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so propagating
162+life `2` to the whole network ensures that anyone who steals the
163+private key for life `1` can't use it in any way -- whether to launch
164+children, or to sign a new, bogus life `2`.
165+
166+## Solving the special case
167+
168+So how can we solve the double-sell problem, for the special case of
169+the system designed above?
170+
171+### Double-spend relaying in Bitcoin
172+
173+The first thing we need to notice about our special case is that _even
174+Bitcoin_, not considered as a general consensus problem but just as a
175+decentralized payment rail, isn't that far from _not_ needing a
176+blockchain.
177+
178+As the Karame ["Two Bitcoins at the Price of
179+One"](http://eprint.iacr.org/2012/248.pdf) paper points out:
180+
181+> An efficient countermeasure to combat double-spending on fast
182+ Bitcoin payments would be for Bitcoin peers to propagate alerts
183+ whenever they receive two or more transactions that share common
184+ inputs and different outputs.
185+
186+"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin without
187+the blockchain. These double-spend alerts have never been integrated
188+into Bitcoin Core, despite frequent proposals. Given that Bitcoin
189+_does_ have a blockchain, it seems quite sensible for purists to shun
190+hacks that make zero-conf transactions somewhat more secure. Also,
191+double-spend alerts in Bitcoin are a DoS vulnerability; Bitcoin has
192+fees to control the cost of propagating transactions, but who pays for
193+an alert?
194+
195+In principle, however, we could imagine a version of Bitcoin without a
196+blockchain, in which the mempool was the ledger, and there was an
197+alerting and/or conflict model to detect and resolve double spends.
198+An accepted transaction is simply one that propagates to one or more
199+randomly chosen observer nodes.
200+
201+This design, for the problem that Bitcoin is solving, intuitively
202+feels weak and a little hacky. The Karame paper is not actually
203+advocating for removing the blockchain from Bitcoin. At the same
204+time, low-value zero-confirmation payments are commonly used.
205+
206+One way to think about security is to flip the tables and think of the
207+defender as the attacker, and vice versa. Just imagine you have some
208+moral right to double spend. The rest of the world is unfairly trying
209+to stop you. Can you defend yourself?
210+
211+In the context of a gossip network that shares all the things, a
212+procedure that involves telling one person one thing, and another
213+person another conflicting thing, and not getting "hacked" by the
214+unfair world which believes there should be only one truth, is
215+inherently quite fragile. And where the attack is fragile, the
216+defense is robust.
217+
218+Most of the security in any digital title system comes from the PKI
219+itself. The double-spend problem, the general issue of Byzantine
220+failures in information propagation, is already a corner case. So
221+perhaps we can solve it as a corner case.
222+
223+Again: _even Bitcoin_ isn't that far from being able to build a
224+practical decentralized ledger without a blockchain. The same gossip
225+model that broadcasts nonconflicting transactions is not at all
226+incapable of reacting to conflicting transactions. We're not really
227+recommending that Bitcoin ditch the blockchain, but this gives us hope
228+with our fundamentally easier problem.
229+
230+## Various specific specialnesses
231+
232+What are the differences between the Urbit double-sell problem and the
233+Bitcoin double-spend problem? Is our special case really, truly,
234+special?
235+
236+In worse-is-better mode, we want every special-case advantage we can
237+get. Every difference we find is one we can use as a leverage point.
238+
239+### Minimal transaction interdependency
240+
241+The first major technical difference between the Urbit title history
242+and the Bitcoin blockchain is that Bitcoin and its relatives are
243+designed to secure a complete, interdependent, collective transaction
244+history. Except for the parent-child relationship, Urbit wills are
245+independent of each other.
246+
247+Bitcoin's use of UTXOs rather than balances reduces interdependency
248+somewhat. But the validity of each transaction is still dependent on
249+all the transactions that created its inputs. (Ethereum drops the
250+UTXO model, whose value in reducing dependencies may not match its
251+cost in complexity.)
252+
253+Urbit is not a payment system or a shared ledger. Bitcoins are
254+divisible, but Urbit ships aren't. An Urbit will containing its
255+parent chain is self-validating and has no dependencies. There is no
256+collective history. There is no Merkle tree. There is no chain, with
257+or without blocks.
258+
259+This simplification doesn't eliminate the double-sell problem in
260+theory, but makes it much more tractable in practice. The set of past
261+transactions (key transfers) that a new transaction could conflict
262+with is much smaller.
263+
264+### Trust hierarchy and governance structure
265+
266+The second major technical difference is that Bitcoin is a flat,
267+trustless, fully decentralized system. Urbit has a hierarchical,
268+polycentric governance system which is a trust hierarchy.
269+
270+Now and for quite some time, urbits default to automatically accepting
271+OS updates from their parent, making this trust effectively absolute.
272+This is not a novelty -- all "evergreen" browsers now work this way.
273+You trust your browser quite a bit, which means you trust your browser
274+vendor.
275+
276+And since few Bitcoin node operators code their own daemons, the same
277+dependency on a source distribution exists in Bitcoin. It's informal
278+and off-chain, though, which is not really a good thing. (Urbit is
279+like if Bitcoin Core hotpatched itself automatically by publishing
280+source-code diffs on the blockchain.)
281+
282+To be on the safe side, we should think of Urbit as a centralized
283+system until the OS update that turns off automatic updates is
284+shipped. This of course requires a certain measure of perfection,
285+which cannot in any way be predicted.
286+
287+After Arvo proper becomes "deciduous" (apps will of course always be
288+remotely hotpatched), child-to-parent trust should diminish to the
289+power of the parent to deny service to the child. This will always be
290+present without some major redesign.
291+
292+But it's opposed by the equal and opposite power of the child to
293+switch to a different parent, creating a competitive market in
294+governance. This should deliver service at the highest quality and
295+lowest price, fortifying trust with incentives. The power of a
296+restaurant owner to deny you service does not give the food industry
297+the power to starve you to death.
298+
299+And if no parent wants your business, with 2^16 stars who could accept
300+it, you probably shouldn't be on the network at all. Urbit, like a
301+real society, is designed to be a network of incentives that holds
302+everyone in productive tension. We want everyone to be free, and no
303+one to be unaccountable.
304+
305+For example: a parent which extends its will also needs to send
306+updated signatures to its children and former children. Either will
307+otherwise be unable to propagate their dossiers to ships whose
308+cabinets have the updated parent will, _even if some other parent
309+adopts them_.
310+
311+But Urbit is a collectively governed and updatable system. A star or
312+galaxy which denies service to its own children will (a) get a bad
313+reputation, (b) drive its children to other parents, and (c) force the
314+network to hardcode a ship-specific exception into the propagation
315+algorithm, overriding stale-key revocation.
316+
317+In theory, a parent can extort its children by denying service. In
318+practice, since Urbit is self-governing, not ungoverned, and its
319+government can right this wrong with a source-code patch, the
320+extortion won't work. So it won't happen. So the act of government
321+won't be necessary, and won't happen either.
322+
323+Of course a perfectly decentralized system would be freer. But worse,
324+as usual, is better. And since we are paying for this worseness,
325+imperfect decentralization, we'd like to get all the mileage out of it
326+that we can.
327+
328+Again, Urbit, not being a trustless system, does not have to solve the
329+trustless consensus problem -- although we still very much want to
330+minimize and bound the delegation of trust. This is an obvious
331+relaxation of Bitcoin's hard theoretical problem.
332+
333+### Routing: security through topology
334+
335+Please don't laugh. Security through routing topology isn't a joke --
336+unless firewalls are a joke. Cisco sells too many firewalls for them
337+to be a joke.
338+
339+In Bitcoin we may have all sorts of reasons to ask what ship holds
340+what coins. In Urbit, when we ask what key controls an ship, we are
341+either sending or receiving a message. Is our outgoing message safely
342+sealed to the current owner? Is our incoming message properly signed
343+by the current owner?
344+
345+When the parent also forwards all packets until a P2P link is
346+established (Urbit forwarding resolves to STUN if either party has
347+full cone NAT, TURN if not), we can design in all kinds of
348+interactions between routing and certificate management.
349+
350+In particular, a parent which is a single source of truth in some
351+sense is a very attractive design element. Again, we're paying for
352+our imperfect decentralization. We might as well use it.
353+
354+For example: I want to send a packet to ship X. Two parties, A and B,
355+are competing for ownership of X. A is the rightful owner. I am
356+secure against B if either of these conditions are true: my packet can
357+only be decoded by A, or my packet is not sent to B. Both would be
358+ideal, of course. Either will do.
359+
360+### Latency and friction tolerance
361+
362+Confirmed Bitcoin payments aren't especially low-latency by payment
363+standards. They're reasonably low-friction by payment standards. But
364+fees are certainly a thing.
365+
366+Urbit is digital real estate, not digital money. When we look at the
367+standards of latency and friction in actual real estate -- where a
368+transaction that takes a week is super-fast, a 5% payment overhead is
369+normal, and a third-party intermediary is standard -- we see a much,
370+much weaker set of requirements.
371+
372+Obviously a week and a 5% overhead are incredibly sucky levels of
373+latency and friction. The point is that even if this is the only
374+level of performance Urbit can achieve, that's not necessarily the end
375+of the world for Urbit.
376+
377+For instance: if we wait a week for a double-sell alert, and we don't
378+see one, either the gossip network is totally hosed (to a point we'd
379+surely find out about), or there wasn't a double-sell. This stuff is
380+just not that hard.
381+
382+(One little-made point about Bitcoin, by the way, is that Bitcoin
383+enables trust-free _payments_, but not trust-free _exchanges_. The
384+seller still needs to deliver the goods either before or after the
385+payment; in either case, there is trust. Only Ethereum can solve this
386+problem -- and only for digital exchanges.)
387+
388+## We can afford to be patient
389+
390+With a better-is-better, general-purpose solution, one size fits all
391+until the end of time. With a worse-is-better, special-case solution,
392+the details of that case are critical.
393+
394+But we actually don't know these details. One rule of the
395+worse-is-better school: never solve a problem before you have to. You
396+don't know all the details, and you need those details. (Of course,
397+with the better-is-better approach, the details don't matter at all.)
398+
399+Is there such a thing as a transitive adjective? Grammarians are
400+unclear. But technically, the adjective "secure" is always an error.
401+Nothing is "secure." "Secure against X" is the correct usage, where X
402+is some threat model.
403+
404+Urbit is an insecure test network with no sensitive data on it. This
405+will remain true for a while. No Urbit ship has ever been transferred
406+cryptographically. This will also remain the status quo for quite a
407+while.
408+
409+We _don't know the threat model_. We _can't solve the problem_. It's
410+as simple as that. The best Urbit can do, at the present time, is map
411+out the ballpark of solutions.
412+
413+And we have time to proceed patiently. One way to think about the
414+timing of cryptographic decentralization is to look at the DNS. It's
415+clear that now, a decentralized DNS with cryptographic domain-name
416+titles would be extremely desirable. It was never designed to happen.
417+It will probably never happen.
418+
419+But if we look at when cryptographic DNS with allodial title _should_
420+have happened, it's probably sometime in the mid-90s. Ie, after over a
421+decade of production use of the Domain Name System. In short: there's
422+no need to hurry here.
423+
424+## A map of the solution space
425+
426+But we still need a map of the worse-is-better ballpark. Let's look
427+at some options, from least secure to most.
428+
429+The essential question we can't answer, without a better sense of the
430+threat model, is how aggressively we need to propagate wills. We
431+especially are not sure about the threat model of malicious stars
432+(16-bit ships) and/or galaxies (8-bit ships).
433+
434+We need to know what kinds of double-sell attacks are plausible. Since
435+we don't know this yet, we need not one propagation design, but a
436+range of designs -- stretching all the way up to a full blockchain.
437+
438+### Acceptance model
439+
440+What doesn't change is the will _acceptance_ model. A ship will
441+always accept a new will if (a) the new will extends the old will, (b)
442+the parent signature on the initial public key is at least as recent
443+as the ship's current version of that parent.
444+
445+The parent clause implies that when a parent extends its will, it
446+needs to send updated initial signatures to all the children it's
447+launched. Otherwise, their own future updates will not be accepted by
448+ships that have seen the parent's update.
449+
450+This is not a big deal in the world of parent responsibilities. But
451+like many such responsibilities, it lets a badly operated parent deny
452+service to its children.
453+
454+A ship accepts all wills, new or updated, and stores them permanently.
455+If this is abused trivially as a DoS vector, Urbit will mitigate it by
456+the usual technique of degrading service to non-scarce ship tiers.
457+Scarcity rules.
458+
459+### Level 0: passive propagation only
460+
461+The Ames protocol can piggyback a will on any packet. Each ship also
462+permanently records which other ships hold which version of its own
463+will. An update is automatically sent when needed.
464+
465+With level 0 propagation, all key exchanges in Ames are passive and
466+invisible to the programmer. When the sender has no will or symmetric
467+key for the receiver, the packet is signed, bundled with the will, and
468+sent as cleartext.
469+
470+Signed cleartext? If you have no will for a peer, you've never talked
471+to this ship before. Your first words to a stranger probably won't be
472+super secret. If this isn't true, the programmer has to send an
473+innocuous message first and wait for it to be acknowledged. Kicking a
474+rare corner case up to the programmer is a classic worse-is-better
475+move.
476+
477+With level 0 propagation only (the current implementation, because we
478+don't even care about key updates yet), an updated does not
479+effectively revoke the old key. If Alice updates to a new key,
480+Mallory steals the old key, then Mallory talks to Bob before Alice
481+does, Mallory can impersonate Alice.
482+
483+So not only does level 0 not solve double-sell, it's also quite
484+insecure. But it's still fine for now (because Urbit isn't really
485+decentralized yet).
486+
487+### Level 1: neighbor-only propagation with parent filtering
488+
489+The list of other ships which hold your will, essentially the list of
490+all ships you've talked to, is your list of _neighbors_. You
491+essentially have permanent, if perhaps very sporadic, conversations
492+with all your cryptographic neighbors. Symmetric keys time out fast,
493+but wills are held forever.
494+
495+By proactively pinging all your neighbors when you extend your will,
496+you prevent anyone who finds the old private key (ideally you update
497+when your old key is stale, not when it's actually been _stolen_) from
498+jumping into these conversations.
499+
500+What about non-neighbors? We add a second feature: a parent will only
501+forward a packet if its sender matches the current will. So updating
502+your parent (who is always your neighbor) transforms it
503+
504+There are two cases: where Alice's parent Trent is also Bob's parent,
505+and where Bob has a separate parent Walter. In the first case, the
506+expected packet flow is that Alice will send the packet to Trent, who
507+sends it to Bob. In the second case, Trent sends it to Walter, who
508+sends it to Bob.
509+
510+In either flow, Bob or Walter is sure that the packet came through
511+Trent. Since Trent is Alice's parent and hence Alice's neighbor, and
512+hence is updated, Trent will forward no packets from Mallory. So
513+Mallory has no way to reach Bob.
514+
515+Non-neighborly packets not matching this flow can't be accepted.
516+Suppose Mallory gets Bob's public IP address directly? If Bob gets a
517+non-forwarded packet marked "Alice," but Alice is not his neighbor,
518+that's super weird. He must reject the packet.
519+
520+Level 1 is nice because it provides a reasonable level of security,
521+but it's still extremely simple. Not only does it not use a
522+blockchain, it doesn't even need a gossip flood!
523+
524+And level 1 propagation also does a competent worse-is-better job on
525+the double-sell problem. Trent simply becomes the single source of
526+truth. The buyer of Alice needs to check that Trent, her parent, has
527+Alice's latest will from the buyer's perspective. If Alice's seller
528+propagates a different fork to other ships, this damages Alice's
529+ability to communicate, but produces no obvious gain for the seller.
530+
531+Level 1 puts a lot of security weight on the parent. If Trent
532+misbehaves, for example by not filtering Mallory's packets, Alice can
533+be impersonated. And its solution to the double-sell problem is
534+adequate, but not ideal. Level 1 is the worse-is-better sweet spot
535+for a young Urbit, but will probably give way to level 2.
536+
537+### Level 2: broadcast all wills
538+
539+We can't say definitively that level 1 will be inadequate. But
540+intuitively, it feels slightly weak. We will probably need a gossip
541+protocol.
542+
543+The only ships that can be transferred are galaxies, stars and
544+planets; if all updates of all wills of all these major ships are
545+broadcast, we hardly have a scaling problem like Bitcoin's. Even if
546+changing the lock on your front door counted as a real-estate
547+transaction, there are a lot fewer real-estate transactions than
548+credit-card payments.
549+
550+Moreover, conflict detection (double-sell alerts) is a natural part of
551+any gossip protocol. Gossip should be between stars, not directly
552+between planets; horizontal gossip, vertical distribution.
553+Star-to-planet distribution may still be limited.
554+
555+Especially since stars are somewhat trusted, ganking a gossip protocol
556+with random update edges is incredibly hard and requires a pretty
557+preposterous conspiracy. And flooding all planet wills does a lot to
558+keep stars honest. It would be incredibly stupid for a star to try a
559+double-sell attack against its own planets, but code is always more
560+powerful than mere incentives.
561+
562+Finally, the exit model isn't fully baked yet, but it will probably
563+have more aggressive propagation needs. What's clear is that an exit
564+statement is another type of will entry, involving a signature both
565+from the previous key and the new parent. You can only escape to
566+another ship of your parent's class that agrees to adopt you.
567+
568+In general, because escaping need to work for routing (without the
569+cooperation of the former parent), wills containing an exit statement
570+(a planet moving to a new star, or a star moving to a new galaxy)
571+exit) probably need to be flooded globally among all 8-bit galaxies
572+and 16-bit stars. Exits should be rare, so they shouldn't present
573+much of a scaling problem.
574+
575+### Level 3: full blockchain
576+
577+Obviously a blockchain can solve Urbit's problem. Probably the right
578+thing to do would be to use the Bitcoin blockchain, and confirm the
579+current Urbit key version with a "colored coin" of some kind. (This
580+should not be confused with the orthogonal idea of representing Urbit
581+_invitations_ as colored coins.)
582+
583+This involves making all Urbit ships into Bitcoin SPV nodes at the
584+least. Not the worst fate in the world, but also a cost.
585+Alternatively, Urbit could have its own "altcoin" blockchain, with
586+actual Urbit-specific mining.
587+
588+Again, given that level 2 seems like it should work quite well, it's
589+hard to see why level 3 propagation would be needed. But we can't
590+really know at this point. There's a reason Urbit can update itself
591+over the air. That's why we say: Urbit (probably) doesn't need a
592+blockchain. If it does, we can retrofit it.
593+
594+## Retrospective note
595+
596+This essay has presented the Urbit cryptographic title as a low-power,
597+stripped-down, worse-is-better variation of Nakamoto consensus.
598+That's clearly the right way to introduce it in 2016.
599+
600+Actually, though, this part of Urbit was designed before the Bitcoin
601+paper was published. There were other academic approaches to
602+Byzantine consensus, but certainly none validated on a large scale as
603+Nakamoto consensus has been. It never seemed appropriate to treat
604+cryptographic titles to network addresses as a case of generalized
605+Byzantine consensus, and without the existence of Bitcoin there was no
606+temptation in this direction.
607+
608+In a sense the secret of PKIs is that PKIs are easy. What's hard is
609+adapting an existing identity and authorization structure into a PKI.
610+If you build the simplest possible PKI, then force the human processes
611+to fit themselves to the protocol instead of vice versa, you have a
612+much easier job. Similarly, if you are not adding PKI to an existing
613+network, but building the network and the PKI as one system, many
614+simplifications are possible. This is once again the classic
615+worse-is-better method.
content/privacy.mdnew file+85
@@ -0,0 +1,85 @@
1++++
2+title = "Privacy Policy"
3++++
4+## Scope of this Privacy Policy
5+
6+Tlon Corporation ('Tlon,' 'we,' 'our,' and/or 'us') values the privacy of individuals who use Urbit software, our websites, and related services (collectively, our 'Services'). This privacy policy (the 'Privacy Policy') explains how we collect, use, and share information from users of our Services ('Users'). By using our Services, you agree to the collection, use, disclosure, and procedures this Privacy Policy describes. Beyond the Privacy Policy, your use of our Services is also subject to our Terms of Service.
7+
8+## Information We Collect
9+
10+We may collect a variety of information from or about you or your devices from various sources, as described below.
11+
12+## Information You Provide to Us
13+
14+*Address Space Information.* When you acquire Urbit address space from Tlon, you provide us with certain information, such as your name and email. You may also provide us with your Ethereum wallet address and public key.
15+
16+*Communications.* If you contact us directly, we may receive additional information about you. For example, when you chat with us in Urbit or contact support, we may receive your email address, the contents of a message or attachments that you may send to us, and other information you choose to provide.
17+
18+## Information We Collect When You Use Our Services
19+
20+*Device Information.* We receive information about the device and software you use to access our websites, including IP address, device identifier, web browser type, device model, and operating system version.
21+
22+*Usage Information.* To help us understand how you use our Services and to help us improve them, we automatically receive information about your interactions with the Services, like the pages or other content you view, and the dates and times of your visits.
23+
24+*Information from Cookies and Similar Technologies.* On our websites, we and third party partners collect information using cookies, pixel tags, or similar technologies. Our third party partners, such as analytics and advertising partners, may use these technologies to collect information about your online activities over time and across different online services. Cookies are small text files containing a string of alphanumeric characters. We may use both session cookies and persistent cookies. A session cookie disappears after you close your browser. A persistent cookie remains after you close your browser and may be used by your browser on subsequent visits to our website.\
25+
26+Please review your web browser 'Help' file to learn the proper way to modify your cookie settings. Please note that if you delete, or choose not to accept, cookies from the Services, you may not be able to utilize the features of the Services to their fullest potential.
27+
28+## How We Use the Information We Collect
29+
30+We use the information we collect:
31+
32++ To provide and maintain our Services;
33++ To understand and analyze how you use the Services, and to improve and enhance our Services and develop new products, services, features, and functionality;
34++ To communicate with you, to provide you with updates and other information relating to the Services, to provide information that you request, to respond to comments and questions, and otherwise provide customer support;
35++ To find and prevent fraud;
36++ To respond to trust and safety issues that may arise;
37++ For compliance purposes, including enforcing our Terms of Service or other legal rights, or as may be required by applicable laws and regulations or requested by any judicial process or governmental agency; and
38++ For other purposes for which we provide specific notice at the time of the collection of the information.
39+
40+## How we Share the Information We Collect:
41+
42+We do not share or otherwise disclose information we collect from or about you except as described below or otherwise disclosed to you at the time of the collection.\
43+
44+*On the Blockchain.* If you purchase address space, we may publish information about that purchase to the Ethereum blockchain, including your public key and Urbit address. We will never publish your name or email address to the blockchain.\
45+
46+*Vendors and Service Providers.* We may share any information we receive with vendors and service providers retained in connection with the provision of the Service.\
47+
48+*Analytics Partners.* We use analytics services such as Google Analytics to collect and process certain analytics data. These services may also collect information regarding your use of other websites, apps, and online resources. You can learn about Google's practices by going to <a href="https://www.google.com/policies/privacy/partners/">https://www.google.com/policies/privacy/partners/</a>, and opt out of them by downloading the Google Analytics opt-out browser add-on, available at <a href="https://tools.google.com/dlpage/gaoptout">https://tools.google.com/dlpage/gaoptout</a>.\
49+
50+*As Required By Law and Similar Disclosures.* We may access, preserve, and disclose your information if we believe doing so is required or appropriate to (a) comply with law enforcement requests and legal process, such as a court order or subpoena; (b) respond to your requests; or (c) protect your, our or others' rights, property, or safety. For the avoidance of doubt, the disclosure of your information may occur if you post any objectionable content on or through the Service.\
51+
52+*Merger, Sale, or Other Asset Transfers.* We may transfer your information to service providers, advisors, potential transactional partners, or other third parties in connection with the consideration, negotiation, or completion of a corporate transaction in which we are acquired by or merged with another company or we sell, liquidate, or transfer all or a portion of our assets. The use of your information following any of these events will be governed by the provisions of this Privacy Policy in effect at the time the applicable information was collected.\
53+
54+*Consent.* We may also disclose your information with your permission.\
55+
56+## Your Choices
57+
58+*Marketing Communications.* You can unsubscribe from our promotional emails via the link provided in the emails. Even if you opt-out of receiving promotional messages from us, you will continue to receive administrative messages from us.\
59+
60+*Do Not Track.* There is no accepted standard on how to respond to Do Not Track signals, and we do not respond to such signals.
61+
62+## Third Parties
63+
64+The Services may contain links to other websites, products, or services that Tlon does not own or operate. We are not responsible for the privacy practices of these third parties. Please be aware that this Privacy Policy will not apply to your activities or any information you disclose to these third parties. We encourage you to read their privacy policies before providing any information to them.\
65+
66+## Security
67+
68+We make reasonable efforts to protect your information by using physical and electronic safeguards designed to improve the security of the information we maintain. However, as our Services are hosted electronically, we can make no guarantees as to the security or privacy of your information.\
69+
70+## Children's Privacy
71+
72+We do not knowingly collect, maintain, or use personal information from children under 13 years of age, and no part of the Service is directed to children. If you learn that a child has provided us with personal information in violation of this Privacy Policy, then you may alert us at accounts@tlon.io.\
73+
74+## International Visitors
75+
76+The Services are hosted in the United States and are intended for visitors located within the United States. If you choose to use the Services from the European Union or other regions of the world with laws governing data collection and use that may differ from U.S. law, then please note that you are transferring your personal information outside of those regions to the United States for storage and processing. Also, we may transfer your data from the U.S. to other countries or regions in connection with storage and processing of data, fulfilling your requests, and operating the Services. By providing any information, including personal information, on or to the Services, you consent to such transfer, storage, and processing.\
77+
78+## Changes to this Privacy Policy
79+
80+We will post any adjustments to the Privacy Policy on this page, and the revised version will be effective when it is posted. If we materially change the ways in which we use or share personal information previously collected from you through the Services, we will notify you through the Services, by email, or other communication.\
81+## Contact Information
82+
83+Tlon is responsible for processing your information. If you have any questions, comments, or concerns about our processing activities, please email us at accounts@tlon.io.\
84+
85+*Last Updated:* September 12, 2018
content/tos.mdnew file+52
@@ -0,0 +1,52 @@
1++++
2+title = "Urbit Website Terms of Use"
3++++
4+
5+Last Updated: September 24, 2018,\
6+
7+Welcome, and thank you for your interest in Tlon Corporation ('*Tlon*,' '*we*,' or '*us*') and our website at urbit.org, along with our related websites and services (collectively, the "Site"). These Terms of Use are a legally binding contract between you and Tlon regarding your use of the Site.\
8+
9+*BY CLICKING 'I ACCEPT,' OR BY OTHERWISE ACCESSING OR USING THE SITE, YOU AGREE THAT YOU HAVE READ AND UNDERSTOOD, AND, AS A CONDITION TO YOUR USE OF THE SITE, YOU AGREE TO BE BOUND BY, THE FOLLOWING TERMS AND CONDITIONS, INCLUDING OUR PRIVACY POLICY (TOGETHER, THESE 'TERMS').* IF YOU ARE NOT ELIGIBLE, OR DO NOT AGREE TO THE TERMS, THEN YOU DO NOT HAVE OUR PERMISSION TO USE THE SITE. YOUR USE OF THE SITE, AND TLON'S PROVISION OF THE SITE TO YOU, CONSTITUTES AN AGREEMENT BY TLON AND BY YOU TO BE BOUND BY THESE TERMS.\
10+
11+*ARBITRATION NOTICE.* Except for certain kinds of disputes described in Section 13, you agree that disputes arising under these Terms will be resolved by binding, individual arbitration, and *BY ACCEPTING THESE TERMS, YOU AND TLON ARE EACH WAIVING THE RIGHT TO A TRIAL BY JURY OR TO PARTICIPATE IN ANY CLASS ACTION OR REPRESENTATIVE PROCEEDING. YOU AGREE TO GIVE UP YOUR RIGHT TO GO TO COURT* to assert or defend your rights under this contract (except for matters that may be taken to small claims court). Your rights will be determined by a NEUTRAL ARBITRATOR and NOT a judge or jury. (See Section 13.)\
12+
13+
14++ *Overview.; Eligibility.* The Site provides information about the Urbit network, as well as our company, products and services. By agreeing to these Terms, you represent and warrant to us that: (a) you are at least 18 years old or otherwise have consent from a parent or guardian who is at least 18 years old; and (b) you have not previously been suspended or removed from the Site.
15++ *Use of the Site.* Subject to your complete and ongoing compliance with these Terms, Tlon grants you, solely for your personal use, non-exclusive, non-transferable, non-sublicensable, revocable permission to access and use the Site. Except and solely to the extent such a restriction is impermissible under applicable law, you may not: (a) reproduce, distribute, publicly display, or publicly perform the Site or any Materials (defined in Section 4 below); (b) make modifications to the Site or any Materials; or (c) interfere with or circumvent any feature of the Site, including any security or access control mechanism. If you are prohibited under applicable law from using the Site, you may not use it.
16++ *Information You Submit.* Do not submit any information or other materials that you consider confidential or proprietary through the Site, except to the extent that such information has been specifically requested by Tlon. If you choose to provide input or suggestions regarding us, our products or services, or problems with or proposed modifications or improvements to the Site ('*Feedback*'), then you do so on a non-confidential basis (regardless of any designation or indication to the contrary in the submitted information or any accompanying correspondence) and you hereby grant Tlon a perpetual, irrevocable, non-exclusive, fully-paid, royalty-free, transferable, sublicensable right to exploit the Feedback in any manner and for any purpose, including to improve the Site and create other products and services.
17++ *Ownership; Proprietary Rights.* The Site is owned and operated by Tlon. The visual interfaces, graphics, design, compilation, information, data, computer code, and all other elements of the Site ('*Materials*') provided by Tlon are protected by intellectual property and other laws. As between us, all Materials included in the Site are the property of Tlon or its third party licensors. Except as expressly authorized by Tlon, you may not make use of the Materials. Tlon reserves all rights to the Materials not granted expressly in these Terms.
18++ *Third Party Sites.* The Site may contain links to third party websites. Linked websites are not under Tlon's control, and Tlon is not responsible for their content.
19++ *Prohibited Conduct.* BY USING THE SITE YOU AGREE NOT TO, AND AGREE NOT TO PERMIT OR ASSIST ANY OTHER PERSON TO: (a) use the Site for any illegal purpose or in violation of any applicable law; (b) violate, or encourage others to violate, any right of a third party, including by infringing or misappropriating any third party intellectual property right; (c) interfere with security-related features of the Site, including by: (i) disabling or circumventing features that prevent or limit use or copying of any content; or (ii) reverse engineering or otherwise discovering the source code of any portion of the Site except to the extent that the activity is expressly permitted by applicable law, or to the extent that Tlon has made such source code has been made available to the public; or (d) interfere with the operation of the Site, including by interfering with or disrupting any network, equipment, or server connected to or used to provide the Site.
20++ *Modification of these Terms.* We reserve the right to change these Terms on a going-forward basis at any time. Please check these Terms periodically for changes. Modifications are effective upon publication. Except as expressly permitted in this Section 7, these Terms may be amended only by a written agreement signed by authorized representatives of the parties to these Terms. Disputes arising under these Terms will be resolved in accordance with the version of these Terms that was in effect at the time the dispute arose.
21++ *Term and Termination.* These Terms are effective beginning when you accept the Terms or first access or use the Site, and terminate as described below in this Section 8. If you violate any provision of these Terms, your authorization to access the Site and these Terms automatically terminate. In addition, Tlon may, at its sole discretion, terminate these Terms or suspend or terminate your access to the Site, at any time for any reason or no reason, with or without notice. Upon termination of these Terms: (a) your license rights will terminate and you must immediately cease all use of the Site and (b) Sections 3, 4, 8, 10, 11, 12, and 14 will survive.
22++ *Modification of the Site.* Tlon reserves the right to modify or discontinue the Site at any time (including by limiting or discontinuing certain features of the Site), temporarily or permanently, without notice to you. Tlon will have no liability for any change to the Site or any suspension or termination of your access to or use of the Site.
23++ *Indemnity.* To the fullest extent permitted by law, you are responsible for your use of the Site, and you will defend and indemnify Tlon and its officers, directors, employees, consultants, affiliates, subsidiaries and agents (together, the '*Tlon Entities*') from and against every claim brought by a third party, and any related liability, damage, loss, and expense, including reasonable attorneys' fees and costs, arising out of or connected with your use or misuse of the Site. We reserve the right, at our own expense, to assume the exclusive defense and control of any matter otherwise subject to indemnification by you (without limiting your indemnification obligations with respect to that matter), and in that case, you agree to cooperate with our defense of those claims.
24++ Disclaimers; No Warranties\
25+
26+THE SITE AND ALL MATERIALS AND CONTENT AVAILABLE THROUGH THE SITE ARE PROVIDED 'AS IS' AND ON AN 'AS AVAILABLE' BASIS, AND TLON HEREBY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, RELATING TO THE SITE AND ALL MATERIALS AND CONTENT AVAILABLE THROUGH THE SITE, INCLUDING: (A) ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, QUIET ENJOYMENT, OR NON-INFRINGEMENT; AND (B) ANY WARRANTY ARISING OUT OF COURSE OF DEALING, USAGE, OR TRADE. TLON DOES NOT WARRANT THAT THE SITE OR ANY FUNCTIONALITY OR FEATURES OF THE SITE, OR ANY MATERIALS OR CONTENT OFFERED THROUGH THE SITE, WILL BE UNINTERRUPTED, SECURE, OR FREE OF ERRORS, VIRUSES, OR OTHER HARMFUL COMPONENTS, AND TLON DOES NOT WARRANT THAT ANY OF THOSE ISSUES WILL BE CORRECTED. NO ADVICE OR INFORMATION, WHETHER ORAL OR WRITTEN, OBTAINED BY YOU FROM THE SITE OR TLON ENTITIES OR ANY MATERIALS OR CONTENT AVAILABLE THROUGH THE SITE WILL CREATE ANY WARRANTY REGARDING ANY OF THE TLON ENTITIES OR THE SITE THAT IS NOT EXPRESSLY STATED IN THESE TERMS.\
27+THE DISCLAIMERS IN THIS SECTION APPLY TO THE FULLEST EXTENT PERMITTED BY LAW.\
28++ Limitation of Liability\
29+
30+TO THE FULLEST EXTENT PERMITTED BY LAW AND EXCEPT AS OTHERWISE STATED IN SECTION 13 BELOW, (A) IN NO EVENT WILL THE TLON ENTITIES BE LIABLE TO YOU FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL OR PUNITIVE DAMAGES (INCLUDING DAMAGES FOR LOSS OF PROFITS, GOODWILL, OR ANY OTHER INTANGIBLE LOSS) ARISING OUT OF OR RELATING TO YOUR ACCESS TO OR USE OF, OR YOUR INABILITY TO ACCESS OR USE, THE SITE OR ANY MATERIALS OR CONTENT ON THE SITE, WHETHER BASED ON WARRANTY, CONTRACT, TORT (INCLUDING NEGLIGENCE), STATUTE, OR ANY OTHER LEGAL THEORY, AND WHETHER OR NOT ANY TLON ENTITY HAS BEEN INFORMED OF THE POSSIBILITY OF DAMAGE, AND (B) THE AGGREGATE LIABILITY OF THE TLON ENTITIES TO YOU FOR ALL CLAIMS ARISING OUT OF OR RELATING TO THE USE OF OR INABILITY TO USE THE SITE OR OTHERWISE UNDER THESE TERMS, WHETHER IN CONTRACT, TORT, OR OTHERWISE, IS LIMITED TO $10.\
31+THE LIMITATIONS IN THIS SECTION 12 WILL APPLY EVEN IF ANY LIMITED REMEDY FAILS OF ITS ESSENTIAL PURPOSE.\
32+
33++ Dispute Resolution and Arbitration\
34+
35+13.1 Generally. In the interest of resolving disputes between you and Tlon in the most expedient and cost effective manner, and except as described in Section 13.2, you and Tlon agree that every dispute arising in connection with these Terms will be resolved by binding arbitration. Arbitration is less formal than a lawsuit in court. Arbitration uses a neutral arbitrator instead of a judge or jury, may allow for more limited discovery than in court, and can be subject to very limited review by courts. Arbitrators can award the same damages and relief that a court can award. This agreement to arbitrate disputes includes all claims arising out of or relating to any aspect of these Terms, whether based in contract, tort, statute, fraud, misrepresentation, or any other legal theory, and regardless of whether a claim arises during or after the termination of these Terms. YOU UNDERSTAND AND AGREE THAT, BY ENTERING INTO THESE TERMS, YOU AND TLON ARE EACH WAIVING THE RIGHT TO A TRIAL BY JURY OR TO PARTICIPATE IN A CLASS ACTION.
36+
37+13.2 *Exceptions. Despite the provisions of Section 13.1, nothing in these Terms will be deemed to waive, preclude, or otherwise limit the right of either party to: (a) bring an individual action in small claims court; (b) pursue an enforcement action through the applicable federal, state, or local agency if that action is available; (c) seek injunctive relief in a court of law in aid of arbitration; or (d) to file suit in a court of law to address an intellectual property infringement claim.*\
38+
39+13.3 *Arbitrator. Any arbitration between you and Tlon will be settled under the Federal Arbitration Act and administered by the American Arbitration Association ('AAA') under its Consumer Arbitration Rules (collectively, 'AAA Rules') as modified by these Terms. The AAA Rules and filing forms are available online at www.adr.org, by calling the AAA at 1-800-778-7879, or by contacting Tlon. The arbitrator has exclusive authority to resolve any dispute relating to the interpretation, applicability, or enforceability of this binding arbitration agreement.*\
40+
41+13.4 *Notice of Arbitration; Process. A party who intends to seek arbitration must first send a written notice of the dispute to the other party by certified U.S. Mail or by Federal Express (signature required) or, only if that other party has not provided a current physical address, then by electronic mail ('Notice of Arbitration'). Tlon's address for Notice is: Tlon Corporation, 548 Market St #56196, San Francisco, CA 94104. The Notice of Arbitration must: (a) describe the nature and basis of the claim or dispute; and (b) set forth the specific relief sought ('Demand'). The parties will make good faith efforts to resolve the claim directly, but if the parties do not reach an agreement to do so within 30 days after the Notice of Arbitration is received, you or Tlon may commence an arbitration proceeding. All arbitration proceedings between the parties will be confidential unless otherwise agreed by the parties in writing. During the arbitration, the amount of any settlement offer made by you or Tlon must not be disclosed to the arbitrator until after the arbitrator makes a final decision and award, if any. If the arbitrator awards you an amount higher than the last written settlement amount offered by Tlon in settlement of the dispute prior to the award, Tlon will pay to you the higher of: (i) the amount awarded by the arbitrator; or (ii) $10,000.*\
42+
43+13.5 *Fees. If you commence arbitration in accordance with these Terms, Tlon will reimburse you for your payment of the filing fee, unless your claim is for more than $10,000, in which case the payment of any fees will be decided by the AAA Rules. Any arbitration hearing will take place at a location to be agreed upon in San Francisco County, CA but if the claim is for $10,000 or less, you may choose whether the arbitration will be conducted: (a) solely on the basis of documents submitted to the arbitrator; (b) through a non-appearance based telephone hearing; or (c) by an in-person hearing as established by the AAA Rules in the county (or parish) of your billing address. If the arbitrator finds that either the substance of your claim or the relief sought in the Demand is frivolous or brought for an improper purpose (as measured by the standards set forth in Federal Rule of Civil Procedure 11(b)), then the payment of all fees will be governed by the AAA Rules. In that case, you agree to reimburse Tlon for all monies previously disbursed by it that are otherwise your obligation to pay under the AAA Rules. Regardless of the manner in which the arbitration is conducted, the arbitrator must issue a reasoned written decision sufficient to explain the essential findings and conclusions on which the decision and award, if any, are based. The arbitrator may make rulings and resolve disputes as to the payment and reimbursement of fees or expenses at any time during the proceeding and upon request from either party made within 14 days of the arbitrator's ruling on the merits.*\
44+
45+13.6 *No Class Actions. YOU AND TLON AGREE THAT EACH MAY BRING CLAIMS AGAINST THE OTHER ONLY IN YOUR OR ITS INDIVIDUAL CAPACITY AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS OR REPRESENTATIVE PROCEEDING. Further, unless both you and Tlon agree otherwise, the arbitrator may not consolidate more than one person's claims, and may not otherwise preside over any form of a representative or class proceeding.*\
46+
47+13.7 *Modifications to this Arbitration Provision. If Tlon makes any future change to this arbitration provision, other than a change to Tlon's address for Notice of Arbitration, you may reject the change by sending us written notice within 30 days of the change to Tlon's address for Notice of Arbitration, in which case your account with Tlon will be immediately terminated and this arbitration provision, as in effect immediately prior to the changes you rejected will survive.*\
48+13.8 *Enforceability. If Section 13.6 is found to be unenforceable or if the entirety of this Section 10 is found to be unenforceable, then the entirety of this Section 10 will be null and void and, in that case, the parties agree that the exclusive jurisdiction and venue described in Section 14 will govern any action arising out of or related to these Terms.*\
49+
50++ Privacy Policy. Please read our [Privacy Policy](https://urbit.org/privacy.html) carefully for information relating to our collection, use, storage, disclosure of your personal information. The Privacy Policy is incorporated by this reference into, and made a part of, these Terms. By accepting these Terms, you consent to receiving certain electronic communications from us as further described in our Privacy Policy. Please read our Privacy Policy to learn more about our electronic communications practices. You agree that any notices, agreements, disclosures, or other communications that we send to you electronically will satisfy any legal communication requirements, including that those communications be in writing.
51++ Additional Terms. Your use of the Site is subject to all additional terms, policies, rules, or guidelines applicable to the Site or certain features of the Site that we may post on or link to from the Site (the '*Additional Terms*'). All Additional Terms are incorporated by this reference into, and made a part of, these Terms.
52++ General Terms. These Terms, including the Privacy Policies and any Additional Terms, are the entire and exclusive understanding and agreement between you and Tlon regarding your use of the Site. You may not assign or transfer these Terms or your rights under these Terms, in whole or in part, by operation of law or otherwise, without our prior written consent. We may assign these Terms at any time without notice or consent. The failure to require performance of any provision will not affect our right to require performance at any other time after that, nor will a waiver by us of any breach or default of these Terms, or any provision of these Terms, be a waiver of any subsequent breach or default or a waiver of the provision itself. Use of section headers in these Terms is for convenience only and will not have any impact on the interpretation of any provision. Throughout these Terms the use of the word 'including' means 'including but not limited to'. If any part of these Terms is held to be invalid or unenforceable, the unenforceable part will be given effect to the greatest extent possible, and the remaining parts will remain in full force and effect. These Terms are governed by the laws of the State of California without regard to conflict of law principles. You and Tlon submit to the personal and exclusive jurisdiction of the state courts and federal courts located within San Francisco County, California for resolution of any lawsuit or court proceeding permitted under these Terms. We operate the Site from our offices in California, and we make no representation that Materials included in the Site are appropriate or available for use in other locations. We make no representation that the Site is appropriate or available for use outside of the United States. Access to the Site from countries or territories or by individuals where such access is illegal is prohibited.
sass/_indigo.scssnew file+20482

This diff is too big to show here.

sass/_main.scssnew file+377

This diff is too big to show here.

sass/_primer.scssnew file+16881

This diff is too big to show here.

sass/_responsive.scssnew file+68

This diff is too big to show here.

sass/styles.scssnew file+9

This diff is too big to show here.

static/assets/dropdown.svgnew file+1

This diff is too big to show here.

static/assets/menu-close.svgnew file+7

This diff is too big to show here.

static/assets/menu-open.svgnew file+3

This diff is too big to show here.

static/images/aegean-1.pngnew file

Binary file not shown.

static/images/aegean-2.pngnew file

Binary file not shown.

static/images/aegean-3.pngnew file

Binary file not shown.

static/images/aegean.svgnew file+1

This diff is too big to show here.

static/images/arvo-complete.svgnew file+1

This diff is too big to show here.

static/images/arvo-large.svgnew file+84

This diff is too big to show here.

static/images/azimuth.svgnew file+1

This diff is too big to show here.

static/images/blockchain-fade.svgnew file+1

This diff is too big to show here.

static/images/business.svgnew file+1

This diff is too big to show here.

static/images/face.svgnew file+23

This diff is too big to show here.

static/images/faces.svgnew file+88

This diff is too big to show here.

static/images/file.svgnew file+1

This diff is too big to show here.

static/images/galaxies-old.svgnew file+19

This diff is too big to show here.

static/images/galaxies.svgnew file+1

This diff is too big to show here.

static/images/iot.svgnew file+62

This diff is too big to show here.

static/images/megacorp.svgnew file+1

This diff is too big to show here.

static/images/moons.svgnew file+73

This diff is too big to show here.

static/images/network-diagram.gifnew file

Binary file not shown.

static/images/network-diagram.svgnew file+1240

This diff is too big to show here.

static/images/new-blockchain.svgnew file+1

This diff is too big to show here.

static/images/new-independence.svgnew file+1

This diff is too big to show here.

static/images/offchain.svgnew file+1

This diff is too big to show here.

static/images/passcode.svgnew file+1

This diff is too big to show here.

static/images/personal-blockchain 2.svgnew file+129

This diff is too big to show here.

static/images/personal-blockchain.svgnew file+1

This diff is too big to show here.

static/images/planets-old.svgnew file+43

This diff is too big to show here.

static/images/planets.svgnew file+1

This diff is too big to show here.

static/images/program.svgnew file+1

This diff is too big to show here.

static/images/server.svgnew file+1

This diff is too big to show here.

static/images/single-interface-green.svgnew file+109

This diff is too big to show here.

static/images/single-interface.svgnew file+111

This diff is too big to show here.

static/images/standard-code.svgnew file+1

This diff is too big to show here.

static/images/stars-old.svgnew file+8

This diff is too big to show here.

static/images/stars.svgnew file+1

This diff is too big to show here.

static/images/sticker-1.svgnew file+6

This diff is too big to show here.

static/images/sticker-2.svgnew file+11

This diff is too big to show here.

static/images/technical-problem.svgnew file+1

This diff is too big to show here.

static/images/their-code.svgnew file+1

This diff is too big to show here.

static/images/urbit-complete.svgnew file+1

This diff is too big to show here.

static/images/what-urbit-is.svgnew file+1

This diff is too big to show here.

static/primer.jsnew file+61

This diff is too big to show here.

static/scripts.jsnew file+9

This diff is too big to show here.

templates/base.htmlnew file+21

This diff is too big to show here.

templates/doc.htmlnew file+26

This diff is too big to show here.

templates/index.htmlnew file+44

This diff is too big to show here.

templates/page.htmlnew file+51

This diff is too big to show here.

templates/partials/footer.htmlnew file+59

This diff is too big to show here.

templates/partials/navigation-docs.htmlnew file+77

This diff is too big to show here.

templates/partials/navigation.htmlnew file+73

This diff is too big to show here.

templates/posts/list.htmlnew file+50

This diff is too big to show here.

templates/posts/single.htmlnew file+57

This diff is too big to show here.

templates/primer.htmlnew file+1038

This diff is too big to show here.

templates/sections/docs.htmlnew file+26

This diff is too big to show here.

templates/sections/docs/chapters.htmlnew file+30

This diff is too big to show here.

templates/shortcodes/soundcloud.htmlnew file+9

This diff is too big to show here.