@@ -1,15 +1,29 @@
1−
2−
3−# Common objections to Urbit
4−
5−*"We choose to go to the moon, not because it is easy, but because it is hard."* -- John F. Kennedy
6−
7−Some objections we've seen:
8−
9−- [Urbit is, like, totally not ready for prime time.](#prime)
1+---
2+sort: 8
3+type: post
4+title: Common objections to Urbit
5+author: Curtis Yarvin
6+preview: Some common objections to Urbit, refuted.
7+layout: urbit,post
8+footer: true
9+navmode: navbar
10+navdpad: false
11+navselect: posts
12+navpath: /
13+navhome: /
14+navclass: urbit
15+---
16+
17+We're strong believers in crowdsourced criticism. We've heard a
18+lot of great criticisms of Urbit. Surely there's more out there!
19+Comments are open at the bottom of the page.
20+
21+Here's our list right now:
22+
23+- [Urbit is not ready for prime time.](#prime)
1024- [Nock jets are a total hoax.](#jets)
1125- [Urbit needs an infinitely extending packet/event log.](#log)
12−- [Urbit is a total scamcoin. It's 100% premined](#scam)
26+- [Urbit is a total scamcoin. It's 100% premined.](#scam)
1327- [Urbit isn't even really decentralized! It has a government!](#gov)
1428- [Urbit doesn't have enough planets for every human being.](#planet)
1529- [Cloud computing is inherently non-private.](#pwned)
@@ -21,297 +35,727 @@ Some objections we've seen:
2135- [Urbit is a reactionary digital dictatorship.](#dictator)
2236- [Urbit is sniffed at by Houyhnhyms.](#horse)
2337
24−We're strong believers in crowdsourced criticism. We've heard a lot of great objections from all kinds of directions. Surely there's more out there -- if you think of a reason Urbit can't work, and it's not listed here, please add it in a comment at the bottom, post it somewhere and send us a link, etc, etc.
25−
26−<h2 id="prime">Urbit is, like, totally not ready for prime time.</h2> **TLDR**: we agree.
27−
28−Urbit right now is barely usable as a toy. It is fun to learn Hoon -- we have seen people have actual fun. (And make actual contributions. Hoon's IEEE floating-point was written by someone we've never met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never seen anyone *not* have fun with Urbit.
29−
30−But there is all kinds of stuff wrong with the codebase. Urbit's documentation is much improved, but remains incredibly weak -- Arvo is almost totally undocumented. Scaling is poor at best. Urbit's reliability is dubious. Its security is nil.
31−
32−Urbit is feature-frozen. The only thing we're working on now, and for the rest of 2016, is doc, debugging and and self-hosting. In that order of importance -- teaching Urbit is more important than fixing it, which is more important than making it useful. But we're quite confident that these are all solvable problems.
33−
34−The most important milestone about Urbit today is that it's ready for technical decisions to be made collectively. A system like Urbit can only be invented by a mad auteur. It can't be maintained or stabilized by a mad auteur. Our primary goal today is expanding the number of people who understand Urbit, and we expect these pioneers to participate in technical governance.
35−
36−<h2 id="jets">Nock jets are a total hoax.</h2>
37−
38−**TLDR**: all of computing is a hoax. You can't compare a hoax to nothing. You can only compare it to all the other hoaxes.
39−
40−A "jet" is a sort of software device driver in Urbit. Urbit is precisely defined in terms of an interpreter that fits on a T-shirt, Nock. But a naive implementation of Nock is nowhere near practical, because Nock has only one integer operation: increment. For example, to decrement a number in Nock, you increment a counter up to the number under it.
38+*"We choose to go to the moon, not because it is easy, but because it is hard."*
39+— John F. Kennedy
4140
42−The only way an efficient Nock interpreter can work is to recognize algorithms like decrement, and implement them non-naively. By far the easiest way to do this is not to analyze arbitrary code as it's being executed, but to register and match well-known implementations in the standard library. No one should be writing their own decrement.
41+<h2 id="prime">Urbit is not ready for prime time.</h2>
4342
44−But the semantics of the interpreter, *so long as the jet and the jet harness are defined correctly*, are exactly those of Nock. We are not extending or changing Nock in any way. We are just taking a shortcut in certain cases we understand perfectly.
43+**TLDR**: we agree.
4544
46−It's not at all unprecedented to have implementations much more complex than the corresponding specification. The x86 instruction set is relatively simple; the complexity of its decoding and execution path in a modern CPU is enormous. This path may well have "peephole optimizations" that replace matched algorithms, and if it doesn't the modern compiler does. People, *bad* people, use "jets" to cheat on benchmarks all the time.
45+Urbit right now is a fun toy. It is fun to learn Hoon. It is
46+even fun and quite practical to make actual contributions.
47+(Hoon's IEEE floating-point was written by someone we've never
48+met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never
49+seen anyone *not* have fun with Urbit.
4750
48−Nock is designed as a standard. It's built like a standard. Typically what causes real problems in standards is ambiguity. Two implementations are incompatible, but each swears it has the right interpretation of the natural-language spec. This simply cannot happen in the Nock world. If two implementations disagree, at least one of them is incorrect. This puts us firmly in "with enough eyeballs, all bugs are shallow" territory.
51+But there is all kinds of stuff wrong with the codebase. Urbit's
52+documentation is much improved, but remains incredibly weak --
53+Arvo is almost totally undocumented. Scaling is poor at best.
54+Urbit's reliability is dubious. Its security is nil.
4955
50−The fact remains, however, that a Nock interpreter without jets is completely useless. And there is not even an informal document that tells you what jets you need for a reasonably efficient Urbit. (There should be such a document.)
56+Urbit is feature-frozen. The only thing we're working on now,
57+and for the rest of 2016, is doc, debugging and and self-hosting.
58+In that order of importance -- teaching Urbit is more important
59+than fixing it, which is more important than making it useful.
60+But we're quite confident that these are all solvable problems.
5161
52−The correct way to think about jets is not to compare them to a perfect interpreter created by unicorns. Jets are a combined replacement for two other techniques in language implementation: intrinsics and a foreign-function interface.
62+The most important milestone about Urbit today is that it's ready
63+for technical decisions to be made collectively. A system like
64+Urbit can only be invented by a mad auteur. It can't be
65+maintained or stabilized by a mad auteur. Our primary goal today
66+is expanding the number of people who understand Urbit, and we
67+expect these pioneers to participate in technical governance.
5368
54−Compared to both intrinsics and an FFI, your jets have one key disadvantage: they need to be specified in pure code. You may not have this executable specification, which means you need to write it. Is this really so bad for your development process? An executable specification? Which can be trivially tested against the efficient implementation?
55−
56−Compared to intrinsics, jets give you true separation between mechanism and policy; only the interpreter, not the programmer and not the compiler, needs to know what's accelerated.
57−
58−Compared to an FFI, jets preclude I/O, so can be trivially sandboxed. Except that the programmer needs to mark routines which may benefit from optimization with a hint, here too we separate mechanism (efficient implementation) from policy.
59−
60−Yes, formal verification of jet equivalence is desirable. However, in the real world, many specifications, including quite complex ones, are tested into equivalence by brute force.
61−
62−Urbit has some jet abuses. The equivalence between our markdown parser in Hoon and the CommonMark C library is super dubious. It should be taken out and shot.
63−
64−But the miscomputation resulting from a minor jet discrepancy is not a security hole or even fatal. It effectively means the event history, computed correctly, does not match the current state. The way to resolve this conflict is for the current state to win, and the event history to be discarded -- not abnormal anyway. See the next question.
69+<h2 id="jets">Nock jets are a total hoax.</h2>
6570
66−<h2 id="log">Urbit needs an infinitely extending packet/event log.</h2>
71+**TLDR**: all of computing is a hoax. You can't compare a hoax
72+to nothing. You can only compare it to all the other hoaxes.
73+
74+A "jet" is a sort of software device driver in Urbit. Urbit is
75+precisely defined in terms of an interpreter that fits on a
76+T-shirt, Nock. But a naive implementation of Nock is nowhere
77+near practical, because Nock has only one integer operation:
78+increment. For example, to decrement a number in Nock, you
79+increment a counter up to the number under it.
80+
81+The only way an efficient Nock interpreter can work is to
82+recognize algorithms like decrement, and implement them
83+non-naively. By far the easiest way to do this is not to analyze
84+arbitrary code as it's being executed, but to register and match
85+well-known implementations in the standard library. No one
86+should be writing their own decrement.
87+
88+But the semantics of the interpreter, *so long as the jet and the
89+jet harness are defined correctly*, are exactly those of Nock.
90+We are not extending or changing Nock in any way. We are just
91+taking a shortcut in certain cases we understand perfectly.
92+
93+It's not at all unprecedented to have implementations much more
94+complex than the corresponding specification. The x86
95+instruction set is relatively simple; the complexity of its
96+decoding and execution path in a modern CPU is enormous. This
97+path may well have "peephole optimizations" that replace matched
98+algorithms, and if it doesn't the modern compiler does. People,
99+*bad* people, use "jets" to cheat on benchmarks all the time.
100+
101+Nock is designed as a standard. It's built like a standard.
102+Typically what causes real problems in standards is ambiguity.
103+Two implementations are incompatible, but each swears it has the
104+right interpretation of the natural-language spec. This simply
105+cannot happen in the Nock world. If two implementations
106+disagree, at least one of them is incorrect. This puts us firmly
107+in "with enough eyeballs, all bugs are shallow" territory.
108+
109+The fact remains, however, that a Nock interpreter without jets
110+is completely useless. And there is not even an informal
111+document that tells you what jets you need for a reasonably
112+efficient Urbit. (There should be such a document.)
113+
114+The correct way to think about jets is not to compare them to a
115+perfect interpreter created by unicorns. Jets are a combined
116+replacement for two other techniques in language implementation:
117+intrinsics and a foreign-function interface.
118+
119+Compared to both intrinsics and an FFI, your jets have one key
120+disadvantage: they need to be specified in pure code. You may
121+not have this executable specification, which means you need to
122+write it. Is this really so bad for your development process?
123+An executable specification? Which can be trivially tested
124+against the efficient implementation?
125+
126+Compared to intrinsics, jets give you true separation between
127+mechanism and policy; only the interpreter, not the programmer
128+and not the compiler, needs to know what's accelerated.
129+
130+Compared to an FFI, jets preclude I/O, so can be trivially
131+sandboxed. Except that the programmer needs to mark routines
132+which may benefit from optimization with a hint, here too we
133+separate mechanism (efficient implementation) from policy.
134+
135+Yes, formal verification of jet equivalence is desirable.
136+However, in the real world, many specifications, including quite
137+complex ones, are tested into equivalence by brute force.
138+
139+Urbit has some jet abuses. The equivalence between our markdown
140+parser in Hoon and the CommonMark C library is super dubious. It
141+should be taken out and shot.
142+
143+But the miscomputation resulting from a minor jet discrepancy is
144+not a security hole or even fatal. It effectively means the
145+event history, computed correctly, does not match the current
146+state. The way to resolve this conflict is for the current state
147+to win, and the event history to be discarded -- not abnormal
148+anyway. See the next question.
149+
150+<h2 id="log">Urbit needs an infinitely extending packet/event
151+log.</h2>
67152
68153**TLDR**: no, it doesn't. Urbit can prune the log.
69154
70−We can prune the event log because the Urbit transition function doesn't have any access to the event history -- just the current state and the current event.
155+We can prune the event log because the Urbit transition function
156+doesn't have any access to the event history -- just the current
157+state and the current event.
71158
72−Urbit defines the semantics of a complete event log. It doesn't and can't require an implementation to maintain the whole log. It can maintain a checkpoint and the log since that checkpoint. The current implementation of Urbit maintains
159+Urbit defines the semantics of a complete event log. It doesn't
160+and can't require an implementation to maintain the whole log.
161+It can maintain a checkpoint and the log since that checkpoint.
162+The current implementation of Urbit maintains
73163
74−However, any practical urbit maintains a periodically updated checkpoint. Our present implementation doesn't provide a way to prune the event log. But that's just a missing feature. We have one or two of those!
164+However, any practical urbit maintains a periodically updated
165+checkpoint. Our present implementation doesn't provide a way to
166+prune the event log. But that's just a missing feature. We have
167+one or two of those!
75168
76169<h2 id="scam">Urbit is a total scamcoin. It's 100% premined</h2>
77170
78171**TLDR**: yeah. But at least it's not the DAO.
79172
80−Like a cryptocurrency, Urbit is a digital title. But Urbit is digital land, not digital money. If you assess it as a currency, it's a lousy currency. If you assess a cat as a dog, it's a lousy dog.
81−
82−In real-world economics, the crucial distinction between land and money is that land (a) has intrinsic utility and (b) is non-fungible.
83−
84−Because of (b) alone, frictionless transactions in land are impossible. A blockchain is only needed to ensure zero-cost high-frequency transactions. So digital land doesn't need a blockchain. Which means it doesn't need mining.
85−
86−Of course, just because a digital title system doesn't need mining, doesn't mean it can't distribute an initial allocation by proof-of-work -- or by any other arbitrary method which is careful not to benefit the system's own developers. Could we give away the Urbit address space randomly? Sure. But why?
87−
88−Probably the purest design is the "proof-of-burn" initial allocation used by some coins. By any standard, proof-of-burn is technically beautiful and results in an extraordinary level of ethical independence. We can't help but admire it.
89−
90−But any altcoin or metacoin is just way less work than Urbit. An altcoin can afford to burn even its creation energy, capturing no value at all from its seigniorage. Your altcoin doesn't have a clean-slate system software stack to drive. If your rocket has to go to the moon, it's going to leave a little bit of smoke in the air.
91−
92−Ethically, what makes "premining" feel wrong is that the creators of the currency are rewarded disproportionately for their effort. The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped. Nothing about Urbit matches this pattern at all.
93−
94−Curtis invented Urbit. So by the [homestead principle](https://en.wikipedia.org/wiki/Homestead_principle), he started out owning all of it. But by now, Urbit's 8-bit galaxies have already been distributed among [57 separate individuals](). Curtis owns 4 -- or 24, counting his whole family. (Some of whom he still owes money.)
95−
96−Tlon, the corporation which still runs Urbit development, has 95. (Without Tlon, there is basically no Arvo.) 50 are reserved for a hypothetical Urbit Foundation. Tlon employees have another 16.
97−
98−The rest of the galaxies belong to donors, investors, contributors, contest winners, and just random people who were in the right place at the right time. One is a Silicon Valley tycoon. Another is an Orthodox nun in a monastery in Greece. A couple are ex-Tlon employees who might totally hate us. There is nothing they all have in common, which is sort of the point.
99−
100−This property distribution looks a lot like land ownership in the real world -- complex and asymmetrical. That's no accident. If you have a problem living in New York because New York's real estate is not distributed equally among its residents, you may have a similar problem with Urbit. The reality is that Urbit, like New York, wasn't born yesterday and comes with a complex ownership history which we couldn't possibly change, even if we wanted to.
101−
102−Decentralization is hard. The only real goal of a property system in address space is to create and maintain decentralization. The whole network has to exhibit centrifugal force, not centripetal force. Proof-of-work systems certainly seem to have unexpected centripetal qualities, producing unanticipated concentrations of centralized hashpower. See the next objection.
103−
104−<h2 id="gov">Urbit isn't even really decentralized! It has a government!</h2>
105−
106−**TLDR**: it's technically impossible for Urbit to be decentralized at this stage of its life. Urbit is designed to achieve decentralization, not be born with it.
107−
108−A young network can't afford to be decentralized. It has to act as a unit. Because it has no network effect, it needs every scrap of efficiency it can get.
109−
110−A decentralized general-purpose computing network like Urbit can *only* be bootstrapped by a central government. For example, by default your urbit upgrades its OS automatically (like an "evergreen" browser) with signed network updates. Whoever signs these updates is a government by definition.
111−
112−When it's impossible to eliminate centralized power, it becomes necessary to tame, stabilize, and limit it. This should not be surprising to anyone living under a constitutional government.
113−
114−As we found out with the DAO, if a network isn't ready to be decentralized, its developers shouldn't even try. If Ethereum is hard-forked to roll back the DAO (which looks like the most probable result), it acknowledges that it both has a central government, and needs a central government. Decentralization is good. Pretend decentralization -- "decentralization theater" -- is harmful, and not a effective path to actual decentralization.
115−
116−A key test of a free software project's health is whether it can fork. So long as the unity of the public-key hierarchy and the network protocol is maintained, the Arvo kernel and Urbit system can fork in all kinds of ways without disrupting the network. Any stress will fragment the "government" that develops the kernel, and as it fragments it grows more limited and stable.
117−
118−Urbit is designed to govern itself collectively by address space ownership -- effectively, "proof of stake." Any arbitrary power, will tend to fracture along these property lines. For instance, our hot updates are sent through the galaxy hierarchy; in a development fork, active galaxies would pick upstream sources. Two implementations of a standard are better than one.
119−
120−And by fragmenting the galaxy space into 57 separate partitions, we've created a global property map which is much more likely to splinter further, than reunite.
121−
122−In the long run, every galaxy should have a separate owner, who is a human being rather than a corporation. Combining galaxy holdings will damage the reputation of both galaxies. The only reason to merge ownership is to move toward incipient monopoly. Whether a galaxy admits this openly or denies it dishonestly, its reputation will suffer.
123−
124−The technical goal of Urbit is to create a network which, *if it actually takes over the world*, inevitably becomes decentralized. Even if Urbit takes over the world, no individual or coherent organization takes over the world. There is nothing even close to a single point of failure in a mature, successful Urbit.
125−
126−This is the goal of all the new "web3" decentralized systems. If IPFS, Sandstorm or Ethereum takes over the world, nobody takes over the world. (The same is almost true of the Internet -- though it wouldn't be that surprising if a time traveler from 2116 revealed that ICANN had become a planetary government.)
127−
128−Urbit, by starting out as a centralized network, just reduces the technical problem to match the actual goal. Only long-term decentralization matters.
129−
130−It's very important that Urbit in 2116 be fully decentralized. For Urbit in 2016, pretending to be decentralized would be a joke at best, and a hoax at worst. And of course, no one can DAO us -- since the property system is still just a central registry. Among other things, we check it into Github. Github is not a blockchain -- but still, good luck with that.
131−
132−[{Sandstorm, IPFS, Ethereum, ...} is way ahead of Urbit.](#sand) <h2 id="sand">{Sandstorm, IPFS, Ethereum, ...} is way ahead of Urbit.</h2>
133−
134−In general, web3 (next distributed web) solutions don't compete with each other. They support each other. Concretely, they are all part of each others' network effect.
135−
136−IPFS, Sandstorm, Ethereum, and Urbit can all take over the world at the same time. None of them competes with the others. They enable each other.
137−
138−For instance, IPFS and Urbit are both global immutable namespaces. IPFS is a chord-routed, content-addressed namespace. Urbit is a direct-routed, identity-addressed namespace. Urbit is a typed revision-control system; IPFS is a blob store. IPFS isn't a computer; the work hasn't been done, but Urbit can easily mount the IPFS namespace and compute functionally against it.
139−
140−So the better IPFS does, the less Urbit needs to struggle against its lack of network effect. The better Urbit does, the easier it is for IPFS to point to a functional language that can actually use its referential transparency directly. So their relationship is symbiotic, not competitive at all.
141−
142−The closest thing to a general-purpose competitor that Urbit has is Sandstorm. Sandstorm, which by the way rocks, is also a personal server built around a network protocol.
143−
144−But Sandstorm and Urbit compete in the way that, on the PC, the OS and the browser compete. In theory, the OS could solve the problems that the browser solves; or the browser could be the OS. In practice, Windows is a great OS to run a browser on.
145−
146−Similarly, a world in which Sandstorm takes off is an awesome world for Urbit, because everyone who has a Sandstorm instance has a great platform for running Urbit on. Urbit on Sandstorm will be a sort of "double-hulled" personal server, safer and more friendly than either system alone.
147−
148−Sandstorm and Urbit have very different approaches to network identification; Sandstorm uses capabilities, Urbit identity. Broadly speaking, we believe, capabilities are optimal for expressive power; but identity is optimal for the UI of the common case. We'd need to see the Powerbox, Sandstorm's UI, more fully fleshed out to understand its UI approach better.
149−
150−<h2 id="planet">Urbit doesn't have enough planets for every human being.</h2>
151−
152−A 32-bit planet is a tool, not a toy. Like a car, it's a device for a responsible and independent adult. There aren't 4 billion cars in the world, nor 4 billion independent adults.
153−
154−If you aren't an independent adult, and you don't need or even shouldn't have unconditional digital freedom (no one's 8-year-old daughter needs unconditional digital freedom), a moon from someone else's planet is fine. (Even most of today's independent adults don't complain enough about being Facebook's moons.)
155−
156−And limiting the supply of anything doesn't create a shortage. It sets a price. Ideally, in the long run, we think a planet should cost about $10. This could be off by an order of magnitude either way, and it wouldn't be the end of the world.
157−
158−If a planet costs $10, that means you paid $10 to get a planet. A planet with no reputation has a positive reputation, because someone paid $10 for it and hasn't yet done anything wrong. Positive default reputation is the single quality that makes a social network social.
159−
160−There is always a tradeoff between free speech and free beer. Urbit will always choose free speech.
173+Like a cryptocurrency, Urbit is a digital title. But Urbit is
174+digital land, not digital money. If you assess it as a currency,
175+it's a lousy currency. If you assess a cat as a dog, it's a
176+lousy dog.
177+
178+In real-world economics, the crucial distinction between land and
179+money is that land (a) has intrinsic utility and (b) is
180+non-fungible.
181+
182+Because of (b) alone, frictionless transactions in land are
183+impossible. A blockchain is only needed to ensure zero-cost
184+high-frequency transactions. So digital land doesn't need a
185+blockchain. Which means it doesn't need mining.
186+
187+Of course, just because a digital title system doesn't need
188+mining, doesn't mean it can't distribute an initial allocation by
189+proof-of-work -- or by any other arbitrary method which is
190+careful not to benefit the system's own developers. Could we
191+give away the Urbit address space randomly? Sure. But why?
192+
193+Probably the purest design is the "proof-of-burn" initial
194+allocation used by some coins. By any standard, proof-of-burn is
195+technically beautiful and results in an extraordinary level of
196+ethical independence. We can't help but admire it.
197+
198+But any altcoin or metacoin is just way less work than Urbit. An
199+altcoin can afford to burn even its creation energy, capturing no
200+value at all from its seigniorage. Your altcoin doesn't have a
201+clean-slate system software stack to drive. If your rocket has
202+to go to the moon, it's going to leave a little bit of smoke in
203+the air.
204+
205+Ethically, what makes "premining" feel wrong is that the creators
206+of the currency are rewarded disproportionately for their effort.
207+The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.
208+Nothing about Urbit matches this pattern at all.
209+
210+Curtis invented Urbit. So by the [homestead
211+principle](https://en.wikipedia.org/wiki/Homestead_principle), he
212+started out owning all of it. But by now, Urbit's 8-bit galaxies
213+have already been distributed among [57 separate individuals]().
214+Curtis owns 4 -- or 24, counting his whole family. (Some of whom
215+he still owes money.)
216+
217+Tlon, the corporation which still runs Urbit development, has 95.
218+(Without Tlon, there is basically no Arvo.) 50 are reserved for
219+a hypothetical Urbit Foundation. Tlon employees have another 16.
220+
221+The rest of the galaxies belong to donors, investors,
222+contributors, contest winners, and just random people who were in
223+the right place at the right time. One is a Silicon Valley
224+tycoon. Another is an Orthodox nun in a monastery in Greece. A
225+couple are ex-Tlon employees who might totally hate us. There is
226+nothing they all have in common, which is sort of the point.
227+
228+This property distribution looks a lot like land ownership in the
229+real world -- complex and asymmetrical. That's no accident. If
230+you have a problem living in New York because New York's real
231+estate is not distributed equally among its residents, you may
232+have a similar problem with Urbit. The reality is that Urbit,
233+like New York, wasn't born yesterday and comes with a complex
234+ownership history which we couldn't possibly change, even if we
235+wanted to.
236+
237+Decentralization is hard. The only real goal of a property
238+system in address space is to create and maintain
239+decentralization. The whole network has to exhibit centrifugal
240+force, not centripetal force. Proof-of-work systems certainly
241+seem to have unexpected centripetal qualities, producing
242+unanticipated concentrations of centralized hashpower. See the
243+next objection.
244+
245+<h2 id="gov">Urbit isn't even really decentralized! It has a
246+government!</h2>
247+
248+**TLDR**: it's technically impossible for Urbit to be
249+decentralized at this stage of its life. Urbit is designed to
250+achieve decentralization, not be born with it.
251+
252+A young network can't afford to be decentralized. It has to act
253+as a unit. Because it has no network effect, it needs every
254+scrap of efficiency it can get.
255+
256+A decentralized general-purpose computing network like Urbit can
257+*only* be bootstrapped by a central government. For example, by
258+default your urbit upgrades its OS automatically (like an
259+"evergreen" browser) with signed network updates. Whoever signs
260+these updates is a government by definition.
261+
262+When it's impossible to eliminate centralized power, it becomes
263+necessary to tame, stabilize, and limit it. This should not be
264+surprising to anyone living under a constitutional government.
265+
266+As we found out with the DAO, if a network isn't ready to be
267+decentralized, its developers shouldn't even try. If Ethereum is
268+hard-forked to roll back the DAO (which looks like the most
269+probable result), it acknowledges that it both has a central
270+government, and needs a central government. Decentralization is
271+good. Pretend decentralization -- "decentralization theater" --
272+is harmful, and not a effective path to actual decentralization.
273+
274+A key test of a free software project's health is whether it can
275+fork. So long as the unity of the public-key hierarchy and the
276+network protocol is maintained, the Arvo kernel and Urbit system
277+can fork in all kinds of ways without disrupting the network.
278+Any stress will fragment the "government" that develops the
279+kernel, and as it fragments it grows more limited and stable.
280+
281+Urbit is designed to govern itself collectively by address space
282+ownership -- effectively, "proof of stake." Any arbitrary power,
283+will tend to fracture along these property lines. For instance,
284+our hot updates are sent through the galaxy hierarchy; in a
285+development fork, active galaxies would pick upstream sources.
286+Two implementations of a standard are better than one.
287+
288+And by fragmenting the galaxy space into 57 separate partitions,
289+we've created a global property map which is much more likely to
290+splinter further, than reunite.
291+
292+In the long run, every galaxy should have a separate owner, who
293+is a human being rather than a corporation. Combining galaxy
294+holdings will damage the reputation of both galaxies. The only
295+reason to merge ownership is to move toward incipient monopoly.
296+Whether a galaxy admits this openly or denies it dishonestly, its
297+reputation will suffer.
298+
299+The technical goal of Urbit is to create a network which, *if it
300+actually takes over the world*, inevitably becomes decentralized.
301+Even if Urbit takes over the world, no individual or coherent
302+organization takes over the world. There is nothing even close
303+to a single point of failure in a mature, successful Urbit.
304+
305+This is the goal of all the new "web3" decentralized systems. If
306+IPFS, Sandstorm or Ethereum takes over the world, nobody takes
307+over the world. (The same is almost true of the Internet --
308+though it wouldn't be that surprising if a time traveler from
309+2116 revealed that ICANN had become a planetary government.)
310+
311+Urbit, by starting out as a centralized network, just reduces the
312+technical problem to match the actual goal. Only long-term
313+decentralization matters.
314+
315+It's very important that Urbit in 2116 be fully decentralized.
316+For Urbit in 2016, pretending to be decentralized would be a joke
317+at best, and a hoax at worst. And of course, no one can DAO us
318+-- since the property system is still just a central registry.
319+Among other things, we check it into Github. Github is not a
320+blockchain -- but still, good luck with that.
321+
322+[{Sandstorm, IPFS, Ethereum, ...} is way ahead of Urbit.](#sand)
323+<h2 id="sand">{Sandstorm, IPFS, Ethereum, ...} is way ahead of
324+Urbit.</h2>
325+
326+In general, web3 (next distributed web) solutions don't compete
327+with each other. They support each other. Concretely, they are
328+all part of each others' network effect.
329+
330+IPFS, Sandstorm, Ethereum, and Urbit can all take over the world
331+at the same time. None of them competes with the others. They
332+enable each other.
333+
334+For instance, IPFS and Urbit are both global immutable
335+namespaces. IPFS is a chord-routed, content-addressed namespace.
336+Urbit is a direct-routed, identity-addressed namespace. Urbit is
337+a typed revision-control system; IPFS is a blob store. IPFS
338+isn't a computer; the work hasn't been done, but Urbit can easily
339+mount the IPFS namespace and compute functionally against it.
340+
341+So the better IPFS does, the less Urbit needs to struggle against
342+its lack of network effect. The better Urbit does, the easier it
343+is for IPFS to point to a functional language that can actually
344+use its referential transparency directly. So their relationship
345+is symbiotic, not competitive at all.
346+
347+The closest thing to a general-purpose competitor that Urbit has
348+is Sandstorm. Sandstorm, which by the way rocks, is also a
349+personal server built around a network protocol.
350+
351+But Sandstorm and Urbit compete in the way that, on the PC, the
352+OS and the browser compete. In theory, the OS could solve the
353+problems that the browser solves; or the browser could be the OS.
354+In practice, Windows is a great OS to run a browser on.
355+
356+Similarly, a world in which Sandstorm takes off is an awesome
357+world for Urbit, because everyone who has a Sandstorm instance
358+has a great platform for running Urbit on. Urbit on Sandstorm
359+will be a sort of "double-hulled" personal server, safer and more
360+friendly than either system alone.
361+
362+Sandstorm and Urbit have very different approaches to network
363+identification; Sandstorm uses capabilities, Urbit identity.
364+Broadly speaking, we believe, capabilities are optimal for
365+expressive power; but identity is optimal for the UI of the
366+common case. We'd need to see the Powerbox, Sandstorm's UI, more
367+fully fleshed out to understand its UI approach better.
368+
369+<h2 id="planet">Urbit doesn't have enough planets for every human
370+being.</h2>
371+
372+A 32-bit planet is a tool, not a toy. Like a car, it's a device
373+for a responsible and independent adult. There aren't 4 billion
374+cars in the world, nor 4 billion independent adults.
375+
376+If you aren't an independent adult, and you don't need or even
377+shouldn't have unconditional digital freedom (no one's 8-year-old
378+daughter needs unconditional digital freedom), a moon from
379+someone else's planet is fine. (Even most of today's independent
380+adults don't complain enough about being Facebook's moons.)
381+
382+And limiting the supply of anything doesn't create a shortage.
383+It sets a price. Ideally, in the long run, we think a planet
384+should cost about $10. This could be off by an order of
385+magnitude either way, and it wouldn't be the end of the world.
386+
387+If a planet costs $10, that means you paid $10 to get a planet.
388+A planet with no reputation has a positive reputation, because
389+someone paid $10 for it and hasn't yet done anything wrong.
390+Positive default reputation is the single quality that makes a
391+social network social.
392+
393+There is always a tradeoff between free speech and free beer.
394+Urbit will always choose free speech.
161395
162396<h2 id="pwned">Cloud computing is inherently non-private.</h2>
163397
164−**TLDR**: a general-purpose cloud computer is much, much more private than a special-purpose cloud computer. In general, a cloud VM is secure against corporations but not governments. With a global adversary, compute in your closet -- or even on your body.
165−
166−One reason we want the decentralized Internet is that we're tired of giant corporations spying on us. Think about it this way: Amazon is Netflix's main competitor. And yet, Netflix runs its whole operation on AWS. Why is Netflix sure that Amazon won't spy on it?
167−
168−A general-purpose virtual machine is special from a privacy standpoint, just because it's commercially realistic to design terms of service that prevent the host from peeking and poking at the customer's machine. Crossing this moat is technically nontrivial and can't possibly happen by any reasonable accident. No hosting contract could contemplate it.
169−
170−Whereas when your cloud computer is a special-purpose machine -- just a database row on some corporation's mainframe -- there is no way these services can promise not to handle your data. Handling your data is *what they do*. On a special-purpose server, the concept of privacy is not even defined.
171−
172−Where even a general-purpose server falls down is where the user has a sovereign adversary, which can secretly violate explicit or implicit hosting contracts. Users with a sovereign adversary must rely only on their own physical security.
173−
174−However, most users don't have a sovereign adversary. And those who do maximize their "herd immunity" if they can use the same protocols as those who don't. Otherwise, the adversary could simply focus on everyone who uses the secure protocols.
175−
176−Also, the portability of a cloud server image is critical. Of course, since Urbit is formally specified, it's trivially portable. In fact, one strategy against sovereign adversaries may be continuous rotation between hosts, like an MX missile.
177−
178−<h2 id="code">Urbit will never be able to call any existing code.</h2>
179−
180−**TLDR**: neither will Javascript. And dear Unix, the browser does not miss interacting with your `$LD_LIBRARY_PATH` at all.
181−
182−You can't talk to the OS or use system libraries from Javascript. Therefore, there is no point in having any kind of gateway, compatibility bridge, native methods, or other interface between Javascript and C.
183−
184−When in doubt, remember that Urbit is "the browser for the server side." It plays by the same general rules. Isolation means isolation.
185−
186−[There's no way Urbit will ever be adopted. It's too weird.](#weird) <h2 id="weird">There's no way Urbit will ever be adopted. It's too weird.</h2>
187−
188−**TLDR**: Urbit adoption is designed to be driven by ordinary end users. Urbit isn't ready for ordinary end users yet. We're working on it -- come help.
189−
190−Right now, Urbit is a developer tool. Or rather, a developer toy -- since the only thing it's useful for is developing Urbit. It also could be a much better toy. We're working on that too.
191−
192−But it's absolutely wrong to think of Urbit being adopted as a developer tool in the conventional sense. If you think this is almost impossible, you're right.
193−
194−If we look at the way most successful platforms are adopted, they're not adopted for their own virtues. They're adopted because they're part of a larger solution. It's very hard to displace a native component of an existing platform. Urbit is not trying to do this.
195−
196−C is a better language than Pascal, but it didn't beat Pascal because it's a better language. C beat Pascal because C was the native language of Unix, and people wanted to program in Unix. People don't use Javascript because Javascript is a great language, but because it's the native language of the browser. Replacing the native language of a platform may be doable -- but it's incredibly hard.
197−
198−Hoon is not competing with C, or even Haskell, as a Unix programming language. The only reason to program in Hoon is that it's the native language of Urbit. Urbit is not competing with node.js or Rails as a Web backend. The only reason to run Urbit is to run a personal server.
199−
200−Nock is cool, but it only gets adopted if Hoon gets adopted. Hoon is cool, but it only gets adopted if Urbit gets adopted. Urbit only gets adopted if it's useful as a personal server for human beings -- most of whom won't be Hoon programmers, or programmers at all.
201−
202−<h2 id="program">Hoon is too weird. No one will be able to program in it.</h2>
203−
204−**TLDR**: Hoon is ridiculously simple. Our documentation and tooling are just immature.
205−
206−It's pretty fair to assume that (a) functional programming is hard and weird, (b) Hoon is weird even for a functional language, so (c) Hoon must be hard-squared.
207−
208−Actually, Hoon is weird even for a functional language because it's an attempt to remove the hardest things about functional programming: category theory, lazy evaluation, and gratuitous abstraction. To know a language is to know what the compiler is doing; all the semantics of the Hoon compiler fit in 2000 lines of code.
209−
210−It's too easy for us to wind up living in Isaac Asimov's Trantor, a world in which everything got invented thousands of years ago and the idea of new technology is just weird and scary. History isn't over yet, and nor is technical history.
211−
212−New things are harder to learn than old things. We ask smart high-school students to learn calculus. Think about how much harder it was for Newton and Leibniz to invent calculus, or for their first students to pick it up. Hoon is nowhere near as hard as calculus.
213−
214−Most of the difference is just the collective certainty that our society conveys to a high-school student that calculus is learnable. When you're learning Urbit, you don't have this collective knowledge; so you don't have the confidence that the problem is solvable. Confidence makes a huge difference. Moreover, any bug or glitch in the developer experience destroys this confidence and takes a long time to heal.
215−
216−Yes, we know: Hoon remains quite hard to learn. Again, we have no reason to think this problem isn't solvable. Public enlightenment remains our main priority.
398+**TLDR**: a general-purpose cloud computer is much, much more
399+private than a special-purpose cloud computer. In general, a
400+cloud VM is secure against corporations but not governments.
401+With a global adversary, compute in your closet -- or even on
402+your body.
403+
404+One reason we want the decentralized Internet is that we're tired
405+of giant corporations spying on us. Think about it this way:
406+Amazon is Netflix's main competitor. And yet, Netflix runs its
407+whole operation on AWS. Why is Netflix sure that Amazon won't
408+spy on it?
409+
410+A general-purpose virtual machine is special from a privacy
411+standpoint, just because it's commercially realistic to design
412+terms of service that prevent the host from peeking and poking at
413+the customer's machine. Crossing this moat is technically
414+nontrivial and can't possibly happen by any reasonable accident.
415+No hosting contract could contemplate it.
416+
417+Whereas when your cloud computer is a special-purpose machine --
418+just a database row on some corporation's mainframe -- there is
419+no way these services can promise not to handle your data.
420+Handling your data is *what they do*. On a special-purpose
421+server, the concept of privacy is not even defined.
422+
423+Where even a general-purpose server falls down is where the user
424+has a sovereign adversary, which can secretly violate explicit or
425+implicit hosting contracts. Users with a sovereign adversary
426+must rely only on their own physical security.
427+
428+However, most users don't have a sovereign adversary. And those
429+who do maximize their "herd immunity" if they can use the same
430+protocols as those who don't. Otherwise, the adversary could
431+simply focus on everyone who uses the secure protocols.
432+
433+Also, the portability of a cloud server image is critical. Of
434+course, since Urbit is formally specified, it's trivially
435+portable. In fact, one strategy against sovereign adversaries
436+may be continuous rotation between hosts, like an MX missile.
437+
438+<h2 id="code">Urbit will never be able to call any existing
439+code.</h2>
440+
441+**TLDR**: neither will Javascript. And dear Unix, the browser
442+does not miss interacting with your `$LD_LIBRARY_PATH` at all.
443+
444+You can't talk to the OS or use system libraries from Javascript.
445+Therefore, there is no point in having any kind of gateway,
446+compatibility bridge, native methods, or other interface between
447+Javascript and C.
448+
449+When in doubt, remember that Urbit is "the browser for the server
450+side." It plays by the same general rules. Isolation means
451+isolation.
452+
453+[There's no way Urbit will ever be adopted. It's too
454+weird.](#weird) <h2 id="weird">There's no way Urbit will ever be
455+adopted. It's too weird.</h2>
456+
457+**TLDR**: Urbit adoption is designed to be driven by ordinary end
458+users. Urbit isn't ready for ordinary end users yet. We're
459+working on it -- come help.
460+
461+Right now, Urbit is a developer tool. Or rather, a developer toy
462+-- since the only thing it's useful for is developing Urbit. It
463+also could be a much better toy. We're working on that too.
464+
465+But it's absolutely wrong to think of Urbit being adopted as a
466+developer tool in the conventional sense. If you think this is
467+almost impossible, you're right.
468+
469+If we look at the way most successful platforms are adopted,
470+they're not adopted for their own virtues. They're adopted
471+because they're part of a larger solution. It's very hard to
472+displace a native component of an existing platform. Urbit is
473+not trying to do this.
474+
475+C is a better language than Pascal, but it didn't beat Pascal
476+because it's a better language. C beat Pascal because C was the
477+native language of Unix, and people wanted to program in Unix.
478+People don't use Javascript because Javascript is a great
479+language, but because it's the native language of the browser.
480+Replacing the native language of a platform may be doable -- but
481+it's incredibly hard.
482+
483+Hoon is not competing with C, or even Haskell, as a Unix
484+programming language. The only reason to program in Hoon is that
485+it's the native language of Urbit. Urbit is not competing with
486+node.js or Rails as a Web backend. The only reason to run Urbit
487+is to run a personal server.
488+
489+Nock is cool, but it only gets adopted if Hoon gets adopted.
490+Hoon is cool, but it only gets adopted if Urbit gets adopted.
491+Urbit only gets adopted if it's useful as a personal server for
492+human beings -- most of whom won't be Hoon programmers, or
493+programmers at all.
494+
495+<h2 id="program">Hoon is too weird. No one will be able to
496+program in it.</h2>
497+
498+**TLDR**: Hoon is ridiculously simple. Our documentation and
499+tooling are just immature.
500+
501+It's pretty fair to assume that (a) functional programming is
502+hard and weird, (b) Hoon is weird even for a functional language,
503+so (c) Hoon must be hard-squared.
504+
505+Actually, Hoon is weird even for a functional language because
506+it's an attempt to remove the hardest things about functional
507+programming: category theory, lazy evaluation, and gratuitous
508+abstraction. To know a language is to know what the compiler is
509+doing; all the semantics of the Hoon compiler fit in 2000 lines
510+of code.
511+
512+It's too easy for us to wind up living in Isaac Asimov's Trantor,
513+a world in which everything got invented thousands of years ago
514+and the idea of new technology is just weird and scary. History
515+isn't over yet, and nor is technical history.
516+
517+New things are harder to learn than old things. We ask smart
518+high-school students to learn calculus. Think about how much
519+harder it was for Newton and Leibniz to invent calculus, or for
520+their first students to pick it up. Hoon is nowhere near as hard
521+as calculus.
522+
523+Most of the difference is just the collective certainty that our
524+society conveys to a high-school student that calculus is
525+learnable. When you're learning Urbit, you don't have this
526+collective knowledge; so you don't have the confidence that the
527+problem is solvable. Confidence makes a huge difference.
528+Moreover, any bug or glitch in the developer experience destroys
529+this confidence and takes a long time to heal.
530+
531+Yes, we know: Hoon remains quite hard to learn. Again, we have
532+no reason to think this problem isn't solvable. Public
533+enlightenment remains our main priority.
217534
218535<h2 id="stuck">Urbit programmers are stuck with Hoon.</h2>
219536
220537**TLDR**: patience, grasshopper.
221538
222−There's quite a straightforward way to implement any perfectly specified language with a reliable interpreter in Hoon. First, write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.
223−
224−It is not clear that Javascript is *quite* well-defined enough for this treatment. But Lua probably is.
225−
226−<h2 id="user">Ordinary users will never be able to manage an Urbit server.</h2>
227−
228−**TLDR**: Urbit's technical simplicity has always been designed to drive human usability. But the polish is the last thing that goes on. So we can't evaluate this claim right now.
229−
230−Right now, Urbit is only for geeks. You already need to be able to wrangle a Unix machine to run it. What's the point?
231−
232−This Urbit isn't the real Urbit. It's an early milestone on the way to the real Urbit.
233−
234−The real Urbit -- for normal human beings -- is a hosted service. Getting a planet is as easy as signing up for Facebook. Probably many users will think of it as another web account. They might not even know it can run more apps than the ones they use.
235−
236−A deterministic, persistent cloud computer is something different from a traditional server. Normally when we think of a server in the cloud, we think of it like a live animal -- a creature that needs to be cared for, fed, and herded. A file in the cloud is more like a rock -- you can forget about it for ten years.
237−
238−An urbit is a general-purpose computer, but it doesn't even have the concept of a reboot. It upgrades itself. If you don't feed it any packets for ten years, then turn it back on, it will spend a day or two upgrading itself, then be back to normal. Maybe it's something in between a rock and an animal -- a cactus?
239−
240−Another huge difference versus an Internet server is that we're confident that Urbit's limited supply of identities will make it easy to keep abusers off the network. So far, so good -- but of course, no one abuses a young network.
241−
242−The bottom line is that managing your urbit has to be as easy as managing your iPhone. Normally, it consists of deciding what apps you want to be running, and how much you trust them. Resources can't be free, so sometimes you have to play memory police. Humans have shown that they can handle these tasks.
243−
244−Our '70s OSes and networks, which were great designs in their day and have matured into excellent industrial tools, give us a totally misleading impression of how hard it should be to manage a general-purpose computer. Computing isn't scary or dangerous. Unix and the Internet are scary and dangerous. That's fine for an industrial tool, but not a personal tool.
539+There's quite a straightforward way to implement any perfectly
540+specified language with a reliable interpreter in Hoon. First,
541+write an interpreter for that language in Hoon. Second, jet that
542+intepreter function with the existing implementation.
543+
544+It is not clear that Javascript is *quite* well-defined enough
545+for this treatment. But Lua probably is.
546+
547+<h2 id="user">Ordinary users will never be able to manage an
548+Urbit server.</h2>
549+
550+**TLDR**: Urbit's technical simplicity has always been designed
551+to drive human usability. But the polish is the last thing that
552+goes on. So we can't evaluate this claim right now.
553+
554+Right now, Urbit is only for geeks. You already need to be able
555+to wrangle a Unix machine to run it. What's the point?
556+
557+This Urbit isn't the real Urbit. It's an early milestone on the
558+way to the real Urbit.
559+
560+The real Urbit -- for normal human beings -- is a hosted service.
561+Getting a planet is as easy as signing up for Facebook. Probably
562+many users will think of it as another web account. They might
563+not even know it can run more apps than the ones they use.
564+
565+A deterministic, persistent cloud computer is something different
566+from a traditional server. Normally when we think of a server in
567+the cloud, we think of it like a live animal -- a creature that
568+needs to be cared for, fed, and herded. A file in the cloud is
569+more like a rock -- you can forget about it for ten years.
570+
571+An urbit is a general-purpose computer, but it doesn't even have
572+the concept of a reboot. It upgrades itself. If you don't feed
573+it any packets for ten years, then turn it back on, it will spend
574+a day or two upgrading itself, then be back to normal. Maybe
575+it's something in between a rock and an animal -- a cactus?
576+
577+Another huge difference versus an Internet server is that we're
578+confident that Urbit's limited supply of identities will make it
579+easy to keep abusers off the network. So far, so good -- but of
580+course, no one abuses a young network.
581+
582+The bottom line is that managing your urbit has to be as easy as
583+managing your iPhone. Normally, it consists of deciding what
584+apps you want to be running, and how much you trust them.
585+Resources can't be free, so sometimes you have to play memory
586+police. Humans have shown that they can handle these tasks.
587+
588+Our '70s OSes and networks, which were great designs in their day
589+and have matured into excellent industrial tools, give us a
590+totally misleading impression of how hard it should be to manage
591+a general-purpose computer. Computing isn't scary or dangerous.
592+Unix and the Internet are scary and dangerous. That's fine for
593+an industrial tool, but not a personal tool.
245594
246595<h2 id="killer">Urbit has no killer app.</h2>
247596
248597**TLDR**: the killer app is personal API aggregation.
249598
250−It's a truism that any new platform has to be fundamentally much better at solving some problem than the mature platform it seeks to replace.
251−
252−We can look at Urbit's killer app from two perspectives: as a developer, and as a user.
253−
254−From the developer's perspective, Urbit's advantage is that it's a network stack which provides exactly-once delivery of typed, validated, transactional, encrypted and authenticated messages. The difference between an Urbit API and a REST API is like the difference between a paved road and a dirt road. On the other hand, you do need to learn a new functional language.
255−
256−From the user's perspective, there's one task that any personal server can perform, that can't be performed by any Web service: unrestricted API aggregation.
257−
258−Well before Urbit is ready to *replace* any conventional web services, it should be ready to *command* them in place by API. (Or if needed, by scraping.) If all you care about is being in control of your own data, it's fine to leave it in the hands of these services, as you have the API secrets to get it out.
259−
260−Managing a set of security connections to your existing services is one of the first important tasks of a modern personal server. This is a stateful task that typically requires both a durable API key and a temporary OAuth token. APIs change all the time, so connection maintenance also requires evergreen updates.
261−
262−The origin of this API key will vary, but usually the best way to set it is BYOK: the user registers their own urbit as an "app." And the neat thing about having your own API keys, for multiple services, on a single general-purpose computer, is that none of these services really has any practical way to control what you do with your own data.
263−
264−Terms of service which constrain the use of data (as opposed to the abuse of the service) simply aren't realistic and will no longer apply. This enables a variety of novel user experiences which aren't implementable as traditional web services, and also aren't available via conventional third-party API aggregators.
265−
266−Also, since Urbit is after all quite immature, it doesn't make much sense to restrict this security state to code within Urbit. The Urbit interpreter `vere` runs as a Unix daemon that implements the FUSE user-level filesystem protocol, and maps the data on your services into the Unix filesystem. For example, one of our demos lets you `ls` your Github issues.
267−
268−So it's straightforward to build, for instance, a Python app that uses Urbit as a gateway to mash up a bunch of web services. As a Unix programmer, you might even just regard Urbit as a generic Web API gateway daemon, without worrying about its internals.
269−
270−We have other ideas for initial killer apps. But this, we feel, is the best one. API libraries for `npm` et al abound. Stateful, self-updating, generic API aggregators with FUSE integration, also integrated with a reactive web server, are rarer.
271−
272−<h2 id="dictator">Urbit is a reactionary digital dictatorship.</h2>
273−**TLDR**: Facebook is a digital dictatorship. Urbit is a decentralized network with a republican constitution.
274−
275−It's especially important to combat the impression that Tlon is a reactionary conspiracy. Tlon is a Delaware corporation. It exists to make its investors as rich as possible. We are not aware of our investors' ideologies. We are pretty confident that they don't take precedence, ever, over turning a profit.
276−
277−As in any corporation, Tlon's employees work for its investors. Those employees would have trouble conspiring in any political sense, though. In 2016 election terms, two of us are for Sanders, one for Clinton, and two for Trump.
278−
279−Now, in the long run, it's quite wrong for Urbit to be run by any profit-oriented corporation, Delaware or otherwise. This is why we've partitioned off 50 galaxies for a future Urbit Foundation. Furthermore, the power of *any* central body in Urbit is designed to wane over time. But we can't get ahead of ourselves in this. Urbit, to create an effective and competent digital republic, needs to move slowly and carefully in establishing it.
599+It's a truism that any new platform has to be fundamentally much
600+better at solving some problem than the mature platform it seeks
601+to replace.
602+
603+We can look at Urbit's killer app from two perspectives: as a
604+developer, and as a user.
605+
606+From the developer's perspective, Urbit's advantage is that it's
607+a network stack which provides exactly-once delivery of typed,
608+validated, transactional, encrypted and authenticated messages.
609+The difference between an Urbit API and a REST API is like the
610+difference between a paved road and a dirt road. On the other
611+hand, you do need to learn a new functional language.
612+
613+From the user's perspective, there's one task that any personal
614+server can perform, that can't be performed by any Web service:
615+unrestricted API aggregation.
616+
617+Well before Urbit is ready to *replace* any conventional web
618+services, it should be ready to *command* them in place by API.
619+(Or if needed, by scraping.) If all you care about is being in
620+control of your own data, it's fine to leave it in the hands of
621+these services, as you have the API secrets to get it out.
622+
623+Managing a set of security connections to your existing services
624+is one of the first important tasks of a modern personal server.
625+This is a stateful task that typically requires both a durable
626+API key and a temporary OAuth token. APIs change all the time,
627+so connection maintenance also requires evergreen updates.
628+
629+The origin of this API key will vary, but usually the best way to
630+set it is BYOK: the user registers their own urbit as an "app."
631+And the neat thing about having your own API keys, for multiple
632+services, on a single general-purpose computer, is that none of
633+these services really has any practical way to control what you
634+do with your own data.
635+
636+Terms of service which constrain the use of data (as opposed to
637+the abuse of the service) simply aren't realistic and will no
638+longer apply. This enables a variety of novel user experiences
639+which aren't implementable as traditional web services, and also
640+aren't available via conventional third-party API aggregators.
641+
642+Also, since Urbit is after all quite immature, it doesn't make
643+much sense to restrict this security state to code within Urbit.
644+The Urbit interpreter `vere` runs as a Unix daemon that
645+implements the FUSE user-level filesystem protocol, and maps the
646+data on your services into the Unix filesystem. For example, one
647+of our demos lets you `ls` your Github issues.
648+
649+So it's straightforward to build, for instance, a Python app that
650+uses Urbit as a gateway to mash up a bunch of web services. As a
651+Unix programmer, you might even just regard Urbit as a generic
652+Web API gateway daemon, without worrying about its internals.
653+
654+We have other ideas for initial killer apps. But this, we feel,
655+is the best one. API libraries for `npm` et al abound.
656+Stateful, self-updating, generic API aggregators with FUSE
657+integration, also integrated with a reactive web server, are
658+rarer.
659+
660+<h2 id="dictator">Urbit is a reactionary digital
661+dictatorship.</h2>
662+
663+**TLDR**: Facebook is a digital dictatorship.
664+Urbit is a decentralized network with a republican constitution.
665+
666+It's especially important to combat the impression that Tlon is a
667+reactionary conspiracy. Tlon is a Delaware corporation. It
668+exists to make its investors as rich as possible. We are not
669+aware of our investors' ideologies. We are pretty confident that
670+they don't take precedence, ever, over turning a profit.
671+
672+As in any corporation, Tlon's employees work for its investors.
673+Those employees would have trouble conspiring in any political
674+sense, though. In 2016 election terms, two of us are for
675+Sanders, one for Clinton, and two for Trump.
676+
677+Now, in the long run, it's quite wrong for Urbit to be run by any
678+profit-oriented corporation, Delaware or otherwise. This is why
679+we've partitioned off 50 galaxies for a future Urbit Foundation.
680+Furthermore, the power of *any* central body in Urbit is designed
681+to wane over time. But we can't get ahead of ourselves in this.
682+Urbit, to create an effective and competent digital republic,
683+needs to move slowly and carefully in establishing it.
280684
281685<h2 id="horse">Urbit is sniffed at by Houyhnhyms.</h2>
282686
283−It's difficult to categorize [this awesome essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/) a single bullet point. So I've saved it for last.
687+It's difficult to categorize [this awesome
688+essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)
689+a single bullet point. So I've saved it for last.
284690
285−When reading this essay, it's important not to forget the amazing absence of genuine, mutually critical discourse in computer science (as in most sciences today). You never hear what Swift's designers think of Go, or vice versa. And critical public discourse decreases, not increases, with increasing academic legitimacy.
691+When reading this essay, it's important not to forget the amazing
692+absence of genuine, mutually critical discourse in computer
693+science (as in most sciences today). You never hear what Swift's
694+designers think of Go, or vice versa. And critical public
695+discourse decreases, not increases, with increasing academic
696+legitimacy.
286697
287−The basic test of any field purportedly scientific in nature is whether its researchers are genuinely interested in each others' work, and willing to share these genuine responses publicly. If this practice does not exist, the field may still be useful and/or interesting. But it is not science.
698+The basic test of any field purportedly scientific in nature is
699+whether its researchers are genuinely interested in each others'
700+work, and willing to share these genuine responses publicly. If
701+this practice does not exist, the field may still be useful
702+and/or interesting. But it is not science.
288703
289−What's awesome about Fare's essay is that he's *doing it right*. All the actual details are irrelevant. And mostly wrong. But that's of very little importance compared to *doing it right*.
704+What's awesome about Fare's essay is that he's *doing it right*.
705+All the actual details are irrelevant. And mostly wrong. But
706+that's of very little importance compared to *doing it right*.
290707
291−Anyway, we've already addressed the idea that jets are a sham. Some other points:
708+Anyway, we've already addressed the idea that jets are a sham.
709+Some other points:
292710
293711### Event-sourcing and/or caching is a pattern, not a layer
294712
295−Fare' is perfectly right that "one size does not fit all" in persistence. Generally, Urbit uses event-sourced persistence.
713+Fare' is perfectly right that "one size does not fit all" in
714+persistence. Generally, Urbit uses event-sourced persistence.
296715
297−But it has multiple layers of event-sourcing: in the definition of Urbit itself; in the application sandbox vane (Gall), and in the application itself. Urbit also has a completely orthogonal revision control system (Clay).
716+But it has multiple layers of event-sourcing: in the definition
717+of Urbit itself; in the application sandbox vane (Gall), and in
718+the application itself. Urbit also has a completely orthogonal
719+revision control system (Clay).
298720
299−And there is not a single cache across the whole system, though arguably there should be; for instance, the functional build system (Ford, which Fare' the master of build systems might appreciate) has its own internal cache.
721+And there is not a single cache across the whole system, though
722+arguably there should be; for instance, the functional build
723+system (Ford, which Fare' the master of build systems might
724+appreciate) has its own internal cache.
300725
301−It is a common mistake to confuse a design pattern with a layer or feature, and equally fatal whichever direction you fail.
726+It is a common mistake to confuse a design pattern with a layer
727+or feature, and equally fatal whichever direction you fail.
302728
303729### Let's be clear about why DSLs suck
304730
305−DSLs suck not because they are difficult to newbies in the base language. DSLs suck because every time a programmer, even one *experienced* in the base language, comes into a new codebase or project, she has to learn a new custom language.
731+DSLs suck not because they are difficult to newbies in the base
732+language. DSLs suck because every time a programmer, even one
733+*experienced* in the base language, comes into a new codebase or
734+project, she has to learn a new custom language.
306735
307−You need enormous wins to justify this cost. It's the goal of the base language designer to preempt these wins, creating a language which is almost never so tiresome and full of boilerplate that it requires a DSL or template layer.
736+You need enormous wins to justify this cost. It's the goal of
737+the base language designer to preempt these wins, creating a
738+language which is almost never so tiresome and full of
739+boilerplate that it requires a DSL or template layer.
308740
309−Hoon is almost entirely made of macros -- but they are internal, fixed, built-in macros (with no gensyms). This fixed set of macros is essentially enough. Occasionally we want to add one or two. But we never, ever pine for context-dependent macros.
741+Hoon is almost entirely made of macros -- but they are internal,
742+fixed, built-in macros (with no gensyms). This fixed set of
743+macros is essentially enough. Occasionally we want to add one or
744+two. But we never, ever pine for context-dependent macros.
310745
311746### Determinism is not consensus, and is not constraining
312747
313−Fare' is totally right that an urbit's data is meant for itself alone. In fact, an urbit has the right to compute incorrectly if it wants. We go to considerable lengths to ensure that you can't gain any particular advantage by incorrect computing.
748+Fare' is totally right that an urbit's data is meant for itself
749+alone. In fact, an urbit has the right to compute incorrectly if
750+it wants. We go to considerable lengths to ensure that you can't
751+gain any particular advantage by incorrect computing.
314752
315−The whole point of Nock is that it's so low-level that there is no conceivable advantage in upgrading it. Divergence is just pointless. This is not a question of network integrity, just of practical standardization.
753+The whole point of Nock is that it's so low-level that there is
754+no conceivable advantage in upgrading it. Divergence is just
755+pointless. This is not a question of network integrity, just of
756+practical standardization.
316757
317−This consistency stops at Nock. Without anyone violating the correctness of their lifecycle functions, anyone or everyone in Urbit could replace Hoon with Javascript. Determinism does not cramp Urbit's semantic style in any way, shape or form.
758+This consistency stops at Nock. Without anyone violating the
759+correctness of their lifecycle functions, anyone or everyone in
760+Urbit could replace Hoon with Javascript. Determinism does not
761+cramp Urbit's semantic style in any way, shape or form.