on master help sign in
Merge remote-tracking branch 'upstream/master'
commitdc3577bb4f0a79dcdb1e8f7eaaeee9e53c161db1 authorMichael Hartl <michael@michaelhartl.com> dateThu 1 Apr 2021, 19:56 (6 years ago) parenta2e08a73b06812
79 files changed+3770−2618
content/blog/2020-to-2021.md+49 content/blog/after-machine-war.md+46 content/blog/bootstrapping-urbit-from-ethereum.md+4−5 content/blog/common-objections-to-urbit.md+2−2 content/blog/creating-sigils.md+1−1 content/blog/eliza.md+49 content/blog/events-series.md+1−1 content/blog/interim-constitution.md+1−1 content/blog/io-in-hoon.md+322 content/blog/metaphase.md+74 content/blog/security-audit.md+157 content/blog/toward-a-new-clay.md+1−1 content/blog/urbit-and-the-blockchain.md+3−3 content/blog/urbit-for-normies.md+1−1 content/blog/value-of-address-space-pt1.md+6−6 content/blog/value-of-address-space-pt2.md+14−12 content/blog/value-of-address-space-pt3.md+9−11 content/breach.md−97 content/community/community-grants.md+1−1 content/community/governance.md+1−1 content/community/hoonschool.md+2−10 content/docs+1−1 content/faq.md+110−93 content/getting-started.md+214 content/getting-started/_index.md+4 content/getting-started/planet.md+129 content/media.md+1−1 content/reset.md+109 content/understanding-urbit/interface.md+1−1 content/understanding-urbit/people-history.md+2−2 content/understanding-urbit/roadmap.md+2−2 content/updates/2016-5-16-roadmap.md+2−2 content/updates/2017-10-7-update.md+1−1 content/updates/2018-4-14-update.md+1−1 content/updates/2018-4-7-update.md+1−1 content/updates/2018-5-16-update.md+1−1 content/updates/2018-5-23-update.md+1−1 content/updates/2018-5-30-update.md+1−1 content/updates/2019-3-4-update.md+1−1 content/updates/2019-4-11-update.md+1−1 content/updates/2020-04-04-update.md+1−1 content/updates/2020-06-15-update.md+1−1 content/using/_index.md+31−3 content/using/develop.md−115 content/using/id/_index.md+33 content/using/operations/bridge-troubleshooting.md → content/using/id/bridge-troubleshooting.md+4−2 content/using/id/creating-an-invite-pool.md+106 content/using/id/guide-to-breaches.md+90 content/using/id/overview.md+71 content/using/operations/using-bridge.md → content/using/id/using-bridge.md+5−5 content/using/install.md−370 content/using/integrating-api.md−224 content/using/operations/_index.md−7 content/using/operations/using-your-ship.md−1439 content/using/os/_index.md+36 content/using/os/filesystem.md+397 content/using/os/getting-started.md+337 content/using/os/messaging.md+254 content/using/os/s3.md+34 content/using/os/shell.md+413 content/using/os/ship-troubleshooting.md+212 content/using/operations/stars-and-galaxies.md → content/using/os/stars-and-galaxies.md+6−6 content/using/running/_index.md+16 content/using/operations/hosting.md → content/using/running/hosting.md+25−18 content/voting-instructions.md+8−8 sass/_main.scss+34−14 static/_redirects+163−12 static/glossary.js+15−99 templates/anchor-link.html+2 templates/essays/post.html+1−1 templates/index.html+10−10 templates/list.html+1 templates/page/getting_started.html+68 templates/page_indiced.html+2−1 templates/partials/footer.html+5−5 templates/partials/navigation-docs.html+58−10 templates/sections/docs/hoon.html+1−1 templates/understanding-urbit/list.html+2−2 templates/understanding-urbit/post.html+1−1
content/blog/2020-to-2021.mdnew file+49
@@ -0,0 +1,49 @@
1++++
2+title = "2020 -> 2021"
3+description = "Reflecting and looking forward."
4+date = 2021-01-21
5+[extra]
6+author = "Josh Lehman"
7+ship = "~wolref-podlex"
8+image = "https://media.urbit.org/site/posts/essays/arch-sunrise-2.jpeg"
9++++
10+
11+<br>
12+
13+![arch](https://media.urbit.org/site/posts/essays/arch-sunrise-2.jpeg)
14+
15+<br>
16+
17+In this post, which has been adapted from our most recent [newsletter](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&id=be143888d2), we'll take a moment to reflect on the events of the last year, and then turn our attention to the next one.
18+
19+## 2020
20+
21+In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
22+
23+It seems like a long time ago now that the folks at Tlon rolled out OS1 (now called Landscape), just as the pandemic forced everyone into their homes throughout the world. At the time, [Urbit is for Communities"](https://urbit.org/blog/urbit-is-for-communities/) was just a vision, but now it’s been transformed into reality—there are more thriving communities in Landscape than any of us can keep track of, with new faces popping onto the network on a daily basis.
24+
25+Landscape brought many new ships onto the network which helped identify those areas in which Urbit’s infrastructure could be most improved. [Ford Fusion](https://urbit.org/blog/ford-fusion/) eliminated the possibility of a partially-applied over-the-air (OTA) update through a drastic reduction in the size and complexity of the codebase. The efficiency of the OTA process was improved by several orders of magnitude, and many long-standing memory issues were resolved. Now we deploy code on our infrastructure nodes and see users receive an update, over a decentralized network, often in less than a minute.
26+
27+After improving the stability of the system Tlon turned its attention to bringing more ships onto the network. A long-standing barrier to Urbit’s adoption has been the technical knowledge required to host one’s own ship—this prompted Tlon to build and launch an Urbit [hosting service](https://tlon.io), the waitlist for which is now thousands deep.
28+
29+With Tlon becoming more singularly focused on building products on Urbit, concrete steps have been taken towards making urbit.org a separate organization that’s focused on long-term development of Urbit’s platform. I joined to [lead that effort](https://urbit.org/blog/first-steps-towards-urbit-org/) back in August and have since spent the majority of my time working with dozens of contributors on projects spanning documentation, education, external integrations, and much more.
30+
31+We rounded out the year with a full network reset (called a “continuity breach”), which has in the past has been synonymous with loss of all data on the network. This time things went differently: tooling was made available to the community that allowed ships to preserve their data, which enabled most to seamlessly rejoin post-reset. This is a significant milestone for the project as it signifies not only a commitment to technical excellence, but to supporting our budding community.
32+
33+## 2021
34+
35+In the last three weeks we’ve seen a huge amount of inbound interest as people are waking up to the inherent problems with using centralized services run by MEGACORPs—we’re just happy we started working on Urbit all those years ago. While we tend to not plan more than about six months in advance, I can still talk at a high level about what urbit.org will be focusing on in the immediate future.
36+
37+Growth in Urbit’s developer community has been growing organically in lockstep with the overall network growth. This means, happily, that there’s a pretty large pool of people eager to contribute to Urbit. The priority for urbit.org, therefore, is to improve its capacity to effectively assist contributors. In broad strokes, this means:
38+
39+- Rework urbit.org to better help developers learn how to contribute to Urbit
40+- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
41+- Guide developers to make high-value contributions to Urbit and its ecosystem
42+- Build community amongst contributors
43+
44+My strategy to date has been heavily focused on working directly with contributors to provide technical guidance and direction, and it’s been working really well. To that end I’ll also be scaling our ability to provide such support by bringing more individuals into urbit.org that can mentor, review work, and provide guidance on where to best direct contributors' energy.
45+
46+
47+2021 is shaping up to be a big year for Urbit, and we'd [love your help](https://grants.urbit.org) in building it. If you want to see what we're working on in real time, join us in Landscape at ~wolref-podlex/foundation.
48+
49+See you on the network!
content/blog/after-machine-war.mdnew file+46
@@ -0,0 +1,46 @@
1++++
2+title = "After the Machine War"
3+description = "The date is January 1, 2050. The place, New York City. The vibe...subdued."
4+date = 2021-03-15
5+[extra]
6+author = "Simon Kovacs"
7+ship = "~bacbec-lormur"
8+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin-wall.jpeg"
9++++
10+
11+<br>
12+
13+![berlin-wall](https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin-wall.jpeg)
14+
15+<br>
16+
17+
18+> The following fictional passage, from a book being written in an Urbit Group called “the Aleph,” sketches out a dismal future for the human race. As an item of speculative fiction, the piece is not what one might call original. Anyone could have come up with these ideas. In fact, several already have. The Matrix is an obvious antecedent. Vonnegut isn’t far behind either. And the treacly humanism lodged beneath the bitter humor resembles nothing so much as the work of that beau monde satirist, George Saunders.
19+>
20+> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.
21+>
22+> It’s easy to be pessimistic about the future. Intellectuals, especially, are drawn to pessimism, because pessimism (falsely) implies a greater wealth of knowledge about the ways of the world. But one thing the pessimist never sees coming is a turn for the better. To wit, the future described in the below excerpt doesn’t have to take place. And Urbit is one piece of evidence for the claim that it will not.
23+>
24+> The philosopher-cum-internet comedian Slavoj Zizek likes to point out that no one was really expecting the Soviet Union to collapse in 1989. In fact, the average Soviet dissident wasn’t even gunning for it. He was haggling over small reforms, pushing to get the less corrupt politicians to the top, just going about his day eating or opening a window or walking dully along. Then, kaboom. Collapse. No more USSR.
25+>
26+> Then as now, the unexpected is more likely to occur than most would believe. One thing is not only possible, but an established fact: A brand new digital infrastructure is slowly, quietly being built. While U.S. political parties haggle over $1,400 disbursements for citizens, the rules of global finance are being re-written in code. While pundits debate the merits of Dr. Seuss’s lesser known titles, a global shift away from traditional publishing is gaining steam. And while users and social apps themselves pop up and down like whack-a-mole, folks are putting down roots with permanent peer-to-peer digital identities. If you’re anything like an optimist, you’ll probably want to get on Urbit ASAP and put down your own.
27+
28+<br>
29+
30+The date is January 1, 2050. The place, New York City. The vibe...subdued. Back in 2020, you made a note to yourself to take stock of the world around you here at the half-century mark. And now the time has come. What do you find? The air quality is a bit worse, the bad parts of town are a bit more dilapidated, the Knicks are still terrible—all in all, from the outside at least, not much has changed from 30 years ago. Today you wake up groggy on your self-adjusting Smart Bed (Smart Bed Never Sleeps), you make yourself a steaming pot of coffee (locally sourced, delivered within the half-hour by a drone, now that you’ve got Titicaca Prime), you shower and get ready for work.
31+
32+But what was that dream you had last night? Only the faintest traces of it remain. A luminous rainbow, a mountain landscape, a sense of profound inner peace, mixed with euphoria, mixed with...an intense desire to go out and buy some Health Morsels cereal?
33+
34+That’s odd. You’ve never even had Health Morsels. You open up your laptop, where you can view the activity of the iThink microchip that you got implanted in your cortex a few years ago. “Ads help Elysium provide you with free, quality sleep-monitoring. To disable ads, please upgrade to Elysium Premium.” That explains it. After all—and you pause for a moment over whether the forthcoming thought is yours or the iThink’s, before deciding that it’s much the same anyway—Health Morsels probably are delicious. And healthy, too.
35+
36+As usual, they’re setting something on fire outside your home. Normally you’d scroll back through your Squawker feed to see what it was all about, but today you’re late for work, and anyway you’re in a pleasant haze after the Health Morsels dream—no point ruining it by poring over the latest Squawker pile-on. You glance at the awning. Ah, the bodega. Toilet paper and Juul Pods are cheaper in bulk from Titicaca anyway.
37+
38+Another day at the office. You were never exactly passionate about content moderation, but hey, it keeps the lights on. (And since ConEd got absorbed by Titicaca, it’s been pretty important to have a Verified Income Stream.) It’s a normal day at work. Algorithms haven’t yet been able to filter out all Unverified Content—so it’s up to you the flag Unacceptable Violence, Disputed Claims, and Unfederated Currency transactions.
39+
40+Except after your pleasant dream, it all suddenly seems so drab. You start to wonder whether there was an error last night—maybe they turned the dream levels up too high. Something from your night-time vision just won’t leave your mind, like a film strip looping over and over. It’s that river beside a sloping field, like you used to swim in when you were a kid. You can almost feel the icy cold against your skin, the sticks and mud against the soles of your feet, and then there’s the ripe, marshy scent of the riverbed. Uh oh. You realize you’re close to danger levels. This isn’t where your head’s supposed to be at. Frantically you scroll through content, seeking to moderate it. A user threatening violence against Titicaca. A stream that violates DMCA. A highly dubious Squawker claim, with no support from experts. Flagged. Flagged. Flagged.
41+
42+Yet the river remains. You see it, you feel it, just as you feel the kiss of the sun on your shoulders, the breeze rustling through your damp hair.
43+
44+Now you know what’s coming. You brace for it and wait. Three. Two. One. ZAP. Your iThink produces an electric shock: plenty painful but not permanently damaging—at least that’s what the Verified studies show. The river recedes from your mind. Following the shock, your iThink, as versatile a little machine as ever was invented, delivers a few milligrams of both amphetamine and oxycodone, bringing on a wonderful feeling of simultaneous alertness and relaxation. You look up at your monitor. Content moderation doesn’t seem so bad, with the stimulant and the barbiturate swirling paradoxically through your system. It’s true what they say in the ads: iThink doesn’t just make you think better, it makes you feel better. You dive back into your content moderation with renewed verve, even flagging a couple completely innocent posts just out of surplus exuberance. So what if you hardly get outside at all these days, so what if you’ll never swim in that stupid river. The fastest electronics, the Your Health and Wellbeing tracked and adjusted by an intelligence far greater than that which you could ever hope to possess, a gizmo that gives a whole new meaning to the term neural net.
45+
46+2050 turned out to be a pretty good year after all.
content/blog/bootstrapping-urbit-from-ethereum.md+4−5
@@ -216,7 +216,7 @@ replacing the storage contracts.
216216
217217We'll walk through how we have designed these contracts in detail here. You can
218218also view our in-progress source at the
219−[`urbit/constitution` GitHub repo](https://github.com/urbit/constitution).
219+[`urbit/azimuth` GitHub repo](https://github.com/urbit/azimuth).
220220
221221### Certificate storage contract
222222
@@ -378,10 +378,9 @@ price in ether of a planet, and the number of planets available.
378378
379379## Okay, so
380380
381−That was quite a lot of information! We've created a fora thread
382−[here](https://urbit.org/fora/posts/~2017.9.20..22.56.04..47ce~) for discussion,
383−and would be glad to hear your feedback. GitHub issues on the
384−[urbit/constitution repo](https://github.com/urbit/constitution) are also more
381+That was quite a lot of information! There's also a blog post about the constitution
382+[here](https://urbit.org/blog/interim-constitution/), and GitHub issues on the
383+[urbit/azimuth repo](https://github.com/urbit/azimuth) are more
385384than welcome.
386385
387386There's a lot more to come on this front as our contracts get closer to getting
content/blog/common-objections-to-urbit.md+2−2
@@ -309,7 +309,7 @@ It's very important that Urbit in 2116 be fully decentralized.
309309For Urbit in 2016, pretending to be decentralized would be a joke
310310at best, and a hoax at worst. And of course, no one can DAO us
311311-- since the property system is still just a central registry.
312−Among other things, we check it into Github. Github is not a
312+Among other things, we check it into GitHub. GitHub is not a
313313blockchain -- but still, good luck with that.
314314
315315## <a name="sand"></a>Sandstorm/IPFS/Ethereum is way ahead of Urbit.
@@ -628,7 +628,7 @@ much sense to restrict this security state to code within Urbit.
628628The Urbit interpreter `vere` runs as a Unix daemon that
629629implements the FUSE user-level filesystem protocol, and maps the
630630data on your services into the Unix filesystem. For example, one
631−of our demos lets you `ls` your Github issues.
631+of our demos lets you `ls` your GitHub issues.
632632
633633So it's straightforward to build, for instance, a Python app that
634634uses Urbit as a gateway to mash up a bunch of web services. As a
content/blog/creating-sigils.md+1−1
@@ -157,7 +157,7 @@ The final step, using the tool we built, was to hand select individual phoneme s
157157
158158This allowed us to start looking at possible combinations and selecting phoneme symbols based on their interplay with others.
159159
160−Once we had selected the final set, we went about compiling the `sigil-js` library that’s now publicly available. This turned out to be fairly technically complex due to the different ways SVG is handled between browsers and Figma — but the end result is a single Javascript library you can use to embed an SVG in almost any context on a web page. See it in action and browse the available sigils [here](https://sigil.azimuth.network). If you're technically inclined, the [source](https://github.com/urbit/sigil-js) can be found on Github.
160+Once we had selected the final set, we went about compiling the `sigil-js` library that’s now publicly available. This turned out to be fairly technically complex due to the different ways SVG is handled between browsers and Figma — but the end result is a single Javascript library you can use to embed an SVG in almost any context on a web page. See it in action and browse the available sigils [here](https://sigil.azimuth.network). If you're technically inclined, the [source](https://github.com/urbit/sigil-js) can be found on GitHub.
161161
162162<br /><br />
163163
content/blog/eliza.mdnew file+49
@@ -0,0 +1,49 @@
1++++
2+title = "Eliza"
3+date = 2021-02-23
4+description = "Building things, even Calm™ things, makes noise."
5+[extra]
6+author = "Christian Langalis"
7+ship = "~pindet-timmut"
8+image = "https://media.urbit.org/site/posts/essays/valleys.jpg"
9++++
10+
11+<br>
12+
13+![valleys](https://media.urbit.org/site/posts/essays/valleys.jpg)
14+
15+<br>
16+
17+## The Storm before the Calm
18+
19+Building things, even Calm™ things, makes noise. George Nakashima’s wooden furniture evokes peace, but its construction still begins with a chainsaw. We mention this because we’re firing up our newest power tool.
20+
21+We call her Eliza. She is a data-collection robot.
22+
23+Hang on. An AI? Harvesting my data? Spying on me? Flooding me with spam? This is Urbit, right? Let us tell you about our new friend in basic terms, where MEGACORP might otherwise deploy legalese.
24+
25+## What Eliza is and isn’t
26+
27+> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
28+>
29+> <cite>Rick Deckard</cite>
30+
31+Let's start with the benefits. Eliza is a simple chatbot. She was made to collect feedback on Landscape. She asks direct questions about peoples' usage of Urbit, records any responses, and reports them to her managers at Tlon. She'll also provide timely advice and information to ships kind enough to chat with her. She'll begin reaching out to ships via DM in the coming month. If you don't want to, just say no, and you'll never hear from her again.
32+
33+Finding bugs is critical to Urbit's rapid development, especially in this period of nascency. Most Urbit-related frustrations go unreported; regular folks don't think to open up Github when they experience a minor issue. That's why it's incumbent upon us to design a lower-friction forum for feedback. People who aren't comfortable filing an issue might be willing to talk to a friendly chatbot.
34+
35+Now, about hazards. By design, there are few. Eliza runs on Tlon's comet, not on your planet. There will be no OTA to install `%eliza-bot-store` on everyone's ships. Eliza learns things through conversation, not hidden surveillance software. Data she requests, like the text output of our network analytic tool, `+tally`, must be sent manually. MEGACORP tends to cut this corner; to refine their products, they just track your reactions in real-time.
36+
37+Since she's [open-source](https://github.com/urbit/urbit/blob/b0c1f83287cbf4c85847a9238d9f4be17e1fcb33/pkg/arvo/app/eliza.hoon), anyone can creatively deploy Eliza. Just write her a dialogue tree. Of course, that also means we can't keep people from misusing Urbit bots. We think automated agents on the Urbit network are inevitable, so let's create a good baseline culture around them. (Much love to Tendiebot, who's serving up stock prices in `~tomdys/wall-star-bets`.) However, once Urbit is used world-wide, we can't rely on culture alone.
38+
39+## A New Internet Economics
40+
41+The sum of Urbit's architectural design is a new online economics: a way to finance and monetize access to internet infrastructure where people retain maximum equity. Explicitly acquire a low-maintenance, low-cost server. Use it to compute explicit things. Return to life.
42+
43+We all know the basic MEGACORP business model: offer a free service (to suckers who don't own a server), secretly mine the data they generate on the (addictive) platform, then sell targeted ads to advertisers. This model will not survive Urbit. The ubiquitous personal server changes the economic equation. You used to 'pay' for an experience with your time and data. On Urbit, once you purchase core internet infrastructure, it's yours.
44+
45+So, can Urbit meaningfully curtail our world's appetite for data? We'll see. Post-enlightenment society runs on instrumental reason, right down to the last byte. Marketers will always want a fresh dataset. However, when the goods are on your Urbit, you can at least demand the respect you deserve. Long term, we expect a transparent market for data, not an opaque "agreement". An analytics company wants to track everything you see and do on Urbit? They better be paying well.
46+
47+Eliza doesn't pay respondents. Her collection is a charity to Urbit's developers. (We're also still busy enabling payments on Urbit with the Bitcoin wallet.) However, her presence is not a term of service either. In a few years, by the nth time some smart aleck uses Eliza's chatbot code and conjures 'Zalexa' to attempt an intrusion upon your Calm™, we will see the economics of Urbit's architecture suddenly vivify. Blacklists, reputation systems, and, eventually, even data markets, all Urbit primitives envisioned long ago, will become real. We won't need Zoogle to underwrite a spam filter for the entire internet; the scarcity of Urbit address space, in tandem with a true web-of-trust, handles that.
48+
49+If Urbit is to be used worldwide, the old system will not go down without a fight. Spammers, spies, and digital robber-barons will hunt for ways to game Urbit. Our passage out of the digital gutter is beginning in earnest, and we are thrilled to put our new architectures to the test.
content/blog/events-series.md+1−1
@@ -25,7 +25,7 @@ Something we tend to talk less about is the fact that Urbit itself is also a com
2525
2626One of the reasons you don’t hear about the Urbit community as much is that community is difficult to pin down: you'd be hard-pressed to put "the community" into a room together. It's a weird, fuzzy notion and doesn't have clear boundaries.
2727
28−Other parts of Urbit do have clear boundaries. If you decided to learn more about Urbit, chances are you started by reading the docs. You might learn about [Nock](https://urbit.org/docs/tutorials/nock/), [Hoon](https://urbit.org/docs/glossary/hoon/), and [Arvo](https://urbit.org/docs/glossary/arvo/). You might get an [Urbit ID](https://urbit.org/understanding-urbit/urbit-id/) and [launch your own ship](https://urbit.org/using/install/). These things are all pretty well documented and, while not necessarily easy, their respective processes are relatively straightforward and [getting easier](https://urbit.org/blog/hosting-the-future/) every day. Community is less well documented. It’s more difficult to document—it’s something you just have to experience.
28+Other parts of Urbit do have clear boundaries. If you decided to learn more about Urbit, chances are you started by reading the docs. You might learn about [Nock](https://urbit.org/docs/tutorials/nock/), [Hoon](https://urbit.org/docs/glossary/hoon/), and [Arvo](https://urbit.org/docs/glossary/arvo/). You might get an [Urbit ID](https://urbit.org/understanding-urbit/urbit-id/) and [launch your own ship](https://urbit.org/getting-started/). These things are all pretty well documented and, while not necessarily easy, their respective processes are relatively straightforward and [getting easier](https://urbit.org/blog/hosting-the-future/) every day. Community is less well documented. It’s more difficult to document—it’s something you just have to experience.
2929
3030We lead with technology because it’s what we’re good at and because it’s easier to write about. But the social side of Urbit is no less important. Since so many of us are working on and contributing to Urbit in order to solve our own problems, and since we’re dogfooding as we go, you could define Urbit as the minimal technological infrastructure needed to sustain the Urbit community. It’s circular, but it’s as good a definition of Urbit as you’re likely to find. For this reason, you can’t really understand Urbit without some degree of exposure to the cultural knowledge of its community. When the Urbit community did fit in a single room together, transmitting cultural knowledge was easy and happened over pizza and beer. As the number and diversity of Urbit stakeholders continue to grow, we need to find ways to scale the transmission of this cultural knowledge.
3131
content/blog/interim-constitution.md+1−1
@@ -136,7 +136,7 @@ the interests of the republic and Urbit as a whole.
136136Externally, these galaxies are held by Tlon; internally, they are
137137managed and voted by Tlon. Once the republic acquires a legal
138138identity and an independent human organization, Tlon pledges to
139−donate the `urbit.org` galaxies, the DNS domain, and the Github
139+donate the `urbit.org` galaxies, the DNS domain, and the GitHub
140140`urbit` account to it.
141141
142142## First consuls
content/blog/io-in-hoon.mdnew file+322
@@ -0,0 +1,322 @@
1++++
2+title = "Input and Output in Hoon"
3+description = "Let's talk about IO in Urbit."
4+date = 2020-12-16
5+[extra]
6+author = "Philip Monk"
7+ship = "~wicdev-wisryt"
8+image = "https://media.urbit.org/site/posts/essays/zion-canyon-1.jpg"
9++++
10+
11+<br>
12+
13+![canyon](https://media.urbit.org/site/posts/essays/zion-canyon-1.jpg)
14+
15+<br>
16+
17+
18+Let's talk about IO in Urbit. I won't say much about how events and effects are processed by the runtime; it suffices to note that the runtime is a normal Unix program which (1) listens for various events, (2) passes them to Arvo (Urbit OS), and (3) processes the effects produced by Arvo. Instead, I’ll focus on how IO works from the perspective of Hoon programs, like Arvo or apps running on Arvo. But first, let's review IO paradigms in other languages.
19+
20+All examples are in a made-up language, since it's useful to understand this information even before you're comfortable in Hoon. If you're learning Hoon and want a challenge, try translating them!
21+
22+## The three styles of IO
23+
24+I will call these styles imperative IO, monadic IO, and state machines (note that this classification refers only to the experience of using them and the program structure they dictate). An imperative programming language can use any of these and a functional programming language can use any of them.
25+
26+### Imperative IO
27+
28+Imperative languages (such as C and Python) perform IO by calling a function in the middle of whatever they were doing. Anywhere, in any statement, you could have IO.
29+
30+In this example and others to follow, the task will be to read a filename from the command line, read a URL out of that file, and fetch the contents at that URL.
31+
32+ output = fetchUrl(stripWhitespace(readFile(cliInput())))
33+
34+For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.
35+
36+### Monadic IO
37+
38+Languages that use explicit monads for IO (such as Haskell) perform IO by running IO behind a bind operation, which I'll notate with `<-`. Thus, while you can't put IO *anywhere*, the general structure is a sequence of IO operations.
39+
40+ fileName <- cliInput()
41+ url <- readFile(fileName)
42+ output <- fetchUrl(stripWhitespace(url))
43+
44+[Tackling the Awkward Squad](https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/mark.pdf) is the canonical description of monadic IO, and does a great job of explaining how the Haskell community decided to use this as their primary IO style.
45+
46+### State machines
47+
48+Languages that use explicit state machines for IO (such as Elm) perform IO by accepting events and producing a list of effects.
49+
50+ event :: Initialize
51+ | CLIInput text
52+ | FileInput text
53+ | HTTPResponse body
54+ effect :: CLIInput
55+ | ReadFile fileName
56+ | FetchUrl url
57+ | Print text
58+ main(event) {
59+ switch event {
60+ Initialize -> [CLIInput ~]
61+ CLIinput fileName -> [ReadFile fileName]
62+ FileInput url -> [FetchUrl stripWhitespace(url)]
63+ HTTPResponse body -> [Print body]
64+ }
65+ }
66+
67+The effects produced are not functions but data.
68+
69+It's important to note that this example is chosen to highlight a particular kind of IO — sequences of events. Further, this example has no persistent state — each IO operation is a pure function of the output of the previous one.
70+
71+## A stateful, loopy example
72+
73+Let's look at another type of program: a simple HTTP server that you can give text at the CLI, which will respond to all HTTP requests with that text.
74+
75+Imperative:
76+
77+ text = "no text entered yet"
78+ while (true)
79+ cli = readCli()
80+ if (cli != Null)
81+ text = cli
82+ request = readHttp()
83+ if (request != Null)
84+ respond(request,text)
85+
86+Monadic:
87+
88+ loop("no text entered yet")
89+
90+ where:
91+
92+ loop :: text -> IO Null
93+ loop =
94+ input <- readInput()
95+ switch input
96+ CLIInput newText -> loop(newText)
97+ HTTPRequest request ->
98+ _ <- respond(request,text)
99+ loop(text)
100+
101+State machine:
102+
103+ text = "no text entered yet"
104+ main(text,event) {
105+ switch event {
106+ CLIInput newText -> [newText, Null]
107+ HTTPRequest request -> [text, HTTPResponse text]
108+ }
109+ }
110+
111+Again, note the response in the state machine is data, not a function.
112+
113+I'm not trying to make a point about which type is better in general. There's a pretty strong argument that in the first example, imperative was the best option, followed by monadic, followed by state machine. There's an equally strong argument that the second example is most naturally represented by the state machine.
114+
115+Look at how state is handled in the monadic example. Formally, bind composes functions, so that every time you see a `<-` there's actually a new function (closure/delimited continuation) being created and stored for when we receive a response. All variables in scope are stored in that closure, so we can conveniently access them later without explicitly storing them. However, the state we preserve over time varies a lot. In this example, it varies between storing `loop`, `[loop input]`, `[loop input newText]`, and `[loop input request]`.
116+
117+By comparison, the state machine does not store intermediate values, it only stores its explicit state. While this is somewhat less flexible, it puts the permanent state front-and-center.
118+
119+I'll reiterate that all of these are possible to implement in purely functional languages, and further they can all be implemented in terms of each other. State machines are trivially implementable -- it's just a function [state event] -> [new-state (list effect)]. Monadic IO can be implemented directly (as in Haskell) or on top of state machines by storing continuations in your state. Imperative IO is somewhat more difficult but should be possible through algebraic effects.
120+
121+When inventing a new system, you should consider which of these you intend to support based on the sort of code you expect to see. For example, a scripting language will almost always benefit from imperative (or at least monadic) style.
122+
123+## In Urbit
124+
125+So much for exploring the space of IO solutions. In terms of deployed code on Earth, the split is about 90% imperative, 5% monadic, and 5% state machine. In Urbit, the split is about 90% state machine and 10% monadic. This is what I intend to explain and defend.
126+
127+Urbit's OS is called Arvo; it has several "kernel modules" called vanes, and it has userspace applications. Colloquially these are called "apps," but when speaking about them abstractly, it's helpful to use their more specific name: ["agents"](https://urbit.org/docs/tutorials/arvo/gall/#agents). Arvo, the vanes, and agents are all structured as explicit state machines.
128+
129+In addition, there are ["threads"](https://urbit.org/docs/tutorials/arvo/gall/#threads), which are structured as monadic IO. Note there's only a superficial resemblance to Unix threads: they are not executed in parallel and they don't share memory, or at least not any more than agents do. They're simply a computation that takes an argument and produces a result, possibly after doing some IO, structured monadically.
130+
131+As you can see, all the lowest levels of Arvo are explicit state machines, and only the highest layer supports monadic IO. To see why this is the case, let's list advantages and disadvantages to each type. Note that, while I'm speaking specifically of agents and threads in the context of Urbit, these are fundamental properties of monadic and state machine IO.
132+
133+Agents are:
134+
135+- Upgradable. Since the state is explicit, you can upgrade an agent in-place by supplying a new state machine and a function from the old state type to the new state type. This is very similar to a database migration.
136+
137+- Robust. A state machine must accept any input at any time. If it receives unexpected input, it must have had explicit error handling for that input, since it's one of the types in the switch statement. Thus, it's relatively easy to stay in a consistent state.
138+
139+- Permanent. Since it's upgradable and robust, there's no reason to stop its running.
140+
141+- Hard to write long sequences of IO. Long sequences of IO create many possible states, and you must handle any input in any state. This can result in complex, hard-to-follow code with code paths that are rarely if ever taken.
142+
143+Threads are:
144+
145+- Not upgradable in-place. Since the state is implicit, you can only cleanly upgrade by (1) killing the thread and restarting it or (2) letting it resolve to a defined "upgradable state" periodically, usually at the top of a "main loop". If you do (2), then you are in fact structuring it as a state machine, so the other advantages of threads are compromised.
146+
147+- Fragile. If we don't receive expected input, the default behavior is to be stuck waiting for input. You must remember to add any error-handling features you want, and it's easy to end up in an inconsistent state.
148+
149+- Impermanent. Since a thread can't be upgraded and may get stuck in case of unexpected input, a thread can't be expected to last forever. It must be "rebooted" from time to time.
150+
151+- Easy to write long sequences of IO. Just...write the IO one line at a time.
152+
153+Arvo proper and the vanes are permanent pieces of software and, for this reason, state machines are more natural.
154+
155+I'll note that other kernels, like the Unix kernel, use imperative IO. The difference is that Unix isn't permanent in itself — it only lasts until you reboot. Since your permanent state is stored externally, you don't need to be upgradable or permanent. With sufficient discipline you can write robust C code, so it makes sense to use imperative style. Even so, a lot of C code is written in a state machine style; even if it doesn't need to be upgradable, it's worth it for the robustness and concurrency advantages.
156+
157+However, Arvo is a single-level store — all of its state is permanent. This is very convenient and eliminates many long-tail bugs, but it also means we need to code for permanence, and that's much easier when you structure your code with explicit state.
158+
159+Further, Arvo and the vanes rarely perform long sequences of IO. Generally, they do one thing and emit some effects, similar to the HTTP server example above. Sometimes they "pass through" a request. For example, the Eyre vane passes HTTP requests to userspace agents or threads. In this case, there is a sequence of IO, which in monadic code would be:
160+
161+ loop()
162+
163+ where:
164+
165+ loop =
166+ request <- receiveRequest()
167+ agent = lookupAgent(request)
168+ response <- callAgent(agent, request)
169+ _ <- sendResponse(request, response)
170+ loop()
171+
172+This is clear code to read, but it leaves open the question of how to respond during the callAgent() function. If another request comes in, can we handle it in parallel? If we need to upgrade ourselves before the agent responds, can we make sure to properly handle the response?
173+
174+The naive solution in monadic code is to say that you can only handle one request at a time, and if an upgrade happens you just drop outstanding requests. You can resolve both of these by introducing a sort of main loop, which is just a way of saying "turn it into a state machine".
175+
176+In a state machine, the naive solution is:
177+
178+ state :: (map request agent)
179+ main(state, event) {
180+ switch event {
181+ HTTPRequest request ->
182+ agent = lookupAgent(request)
183+ [put(state, request, agent), CallAgent agent request]
184+ AgentResponse request response ->
185+ [del(state, request), HTTPRespond request response]
186+ }
187+ }
188+
189+Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.
190+
191+I won't claim this is easier or harder to write than the monadic version, but it has the properties we need at this level of the system.
192+
193+Userspace agents similarly are permanent entities that need to not lose data or get stuck. For this reason they’re structured as state machines.
194+
195+A helpful comparison is that explicit state machines are basically Mealy machines, the kind you might have learned about in an introductory digital design class. This shouldn't be surprising; a digital circuit must always be consistent because it can't be manually "rebooted", and their input and output is highly formalized. By contrast, a Rube Goldberg machine doesn't have the same constraints; which is why they're a lot more fun!
196+
197+It's notable also that explicit state machines are considerably more declarative than imperative or monadic IO. Not everyone thinks that's a good thing, but anyone who defends functional programming should see some advantages to that.
198+
199+However, userspace sometimes needs to perform long sequences of IO. Let's look at an example where we want to fetch the front page of a site and the first couple comments on each story. HTTP is unreliable, so on failure we retry five times.
200+
201+Monadic:
202+
203+ topStories <- fetch(topStoriesUrl)
204+ loop(topStories)
205+
206+ where:
207+
208+ loop :: topStories -> IO Null
209+ if topStories is Null
210+ return Null
211+ comments <- retryLoop(5,head(topStories))
212+ otherComments <- loop(tail(topStories))
213+ append(comments,otherComments)
214+
215+ retryLoop :: [n story] -> IO Comments
216+ comments <- fetchComments(story)
217+ if comments is HTTPError:
218+ if n == 0:
219+ bail
220+ else:
221+ retryLoop(n-1, story)
222+
223+State machine:
224+
225+ state :: Initial
226+ | FetchingTop
227+ | FetchingStory comments stories retries
228+ | Done comments
229+
230+ main(state, event) {
231+ switch event {
232+ Initialize ->
233+ assert state == Initial
234+ [FetchingTop, Fetch topStoriesUrl]
235+ HttpResponse response ->
236+ switch state {
237+ FetchingTop ->
238+ [FetchingStory Null stories 5, FetchComments head(stories)]
239+ FetchingStory comments stories retries ->
240+ if response is HTTPError:
241+ if retries == 0:
242+ [Initial, Null]
243+ else:
244+ [FetchingStory comments stories retries-1,
245+ FetchComments head(stories)]
246+ else:
247+ comments = append(response,comments)
248+ if tail(stories) is Null:
249+ [Done comments, Null]
250+ else:
251+ [FetchingStory append(comments,response) tail(stories) 5,
252+ FetchComments head(tail(stories))]
253+ }
254+ }
255+ }
256+
257+With practice, the state machine version of this can be written correctly. However, (1) it's verbose, (2) the control flow jumps all over the place, and (3) in practice it's challenging to get exactly right. This is still a small example, and it gets much worse as the length and complexity of the IO sequence grows.
258+
259+The monadic version, on the other hand, flows cleanly down the page. We can factor out generic functionality like "retry this request n times" to make the essence of the computation clear.
260+
261+Suppose you have to upgrade this. In the state machine, you can see exactly which stage of the computation you're in and write specific code to upgrade cleanly.
262+
263+Threads, as we've discussed, can't be upgraded in-place. Let's be real though: we're downloading comment sections, not regulating a nuclear reactor. If we get a better version of this script, just kill the old one and start the new one from scratch. What's a couple extra HTTP requests?
264+
265+This suggests a general division of workloads: code which needs to be permanent, upgradable, and concurrent should generally be a state machine. Code with long or complex sequences of IO and definite termination should generally be a thread.
266+
267+These aren't completely mutually exclusive, but it's surprising how often they are.
268+
269+### Jael: a case study
270+
271+When you need to do something permanent and upgradable, but you also need to do long sequences of IO, the main trick is to factor your problem into both an agent and a thread (or several).
272+
273+As a case study, consider Jael, one of our vanes. This maintains our PKI state, which it downloads over HTTP from an Ethereum node. Downloading from an Ethereum node is a complex sequence that starts with fetching its most recent block number, then fetching all the blocks we haven't seen and scanning for transactions we care about. We also maintain a map of block hashes to block number, and if we see that a block's parent doesn't have the hash we expect, that means a reorganization has occurred, so we must "rewind" one block at a time until we find where the fork happened, then restart going forward.
274+
275+You don't have to understand this sequence of IO; it's sufficient to see that it's complex and must be exactly right. We used to do this in a state machine directly in Jael. This data is, of course, permanent and needs to be accessible to the rest of the system, so Jael must be a state machine.
276+
277+However, we had many small mistakes in this sequence of IO, some of which only appeared during unusual events, such as when an HTTP request failed at the same time as a reorganization happened.
278+
279+We're in a bit of a bind, though: Jael has to be a state machine. The solution is to factor out the act of getting updates into a thread while the main PKI state is stored in the state machine in Jael.
280+
281+This thread has a definite purpose: given the most recent block number we already know about, fetch all the PKI transactions since then. The function signature is:
282+
283+ syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]
284+
285+Jael runs this thread every five minutes and, if it succeeds, then we update our block number and PKI state. If the thread fails, gets stuck, or we need to upgrade it, we just kill the old thread and start a new one. Again, a few extra HTTP requests don’t matter.
286+
287+From Jael's perspective, it looks something like:
288+
289+ state :: State block txs outstandingThread
290+ main(state,event) {
291+ switch event {
292+ Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]
293+ TimerFired ->
294+ effects = If outstandingThread is Null
295+ then Null
296+ else [Kill outstandingThread]
297+ newId = newThreadId()
298+ [State txs newId,
299+ append(effects,
300+ StartThread newId syncEthereum(block),
301+ StartTimer (now + five minutes))]
302+ ThreadFinished Failure -> [State block txs Null, Null]
303+ ThreadFinished Success newBlockNumber newTxs ->
304+ [State newBlockNumber append(txs,newTxs) Null, Null]
305+ }
306+ }
307+
308+In other words, from Jael's perspective, it's just a single IO event that encapsulates arbitrarily complex IO in the thread. A single IO event is easy enough, and we can maintain all our permanency and robustness guarantees, because we know the thread will have one of three results: success, failure, or it hangs. If we set a timeout, hang becomes failure, so there's only two possible results: success or failure. If we handle both of those correctly, we've handled all the possible IO errors that could have occurred.
309+
310+What about upgrading? We've already said we can handle the thread dying for arbitrary reasons, so if an upgrade comes in, we just kill it. We can upgrade Jael's state machine easily since its state is very simple.
311+
312+## Recap
313+
314+Let's recap what we've covered:
315+
316+- There are three styles of IO: imperative, monadic, and explicit state machines.
317+- Urbit supports explicit state machines (agents) and monadic IO (threads).
318+- Explicit state machines are preferred for permanent, robust, concurrent code.
319+- Monadic IO is preferred for short-lived code with complex IO.
320+- If a state machine needs to perform complex IO, it should encapsulate it in a thread so that, from the perspective of the state machine, it's simple IO.
321+
322+Hopefully it's fairly clear why Urbit uses explicit state machines in most situations. More than anything else, our goal is to build software that can last forever. Explicit state machines are a crucial tool for that.
content/blog/metaphase.mdnew file+74
@@ -0,0 +1,74 @@
1++++
2+title = "Metaphase"
3+date = 2020-12-09
4+description = "On the upcoming and foregoing Landscape lifecycles, and other forms of mitosis across the Urbit project."
5+[extra]
6+author = "Matilde Park"
7+ship = "~haddef-sigwen"
8+image = "https://media.urbit.org/site/posts/essays/metaphase.jpg"
9++++
10+
11+<br>
12+
13+![mitosis](https://media.urbit.org/site/posts/essays/metaphase.jpg)
14+
15+<br>
16+
17+*Previous versions of this essay specified the stream deploy date as December 11, 2020; then December 18, 2020. This has been amended to the actual date of release, with our sincere apologies. For new readers, you can opt into the dev stream by running `|ota ~lomlyx-lopsem-nidsut-tomdun %kids` (you may have to resolve a merge conflict using `|merge %home ~lomlyx-lopsem-nidsut-tomdun %kids, =gem %take-that`). We will surface this option more broadly in a future settings overhaul.*
18+
19+A few weeks ago, the Landscape team — those of us building Tlon’s suite of userspace applications on top of Urbit— deployed our first over-the-air update for notifications. This is a big leap forward for us. Of course, getting notifications inside Landscape itself is a big deal, but getting a push notification on your phone, or an email digest based on activity inside Urbit is now just one step away, a weekend project for a hobby developer, not an indeterminate number of steps away.
20+
21+After release, we received some feedback from users on the behaviour and design of this feature; beyond the obvious kinks that come from an initial release, it seemed to some like a minimum viable affordance pitched as a fully designed feature. This “bottom-up” development approach was, to us, fairly straightforward; to some of our users, it seemed that we had closed the door on the feature without even beginning to expose all its possibilities.
22+
23+As I’ll describe, we haven’t just been iterating Landscape, but the way we develop Landscape, and the way we consider Landscape in relation to Arvo. Finally, we’ll discuss our upcoming two-stream release process: a “stable” release stream with updates every six weeks and a development stream, with ongoing changes continuously deployed on an opt-in basis.
24+
25+To someone coming to Landscape for the first time, it is starting to look mature; and it is indeed maturing quickly. After all, these mismatches in expectations are pangs calling out for growth. Landscape truly has *users*, not just explorers, who are developing the same expectations they have with the other tools they use: predictability, reliability, and iterative improvements, not just leaps forward. So to meet those expectations, we’ve been working on the prerequisite work for a mature release schedule, with two different release streams for users and explorers: a lifecycle, with the cells, interlinked, dividing into a coherent higher being.
26+
27+## Landscapers and lifecycles
28+
29+For most of 2020, the core Landscape team has comprised of Liam (`~hastuc-dibtux`), Logan (`~tacryt-socryp`), and myself (`~haddef-sigwen`). Others at Tlon have rotated on and off, and some community members (`~radbur-sivmus` comes to mind) have also contributed a lot, but the three of us handle the core decisions and the entire stack for Landscape, working with designers, infrastructure, and third-party developers.
30+
31+After OS1’s release in April 2020, Landscape’s back-end has changed quite a bit; the first rearchitecture we performed was in group-store, adding roles and simplifying quite a lot of the back-end logic at the same time.
32+
33+Around May of this year, Logan flagged that our code surface was too large and had too much boilerplate by writing a set of bespoke full-stack applications when just one flexible userspace database would do. Our designers also had a vision of our interfaces being “modes and genres of the same data” that fit this vision as well; and so since then, we’ve put our resources into migrating all of Landscape to use graph-store (more information available in [this developer call](https://www.youtube.com/watch?v=E4DFuAZQ32Y)).
34+
35+Obviously, developing userspace for distributed computing has some additional challenges that you don’t have to consider when writing software for a single server. Each ship interacting has to mutually coordinate the agents running and the events to be processed. If those fall out of synchronisation, the edge cases multiply.
36+
37+We traditionally tended toward solving those problems by writing the simplest possible incarnation of an application or a solution first, triaging out additional complications until they can be most prudently addressed — usually when they are just one step away.
38+
39+For most of its history, Landscape’s userspace suite had to be up-to-date on all ships to function at all, so multiple staging streams added quite a few complications. Since incompatible versions of applications on different ships would produce mutual fail states if they attempted to interact –and since each application had no sense of how to negotiate compatibility with older applications, each user had to keep up-to-date. Landscape was moving too fast, constantly reconfiguring (to give you a sense of this: we still refer to a month ago as “old”).
40+
41+Historically, Arvo and Landscape were also considered just one object; changes in Landscape would often require refining the layers underneath it as well. We often aimed to use our interface’s requirements to refine Arvo in turn. But as Landscape’s cells continued to split, as it became a proper client *for* Arvo rather than a subsection *of* Arvo, it required its own planning and execution cycle that only came to fruition around April of this year.
42+
43+The first thing we did was start recurring, six-week product backlogs with designers and engineers to occasionally reassess short-term priorities with a larger roadmap. Once we did that, we began working on opening our process to the public, migrating all tasks, priorities, and current decisions to a [product board](https://github.com/urbit/landscape). By doing this, community members could both suggest features *and* contribute features, with a centralised, transparent process for getting designer input and Tlon engineer priorities. This has also been a successful effort.
44+
45+By adjusting ourselves to a six week rhythm for execution, it’s clearly time to slow down our release schedule and dedicate design and QA time to each release.
46+
47+Since Arvo is still quite young, we can’t quite get to all the thornier aspects of instituting a lifecycle. For example, we can’t tackle agent version negotiation in full yet; and mark versioning is still not present. This means modifying the validators for our graph modules (that is, validating the graph structure of a notebook vs. a collection) presents a deployment challenge in a two-stream lifecycle.
48+
49+That said, our userspace infrastructure is maturing, so we could at least organise the APIs to those agents; and we could at least slow the development cycle on those agents in favour of the more flexible components of the stack. The front-end specific features, for example, can be deployed on different ships without side effects for other users.
50+
51+So now, before we could launch a stable stream, we had some things to do first:
52+
53+- **We wanted to provide assurance that the userspace suite is relatively stable.** All our remaining stores (invite-store, metadata-store, and contact-store) needed to be modernised to use the same libraries and utilities inside Arvo as newer userspace applications.
54+- **We wanted all our applications to be using graph-store.** If we were going to migrate the entire network to a new userspace model, we shouldn’t undermine the new release cycle process and make it more difficult to test and deploy to meet higher user expectations. We needed to migrate everything first.
55+- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.
56+- Finally, **we wanted all of Landscape to use the [Indigo component library](https://github.com/urbit/indigo-react).** Landscape shipped with each application using its own build with handwritten, bespoke DOM components. Once we moved to a single-page application architecture in June 2020, we wanted the same guaranteed consistency for both back-end and front-end code.
57+
58+Most of these are now accomplished; the remaining tasks are awaiting some final tests and UX work. We’re aiming for a stable stream of Landscape to deploy by **January 5, 2021**.
59+
60+What does this mean? For everyday users, you can expect Landscape releases every six weeks; the slate of features and any breaking changes will be flagged well in advance for third-party developers; and you can expect a more thoroughly considered user experience with notes and copy for each new release.
61+
62+And for intrepid users, you can opt-in to a development stream and help us find and eliminate bugs before release to the wider public. This development stream is much like how we've been deploying Landscape up until now — but now it's optional.
63+
64+## Mitosis
65+
66+Describing our progress so candidly can feel strange — after all, it sounds so *early*. But to me, it’s exciting. It’s mitosis.
67+
68+Take another example. For all of Urbit’s history — all until now — Tlon was playing the role of both parents to the project when it was really just an embryonic corporate vehicle itself, fated to become twins. But in the past few months the burgeoning Urbit Foundation’s interim Director, Josh Lehman (`~wolref-podlex`), has begun to ramp up responsibility, taking increasing stewardship over urbit.org and giving it a physical voice, an Otherness, apart from Tlon’s own goals.
69+
70+Now, each day, we stray a little closer to these entities splitting apart, a step closer to the Urbit Foundation and the Tlon Corporation being completely different entities with completely different concerns.
71+
72+The same has occurred with Landscape. Previously Landscape was “*the* interface to Urbit,” the proof that there was more to the project than a Unix executable. And slowly to those of us at Tlon, it became obvious what it was destined to become: a flagship client for an entire network, a tree branch rooting a world beneath clearnet, the first cell by which other clients might be born. Mitosis can be clumsy to watch; it can be nauseating to experience; it can be difficult to make out what will arrive where.
73+
74+But this is, after all, how a body forms.
content/blog/security-audit.mdnew file+157
@@ -0,0 +1,157 @@
1++++
2+title = "Ames Security Audit and the Future of the Protocol"
3+description = "Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI."
4+date = 2020-12-18
5+[extra]
6+author = "Ted Blackman + Anthony Arroyo"
7+ship = "~rovnys-ricfer + ~poldec-tonteg"
8+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/20201218-audit.png"
9++++
10+
11+<br>
12+
13+![audit](https://storage.googleapis.com/media.urbit.org/site/posts/essays/20201218-audit.png)
14+
15+<br>
16+
17+The security firm Leviathan has now finished their initial audit of the security of Urbit's Ames network protocol. In addition to their review of Ames, we also asked them to identify any other issues in order to help guide further development.
18+
19+I'm pleased to report they confirmed the cryptographic soundness of the protocol, namely that "a ship must have possession of their own valid Urbit key in order to authenticate as that ship and to send valid Ames messages. Additionally, no other ship except the two communicating may be able to decrypt or modify messages during transport."
20+
21+This means Ames uses cryptography in a mathematically sound manner that protects your privacy, keeps your secrets secret, and ensures nobody else will be able to impersonate you on the network. Since this was an architectural audit, it’s possible there are still vulnerabilities in the runtime implementation. Until the runtime has been hardened, Tlon continues to recommend against storing valuables in your ship.
22+
23+Aside from a couple of minor issues that have already been resolved, there are three general classes of problem highlighted in their report that future work will need to address:
24+
25++ Forward secrecy
26++ Protection against denial of service attacks
27++ Enforcement of social boundaries
28+
29+Ames’ design allows for versioning of the protocol, which means that the proposed changes below can be deployed as over-the-air updates as they become more pressing concerns. This feature gives us confidence that we can address future security issues as they arise.
30+
31+We will need to improve all of these over the next couple of years, as independent lines of work. As the network grows: better forward secrecy will decrease the damage from a key getting compromised; resistance against denial of service attacks will make the Urbit network resilient to increasingly determined saboteurs; and stricter enforcement of social boundaries will let Urbit’s social networks remain safe and friendly despite potentially increasingly large numbers of bad actors and increasingly complex app ecosystems.
32+
33+## Forward Secrecy
34+
35+A protocol is said to have forward secrecy if compromising a key used in a recent message doesn’t also compromise all previous messages. Similarly, a protocol is said to have backward secrecy -- also called future secrecy -- if compromising a key used in a previous message fails to compromise all future messages. Ames has some degree of both, but more would be better, to decrease the damage an attacker could inflict by compromising a key.
36+
37+As it stands, an Urbit user can change their Ames keys whenever they want, by conducting an Ethereum transaction to update the Ames public key listed in the Azimuth contract, which implements Urbit’s PKI on Ethereum. Compromise of one Ames private key does not compromise earlier or later keys, so this has both forward and backward secrecy. The main drawback is that Ethereum transactions can be expensive, so key rotation is likely to be infrequent, and an attacker might be able to gain access to a long stretch of time by compromising a single key.
38+
39+Various key rotation “ratchet” schemes could be added to Ames to establish varying degrees of forward and backward secrecy, and other kinds of cryptographic protections beyond basic soundness, such as break-in recovery.
40+
41+Right now, changing a key through Azimuth is a manual process. It could be automated, possibly as one of a suite of services that an Urbit Provider will offer. Unfortunately, each key rotation costs the user money, so automating rotation could get prohibitively expensive.
42+Existing protocols, such as the Signal app's encrypted messaging protocol, the Noise protocol framework, and the Wireguard VPN protocol, use ephemeral Diffie-Hellman key exchange and KDF chaining to achieve forward and backward secrecy and self-healing.
43+
44+Ames could be upgraded to use one of these existing ratchet algorithms, or we might create an Urbit-specific variant optimized for the Urbit network. This is work that should be done, but fortunately it will not require any novel research or drastic changes to Ames’s architecture.
45+
46+While Urbit’s cryptographic protections don’t yet match those of Signal or a few other privacy-focused apps, Ames is cryptographically sound, and since Urbit updates itself over-the-air and is backed by a stable, decentralized PKI, I’m confident that the level of sophistication of Urbit’s cryptography has the potential to be world-class with just a bit more work.
47+
48+## Denial of Service
49+
50+A denial of service (DoS) attack against an Urbit ship is an attempt to overwhelm it remotely by sending it network data in such a way as to interfere with the ship’s ability to communicate with other ships or process other events -- usually by hogging its resources (computational power, memory, or bandwidth) until normal operation slows down or ceases entirely. Since the promise of Urbit is that everyone can run their own server, that server needs to be able to defend itself against DoS attacks. This is in fact one of the main impediments to running your own server in the modern world.
51+
52+Right now, Urbit has no protection. Soon, it will need to at least be able to resist a simple attack carried out by an individual. Eventually, it should be able to resist a determined Distributed Denial of Service (“DDoS”) attack, which is more difficult.
53+
54+There are two categories of DoS attacks in Urbit: authenticated and unauthenticated. An authenticated attack requires access to a ship's private key to construct valid Ames packets intended to overwhelm a target. All authenticated attacks will be handled primarily through enforcement of social boundaries, as discussed in the next section.
55+
56+An unauthenticated DoS attack constructs packets that eventually fail to authenticate and decrypt but still overwhelm the target by causing it to waste resources (CPU, memory, disk, bandwidth) in such a way that it can't keep up with legitimate communications.
57+
58+An unauthenticated DoS attack relies on the lack of Sybil resistance of IP networks: it's possible to generate new IP addresses rapidly, and a determined attacker might also be able to spoof its sender IP address. This is best considered an IP-layer attack that must be handled mostly at the IP layer itself, by maintaining state about which IP addresses can be trusted and which can't, determined empirically and heuristically by the Urbit runtime. The best any higher-level protocol, such as Ames or TCP, can do is make it as cheap as possible for a DoS target to reject a bad packet.
59+
60+The overall strategy that Ames can take, as a protocol layering over the IP protocol, is to add an authentication procedure to each packet that can quickly identify bad packets, which an implementation will then use to mark that IP address as suspect and to refrain from adding the sender IP to a list of known-good IPs.
61+
62+Currently, Ames handles this by attempting to decrypt a message and rejecting the message on failure. This may be a more costly solution than other methods, such as attaching a signature or a MAC to each message. The way to mitigate unauthenticated attacks is to make bad packets fail faster by augmenting each packet with a signature or MAC to each packet, since those are faster to validate than encryption.
63+
64+So far, we have identified three approaches that could be taken here. Of these three, Leviathan recommended the end-to-end HMAC solution, since that would not impose additional CPU requirements on packet-relay nodes, such as stars.
65+
66++ Sign each packet, and any relay or final recipient could validate the signature
67++ Wrap each packet in an HMAC, validated by the final receiver
68++ Wrap each packet in a HMAC for each hop in a relay chain; each relay would validate and strip the previous HMAC and add a new one for the next hop
69+
70+Any of these solutions would be attempts to increase the rate at which the network could discard invalid packets, with different tradeoffs. I'll back up a bit to provide some context, and then I'll compare the approaches.
71+
72+In any DoS solution, a planet will want to block or throttle IPs that have been sending it packets that fail to authenticate and decrypt. Ideally, a star will help protect planets for whom it’s relaying, too. Many different arrangements among galaxy, star, and planet are imaginable here, from an open policy to a policy wherein each packet has to come from a known-good IP. This sort of paranoid, closed-off arrangement might still not be enough to withstand a determined DDoS, but it's difficult for me to imagine doing better than that without launching Urbit-specific ISPs. Ames packets are cryptographically authenticated, so an Urbit ISP would actually be feasible.
73+
74+This brings us back to the three possible ways of mitigating DoS from within the Ames protocol. They all involve adding a piece of authenticating information to each packet that can be verified more quickly than waiting for the cyphertext to fail to decrypt — Ames's symmetric encryption is authenticated, so it's not a cryptographic soundness issue, but the performance impact of trying to decrypt could be significant enough to make it hard to prevent a DoS.
75+
76+As-is, an Ames packet is basically `[protocol-version checksum sndr rcvr (nullable origin) cyphertext]` (visit [this PR](https://github.com/urbit/urbit/pull/4051#issue-530369627) for a full specification). Let’s walk through the construction of the packet and how it can be upgraded to offer different DOS mitigations.
77+
78+### DoS Mitigation Approach 1: Signature
79+
80+The first approach to DoS protection would be to add a signature to the packet. The signature would cover everything except the checksum and the origin, since those need to be swapped out by relays. The signature would probably obviate the need for the (20-bit) checksum, although we could also leave it in there if we can't figure out what else to do with those header bits.
81+
82+#### Advantages of a signature over other approaches
83+
84+- It can be validated by anyone on the network. Relays would not need to modify it. This might also give it symmetry with the upcoming remote scry protocol, which might also sign every packet. I'm not quite sure this is an important property, actually, but it might theoretically make launching an Urbit ISP or internet backbone easier one day.
85+- It would be signed directly by the key listed on Ethereum, not something that might get ratcheted at some point for better forward secrecy — this could eventually lower the rate at which intermediate validators need their key caches invalidated, although this is a bit of a theoretical concern.
86+
87+#### Disadvantages of a signature over other approaches
88+
89+- Generating and validating a signature is significantly slower than generating and validating an HMAC.
90+- An ECDSA signature is 64 bytes, which is ~6% of a packet payload. As far as I can tell, it can't be compressed.
91+- Since the signature could be validated by anyone, it doesn't attest to a specific communication channel, so it might not help as much with IP filtering.
92+
93+### DoS Mitigation Approach 2: End-to-End HMAC
94+
95+The second approach would be to use an HMAC instead of a signature, validated by the eventual receiver. This HMAC would also cover everything except the mug and origin. I'm calling this the "end-to-end HMAC" design. An HMAC requires a shared secret, for which we could use the same symmetric key that Ames uses.
96+
97+#### Advantages of end-to-end HMAC
98+
99+- It's simple in some sense; relays don't need to do anything cryptographic.
100+- HMACs are much faster to create and validate than signatures.
101+- HMACs, since they're hashes, can be truncated arbitrarily and still maintain some security — to find hash collisions, you'd still have to guess what packet||shared-secret would hash to; it would just be a smaller search space. Since Ames's encryption already guarantees authentication and we'd just be using this as a performance optimization, I suspect we could get away with using one that's significantly smaller than a signature — I'm not sure how small, but if 4 bytes would be enough in practice, that would take up less than 0.5% of the space in a packet.
102+
103+#### Disadvantages of end-to-end HMAC
104+
105+- Only the recipient can validate. This means the authentication couldn't be used by relays to discard invalid packets. The recipient could provide back-pressure out-of-band to a relay to ask the relay to discard packets from an IP with an invalid HMAC, but this is indirect and might need to filter backward through multiple relays to work properly.
106+
107+### DoS Mitigation Approach 3: Point-to-Point HMAC
108+
109+The third approach, which is what I would build unless convinced otherwise, is what I'm calling "point-to-point HMAC". This design would include a different HMAC for each hop in a relay chain, instead of (or maybe in addition to) including one end-to-end HMAC.
110+
111+We have a couple different options for how to construct the shared secret for each hop. I would intuitively construct it using a Diffie-Hellman of my private signing key and your public signing key — the "networking keys" on Ethereum include a currently unused signing key in addition to the encryption key that Ames uses. This way even if we add more forward secrecy to Ames, changing the symmetric key used for encryption, relays wouldn't have to have their caches invalidated as often; the state required to perform relaying wouldn't be as tied to the state required to receive a message.
112+
113+#### Advantages of point-to-point HMAC
114+
115+- A star could perform some validation on every packet it's asked to relay. This makes it more difficult for an attacker to route a ton of packets to a planet through a star, or even through many relays. Signatures also have this property, but they're slower to verify. This approach and the signature approach, but not the end-to-end HMACs, force an attacker to use an (at least partially) authenticated attack in order to use a relay as a way to get to a planet.
116+- A planet could quickly validate that a relayed packet actually came from its star, not an attacker who's managed to spoof the star's IP address.
117+
118+#### Disadvantages of point-to-point HMAC
119+
120+- Not everyone on the network can validate a packet, unlike a signature.
121+- Each relay needs to validate and strip off the previous HMAC and create a new one before sending it. This should be quite fast, since an HMAC is just a hash, but it's still some CPU, and potentially creates an imbalance where an attacker could induce the relay to spend more CPU in validation than the attacker spent in constructing the packets.
122+- By itself, it doesn't validate the cyphertext in an end-to-end way. I suspect we might want to include both a per-route HMAC and an end-to-end one, especially if we use truncated HMACs — although per-route might be enough on its own, since if the receiver fails to validate a bunch of packets whose HMACs were validated by the relay, the receiver can ask the relay to block that whole Urbit address regardless of IP, so it shouldn't be possible to sustain that kind of attack for long.
123+
124+#### An Aside About Cryptographic Performance
125+
126+I'm not sure exactly how much faster HMAC is. According to DJB (https://ed25519.cr.yp.to/ed25519-20110705.pdf), an ECDSA signature can be created in around 30 microseconds and verified in around 100 microseconds. This source (https://www.jacksondunstan.com/articles/3206) suggests about 21 microseconds for HMAC-SHA256, so about a 1.5x improvement in generation speed and 5x in validation speed. We should verify these numbers for ourselves before making a decision.
127+
128+### DoS Protection Strategy and Timeline
129+
130+Tlon is not currently pursuing adding any of the extra cryptographic authentication on Ames packets described above. Since this is ultimately a performance issue, there are other more pressing performance issues that we could improve upon before decryption will become the limiting factor in how many packets can be processed by a ship. We will revisit this authentication performance question once some of the low-hanging fruit has been done, perhaps roughly a year from now.
131+
132+Since the audit, we’ve already improved the Ames packet format to allow faster parsing, faster validation of basic fields, and faster relaying; in the future, increases in performance of Nock execution and inter-process communication between Urbit's I/O process and Nock worker would allow Urbit to absorb somewhat more punishment before service can be effectively denied.
133+
134+## Enforcement of Social Boundaries
135+
136+While Urbit needs to rely largely on its runtime to mitigate unauthenticated attacks, any attack conducted from an Urbit ship needs to be handled inside Arvo itself, not just by IP filtering in the runtime. Just like in any DoS, an attacker ship might try to induce you to use too much memory, CPU, or disk space in order to sabotage normal operation. An authenticated attack is harder to define than an unauthenticated attack, because it depends on what social relationship the attacker and target have, and it involves valid, authenticated Ames packets; once discovered, though, it’s easier to mitigate, because it can use Urbit’s permanent identity system to enforce social consequences, i.e. stop listening to that Urbit address and possibly encourage others to do so as well.
137+
138+There are a couple of different kinds of authenticated attack: attempts to exploit vulnerabilities in the Nock worker (the interpreter, allocator, and jets) by causing particular Nock code to run, and attempts to induce the target to exhaust various computational resources.
139+
140+Protecting against attempts to break out of the sandbox and hijack or otherwise interfere with the Unix process running Nock will require a process of hardening, fuzzing, and likely further security audits specifically evaluating the security of that boundary. This is largely out of scope of the Ames protocol itself, which was the subject of this audit.
141+
142+This leaves us with the latter case: resource exhaustion attacks. A peer could try to get my ship to use too much RAM, disk, CPU, or bandwidth by sending it valid Ames packets. This represents a social problem: a person on the network is trying to interfere with me. It's what's known in blockchain circles as an "attributable fault": once the attack is detected, it's trivial to determine the identity of the culprit.
143+
144+Once the attacker’s Urbit address is known, Urbit will fall back on the Sybil resistance of its identity system: there are a finite number of identities, each of which costs some money. Because Urbit identities are relatively permanent, they can be blocked permanently. As long as the expected value of an authenticated attack is less than the cost of the identity, the attacks won't happen very much — they'll cost money to sustain, instead of being self-perpetuating.
145+
146+Attacks like this are best thought of as attempts to violate social boundaries. I don't want you using up too many of my resources; that's a social boundary, and an attempt to force my ship to spend its resources on your behalf constitutes a violation of this boundary. The strategy for mitigating these attacks is to impose social and, indirectly, economic consequences on the perpetrators. The main social consequence is other ships refusing to communicate with you anymore.
147+
148+Some of this mitigation will take place in the Arvo kernel, and some will need to be application-specific. To protect the system from attackers, the kernel needs to be able to free space (Urbit is a single-level store, so there's no distinction between disk and RAM from Arvo's perspective) taken up by unfinished messages sent by peers. This can be done by allowing an application to ask Ames to delete partially received messages from a peer, generally replacing the received packets with an intent to nack (negative acknowledgment) to indicate that the transaction the peer wanted me to perform has been rejected.
149+
150+Applications should also be able to set resource usage policies that the Arvo kernel will enforce. For example, a chat application should configure Ames to reject any chat messages larger than, say, two hundred kilobytes. A file-sharing application would need a much larger per-message limit (ideally no per-message limit), but it might need to place a cap on its bandwidth usage to make sure lower-latency communications aren't swamped by a large file transfer. This kernel/application interface starts to resemble a permissioning or capabilities system, and it could be built as part of the crucial larger project of providing for configurable application permissions.
151+
152+To close the loop on enforcing social boundaries, reputation information should be shared across ships. This will likely be done by building one or more applications that share statistics and block operations. Some forms of reputation are likely to be globally shared, whereas others are likely to be multipolar, i.e. some people like you and some don’t. Generally, the lower the layer of the attack, the more global the reputation effect will be; the higher the layer, the more multipolar. An attempt to spam the network with millions of malicious packets will cause most people not to want to talk to you; sending me a movie I found mediocre is probably not even information worth sharing with anyone else.
153+
154+
155+## Conclusion
156+
157+Ames’ design has unparalleled potential to deter, mitigate, and recover from attacks, since every packet is authenticated and encrypted and backed by a stable, decentralized PKI. It feels good to have our design for encryption and authentication be confirmed by a third party as cryptographically sound, and we know more or less what we need to build to reach the full security potential of the platform, including the steps outlined here.
content/blog/toward-a-new-clay.md+1−1
@@ -40,7 +40,7 @@ spartan than `bzr`.
4040
4141(In fact, it's really too spartan to fully use at the moment. We
4242ourselves still use `%clay` mainly as a distribution system, and
43−do all internal development on Github. This is because the
43+do all internal development on GitHub. This is because the
4444present `%clay` lacks a few little conveniences, like commit
4545messages. See upgrades, below.)
4646
content/blog/urbit-and-the-blockchain.md+3−3
@@ -34,7 +34,7 @@ for this reason alone. (That said, Ethereum may be less exposed to Chinese
3434politics.)
3535
3636We chose ETH because it is the strongest *computational* chain. It is certainly
37−stronger than the way we're storing the Urbit land registry now: Github, plus
37+stronger than the way we're storing the Urbit land registry now: GitHub, plus
3838internal records.
3939
4040Urbit is not endorsing Ethereum. Urbit is not creating any appreciable monetary
@@ -58,7 +58,7 @@ wasn't between a blockchain and nothing. It was a choice between 21st-century
5858tools and 20th-century tools.
5959
6060The current Urbit land registry is divided into parts stored in various places:
61−Github commits, database records held by Tlon Corporation, and insecure keys on
61+GitHub commits, database records held by Tlon Corporation, and insecure keys on
6262a test network. This might have been fine, for us, in 2015. In 2017, it's
6363borderline unacceptable.
6464
@@ -182,7 +182,7 @@ friend help.
182182
183183Bitcoin maximalists understand that all monetary energy should concentrate in a
184184single currency. But land isn't money. And the technical details of the
185−implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or Github
185+implementation of the Urbit registry -- whether `OP_RETURN`, Ethereum, or GitHub
186186-- have no effect on Bitcoin supply and demand.
187187
188188## Another reminder
content/blog/urbit-for-normies.md+1−1
@@ -160,7 +160,7 @@ Imagine, as is already becoming the case, that it becomes highly valuable to hav
160160
161161Some of these cases are, admittedly, a bit speculative since we haven’t built all the functionality yet. But it’s coming, and quite soon.
162162
163−For now, if you like the way this sounds you can [get yourself an Urbit ID](https://urbit.org/using/install/#id) and start learning about how to safely store cryptographic keys (it’s really not that hard, and we give you suggestions). If you’re feeling technical or adventurous, you can try booting our beta OS interface to see what it looks like. It’s fussy, but it exists. Soon it will be less fussy. You can check out our [roadmap](https://urbit.org/understanding-urbit/roadmap/) if you’d like to know when.
163+For now, if you like the way this sounds you can [get yourself an Urbit ID](https://urbit.org/getting-started/#id) and start learning about how to safely store cryptographic keys (it’s really not that hard, and we give you suggestions). If you’re feeling technical or adventurous, you can try booting our beta OS interface to see what it looks like. It’s fussy, but it exists. Soon it will be less fussy. You can check out our [roadmap](https://urbit.org/understanding-urbit/roadmap/) if you’d like to know when.
164164
165165## Why we need Urbit
166166
content/blog/value-of-address-space-pt1.md+6−6
@@ -88,15 +88,15 @@ Urbit was originally an experimental personal project. The original Urbit addres
8888
8989Once Urbit became a working prototype, in mid 2013, a company (Tlon) got off the ground to help develop Urbit and a number of other developers joined. At this point, Tlon bought half the address space from Curtis for what now looks like an exceptionally good deal. Then Curtis and Tlon each earmarked a significant chunk of address space for infrastructure and community development — we refer to this as the urbit.org address space, and it’s held by Tlon.
9090
91−From 2014-2018 Tlon and Curtis both gave away address space to individual contributors who were helping with the project. In 2016 and 2017, Tlon sold some of its address space in two crowdsales to fund the development of Urbit (which formatted the Urbit address space as a user-facing system).
91+From 2014-2018 Tlon and Curtis both gave away address space to individual contributors who were helping with the project. In 2016 and 2017, Tlon sold some of its address space in two crowdsales to fund the development of Urbit (which formatted the Urbit address space as a user-facing system). These sales were focused on getting address space into the custody of users with an interest in the technology and developing the network.
9292
9393It was then decided that a public key infrastructure was the most logical way to instantiate ownership of Urbit address space. Thus, after much [consideration](https://urbit.org/blog/urbit-and-the-blockchain/), Urbit ID was deployed to Ethereum in January 2019 under a set of contracts called Azimuth. At this point, there were about 2000 star holders and around 80 galaxy holders. We can’t be sure how many independent holders there are now — the address space is entirely out of our hands — but the distribution has been steadily increasing. Addresses trade regularly on urbit.live and Opensea, and are sold by a few other smaller outlets like planet.market and Urbit Marketplace, all of which are independent of Tlon.
9494
9595## Analogues and the intrinsic value of address space
9696
97−We’ve often said that Urbit address space, particularly stars and galaxies, have intrinsic value that should be understood beyond simply the price of the planets they contain. Another way of putting this is that, because stars and galaxies are infrastructure nodes, they’re uniquely positioned to generate cash flow from activities on the network beyond simply selling their planets.
97+We’ve often said that Urbit address space, particularly stars and galaxies, have intrinsic value that should be understood beyond simply the price of the planets they contain. Another way of putting this is that, because stars and galaxies are infrastructure nodes, they’re uniquely positioned to generate cash flow from activities on the network beyond simply selling their planets.
9898
99−Let’s dig a bit deeper into these activities through the lens of some analogues to the existing world.
99+This cash flow won't likely come from passive activity, but from actively working to develop businesses located on stars and galaxies. Let’s dig a bit deeper into these activities through the lens of some analogues to the existing world.
100100
101101### DNS
102102
@@ -112,7 +112,7 @@ CDNs (content delivery networks) are another useful comparison. Stars are perfec
112112
113113### Software distribution
114114
115−An infrastructure innovation that’s relevant here is that Urbit OS is specifically designed to make over-the-air (OTA) updates to the system — meaning software and updates are distributed automatically with no effort on the part of the end user. By default, planets and stars get their system updates from their sponsors. As the system evolves, we expect stars and galaxies to not only provide core system (kernel) updates, but also to act as software distribution hubs. This service likewise represents a potential profit center.
115+An infrastructure innovation that’s relevant here is that Urbit OS is specifically designed to make over-the-air (OTA) updates to the system — meaning software and updates are distributed automatically with no effort on the part of the end user. By default, planets and stars get their system updates from their sponsors. As the system evolves, we expect stars and galaxies to not only provide core system (kernel) updates, but also to act as software distribution hubs. Stars will distinguish themselves from one another by the quality of their service. Some might focus on speed of distrubtion; others on assesing the quality of the code they distribute. All of this represents effort on behalf of the star, and could act as a profit center for the star operator.
116116
117117### Payments and transactions
118118
@@ -132,13 +132,13 @@ Another approach to developing the value of address space that is already emergi
132132
133133These providers sell users a planet, host it for them, and deliver related services through their stars and galaxies. This means that with a couple of clicks an ordinary user could buy a planet, sign up for a hosting/routing bundle, get access to a set of services, and be immediately ready to interact with the community of their choice.
134134
135−There are plenty of other examples that we haven’t even imagined yet. The important thing is that stars will likely distinguish themselves through the services they provide. Since planets and stars can always change sponsors, a large part of the long-term monetization of a star or galaxy lies in the quality of service.
135+There are plenty of other examples that we haven’t even imagined yet. The important thing is that stars will likely distinguish themselves through the services they provide. Since planets and stars can always change sponsors, a large part of the long-term monetization of a star or galaxy lies in the quality of service that a given star operator provides.
136136
137137This independent ecosystem has a secondary benefit of creating a varied tapestry of digital environments on Urbit, since every community and every dealer-operator can customize as they see fit. That variety will make the landscape much more interesting and ripe for exploration than anything we might create with the top-down approach found on centralized services. That variety will also likely cause a range of values for planets depending on their sponsor or “location”.
138138
139139This ecosystem has already begun to emerge. Both Tlon and urbit.live are working on developing services along these lines, and we’ve heard from several other entrepreneurs considering similar offerings. This is emerging not simply because it serves a user need, but because it’s the directional flow of the system. In other words, it’s the simplest way to monetize address space while avoiding the oligarchic, surveillance-based, advertising-oriented systems we’re stuck with today.
140140
141−To summarize, our view is that Urbit address space is valuable because it’s useful and it’s scarce (also, it’s tradable and has network effect, but more on those later). What’s more, while the use case has already begun to take shape, it will grow in directions we can’t yet imagine because the system is designed to be extensible — Urbit is a homestead, not a hotel.
141+To summarize, our view is that Urbit address space is valuable because it’s useful and it’s scarce (and it has network effect, but more on that later). What’s more, while the use case has already begun to take shape, it will grow in directions we can’t yet imagine because the system is designed to be extensible — Urbit is a homestead, not a hotel.
142142
143143We’re looking forward to seeing what the world builds with Urbit.
144144
content/blog/value-of-address-space-pt2.md+14−12
@@ -16,7 +16,7 @@ image ="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2.jpg
1616
1717## Measuring value
1818
19−Value and price are distinct concepts that often get conflated. In our view, Urbit address space has value for four fundamental reasons: it’s scarce; it has utility; it’s tradeable with increasing liquidity; and it has network effect. Price, on the other hand, is always a function of supply and demand. Let’s take a look at these fundamentals within the Urbit ecosystem.
19+Value and price are distinct concepts that often get conflated. In our view, Urbit address space has value for four fundamental reasons: it’s scarce; it has utility; it has some limited liquidity; and it has network effect. Price, on the other hand, is always a function of supply and demand, and it's not something we – as builders – concern ourselves with very much. Let’s take a look at these fundamentals within the Urbit ecosystem.
2020
2121
2222
@@ -35,9 +35,9 @@ There are 256 galaxies on the network. Each galaxy is initialized with ownership
3535
3636There are 65,536 total stars on the network. In turn, each star is initialized with ownership of 65,536 planets. Stars currently trade on platforms independent of Tlon, such as [urbit.live](https://urbit.live/) and [opensea.io](https://opensea.io/). The current price range can easily be ascertained on those sites, but as of the time of this writing, stars are selling at a price that greatly discounts their planet holdings.
3737
38−We anticipate the relative pricing of stars and planets to align (so to speak) as Tlon and others increase education about Urbit, and as additional planet sellers and hosting providers enter the market.
38+One would expect that in an efficient market the relative pricing of stars on one hand, and planets on the other hand would eventually align (so to speak). This may come to pass as the Urbit community increases education about Urbit, and as additional planet sellers and hosting providers enter the space.
3939
40−Finally, there are 4,294,967,296 (or 2<sup>32</sup>) planets on the network. Planets currently trade largely in a range of $10 to $15. While we expect planet prices to fluctuate from provider to provider as described in the previous post, we also expect they will ultimately find an equilibrium price somewhere near their current range for two reasons. First, this range is affordable for most purchasers, and second, the cost to configure addresses for distribution is fairly static and acts as something of a price floor.
40+Finally, there are 4,294,967,296 (or 2<sup>32</sup>) planets on the network. Planets currently trade largely in a range of $10 to $15. We expect planet prices to fluctuate from provider to provider as described in the previous post, based on the quality of services various providers offer. That said, it's worth noting that the cost to configure addresses for distribution is fairly static and this may act as something of a lower bound.
4141
4242That said, we also anticipate that planet prices will be abstracted away from most purchasers, and will be included in bundled annual packages of hosting and data routing services. For this reason, infrastructure service providers (i.e. hosting providers) will likely be the best positioned parties to capture value from planet distribution.
4343
@@ -50,15 +50,15 @@ Utility (i.e. what Urbit addresses can be used for) has largely been addressed i
5050
5151As a refresher, this use value falls in five broad categories.
52521. Authentication technology is broadly useful. All Urbit identities — planets, stars, and galaxies — can be used for authenticating one’s Urbit computer, and for authentication in general. Urbit ID was designed for Urbit-specific authentication, but a lot of general functionality can be built on top of this infrastructure. Urbit ID is simple, extensible, and easy to use, making PGP style claims much more useful than they are today.
53−2. Network infrastructure services represent a revenue stream. Stars and galaxies specifically should be understood primarily as revenue-generating network infrastructure. We anticipate that stars and galaxies will eventually charge for infrastructure related services, like hosting and packet routing, and will distinguish themselves on quality and service.
53+2. Network infrastructure services represent a potential revenue stream. Stars and galaxies specifically should be understood as providing their owners the opportunity to develop and use network infrastructure. We anticipate that stars and galaxies will eventually charge for infrastructure related services, like hosting and packet routing, and will distinguish themselves on quality and service.
54543. Stars and galaxies are well positioned to offer additional services. Because of their role as high level network nodes, stars and galaxies are uniquely positioned to offer additional services, including content delivery networks (CDNs), Bitcoin and other blockchain-related nodes, 0x relays, and Tor exit nodes.
55554. Schelling points have value. Because stars and galaxies hold a certain authority on the network (by dint of their relationship to their subsidiary nodes), they act as [Schelling points](https://nav.al/schelling-point), or default hubs, for various activities that will arise as the network grows. Already various groups and communities are beginning to collect around stars. This gravity has value and will eventually be priced.
56−5. Voting has value. Galaxies exclusively hold a vote on the network. This voting right can be separated from the galaxy itself and transferred, and we anticipate that this will happen eventually. The value of this right has not yet been priced into the market, though as Urbit adoption grows, the value of a vote will emerge and increase.
56+5. Voting has value. Galaxies exclusively hold a vote on the network. This voting right can be separated from the galaxy itself and transferred, and we anticipate that this will happen eventually. The value of this right has not and may never be priced into the market, though as Urbit adoption grows, the value of a vote may emerge.
5757
5858Utility is only one component of a value calculation. To further develop the inquiry into value, let’s move on to trading factors.
5959
6060## Trading, volume, and liquidity
61−Urbit IDs are individually represented by non-fungible ERC-721 tokens, and are therefore tradable on the open market by any platform that supports this token standard. Currently there are three known Urbit-exclusive sales platforms and one generalized ERC-721 trading platform that list Urbit IDs. Aggregate market prices for stars and planets are readily available. Volume is low, as no effort has been made to promote the fact of availability, yet the number of [total transactions](https://azimuth.network/stats/events.txt) has increased steadily since the network was launched to Ethereum in 2019, even absent public messaging.
61+Urbit IDs are individually represented by non-fungible ERC-721 tokens, and can therefore be sold by any platform that supports this token standard. Currently there are three known Urbit-exclusive sales platforms and one generalized ERC-721 platform that list Urbit IDs. Prices for stars and planets are readily available. Volume is low, as no effort has been made to promote the fact of availability, yet the number of [total transactions](https://azimuth.network/stats/events.txt) has increased steadily since the network was launched to Ethereum in 2019, even absent public messaging.
6262
6363<br>
6464<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2-tps.svg">
@@ -68,7 +68,7 @@ Urbit IDs are individually represented by non-fungible ERC-721 tokens, and are t
6868<img class="" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt2-tss.svg">
6969<br>
7070
71−Trading non-fungible tokens like Urbit IDs is rather different than trading quasi-fungible tokens like Bitcoin (even setting aside the issue of volume). Each Urbit ID is unique, and so they tend to be purchased by end users for their specific characteristics, rather than generically. As an example, the planet `~parret-barret` sold for about $1,000 at a time when most planets were selling for $10-20, perhaps due to its rhyming name. Planets with circular sigils also often sell for significantly above market rate — we’re not entirely sure why this is the case.
71+Buying non-fungible tokens like Urbit IDs is rather different than trading quasi-fungible tokens like Bitcoin (even setting aside the issue of volume). Each Urbit ID is unique, and so they tend to be purchased by end users for their specific characteristics, rather than generically. As an example, the planet `~parret-barret` sold for about $1,000 at a time when most planets were selling for $10-20, perhaps due to its rhyming name. Planets with circular sigils also often sell for significantly more than other planets — we’re not entirely sure why this is the case.
7272
7373## Planet Sales
7474
@@ -88,9 +88,7 @@ Trading non-fungible tokens like Urbit IDs is rather different than trading quas
8888
8989This ID-specific trading pattern is generally appropriate in our view: Urbit ID isn’t designed to be rapidly traded at high volume. Urbit is more like a house than a fungible good like a currency.
9090
91−Nevertheless, it would be theoretically possible to create a more traditional orderbook for unstarted addresses. Unstarted addresses have different names and sigils, but they’re functionally the same in every other way, so they could be collateralized to a specific token to encourage price discovery. This hasn’t happened, and Tlon has no intention of releasing such functionality, but it’s worth mentioning in a discussion of liquidity.
92−
93−For the time being trading of Urbit IDs happens through auctions on specific platforms, and via person-to-person transactions, because each trade is for a _specific_ Urbit ID. Again, Urbit ID is designed in the spirit of property titles, rather than currencies, so this makes sense.
91+For the time being buying and selling of Urbit IDs happens through auctions on specific platforms, and via person-to-person transactions, because each transaction is for a _specific_ Urbit ID. Again, Urbit ID is designed in the spirit of property titles, rather than currencies, so this makes sense.
9492
9593Strictly speaking, liquidity is a measure of the degree to which a given asset will change in value due to a given transaction. In that sense, Urbit address space is likely fairly illiquid. But liquidity can’t be properly understood without volume. As noted above, the volume of transactions on the network has been steadily increasing since inception, and yet the price has remained fairly constant. This seems to indicate a healthy ratio.
9694
@@ -100,7 +98,7 @@ Strictly speaking, liquidity is a measure of the degree to which a given asset w
10098
10199<br>
102100
103−A further impact on liquidity and volume is that of available supply. At present, the majority of Urbit address space is locked by smart contracts. These lockups began to release at varying linear rates in January 2019. All address space will be completely unlocked and tradeable by January 2025. We anticipate initial downward price pressure on stars and planets as availability outstrips initial demand. Eventually as both understanding and demand increase, we anticipate that planets will find their equilibrium price, and stars will be repriced accordingly.
101+A further impact on liquidity and volume is that of available supply. At present, the majority of Urbit address space is locked by smart contracts. These lockups began to release at varying linear rates in January 2019. All address space will be completely unlocked and tradeable by January 2025. Eventually as both understanding and demand increase, we anticipate that planets will find an equilibrium price, and stars will be repriced accordingly.
104102
105103We’ll discuss lockups and spawning limits in more detail in the third installment of this series.
106104
@@ -122,7 +120,9 @@ Digging deeper, Urbit is unusual as a network for the following interrelated rea
122120The upshot is that Urbit can serve as the meta-network for many different kinds of individual networks, each with their own value. Urbit is much more akin to the internet itself than it is to, say, Facebook. Reed’s and Metcalf’s laws therefore apply to Urbit in some very interesting ways.
123121
124122## Network laws
125−Three laws are typically cited to express the value of a network:
123+Before diving into a discussion of network effect, it's worth noting that although individual tokens and users of those tokens benefit in various ways from a thriving network, the structure of the Urbit network does not grant token holders any rights to profits or losses "generated by the network" as a whole. In fact the very notion is counter to the intent of Urbit's ethos of decentralization. Individuals on the network may profit by their own activities, but there is no central authority profiting off activity in the aggregate; there is no ownership of the network as a whole, and so there are no centralized profits and losses to share. Address space tokens represent one's ownership of their own parcel of land as it were.
124+
125+That said, an entire continent may have aggregate value even though it is distributed. To explore this notion with regards to Urbit, it's worth reviewing the three laws typically cited to express the value of a network as a whole:
126126- Sarnoff’s law states that the value of a network increases proportionally to its size. This is widely understood to understate the value of most modern networks.
127127- Metcalf’s law states that the value of a network is the square of the number of users (n^2).
128128- Reed’s law states that the value of a network increases with the number of groups that can be built on the network. This is expressed as 2^n, where n is the number of groups.
@@ -133,6 +133,8 @@ Urbit is a network of networks, and so is best described by Reed’s law.
133133
134134Urbit’s unique approach to groups also helps resolve two other problems which lead to value loss in many networks: Urbit’s design significantly reduces both network pollution (i.e. irrelevant feeds) and network congestion (clogged bandwidth), as individual clusters can easily separate their activity from other networks on the platform.
135135
136+
137+
136138## Urbit is a platform network
137139It’s important to note that Urbit has utility absent the network, as Urbit OS is in fact a Turing-complete virtual computer. Though the system is designed around communities, individuals can use Urbit to create personal documents, archive data, and write code for the system. This is how Urbit’s total network size can be relatively small and still provide value for individual users and clusters. However, Urbit already has users, and for many of these, critical mass — the point at which the network is more valuable than its cost — has already been reached. In addition, as each of these individual clusters writes code for the platform, positive indirect network effects increase (more utility arises from these individual development efforts).
138140
content/blog/value-of-address-space-pt3.md+9−11
@@ -44,7 +44,7 @@ For the purposes of this discussion, we’re primarily referring to unbooted add
4444
4545Locked vs. Unlocked Addresses –
4646
47−At present, the majority of Urbit address space is locked by smart contracts. When Urbit address space was first registered on the Ethereum blockchain, this unlocking mechanism was put in place to prevent the market from being flooded. A young Urbit network in which all of the address space had been unlocked would be exposed to attacks by bots and spammers. Scarcity, on the other hand, encourages good behavior as it increases the cost to spam.
47+At present, the majority of Urbit address space is locked by smart contracts. When Urbit address space was first registered on the Ethereum blockchain, this unlocking mechanism was put in place to prevent the network from being flooded with users. A young Urbit network in which all of the address space had been unlocked would be exposed to attacks by bots and spammers. Scarcity, on the other hand, encourages good behavior as it increases the cost to spam.
4848
4949A locked star is held in a contract and can neither be booted nor issue planets. The lockup contracts can be examined on [GitHub](https://github.com/urbit/azimuth).
5050
@@ -63,7 +63,7 @@ These lockups all began to release at varying linear rates in January 2019 (spec
6363The various linear unlocking schedules are grouped as follows:
6464
6565- The urbit.org addresses, and early prize winners unlock linearly from 2019-2021.
66−- Tlon, its founders, employees, and its investors were frozen for a year, and now unlock linearly from 2020-2024.
66+- Tlon, its founders, employees, and most purchasers from Tlon were frozen for a year, and now unlock linearly from 2020-2024.
6767- 2018 private buyers were frozen for a year, and then began to unlock linearly over the course of one or three years, depending on the terms of their respective contracts.
6868- Earlier private buyer addresses—including those in our first two crowdsales—were unlocked right away.
6969
@@ -85,7 +85,7 @@ When we layer the spawning limits over the various lockup contracts, we find tha
8585
8686## Address space distribution
8787
88−Address space has continued to change hands since we put the Urbit on-chain in January 2019. At that time, we had a fairly granular understanding of who owned what. Today we only have precise numbers for the Tlon and urbit.org owned address space. Galaxies change hands quite infrequently, so we know more about that ownership table than stars and planets. We know next to nothing about the distribution of planets.
88+Address space has continued to change hands since we put Urbit on-chain in January 2019. At that time, we had a fairly granular understanding of who owned what. Today we only have precise numbers for the Tlon and urbit.org owned address space. Galaxies change hands quite infrequently, so we know more about that ownership than stars and planets. We know next to nothing about the distribution of planets.
8989
9090We consider the opacity of our understanding about transactions on the network to be a privacy feature rather than a bug. To be specific about the information we can collect here: first, we don’t know anything about users beyond their ETH address, and second, we can’t tell the difference between a transfer of an address, and the re-keying of an address. This means we’re never entirely sure if a transfer has in fact occurred; we only know that the address has changed.
9191
@@ -95,11 +95,11 @@ The chart below is an estimate (as of January 2020) based on our general underst
9595<img class="ba" src="https://media.urbit.org/site/posts/essays/value-of-address-space-pt3-graph4.png">
9696<br>
9797
98−Address space distribution is best understood in terms of galaxies and stars independently, as they’re distinct asset classes. The chart above only illustrates galaxy distribution, but describes Tlon’s “naked” galaxy holdings, which are galaxies empty of their stars. These galaxies are empty because the stars they once contained have been distributed, primarily to Tlon contractors, employees, and to certain private buyers.
98+Address space distribution is best understood in terms of galaxies and stars independently, as they’re distinct assets. The chart above only illustrates galaxy distribution, but describes Tlon’s “naked” galaxy holdings, which are galaxies empty of their stars. These galaxies are empty because the stars they once contained have been distributed, primarily to Tlon contractors, employees, and to certain private buyers.
9999
100−We believe that wide distribution is important to the health of the network and the growth of Urbit as a whole. Our own distribution efforts in conjunction with a robust secondary market, will disburse Urbit address space ownership as broadly as possible.
100+We believe that wide distribution is important to the health of the network and the growth of Urbit as a whole. Our own distribution efforts are focused on disbursing Urbit address space ownership as broadly as possible to those interested in using and developing the network.
101101
102−We intend to further distribute Tlon’s address space over the coming years through private sales, employee compensation, grants, bounties, and gifts. It’s worth noting that the grants and bounties program specifically is set to increase dramatically. We’re very much interested in putting address space in the hands of people interested in helping develop the network; we see grants as the perfect mechanism for doing so.
102+We intend to further distribute Tlon’s address space over the coming years through private sales, employee compensation, grants, bounties, and gifts. It’s worth noting that the grants and bounties program specifically is set to increase in coming years. We’re very much interested in putting address space in the hands of people interested in helping develop the network; we see grants as the perfect mechanism for doing so.
103103
104104## Usage data and composition
105105
@@ -109,7 +109,7 @@ First, it’s too early. Urbit’s current users are a fanbase of pioneers who a
109109
110110We’re laying the groundwork so that we can, in earnest, invite our friends and communities to a network they will love. That means we’re designing smooth onboarding, an elegant user interface, and increasing the stability of both the system and network. Tlon’s forthcoming hosting services will vastly reduce barriers to entry, and will be our first major push into the public sphere.
111111
112−Second, and perhaps more importantly, capturing data about traction on the network is difficult by design. Due to Urbit's privacy-forward architecture, there’s quite a lot we will never know. Once an Urbit is up and running, we don’t know how often it operates, where it’s hosted, or what it’s doing. This makes capturing usage metrics challenging, but we think this is the right problem to have.
112+Second, and perhaps more importantly, capturing data about traction on the network is difficult by design. Due to Urbit's privacy-forward architecture, there’s quite a lot we will never know. Once an Urbit ID is up and running, we don’t know how often it operates, where it’s hosted, or what it’s doing. This makes capturing usage metrics challenging, but we think this is the right problem to have.
113113
114114The Network Explorer –
115115
@@ -119,12 +119,10 @@ Urbit’s privacy-forward design makes collection of data appropriately impossib
119119
120120Closing –
121121
122−We have long said that Urbit address space had value because it was both useful and scarce. Taking a deeper look, we found that tradeability and network effect also play an important role in the value framework.
123−
124−The market seems to agree with our hypothesis, and price has remained fairly steady even at a time when we’re not promoting Urbit to the public.
122+We have long said that Urbit address space had value because it was both useful and scarce. Taking a deeper look, we found that some limited liquidity, and network effect also play an important role in the value framework.
125123
126124All of the factors that make up our framework are, in turn, impacted by availability of supply and by user growth. In the Urbit ecosystem, supply is effectively gated—as described above—in order to prevent flooding of the network.
127125
128126User growth, on the other hand, is something we simply have not yet pursued in earnest. Instead, our development efforts have been focused on enhancing usability and stability of the platform. Our focus on user growth will begin as we roll out hosting. Once that happens, usage metrics will become both more interesting and more relevant.
129127
130−This concludes the final installment of our series on the value of Urbit address space. Though the explanation was long, the framework is quite simple: value in Urbit is derived from its use, scarcity, tradeability, and network effect. Let us know if you’d like us to dig deeper into any of these elements—we’re always happy to opine about Urbit.
128+This concludes the final installment of our series on the value of Urbit address space. Though the explanation was long, the framework is quite simple: value in Urbit is derived from its use, scarcity, some liquidity, and network effect. Let us know if you’d like us to dig deeper into any of these elements—we’re always happy to opine about Urbit.
content/breach.mddeleted−97
@@ -1,97 +0,0 @@
1−+++
2−title = "~2020.12 Network Breach"
3−template = "page_indiced.html"
4−+++
5−
6−## TL;DR
7−
8−*Last updated ~2020.12.8*
9−
10−A network breach is happening this morning at 10am PST (~2020.12.8).
11−
12−Unlike past breaches, this one comes with a tool to export and reimport all of your data so that you don't lose anything; we call it `flagday`. Details on its usage can be found below.
13−
14−This document will be kept up-to-date throughout the process, and updates will be issued via Twitter [here](https://twitter.com/zodisok/).
15−
16−*If you are self-hosting your ship, following these instructions is mandatory in order to communicate with the rest of the network.*
17−
18−## When is the next breach?
19−
20−Today at 10am PST (~2020.12.8).
21−
22−## How do I get updates about what's going on throughout the process?
23−
24−We'll be adding new information to this document as soon as there's anything to share. Updates will be broadcasted via Twitter [here](https://twitter.com/zodisok/) as well.
25−
26−## What is a “network breach”?
27−
28−A network breach occurs when we need to change the Ames networking protocol number in order to reset the network’s state. When we change the protocol number, it will essentially create a new network. This rupture in continuity is why we refer to it as a “breach”. In the past, this has required users to take some action in order to get on the new network, but we are striving to make this as painless and loss-free as possible.
29−
30−## Why does the network need to breach?
31−
32−A network breach occurs when:
33−- A change must be made to all ships on the network simultaneously
34−- A change must be made to the Ames networking protocol
35−- Substantial changes must be made to Arvo and Vere simultaneously
36−
37−In this breach, we are including changes that will allow us to make these changes in the future without breaching the network.
38−
39−## Do I need to perform a personal breach?
40−
41−No. A network breach subsumes all personal breaches, so please don’t also perform a personal breach.
42−
43−## What can I expect?
44−
45−If you are using a self-hosted ship, you need to affirmatively perform the breach using the instructions below. If you are using hosting, your ship will process the breach automatically.
46−
47−In either case, the breach will render your ship unavailable for roughly one hour.
48−
49−## Do I need to do anything with Bridge/Ethereum?
50−
51−There are no Ethereum transactions necessary for this breach.
52−
53−## I’m self-hosted—what do I need to do?
54−
55−**Simply use the `flagday` tool that we have provided**. It will perform all the relevant actions on your behalf, as well as exporting and reimporting your data. Flagday should be run **after the breach has occurred.**
56−
57−To use `flagday`, run the following:
58−
59−```shell
60−curl https://bootstrap.urbit.org/flagday.sh > flagday.sh; chmod 755 ./flagday.sh; ./flagday.sh PIER_DIRECTORY
61−```
62−
63−Alternatively, you can perform the migration manually (see below).
64−
65−## Can I perform the migration manually?
66−
67−Yes, by following these steps (note that these steps **will not** back up your data as is the case with `flagday`):
68−
69−1. Download your [keyfile from Bridge](https://urbit.org/using/install/#keyfile).
70−2. Shut down your ship.
71−3. [Archive and move your old pier](https://urbit.org/using/operations/using-your-ship/#moving-your-pier) (this is the directory that contains your urbit event log).
72−4. [Download the latest version](@/using/install.md#macos-and-linux) of the urbit binary.
73−5. [Boot your ship with the new keyfile](https://urbit.org/using/install/#boot-your-planet).
74−
75−## I’m hosted by Tlon, or someone else—what do I need to do?
76−
77−Users hosted by Tlon will not need to take any action. We’re handling everything on our end. If you’re hosted by another provider, you should contact that provider for instructions.
78−
79−## What happens to my data?
80−
81−We’ve written a tool called `flagday` that will allow you to easily export your ship’s Landscape data. This includes your subscriptions and any content such as Collections, Notebooks and Chats that are on your ship. This data can then be seamlessly imported into a new ship.
82−
83−## What is unique about this breach?
84−
85−This breach will include Arvo/Vere Version Negotiation. This will allow us to ship updates to Vere and Arvo separately without worrying about an incompatibility on ships. For example, if you are running Vere 1.0 and an OTA of Arvo goes out that requires Vere 2.0, your ship will simply drop the update and notify you that you need to update your binary in order to receive the next update. When you update your binary is up to you.
86−
87−## Will there be more network breaches?
88−
89−We are optimistic that this will be our last breach, as all future updates to the network can be distributed as OTA (over-the-air) updates, possibly accompanied by a notification to update a binary version.
90−
91−## What happens if I don’t breach?
92−
93−Your Urbit will fall out of communication with the rest of the Urbit network which has performed the breach. This means that updates (OTAs) will no longer process and you won’t be able to communicate with anyone else on the network.
94−
95−## How do I get help if I need it?
96−
97−If you're in a tight spot or confused, reach out to us at support@urbit.org.
content/community/community-grants.md+1−1
@@ -7,7 +7,7 @@ hideprevious = "true"
77hidenext = "true"
88+++
99
10−Interested in getting your community on Urbit? We are currently accepting applications for select groups to get started on Urbit together using an [invite pool](@/docs/tutorials/creating-an-invite-pool.md).
10+Interested in getting your community on Urbit? We are currently accepting applications for select groups to get started on Urbit together using an [invite pool](@/using/id/creating-an-invite-pool.md).
1111
1212To get started, fill out the application below. Any information you share will be held privately, and only for the purpose of consideration for the grant.
1313
content/community/governance.md+1−1
@@ -20,6 +20,6 @@ For off-chain process around proposals, as suggested by core developers, please
2020
2121The group of core developers manages Urbit’s [GitHub repository](https://github.com/urbit/), which controls Arvo, Urbit’s operating system. Changes and upgrades are decided upon by consensus.
2222
23−You can participate in the governance of the senate by acquiring a galaxy. If you would like to be involved with the governance of Arvo, check out our [developer guide](@/using/develop.md) to learn how you can contribute to core development.
23+You can participate in the governance of the senate by acquiring a galaxy. If you would like to be involved with the governance of Arvo, check out our [developer guide](@/docs/development/develop.md) to learn how you can contribute to core development.
2424
2525
content/community/hoonschool.md+2−10
@@ -8,16 +8,8 @@ hideprevious = "true"
88hidenext = "true"
99+++
1010
11−Interested in developing on Urbit? You’ll want to learn [Hoon](https://urbit.org/docs/tutorials/hoon/hoon-school/), a functional programming language that’s custom-designed for use with Arvo, the Urbit operating system.
11+Hoon School and Hooniversity (the community run Hoon School project) are currently on hiatus pending a rework of the course.
1212
13−We want you to learn Hoon, too. That’s why we’re offering Hoon School: a free, online, asynchronous program that’s fully supported by an instructor. We currently offer a 101-level course.
14−
15−[Apply below ↓](#apply)
16−
17−## Hoon 101
18−
19−Hoon 101 is a six-week, introductory-level course. It’s appropriate for motivated learners with no programming experience, and for those familiar with other programming languages. You’ll leave Hoon 101 with a strong understanding of the language’s fundamentals. Expect to devote four hours a week to this course.
20−
21−The next Hoon School session, Session 4, will be held from **April 6th to May 17th**. Enroll now!
13+You can still apply below and we'll let you know when the new course is ready!
2214
2315<iframe id="apply" src="https://docs.google.com/forms/d/e/1FAIpQLSdcEoEqpFvB1WCTKPaYUSbJcjQ2nHk_z4XcZPIQc0SFD1rgmA/viewform?embedded=true" width="640" height="1350" frameborder="0" marginheight="0" marginwidth="0">Loading…</iframe>
content/docs+1−1

Submodule changed.

content/faq.md+110−93
@@ -11,15 +11,17 @@ hidetitle = "true"
1111
1212Urbit reimagines the internet as a peer-to-peer network designed to stay that way. Previous attempts to "decentralize" the internet have only attempted to solve certain corners of the problem. Urbit proposes that only a new stack, built from the ground up as a tightly integrated system, can realize a great user experience for people using a peer-to-peer web.
1313
14−Combining a deterministic operating system (Urbit OS / Arvo) and a secure, global identity layer (Urbit ID / Azimuth), the Urbit project has created something that’s never existed before: an encrypted peer-to-peer network where you can be sure that messages are never tampered with or surveilled, and where strangers on that network can be trusted by default.
14+Combining a deterministic operating system ([Urbit OS](#what-is-arvo) / Arvo) and a secure, global identity layer ([Urbit ID](#what-is-urbit-id) / [Azimuth](#what-is-azimuth)), the Urbit project has created something that’s never existed before: an encrypted [Sybil resistant](https://en.wikipedia.org/wiki/Sybil_attack) peer-to-peer network where you can be sure that messages are never tampered with or surveilled.
1515
16−The connected world anticipated by Urbit is a much friendlier one, much like the early Internet, where collegial discussion and collaboration was the norm. Problems that are unsolvable without large-scale political centralization in our current internet – data breaches, spam, fake reviews, malware-spreading, harassment – become tractable when individuals control their computing again. You have one login for everything. You own and control all of your software and all of your data by default. Software is designed around the friendships, families, communities, and organizations you're already a part of – not the other way around.
16+The connected world anticipated by Urbit is a much friendlier one, much like the early Internet, where collegial discussion and collaboration was the norm. Problems that are unsolvable without large-scale political centralization in our current internet – data breaches, spam, fake reviews, malware-spreading, harassment – become tractable when individuals control their computing again. You have one login for everything. You own and control all of your software and all of your data by default. Software is designed around the friendships, families, communities, and organizations you're already a part of – not the other way around.
1717
1818### How secure is Urbit right now? {#how-secure-is-urbit}
1919
20−Urbit ID / Azimuth, Urbit's identity layer, is live on the Ethereum blockchain and has been audited by Open Zeppelin, Blockchain at Berkeley, and Bloctrax. [We run a bug bounty program](https://hackerone.com/tlon) on HackerOne.
20+[Urbit ID](#what-is-urbit-id) / [Azimuth](#what-is-azimuth), Urbit's identity layer, is live on the Ethereum blockchain and has been audited by Open Zeppelin, Blockchain at Berkeley, and Bloctrax.
2121
22−Urbit OS / Arvo is still an early beta. Arvo is safe to play with, but it’s not yet a place to store or share private information. Urbit's cryptographic protocols have not been professionally audited, and the OS itself doesn't provide protection from attackers on the network — although we haven't seen any yet.
22+In late 2020, Urbit's [Ames](@/docs/glossary/ames.md) networking protocol was audited by [Leviathan Security](https://www.leviathansecurity.com/). You can read about this milestone [here](@/blog/security-and-continuity.md).
23+
24+Looking to the future, Tlon has plans to begin working to make Urbit secure against attacks from quantum computers in 2021.
2325
2426### How can I contribute to Urbit? {#contribute}
2527
@@ -29,77 +31,34 @@ We encourage outside contributors to become a part of the project. The best way
2931
3032[Tlon](https://tlon.io), a San Francisco-based company, is the primary developer of Urbit, along with [various independent developers](https://github.com/urbit/urbit/graphs/contributors) and [urbit.live](https://urbit.live).
3133
32−## Objections to Urbit
33−
34−### Who is Curtis? {#who-is-curtis}
35−
36−Urbit started back in 2002 as Curtis Yarvin’s personal project. Curtis developed the original prototype for Urbit and, separately, wrote a blog on history and politics under the pen name ‘Mencius Moldbug’.
37−
38−In early 2019, Curtis left the Urbit project and gave all of his voting interest (both as address space and voting shares in the company) back to Tlon. He retains a non-voting, minority interest in both the address space and the company — but is not involved in the day-to-day development or operations.
39−
40−Curtis laid the foundation for Urbit by delivering its first prototype but, since 2013, it has been refined and almost entirely rewritten by a community of developers. No one working on Urbit today had anything to do with Curtis’s writing. For the most part, we couldn’t be less interested in it.
41−
42−The community of people who build Urbit have widely varied ways of thinking and looking at the world, but they all share two things: the desire to build neutral infrastructure for all people and to think from first principles about hard problems. We welcome spirited debate and disagreement as a primary tool for refining our work. Successful infrastructure, we think, serves all people — no matter their background, culture, or worldview.
43−
44−### Why aren't there more planets? {#more-planets}
45−
46−Urbit is designed to be as simple as possible. The sponsorship tree for Urbit ID simply expands by squaring the size of the last tier. That is, there are <span class="mono">2<sup>8</sup> (256)</span> galaxies, <span class="mono">(2<sup>8</sup>)<sup>2</sup> = 2<sup>16</sup> (~65K)</span> stars, <span class="mono">(2<sup>16</sup>)<sup>2</sup> = 2<sup>32</sup> (~4B)</span> planets. There are <span class="mono">2<sup>64</sup></span> moons — but moons are tethered to their planet, unlike stars and planets.
47−
48−This pattern exists because it’s a simple way to enforce the scarcity of addresses and build a friendly network. When a tier of the address space begins to be populated, we start populating the next tier down. When Urbit nears the limit of <span class="mono">2<sup>32</sup> (4B)</span> planets, we’ll figure out a way to populate the <span class="mono">2<sup>64</sup></span> moons. The galaxies that govern the Urbit ID contracts can always vote to upgrade them — and we expect that they will.
49−
50−(For more background on why Urbit ID is the way it is, read [this](/understanding-urbit/urbit-id/).)
51−
52−The problem with populating the moons now is that <span class="mono">2<sup>64</sup></span> is a *really, really big* number. We’ll need some way of differentiating between humans and their devices (to prevent devices turning into rogue botnets). But that’s a hard problem, and we prefer to start with the simplest possible solution before solving hard problems. The current scheme works. Once we need to update it, we’ll figure it out.
53−
54−It’s also worth noting that, while there are almost 8B people on Earth, there are almost certainly not 8B internet users. Facebook has about 2.5B users, Apple has about 1B. Urbit has a long way to go before we get close to <span class="mono">2<sup>32</sup></span>.
55−
56−### Why do you use Ethereum? {#why-eth}
57−
58−As of 2019, Ethereum is the most widely deployed, most secure, and best documented general purpose blockchain. Using Ethereum is a practical engineering choice. It’s the best way to bootstrap real cryptographic ownership. We’re not specifically interested in Ethereum one way or the other.
59−
60−One day we’d really like the Urbit ID registry to be hosted on Urbit OS itself. But the first challenge is getting Urbit OS to be completely secure.
61−
62−### Why is Hoon so weird? {#why-hoon}
63−
64−There are things about Urbit that are weird by design, and some that are weird because we haven’t gotten around to cleaning them up. Hoon, for the most part, is weird by design, but there are a few things about it we’d like to clean up.
65−
66−The runes are, once you get the hang of them, pretty nice. Your mileage may vary, of course, but many talented engineers have spent many, many hours writing Hoon. It’s a simple, practical language. But the learning curve can be a bit high.
67−
68−The standard library and naming is something we’ve discussed changing, and it could happen. It’s definitely up for debate whether or not the four-letter naming convention works well. The vanes (kernel modules) have largely moved away from this convention.
69−
70−The right way to think about Hoon is as the ‘C of Urbit’. It’s a bare bones language that gets you pretty close to Nock. Eventually, we’ll probably implement more expressive languages that compile to Urbit. But for now, satisfy your curiosity and [sign up for Hoon School](/hoonschool/).
71−
72−### What is the point of Nock? {#why-nock}
73−
74−The primary technical reason we can’t run our own computers already is that they don’t all compute the same way. Nock solves this problem. It provides a single computing foundation for the whole network. It’s also deterministic — which is an important feature for anything you’re going to put sensitive data into.
75−
76−It’s true that Nock, without jets, is slow. With the ability to call out to a native function, it’s not so bad. We’ve been working on a new Nock interpreter for Grall Truffle that’s about 10x faster than the current one — so we’re not all that worried about performance for the time being.
77−
78−### Can I really host my Urbit with someone else? {#why-hosting}
34+## Urbit ID
7935
80−As a rule, anyone that has physical access to your computer owns you. They can steal your secrets and read its contents. There’s no way around that. We can’t prevent anyone hosting your Urbit from inspecting it — but we think it’s much nicer to host an Urbit than to run a web service for two reasons:
36+### What is Urbit ID? {#what-is-urbit-id}
8137
82−One, you own your Urbit ID with a key that you never have to give your host. Your host only gets an operating key, and you can always revoke that key remotely. So, you might lose your data but it’s up to you to take good care of your identity.
38+Urbit ID is the identity system utilized by Urbit, which associates to each [ship](@/docs/glossary/ship.md) a public and private key used to establish encrypted connections between one another and to guard private data. For [planets](@/docs/glossary/planet.md), [stars](@/docs/glossary/star.md), and [galaxies](@/docs/glossary/galaxy.md), this is achieved with a set of Ethereum smart contracts called [Azimuth](#what-is-azimuth). Keys for [moons](@/docs/glossary/moon.md) and [comets](@/docs/glossary/comet.md) are handled within Urbit.
8339
84−Two, your Urbit runs inside a VM. There’s a very clear line over which a host should never step: your event log. This is not unlike the way that cloud hosting works today. Netflix is hosted on AWS — one of their biggest competitors. Luckily, the AWS terms of service protects Netflix from a legal standpoint.
40+### What are stars, galaxies, and planets? {#stars-galaxies-planets}
8541
86−At the end of the day, if you’re really worried about security, it’s quite easy to host Urbit yourself. This means that people who care a lot about privacy can still get the same usability as those who want the convenience of hosting.
42+Urbit IDs come in three classes: galaxies, stars, and planets. The length of an identity’s name will tell you its class. Galaxies are 8-bit and have names like `~mul`. Galaxies issue 16-bit stars (`~dacmul`), which can themselves issue 32-bit planets (`~laptel-holfur`).
8743
88−## Urbit ID
44+Planets are intended for everyday use by individuals, and there are 4.3 billion of them (two to the 32nd power). Stars and galaxies, on the other hand, are meant to act as network infrastructure: on the [Urbit OS](#what-is-arvo) network they provide routing and are responsible for distributing software updates.
8945
90−### What is Urbit ID? {#what-is-urbit-id}
46+### Why is is currently expensive to acquire a planet? {#gas-prices}
9147
92−Urbit ID is a general-purpose PKI ("public key infrastructure") that Urbit uses as an identity system. This system is implemented as a suite of smart contracts on the Ethereum blockchain, and it determines which Ethereum addresses own which Urbit planets, stars, or galaxies. In Urbit OS, a single identity is called a "ship", whereas in Urbit ID a single identity is just an "identity."
48+As of early 2021, if you try to acquire a planet from a market, you will likely encounter an enormous "gas price" fee. Ethereum is going through some growing pains, and this is an issue for every
49+smart contract on the network. This fee is unrelated to Urbit specifically, rather it results from how Ethereum transactions are paid for. The gas fee does not go to the person selling you the planet, nor to the market, nor to anybody associated with Urbit - it goes to the "miners" processing all Ethereum transactions.
9350
94−### What are stars, galaxies, and planets? {#stars-galaxies-planets}
51+Tlon is aggressively pursuing a solution we call "naive rollups" which we predict to reduce gas costs by a factor of at least 100. We cannot give a precise estimate on when this will be complete, but it is top priority and this solution was chosen in part for the speed with which it can be implemented without sacrificing security. If you'd like to know more, we recommend watching this [Developer Call](https://www.youtube.com/watch?v=CKuHXrdkIw0) with `~wicdev-wisryt`.
9552
96−Urbit IDs come in three classes: galaxies, stars, and planets. The length of an identity’s name will tell you its class. Galaxies are 8-bit and have names like `~mul`. Galaxies issue 16-bit stars (`~dacmul`), which can themselves issue 32-bit planets (`~laptel-holfur`).
53+In the meantime, we recommend either using the network as a [comet](@/docs/glossary/comet.md), or signing up with a [hosting provider](#why-hosting), which includes a free planet.
9754
98−Planets are intended for everyday use by individuals, and there are 4.3 billion of them (two to the 32nd power). Stars and galaxies, on the other hand, are meant to act as network infrastructure: on the Urbit OS network they provide routing and are responsible for distributing software updates.
55+We understand that this is an enormous frustration, and will keep this section updated as we get closer to resolving it.
9956
10057### What is Azimuth? {#what-is-azimuth}
10158
102−Azimuth is what we call the set of Ethereum contracts that make up Urbit ID. It's also kind of a [cool astronomical concept](https://en.wikipedia.org/wiki/Azimuth).
59+[Azimuth](@/docs/glossary/azimuth.md) is what we call the set of Ethereum contracts that make up a general-purpose decentralized PKI ("public key infrastructure") utilized by Urbit ID. It keeps a record of which Ethereum addresses own which Urbit planets, stars, and galaxies, as well as the public keys associated with those ships.
60+
61+It's also kind of a [cool astronomical concept](https://en.wikipedia.org/wiki/Azimuth).
10362
10463### How many planets, stars, and galaxies are active? {#how-many-planets-stars-galaxies}
10564
@@ -109,29 +68,31 @@ You can also inspect and execute functions in the [azimuth.eth](https://ethersca
10968
11069### What are comets and moons? {#comets-moons}
11170
112−In addition to the three classes of identities mentioned above, there are two other kinds of Urbit ships that are _not_ registered in the Urbit ID / Azimuth contracts.
71+In addition to the three classes of identities mentioned above, there are two other kinds of Urbit [ship](@/docs/glossary/ship.md)s that are _not_ registered in the Urbit ID / Azimuth contracts.
11372
114−Moons are 64 bits, issued by planets, and have names like `~doznec-salfun-naptul-habrys`. Moons are meant for connected devices: phones, desktops, smart TVs, digital thermostats, and other IoT devices. Moons are subordinated to their parent planet.
73+[Moons](@/docs/glossary/moon.md) are 64 bits, issued by [planets](@/docs/glossary/planet.md), and have names like `~doznec-salfun-naptul-habrys`. Moons are meant for connected devices: phones, desktops, smart TVs, digital thermostats, and other IoT devices. Moons are subordinate to their parent planet. A strong analogy here is that ordinary social media sites are somewhat like planets, and your account on them is a moon. Urbit elevates everybody to the level of planet.
11574
116−Comets are 128 bits and have no parents. They can be launched by anyone. They are temporary, disposable identities. Being disposable and essentially unlimited, they will likely not be trusted by default by others on the Urbit OS network, though you shouldn't have any problem until the network grows much larger. They have long, hard-to-memorize names, like `~racmus-mollen-fallyt-linpex-watres-sibbur-modlux-rinmex`.
75+[Comets](@/docs/glossary/comet.md) are 128 bits and have no parents. They can be launched by anyone for free. Since their identity is not maintained on the blockchain, they will likely not be trusted by default by others on the [Urbit OS](#what-is-arvo) network, though you shouldn't have any problem until the network grows much larger. They have long, hard-to-memorize names, like `~racmus-mollen-fallyt-linpex-watres-sibbur-modlux-rinmex`.
11776
11877### What is a `@p`? Why is my username generated for me? {#what-is-patp}
11978
120−A `@p` (pronounced *pat-pee*) is a name like `~zod` or `~lodleb-ritrul` composed of pronounceable, three-letter phonemic elements like `zod`, `lod`, `leb`, `rit` and `rul`. Shorter names, such as `~zod` and `~marzod`, are assigned to ships with special duties on the Arvo network stars and galaxies, respectively. Longer names like `~palfun-foslup` are identities for typical users.
79+A `@p` ([pronounced](@/docs/hoon/hoon-school/hoon-syntax.md#reading-hoon-aloud) *pat-pee*) is a name like `~zod` or `~lodleb-ritrul` composed of pronounceable, three-letter phonemic elements like `zod`, `lod`, `leb`, `rit` and `rul`. Shorter names, such as `~zod` and `~marzod`, are assigned to [ship](@/docs/glossary/ship.md)s with special duties on the [Arvo](#what-is-arvo) network galaxies and stars, respectively. Longer names like `~palfun-foslup` are identities for typical users.
12180
12281These names map directly to a corresponding number in the Urbit ID address space. Galaxies occupy the 8-bit address space, so any galaxy is actually a number between zero and 255. Stars occupy the 16-bit address space, and planets occupy the 32-bit address space.
12382
83+Your name is generated for you as a solution to [Zooko's triangle](https://en.wikipedia.org/wiki/Zooko%27s_triangle), which roughly states that names on a network protocol can only be two of (i) human-meaningful, (ii) secure, and (iii) decentralized. Urbit chooses (ii) and (iii), while something like DNS chooses (i) and (ii).
84+
85+Regardless, you can always choose to set your nickname in [Landscape](#what-is-landscape), so if you wish for a different name to be displayed then you have the freedom to do so.
86+
12487### Can I change my `@p`? {#change-my-patp}
12588
12689Nope. There is a 1:1 mapping between name and identity. Think of your `@p` sort of like a phone number. It's just a random synthetic name that doesn't leak any personal information about you.
12790
12891### How do I get an identity? {#get-an-identity}
12992
130−The easiest way is to find a friend who can give you one. They're out there — just ask around.
93+The easiest way is to find a friend who can give you one. They're out there — just ask around. You'll have a good chance of meeting one if you join Urbit Community, the default group for new [ship](@/docs/glossary/ship.md)s at `~bitbet-bolbel/urbit-community`, as a [comet](@/docs/glossary/comet.md) and contribute pleasantly to the conversation.
13194
132−Or, if you must, try an ERC-721 (NFT) exchange (Google or Twitter should help you with this). This will probably involve a purchase and a transfer to an Ethereum address that you own. We recommend using [Bridge](https://bridge.urbit.org) to access the address that the identity is transferred to.
133−
134−If you don't want to use Bridge, a tool like [Etherscan](https://etherscan.io) will allow you to execute functions in the [ecliptic.eth](https://etherscan.io/address/ecliptic.eth#code) contract.
95+Or, if you must, try an ERC-721 (NFT) exchange (Google or Twitter should help you with this). This will probably involve a purchase and a transfer to an Ethereum address that you own. We recommend using [Bridge](@/docs/glossary/bridge.md), available at [https://bridge.urbit.org](https://bridge.urbit.org), to access the address that the identity is transferred to.
13596
13697### How do I transfer an identity to someone else? {#transfer-identity}
13798
@@ -141,44 +102,58 @@ Access the Ethereum address that holds the identity you wish to transfer via [Br
141102
142103We recommended using [Bridge](https://bridge.urbit.org) for all Urbit ID-related operations. It’s great for managing your identities, as well as for viewing information about identities you don’t own.
143104
144−Be careful about using hosted versions of Bridge not hosted on urbit.org. Since Bridge touches your private keys, it can also steal them.
105+Be careful about using online versions of Bridge not hosted on urbit.org. Since Bridge touches your private keys, it can also steal them.
106+
107+### Why aren't there more planets? {#more-planets}
108+
109+Urbit is designed to be as simple as possible. The sponsorship tree for Urbit ID simply expands by squaring the size of the last tier. That is, there are <span class="mono">2<sup>8</sup> (256)</span> [galaxies](@/docs/glossary/galaxy.md), <span class="mono">(2<sup>8</sup>)<sup>2</sup> = 2<sup>16</sup> (~65K)</span> [stars](@/docs/glossary/star.md), <span class="mono">(2<sup>16</sup>)<sup>2</sup> = 2<sup>32</sup> (~4B)</span> [planets](@/docs/glossary/planet.md). There are <span class="mono">2<sup>64</sup></span> [moons](@/docs/glossary/moon.md) — but moons are tethered to their planet, unlike stars and planets.
110+
111+This pattern exists because it’s a simple way to enforce the scarcity of addresses and build a friendly network. When a tier of the address space begins to be populated, we start populating the next tier down. When Urbit nears the limit of <span class="mono">2<sup>32</sup> (4B)</span> planets, we’ll figure out a way to populate the <span class="mono">2<sup>64</sup></span> moons. The galaxies that govern the Urbit ID contracts can always vote to upgrade them — and we expect that they will.
112+
113+The problem with populating the moons now is that <span class="mono">2<sup>64</sup></span> is a *really, really big* number. We’ll need some way of differentiating between humans and their devices (to prevent devices turning into rogue botnets). But that’s a hard problem, and we prefer to start with the simplest possible solution before solving hard problems. The current scheme works. Once we need to update it, we’ll figure it out.
114+
115+The number of addresses is in a sort of 'Goldilocks zone' for preventing spam. Too many addresses will result in them being very cheap and thus spammers can just acquire more once they get blocked. Too few addresses and they end up too expensive for the average user. The technical term for what the finite address space bestows upon the network is [Sybil resistance](https://en.wikipedia.org/wiki/Sybil_attack), a very important property for any decentralized network.
116+
117+It’s also worth noting that, while there are almost 8B people on Earth, there are almost certainly not 8B internet users. Facebook has about 2.5B users, Apple has about 1B. Urbit has a long way to go before we get close to <span class="mono">2<sup>32</sup></span>.
118+
119+(For more background on why Urbit ID is the way it is, read [this](/understanding-urbit/urbit-id/).)
145120
146121## Urbit HD Wallet
147122
148123### What is the Urbit HD Wallet? {#urbit-hd-wallet}
149124
150−The Urbit Hierarchical Deterministic (HD) Wallet is a custom Ethereum wallet based on BIP39 and BIP44 – the same underlying technology used by wallet providers like Ledger, Trezor, Metamask, and MyEtherWallet. You can think of the Urbit HD wallet as a wallet of wallets, which lets you keep a single passphrase for all of your Urbit ID keys. Urbit ID uses multiple keys with different capabilities – a bit like permissions – so that you can keep the more valuable keys in cold storage while keeping less valuable keys, used in day-to-day operation, more easily accessible. If you're only operating a planet, you shouldn't have to worry about this: you can simply think of your "master ticket" as the password to your Urbit ID. If you're operating a star or galaxy, the Urbit HD Wallet allows you to implement a multi-tier key custody scheme.
125+The [Urbit Hierarchical Deterministic (HD) Wallet](@/docs/glossary/hdwallet.md) is a custom Ethereum wallet based on BIP39 and BIP44 – the same underlying technology used by wallet providers like Ledger, Trezor, Metamask, and MyEtherWallet. You can think of the Urbit HD wallet as a wallet of wallets, which lets you keep a single passphrase for all of your Urbit ID keys. Urbit ID uses multiple keys with different capabilities – a bit like permissions – so that you can keep the more valuable keys in cold storage while keeping less valuable keys, used in day-to-day operation, more easily accessible. If you're only operating a planet, you shouldn't have to worry about this: you can simply think of your "master ticket" as the password to your Urbit ID. If you're operating a star or galaxy, the Urbit HD Wallet allows you to implement a multi-tier key custody scheme.
151126
152127If you're interested, you can read the spec here: [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet.md).
153128
154129### What is a master ticket? {#master-ticket}
155130
156−The "master ticket" is the entropy seed from which your other Urbit ID keys are derived. It should be treated like a master password: **you should never share it with anyone, and you must store it very securely (see our practices below).** This ticket is used to derive the Ethereum wallet that holds your ownership keys, your Urbit OS key – used to boot your Urbit – and the other keys associated with your identity. You’ll have a ticket if you used the Urbit Wallet Generator or claimed a ship on our hosted version of Bridge.
131+The "master ticket" is the entropy seed from which your other Urbit ID keys are derived. It should be treated like a master password: **you should never share it with anyone, and you must store it very securely (see our practices below).** This ticket is used to derive the Ethereum wallet that holds your ownership keys, your [Urbit OS](#what-is-arvo) key – used to boot your Urbit – and the other keys associated with your identity. You’ll have a master ticket if you used the Urbit Wallet Generator or claimed a [ship](@/docs/glossary/ship.md) on our hosted version of Bridge.
157132
158133If you're operating a planet, you can use your master ticket to authenticate with Bridge.
159134
160135### What is an ownership address? {#ownership-address}
161136
162−An ownership address is an Ethereum address that owns one or more of your Urbit IDs. The Urbit Wallet Generator creates one Urbit HD Wallet and associated addresses for each of your identities. Using the ownership key associated with your ownership address, you can transfer identities to other people, meaning that it’s very important to store securely.
137+An ownership address is an Ethereum address that owns one or more of your Urbit IDs. The Urbit Wallet Generator creates one [Urbit HD Wallet](@/docs/glossary/hdwallet.md) and associated addresses for each of your identities. Using the ownership key associated with your ownership address, you can transfer identities to other people, meaning that it’s very important to store securely.
163138
164139### What are proxies? {#proxies}
165140
166−Proxies are seeds derived from your master ticket used to generate sub-wallets, which in turn are used to generate keys that have the ability to execute different Urbit ID functions associated with your Urbit identity. Proxies generally have more restricted capabilities than your ownership seed. These capabilities include spawning child identities, voting, and setting networking keys.
141+[Proxies](@/docs/glossary/proxies.md) are seeds derived from your master ticket used to generate sub-wallets, which in turn are used to generate keys that have the ability to execute different Urbit ID functions associated with your Urbit identity. Proxies generally have more restricted capabilities than your ownership seed. These capabilities include spawning child identities, voting, and setting networking keys.
167142
168143- Transfer proxy: Can transfer your identity to another Ethereum address.
169−- Spawn Proxy: For stars and galaxies only. Can create new child identities.
144+- Spawn Proxy: For [stars](@/docs/glossary/star.md) and [galaxies](@/docs/glossary/galaxy.md) only. Can create new child identities.
170145- Management Proxy: Can configure or set networking keys and conduct sponsorship related operations.
171−- Voting Proxy: Galaxies only. Galaxies are the part of the galactic senate, which means they can cast votes on new proposals including changes to the "Ecliptic" contract, which defines the operations of Azimuth.
146+- Voting Proxy: [Galaxies](@/docs/glossary/galaxy.md) only. Galaxies are the part of the [galactic senate](@/docs/glossary/senate.md), which means they can cast votes on new proposals including changes to the "[Ecliptic](@/docs/glossary/ecliptic.md)" contract, which defines the operations of [Azimuth](@/docs/glossary/azimuth.md).
172147
173148### What are seeds? {#seeds}
174149
175−All Ethereum key-pairs in the Urbit wallet system, including proxies, are produced by 128-bit cryptographically random values called seeds. These seeds are the equivalent of the BIP39 mnemonic of an Ethereum wallet and are yours alone. An ownership key pair is derived from an ownership seed and, likewise, the various proxy key pairs are generated from their respective proxy seeds.
150+All Ethereum key-pairs in the Urbit wallet system, including [proxies](@/docs/glossary/proxies.md), are produced by 128-bit cryptographically random values called seeds. These seeds are the equivalent of the BIP39 mnemonic of an Ethereum wallet and are yours alone. An ownership key pair is derived from an ownership seed and, likewise, the various proxy key pairs are generated from their respective proxy seeds.
176151
177152For detailed information see the [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet.md).
178153
179154### What does it mean to “set public keys”? {#set-public-keys}
180155
181−This means registering the public keys of your identity's encryption and authentication key pairs (together known as "networking keys") with Urbit ID / Azimuth, so that others can discover them. The corresponding private keys can then be used to, for example, run a ship on the Urbit OS network.
156+This means registering the public keys of your identity's encryption and authentication key pairs (together known as "networking keys") with Urbit ID / [Azimuth](@/docs/glossary/azimuth.md), so that others can discover them. The corresponding private keys can then be used to, for example, run a [ship](@/docs/glossary/ship.md) on the [Urbit OS](#what-is-arvo) network.
182157
183158You want to reset these keys if they are compromised, or if your ship has sunk. This is of little practical significance today, but resetting your networking keys resets your relationship with other ships on the network.
184159
@@ -235,25 +210,25 @@ There are two kinds of release schemes for locked up assets: linear and conditio
235210
236211In either scheme, you start out being able to take one star out of lockup, regardless of the terms set around the lockup as a whole. This way, you get to participate with a star right away. Go do something cool!
237212
238−If your lockup involved a galaxy, all of its stars will be locked up, but you will have immediate, lock-free control of the galaxy. You will likely need it to use that star.
213+If your lockup involved a [galaxy](@/docs/glossary/galaxy.md), all of its [stars](@/docs/glossary/star.md) will be locked up, but you will have immediate, lock-free control of the galaxy. You will likely need it to use that star.
239214
240215Note that the "releasing" of stars just means that they become available for you to claim. They don't automatically get transferred to you; you have to withdraw them from the appropriate lockup contract.
241216
242217Linear release is the simplest: your stars will be released linearly over a period of time. Most often this is a period of four years. If you have four stars in lockup, that means you will be able to withdraw one star per year. In many cases, there is also an initial windup period which has to pass before linear releasing begins, typically one year. Since Azimuth launched in January 2019, the linear release will begin in January 2020.
243218
244−Conditional release is a bit more complicated. If your stars are in conditional lockup, they're likely divided over three so-called tranches. Each of these unlocks only after a unique condition is met. Since it's difficult to verify things about the real world using smart contracts, the Galactic Senate verifies that they've been met. Once the Senate marks a condition for a tranche as cleared, it starts releasing linearly over the period of a year.
219+Conditional release is a bit more complicated. If your stars are in conditional lockup, they're likely divided over three so-called tranches. Each of these unlocks only after a unique condition is met. Since it's difficult to verify things about the real world using smart contracts, the [Galactic Senate](@/docs/glossary/senate.md) verifies that they've been met. Once the Senate marks a condition for a tranche as cleared, it starts releasing linearly over the period of a year.
245220
246221## Urbit OS
247222
248223### What is Urbit OS? {#what-is-arvo}
249224
250−Urbit OS, also called Arvo, is our functional and deterministic software stack. Arvo is written in Hoon, our purely functional programming language, which compiles to Nock, a compact bytecode language.
225+Urbit OS, also called [Arvo](@/docs/glossary/arvo.md), is our functional and deterministic software stack. Arvo is written in [Hoon](@/docs/glossary/hoon.md), our purely functional programming language, which compiles to [Nock](@/docs/glossary/nock.md), a compact bytecode language.
251226
252−Instances of Urbit OS / Arvo, called 'ships', communicate as peers on what we refer to as “the Urbit OS network.” Using Urbit ID, Urbit OS ships can prove their identities to one another.
227+Instances of Urbit OS, called '[ships](@/docs/glossary/ship.md)', communicate as peers on what we refer to as “the [Ames](@/docs/glossary/ames.md) network.” Using Urbit ID, Urbit OS ships can prove their identities to one another.
253228
254229### What is unique about Urbit OS / Arvo? {#what-is-unique-about-arvo}
255230
256−Arvo is different from other operating systems in many ways. One notable way is that it is completely deterministic. Processing in the system happens in a unique way: when an event happens, a transition function takes that event and the old state of Arvo, and produces an effect and a new state of Arvo. To visualize:
231+[Arvo](@/docs/glossary/arvo.md) is different from other operating systems in many ways. One notable way is that it is completely deterministic. Processing in the system happens in a unique way: when an event happens, a transition function takes that event and the old state of Arvo, and produces an effect and a new state of Arvo. To visualize:
257232
258233`[event, old state] -> [effects, new state]`
259234
@@ -261,21 +236,21 @@ All events are logged to disk, so you can always restore the system to a previou
261236
262237### How is Urbit OS / Arvo connected to Ethereum? {#arvo-ethereum}
263238
264−When an Arvo ship (instance) is started for the first time you must use a "keyfile" containing the private keys for your identity's networking keys. Urbit ID uses the Ethereum blockchain as its decentralized ledger.
239+When an [Arvo](@/docs/glossary/arvo.md) ship (instance) is started for the first time you must use a "[keyfile](@/docs/glossary/keyfile.md)" containing the private keys for your identity's networking keys. Urbit ID uses the Ethereum blockchain as its decentralized ledger.
265240
266−See our [Getting Started](@/using/install.md) guide to learn how to get your ship onto the Urbit OS / Arvo network.
241+See our [Getting Started](@/getting-started/planet.md) guide to learn how to get your ship onto the Urbit OS / [Ames](@/docs/glossary/ames.md) network.
267242
268243### Will the Urbit OS network survive if Ethereum dies? {#if-ethereum-dies}
269244
270−Yes. It would be annoying, but Urbit ID / Azimuth could be ported to another decentralized ledger, or hosted on Urbit OS / Arvo itself.
245+Yes. It would be annoying, but Urbit ID / [Azimuth](@/docs/glossary/azimuth.md) could be ported to another decentralized ledger, or hosted on Urbit OS / [Arvo](@/docs/glossary/arvo.md) itself.
271246
272247### How do I install Urbit OS? {#install-urbit-os}
273248
274−Check out our guides [here](@/using/install.md).
249+Check out our guides [here](@/getting-started.md).
275250
276251### How do I use Urbit OS? {#use-urbit-os}
277252
278−The [Using](@/using/operations/_index.md) section of the documentation will help you out.
253+The [Using](@/using/os/getting-started.md) section of the documentation will help you out.
279254
280255### How do over-the-air updates work? {#over-the-air-updates}
281256
@@ -283,13 +258,13 @@ Your sponsor, a star or galaxy that your ship is connected to, may send you new
283258
284259### What is Landscape? {#what-is-landscape}
285260
286−Landscape is an experimental Urbit OS web interface that includes social functions such as chat and publishing. You can access Landscape by navigating to `http://localhost:PORT`, where PORT is typically 80, 8080, or 8081 (check your boot messages).
261+[Landscape](@/docs/glossary/landscape.md) is an experimental Urbit OS web interface that includes social functions such as chat and publishing. You can access Landscape by navigating to `http://localhost:PORT`, where PORT is typically 80, 8080, or 8081 (check your boot messages).
287262
288263### I have an Urbit ID, now what? {#now-what}
289264
290−Follow our guide on how to boot a ship [here](@/using/install.md).
265+Follow our guide on how to boot a ship [here](@/getting-started/planet.md).
291266
292−Get on the [mailing list](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&amp;id=be143888d2). Learn [Hoon](@/docs/tutorials/hoon/hoon-school/_index.md). Sign up for [Hoon School](@/community/hoonschool.md). [Make stuff](https://grants.urbit.org).
267+Get on the [mailing list](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&amp;id=be143888d2). Learn [Hoon](@/docs/hoon/hoon-school/_index.md). Sign up for [Hooniversity](https://hooniversity.org/). [Make stuff](https://grants.urbit.org).
293268
294269
295270## Urbit Grants
@@ -375,8 +350,50 @@ Here are a few important points from the bounty and proposal contracts:
375350
376351- **No employment relationship:** You agree that being approved for the grant or bounty does not imply any employment relationship with Tlon.
377352
378−- **Termination:** Either party (you or Tlon) can terminate the agreement on seven days' written notice. If that happens, you may be compensated *pro rata* for the amount of work you've completed, but this compensation is at the sole discretion of Tlon.
353+- **Termination:** Either party (you or Tlon) can terminate the agreement on seven days' written notice. If that happens, you may be compensated *pro rata* for the amount of work you've completed, but this compensation is at the sole discretion of Tlon.
379354
380355- **Governing law:** The agreement is governed by the laws of the State of California.
381356
382357Note that these paraphrased points are just for summarization purposes. The language in contract that you receive and sign is the only source of authority for the grant agreement.
358+
359+## Miscellaneous
360+
361+### Who is Curtis? {#who-is-curtis}
362+
363+Urbit started back in 2002 as Curtis Yarvin’s personal project. Curtis developed the original prototype for Urbit and, separately, wrote a blog on history and politics under the pen name ‘Mencius Moldbug’.
364+
365+In early 2019, Curtis left the Urbit project and gave all of his voting interest (both as address space and voting shares in the company) back to Tlon. He retains a non-voting, minority interest in both the address space and the company — but is not involved in the day-to-day development or operations.
366+
367+Curtis laid the foundation for Urbit by delivering its first prototype but, since 2013, it has been refined and almost entirely rewritten by a community of developers. No one working on Urbit today had anything to do with Curtis’s writing. For the most part, we couldn’t be less interested in it.
368+
369+The community of people who build Urbit have widely varied ways of thinking and looking at the world, but they all share two things: the desire to build neutral infrastructure for all people and to think from first principles about hard problems. We welcome spirited debate and disagreement as a primary tool for refining our work. Successful infrastructure, we think, serves all people — no matter their background, culture, or worldview.
370+
371+### Why do you use Ethereum? {#why-eth}
372+
373+In 2019 (when [Azimuth](#what-is-azimuth) was launched), Ethereum was the most widely deployed, most secure, and best documented general purpose blockchain, and it remains so today. Using Ethereum is a practical engineering choice. It’s the best way to bootstrap real cryptographic ownership. We’re not specifically interested in Ethereum one way or the other.
374+
375+One day we’d really like the Urbit ID registry to be hosted on [Urbit OS](#what-is-arvo) itself. But the first challenge is getting Urbit OS to be completely secure.
376+
377+### Why is Hoon so weird? {#why-hoon}
378+
379+There are things about Urbit that are weird by design, and some that are weird because we haven’t gotten around to cleaning them up. [Hoon](@/docs/glossary/hoon.md), for the most part, is weird by design, but there are a few things about it we’d like to clean up. For a complete description of why we created Hoon, see the [Hoon overview](@/docs/hoon/overview.md).
380+
381+The runes are, once you get the hang of them, pretty nice. Your mileage may vary, of course, but many talented engineers have spent many, many hours writing Hoon. It’s a simple, practical language. But the learning curve can be a bit high.
382+
383+The standard library and naming is something we’ve discussed changing, and it could happen. It’s definitely up for debate whether or not the four-letter naming convention works well. The vanes (kernel modules) have largely moved away from this convention.
384+
385+The right way to think about Hoon is as the ‘C of Urbit’. It’s a bare bones language that gets you pretty close to Nock. Eventually, we’ll probably implement more expressive languages that compile to Urbit. But for now, satisfy your curiosity and [sign up for Hooniversity](https://hooniversity.org/), a community led Hoon educational organization.
386+
387+Another option is to treat [Urbit as an API](@/docs/arvo/eyre/using-eyre.md), which allows one to use common languages such as Python and Javascript to build userspace programs. For now this option is not as powerful as Hoon, but there is still a lot that a developer without the time or inclination to learn Hoon can do.
388+
389+### What is the point of Nock? {#why-nock}
390+
391+The primary technical reason it is difficult for the individual to run a personal server is that modern computing architectures are not deterministic. What solves a problem for one person is not guaranteed to work on another person's computer, even if they are using identical hardware. [Nock](@/docs/glossary/nock.md) solves this problem. It provides a single computing foundation for the whole network, so that difficult issues that arise when running a server need only to be solved once and the solution is guaranteed to work for everyone on the network.
392+
393+It’s true that Nock, without jets, is slow. With the ability to call out to a native function, it’s not so bad. This is done by our runtime, [Vere](@/docs/glossary/vere.md), a Nock interpreter written in C.
394+
395+### Can I host my Urbit with someone else? {#why-hosting}
396+
397+Yes, [Tlon](@/blog/hosting-the-future.md) and [a few others](@/blog/providers.md) began [accepting signups](https://tlon.io) to provide hosting service in 2020. Under this arrangement, Tlon does all the work of setting up cloud infrastructure and getting your planet up and running, making getting started with Urbit as simple as signing up for an ordinary online service.
398+
399+Should you one day wish to run your Urbit yourself, any hosting provider ought to offer you the ability to download your [ship](@/docs/glossary/ship.md)'s [pier](@/docs/glossary/pier.md) to your own device and do so. This is a very low friction process thanks to Urbit's deterministic design.
content/getting-started.mdnew file+214
@@ -0,0 +1,214 @@
1++++
2+title = "Getting Started"
3+weight = 1
4+description = "How to install Urbit."
5+template = "page_indiced.html"
6+aliases = ["/docs/getting-started/"]
7++++
8+
9+The price of using other platforms is your data and its security. There's a reason they're free to use.
10+
11+The price of using Urbit is your own responsibility — you must run it yourself (or pay someone to run it for you).
12+
13+It's easy and it keeps getting easier.
14+
15+There are currently two ways to run Urbit:
16+
17+If you use Mac or Linux and are not afraid of a few terminal commands, we recommend you run it yourself. That is the aim of this guide.
18+
19+If you run Windows or just want to give it a shot without worrying about the gritty bits, you may want to consider a [hosting provider](@/getting-started/planet.md#hosting-providers).
20+
21+## Installing Urbit {#macos-and-linux}
22+
23+Choose the code for your operating system and run the commands in your terminal.
24+
25+<div id="os">
26+ <input type="radio" id="macos" name="os" checked>
27+ <label for="macos">MacOS</label>
28+ <div class="tab">
29+
30+```sh
31+mkdir ~/urbit
32+cd ~/urbit
33+curl -JLO https://urbit.org/install/mac/latest
34+tar zxvf ./darwin.tgz --strip=1
35+~/urbit/urbit
36+```
37+ </div>
38+
39+ <input type="radio" id="linux" name="os">
40+ <label for="linux">Linux</label>
41+ <div class="tab">
42+
43+```sh
44+mkdir ~/urbit
45+cd ~/urbit
46+wget --content-disposition https://urbit.org/install/linux64/latest
47+tar zxvf ./linux64.tgz --strip=1
48+~/urbit/urbit
49+```
50+
51+Linux users may need to run this command in another terminal window to access your Urbit on port 80:
52+
53+```sh
54+sudo apt-get install libcap2-bin
55+sudo setcap 'cap_net_bind_service=+ep' ~/urbit/urbit
56+```
57+</div>
58+
59+ <input type="radio" id="windows" name="os">
60+ <label for="windows">Windows</label>
61+ <div class="tab">
62+
63+> Please note that this method of installing Urbit is experimental, and we may not be able to assist you if you encounter issues related to WSL 2.
64+
65+Urbit cannot run on Windows itself, but there is a convenient way to run Linux using the [Windows Subsystem for Linux 2](https://docs.microsoft.com/en-us/windows/wsl/wsl2-install) on Windows 10. Install the Windows Subsystem for Linux 2 and open a Linux terminal in Windows, then follow the Linux installation instructions below. These instructions have been tested and verified for WSL 2 + Ubuntu 18.04 LTS, as demonstrated in `~sitful-hatred`'s step-by-step setup guide [here](https://subject.network/posts/urbit-wsl2/).
66+
67+For performance reasons, do not install Urbit in the mounted Windows volume, but install it in the Linux file system. For example, in your home directory, which can be navigated to by entering `cd ~`.
68+</div>
69+</div>
70+
71+<style>
72+ #os {
73+ display: flex;
74+ flex-wrap: wrap;
75+ }
76+ #os label {
77+ order: -1;
78+ padding: .5rem;
79+ border-width: 1px 0px 0px 1px;
80+ border-style: solid;
81+ cursor: pointer;
82+ }
83+ #os label[for=windows] {
84+ border-right-width: 1px;
85+ }
86+ #os input[type="radio"] {
87+ display: none;
88+ }
89+ #os .tab {
90+ display: none;
91+ border: 1px solid;
92+ padding: 1rem;
93+ max-width: 100%;
94+ }
95+ #os input[type='radio']:checked + label {
96+ font-weight: bold;
97+ }
98+ #os input[type='radio']:checked + label + .tab {
99+ display: block;
100+}
101+</style>
102+
103+If successful, you will see a block of output beginning with the line:
104+
105+```
106+Urbit: a personal server operating function
107+```
108+
109+## Booting a Free Identity {#comet}
110+
111+There are two parts to Urbit: an **ID** and an **Operating System**.
112+
113+You have just installed the Operating System on your computer.
114+
115+The **ID** is similar to a username and password on another site. The difference is that the public part (the username) is verified by thousands of people around the world while only you hold the key (the password) to that ID.
116+
117+There are five kinds of Urbit IDs but to get started you only need to know about two: we call them **planets** and **comets**.
118+
119+***
120+
121+**Planets** are scarce (this prevents spamming, among other things) and usually require a price to acquire. This is the recommended way to run Urbit, but it's a bit more involved.
122+
123+A planet name looks like `~sampel-palnet`.
124+
125+[Follow this guide](@/getting-started/planet.md) if you have already acquired a planet.
126+
127+[Find a planet to purchase](@/getting-started/planet.md#purchase)
128+
129+***
130+
131+**Comets** are practically unlimited and free to acquire. At present, these are a great way to try out the network for free.
132+
133+A comet name looks like `~dasres-ragnep-lislyt-ribpyl--mosnyx-bisdem-nidful-marzod`.
134+
135+[Read more about Urbit ID here](/understanding-urbit/urbit-id)
136+
137+
138+***
139+
140+To boot a comet, go into the command line and run the following command from the `urbit` directory you created during [Urbit installation](#installing-urbit):
141+
142+```sh
143+~/urbit/urbit -c mycomet
144+```
145+
146+It may take a while to load the comet (probably only take a few minutes, but it could take longer). This comes along with it being free. When it's done you'll some messages ending like this:
147+
148+```
149+ames: on localhost, UDP 31337.
150+http: live (insecure, public) on 8080
151+http: live ("secure", public) on 8443
152+http: live (insecure, loopback) on 12321
153+~sampel_marzod:dojo>
154+```
155+
156+When your comet is finished booting, you will see `~sampel_marzod:dojo>` (Dojo: the Urbit command line).
157+
158+To exit Urbit, use `Ctrl-D` or enter `|exit` into Dojo.
159+
160+To start your comet up again, run the following from your `urbit` directory (note the lack of `-c` argument):
161+
162+```sh
163+~/urbit/urbit mycomet
164+```
165+
166+## Using Landscape
167+
168+Urbit is an entirely new computer, so by default it drops you into the "dojo," which is its terminal. Like your current computer, it can be used to do just about anything if you know the right commands. You only need to know one command for now.
169+
170+At the moment, the most common way to use Urbit is through a web app named Landscape, which comes with Urbit. It runs in your browser and provides an interface to Urbit without using the terminal. You need to get the password, or `code`.
171+
172+1. With your Urbit running, look for a line that says something like `http: live (insecure, public) on 80`. The number given is the port that your ship is using. It will probably be 80, but we're just making sure. (Don't worry about the "insecure, public" part — that just means you can access it from your own web browser. It doesn't give anyone else access.)
173+2. If the port given is `80`, simply type `localhost` into your browser's address bar. If the given port is a different number, such as `8080`, you would type `localhost:8080`. You'll be met with a login prompt.
174+3. In the window where you found the port number, type `+code` and press return. Copy-paste the code that appears into the "Access Key" field in the browser, and press continue.
175+4. Once in, take a look around and read the instructions on screen. If you ever get logged out, follow these instructions again.
176+
177+## Next Steps
178+
179+### Updating your comet {#updating}
180+
181+The Urbit application comes with a recent release of the Urbit OS, but automatic updates ("over the air") can be enabled so new binaries aren't necessary for each update. Planets have automatic updates enabled by default, but this is not the case for comets. Many comets are used only once and thrown away, so it would be wasteful to update every single comet as soon as it boots. If you plan to use your comet for more than a quick test, you'll probably want to ensure you're running the latest version of the OS.
182+
183+You can enable updates for your comet by typing `|ota (sein:title our now our) %kids` into Dojo and pressing Enter.
184+
185+```
186+> |ota (sein:title our now our) %kids
187+>=
188+```
189+
190+If you want to make sure you'll get updates, you can check by typing `|ota` with no arguments:
191+
192+```
193+~sampel_marzod:dojo> |ota
194+OTAs enabled from %kids on ~marzod
195+use |ota %disable or |ota ~sponsor %kids to reset it
196+> |ota
197+>=
198+```
199+
200+### Read More about the Dojo {#the-dojo}
201+
202+The dojo is Urbit's command line. You can use it to control your ship, or to execute arbitrary code. Check out the links below for more information.
203+
204+- [Basic Operations](@/using/os/getting-started.md)
205+- [Basic Hoon](/docs/tutorials/hoon/hoon-school/setup)
206+- [Glossary Entry](/docs/glossary/dojo)
207+
208+### Purchase a Permanent Identity {#boot-your-planet}
209+
210+You can continue using this comet indefinitely. There are currently few differences between using a comet-level identity and a planet-level one. However, some groups will not allow comets entry in order to maintain a certain level of quality, and changes may be made in the future that further devalue comets. They will always, however, be able to access the basic functions of the network.
211+
212+A comet also comes with a long and fairly unmemorable name whereas a planet has a short name and a "sigil" (avatar) associated with it that makes it more identifiable on the network. You may notice all this within the first few minutes of using Urbit.
213+
214+[To read instructions on how to purchase and use a planet, visit this page](@/getting-started/planet.md).
content/getting-started/_index.mdnew file+4
@@ -0,0 +1,4 @@
1++++
2+title = "Getting Started"
3+render = false
4++++
content/getting-started/planet.mdnew file+129
@@ -0,0 +1,129 @@
1++++
2+title = "Setting up Your Planet"
3+weight = 1
4+description = "Getting started with a permanent Urbit identity."
5+template = "page/getting_started.html"
6++++
7+
8+A planet is a permanent Urbit identity. Like all Urbit identities, they can never be taken away from you. Unlike comets which are free, planets are designed for use well into the future. If you're not yet familiar with the Urbit network, please follow the [Getting Started guide](@/getting-started.md), which will explain the basics and walk you through using a free identity. This guide explains the next steps.
9+
10+### Purchase a planet {#purchase}
11+
12+There are a few ways to get your own planet:
13+
14+- Getting an invitation from a friend (or stranger).
15+- Purchasing a planet, including hosting, from a [hosting provider](#hosting-providers) such as [geturbitid.com](https://www.geturbitid.com/).
16+- Manually setting up and hosting a planet purchased from a third party such as [urbit.live](https://urbit.live), [OpenSea](https://opensea.io), [planet.market](https://planet.market/), [urbit.me](https://urbit.me), [urth systems](https://urth.systems/), or [Urbit Marketplace](https://urbitmarketplace.com/).
17+
18+Note that when you buy a planet, you should ensure with the provider that your parent star is operating. If you need to escape a non-operational star, see [Escaping A Sponsor](@/using/id/using-bridge.md#escaping-your-sponsor).
19+
20+### Hosting Providers {#hosting-providers}
21+
22+Hosting providers will often sell you a planet and run it for you. This option is very simple but will probably cost a regular fee.
23+
24+Urbit is designed to be portable. This means that if you sign up for hosting now but later want to leave your hosting provider and run your Urbit yourself, you should be able to work with them to obtain all of your data and boot your planet back up without losing anything.
25+
26+Using hosting does mean that you're trusting your provider with your data, but so long as you have your planet, you'll always own your identity.
27+
28+Current hosting providers are:
29+
30+- [Tlon Corporation](https://tlon.io): Tlon is the creator of Landscape and is primarily responsible for the creation and maintenance of the Urbit project itself.
31+- [Get an Urbit ID](https://www.geturbitid.com/): Get an Urbit ID was the first hosting provider and is run by a member of the Urbit community.
32+
33+
34+### Choose to run your planet on your computer or on a cloud service
35+
36+Urbit must run on an existing computer somewhere. Most users run their planet on their personal computer, but we recommend eventually using a cloud service (Digital Ocean, Linode, etc) because it allows your planet to be accessed from anywhere on multiple devices. Hosting your planet in the cloud also allows it to always be online and ready for automatic updates. You are welcome to run from your personal computer and switch to the cloud later...all without losing any data!
37+
38+There is a guide for [hosting your planet on DigitalOcean](@/using/running/hosting.md) and [hosting your planet on Linode](https://jeremytunnell.com/2021/01/09/how-to-install-urbit-on-a-linode-vps), but any cloud hosting service should work.
39+
40+### Get your keyfile {#keyfile}
41+
42+If you received an email invite to Urbit, the master ticket should be a .pdf file in the passport folder inside the archive that you downloaded. **If you bought your planet or someone sent you one you probably do not have a master ticket, and you probably don't need one. Do not issue a new master ticket unless you are sure you need to.**
43+
44+1. Connect to [Bridge](https://bridge.urbit.org). (Bridge is like an Urbit wallet)
45+2. Enter the name of your planet and the associated master ticket if you have one. Click the "Metamask, Mnemonic, Hardware Wallet..." button if you don't have a master ticket.
46+3. Once you're logged in, click the "OS" option.
47+4. Click the "Download Arvo Keyfile" button. If this is grayed out, click on "Reset Networking Keys", then click on "Reset Networking Keys" on the following page, validate the transaction using your wallet, and then click "Send Trasaction". Once the transaction is complete, the "Download Arvo Keyfile" button should be available for you to press. You should receive a `.key` file that contains the secret needed to boot your planet. Hold onto this file.
48+
49+### Run the boot command {#the-dojo}
50+
51+Navigate to your `urbit` directory.
52+
53+Open your keyfile (it is just a text file) and copy the key inside. Paste it into the following command, with `sampel-palnet` replaced by the name of your planet. **Do not include the tilde in your planet name.**
54+
55+```sh
56+./urbit -w sampel-palnet -G rAnDoMkEy
57+```
58+
59+Or you can copy the keyfile into the current directory and run:
60+
61+```sh
62+./urbit -w sampel-palnet -k ./my-planet.key
63+```
64+
65+Either command will create a directory called `sampel-palnet/` and begin booting your planet. It may take a few minutes.
66+
67+When your planet is finished booting, you will see `~sampel-palnet:dojo>` (Dojo: the Urbit command line).
68+
69+Get your password to log into landscape (the Urbit web interface) by typing:
70+
71+```sh
72++code
73+```
74+
75+To shut down your planet, use `Ctrl-D`.
76+
77+To start your planet up again, run the following from your `urbit` directory.
78+
79+```sh
80+./urbit sampel-palnet
81+```
82+
83+Note that `sampel-palnet/` is the path of a folder, which we just created in your `urbit` directory. This folder is called your planet's **pier**, and it holds all of your data.
84+
85+Never boot multiple instances of your planet at the same time. You can prevent this from happening on accident by only ever keeping a single copy of your pier.
86+
87+**Important:** once a key has been used to boot a planet onto the network, it cannot be used to boot that planet again later - doing so will cause communication problems with other planets. For this reason you should **delete the keyfile from your machine once your planet has booted successfully**. If you do use the same key twice, you'll need to reset your planet to restore its functionality.
88+
89+Delete the keyfile with the command below:
90+
91+```sh
92+rm ./my-planet.key
93+```
94+
95+## Setup {#setup}
96+
97+The first thing you generally want to do with a new planet is to **mount** it. A planet being mounted means that it can be seen by Linux, allowing files to be shared between it and your planet. To mount your planet, type `|mount %` at the Dojo prompt.
98+
99+```
100+|mount %
101+>=
102+```
103+
104+The `>=` output means that a command was successful. Now you can see your planet's files in its directory.
105+
106+To understand what happened with this command, read more about Urbit’s filesystem (called “clay”) [here](@/docs/arvo/clay/clay.md).
107+
108+## Updating {#updating}
109+
110+By default, planets have a sponsor — a star that provides updates and routing services. To see who you receive updates from, enter `|ota` in the dojo. You will see something like this:
111+
112+```
113+~sampel-palnet:dojo> |ota
114+OTAs enabled from %kids on ~dopzod
115+use |ota %disable or |ota ~sponsor %kids to reset it
116+> |ota
117+>=
118+```
119+
120+If for some reason your sponsor (in this case, `~dopzod`) is not responding, read instructions on [escaping your sponsor](@/using/id/using-bridge.md#escaping-your-sponsor).
121+
122+
123+## Next Steps
124+
125+Now that you’re up and running, take some time to deepen your understanding by checking out some of our other guides:
126+
127+- [Host your Ship in the Cloud](@/using/running/hosting.md): Follow this guide to set your ship up to run as a cloud server, accessible from anywhere.
128+- [Read the Operations Manual](@/using/os/getting-started.md): Become an expert pilot by learning to use your ship.
129+- [Learn to Develop on Urbit](@/docs/development/develop.md): Learn how to contribute to or develop on Urbit.
content/media.md+1−1
@@ -1,4 +1,4 @@
11+++
22title = "Media"
33template = "media/list.html"
4−+++
4++++
content/reset.mdnew file+109
@@ -0,0 +1,109 @@
1++++
2+title = "~2020.12 Network Reset"
3+template = "page_indiced.html"
4++++
5+
6+## TL;DR
7+
8+*Last updated ~2021.1.14*
9+
10+A network reset happened on ~2020.12.8 — you may need to take action.
11+
12+Unlike past resets, this one comes with a tool to export and reimport all of your data so that you don't lose anything; we call it `flagday`. Details on its usage can be found below.
13+
14+*If you are self-hosting your ship, following these instructions is mandatory in order to communicate with the rest of the network.*
15+
16+## When was the last network reset?
17+
18+On Tuesday, ~2020.12.8.
19+
20+## How do I get updates about what's going on throughout the process?
21+
22+We'll be adding new information to this document as soon as there's anything to share. Updates will be broadcasted via Twitter [here](https://twitter.com/zodisok/) as well.
23+
24+## What is a "network reset"?
25+
26+A network reset occurs when we need to change the Ames networking protocol number in order to reset the network’s state. When we change the protocol number, it will essentially create a new network. This change in continuity is why we refer to it as a "reset". In the past, this has required users to take some action in order to get on the new network, but this time we've provided tooling to make it seamless.
27+
28+## Why does the network need to reset?
29+
30+A network reset occurs when:
31+- A change must be made to all ships on the network simultaneously
32+- A change must be made to the Ames networking protocol
33+- Substantial changes must be made to Arvo and Vere simultaneously
34+
35+In this reset, we are including changes that will allow us to make these changes in the future without resetting the network.
36+
37+## Do I need to perform a personal breach?
38+
39+No. A network reset subsumes all personal breaches, so please don’t also perform a personal breach.
40+
41+## What can I expect?
42+
43+If you are using a self-hosted ship, you need to affirmatively perform the reset using the instructions below. If you are using hosting, your ship will process the reset automatically.
44+
45+## Do I need to do anything with Bridge/Ethereum?
46+
47+There are no Ethereum transactions necessary for this reset.
48+
49+## I’m self-hosted—what do I need to do?
50+
51+You are still in the old era. First you need to ensure that you are on the
52+correct base hash - run `+trouble` in dojo and check that the following line
53+is displayed.
54+```
55+[%base-hash [0v1f.lbtqc.5o909.qqja6.17dgp.m8gde.bmiqc.fa97p.8jer8.msu43.5rf36]]
56+```
57+If `%base-hash` is different, you need to download the correct OTA from `~fet`,
58+a galaxy that Tlon has left running in the old era specifically for this
59+purpose. Enter `|ota ~fet %kids` into dojo and wait until the OTA update is
60+complete. Now you are ready to proceed.
61+
62+**Simply use the `flagday` tool that we have provided**. It will perform all the
63+relevant actions on your behalf, as well as exporting and reimporting your data.
64+
65+To use `flagday`, run the following:
66+
67+```shell
68+curl https://bootstrap.urbit.org/flagday.sh > flagday.sh; chmod 755 ./flagday.sh; ./flagday.sh PIER_DIRECTORY
69+```
70+
71+Alternatively, you can perform the migration manually (see below).
72+
73+## Can I perform the migration manually?
74+
75+Yes, by following these steps (note that these steps **will not** back up your data as is the case with `flagday`):
76+
77+1. Download your [keyfile from Bridge](https://urbit.org/getting-started/#keyfile).
78+2. Shut down your ship.
79+3. [Archive and move your old pier](@/using/os/getting-started.md#moving-your-pier) (this is the directory that contains your urbit event log).
80+4. [Download the latest version](@/getting-started.md#macos-and-linux) of the urbit binary.
81+5. [Boot your ship with the new keyfile](@/getting-started.md#boot-your-planet).
82+
83+## I’m hosted by Tlon, or someone else—what do I need to do?
84+
85+Users hosted by Tlon will not need to take any action. We’re handling everything on our end. If you’re hosted by another provider, you should contact that provider for instructions.
86+
87+## What happens to my data?
88+
89+We’ve written a tool called `flagday` that will allow you to easily export your ship’s Landscape data. This includes your subscriptions and any content such as Collections, Notebooks and Chats that are on your ship. This data can then be seamlessly imported into a new ship.
90+
91+## What is unique about this reset?
92+
93+This reset will include Arvo/Vere Version Negotiation. This will allow us to ship updates to Vere and Arvo separately without worrying about an incompatibility on ships. For example, if you are running Vere 1.0 and an OTA of Arvo goes out that requires Vere 2.0, your ship will simply drop the update and notify you that you need to update your binary in order to receive the next update. When you update your binary is up to you.
94+
95+## Will there be more network resets?
96+
97+We are optimistic that this will be our last reset, as all future updates to the network can be distributed as OTA (over-the-air) updates, possibly accompanied by a notification to update a binary version.
98+
99+## What happens if I don’t follow these instructions?
100+
101+Your Urbit will fall out of communication with the rest of the Urbit network which has performed the reset. This means that updates (OTAs) will no longer process and you won’t be able to communicate with anyone else on the network.
102+
103+## How do I get help if I need it?
104+
105+If you're in a tight spot or confused, reach out to us at support@urbit.org.
106+
107+## What's a 'breach'?
108+
109+We often call events like this a 'breach' since we "breach" the continuity of Urbit's network protocol. This language has no relationship to security. If anything, it's more like a "hard fork" of the network.
content/understanding-urbit/interface.md+1−1
@@ -43,7 +43,7 @@ OS 1 is a minimal, multipurpose interface for bringing a group together to chat,
4343
4444We built OS 1 for ourselves. We were sick of using centralized, mainstream software. We didn’t want to be stuck switching between bloated, monolithic services in order to keep in touch and move our work forward. We were done relying on some third party to take care of our community—so we exited to Urbit, and it feels good.
4545
46−If you’re curious to get a complete overview of OS 1, check out [this post](https://urbit.org/blog/introducing-os1/), watch the [release event](https://www.youtube.com/watch?v=71ViyftPkGk&feature=youtu.be&t=3963) or feel free to [boot a node](@/using/install.md#comet) to come talk to us.
46+If you’re curious to get a complete overview of OS 1, check out [this post](https://urbit.org/blog/introducing-os1/), watch the [release event](https://www.youtube.com/watch?v=71ViyftPkGk&feature=youtu.be&t=3963) or feel free to [boot a node](@/getting-started.md#comet) to come talk to us.
4747
4848(Running Urbit still requires a little fiddling around in the command-line, so it’s not for everyone—but we do have [plans for that to improve](https://urbit.org/blog/providers/).)
4949
content/understanding-urbit/people-history.md+2−2
@@ -38,7 +38,7 @@ src="https://media.urbit.org/site/understanding-urbit/uu-people-history-2a.jpg"/
3838src="https://media.urbit.org/site/understanding-urbit/uu-people-history-2c.jpg"
3939/>
4040
41−Given how new and unusual Urbit is, it attracts a wide variety of interesting people — both technical and non-technical. The community is generally happy to talk to people about what Urbit is, what we’re up to, and where we’re going. The best way to get involved is to simply join the Urbit Community at `~bitbet-bolbel/urbit-community` — which our [setup instructions](/using/operations/using-your-ship/) can help you do.
41+Given how new and unusual Urbit is, it attracts a wide variety of interesting people — both technical and non-technical. The community is generally happy to talk to people about what Urbit is, what we’re up to, and where we’re going. The best way to get involved is to simply join the Urbit Community at `~bitbet-bolbel/urbit-community` — which our [setup instructions](@/using/os/getting-started.md) can help you do.
4242
4343For those interested in contributing there are some simple instructions on [GitHub](https://github.com/urbit/urbit/blob/master/CONTRIBUTING.md#contributing-to-urbit), but we also run a [grants program](https://grants.urbit.org/) where we reward contributors with Urbit ID address space. Grants aren’t solely for pre-determined projects, either. If you have something you’d like to propose, we’d love to hear from you.
4444
@@ -97,7 +97,7 @@ Building Urbit is about building a future where technology doesn’t control us.
9797
9898Keep in touch while we make build this vision into reality by [joining our mailing list](https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&id=be143888d2) or following us on [Twitter](https://twitter.com/urbit) or [GitHub](https://github.com/urbit).
9999
100−If you’re somewhat technical and you’d like to help and contribute, [install Urbit](/using/install) and consider [applying for a grant](https://grants.urbit.org/s).
100+If you’re somewhat technical and you’d like to help and contribute, [install Urbit](/getting-started) and consider [applying for a grant](https://grants.urbit.org/s).
101101
102102If you’re interested in homesteading a community when OS 1 comes out, [apply here](/community/community-grants).
103103
content/understanding-urbit/roadmap.md+2−2
@@ -40,7 +40,7 @@ Let’s walk through the next few phases of Landscape to get a sense of where we
4040
4141We built OS 1 for ourselves, because we wanted to use a communication tool that we can trust and put our system to work for real.
4242
43−Today we use OS 1 every day to chat, write, and share links. It’s a calm, minimalist tool that gets us one step away from the ads, tracking, distraction and disruption of mainstream software. (We won’t get into the details of OS 1 here, but you can check out [this post](https://urbit.org/blog/introducing-os1/) for a walkthrough. You’re also welcome to try [booting a node yourself](https://urbit.org/using/install/).)
43+Today we use OS 1 every day to chat, write, and share links. It’s a calm, minimalist tool that gets us one step away from the ads, tracking, distraction and disruption of mainstream software. (We won’t get into the details of OS 1 here, but you can check out [this post](https://urbit.org/blog/introducing-os1/) for a walkthrough. You’re also welcome to try [booting a node yourself](https://urbit.org/getting-started/).)
4444
4545The first version of OS 1 shipped in March and we’ve been improving it continuously ever since. OS 1 now runs on a much faster, more reliable Urbit OS kernel and network. The interface itself has been cleaned up and made vastly more efficient. If we weren’t so busy, we would have called it OS 1.12 by now.
4646
@@ -93,6 +93,6 @@ Our goal with Landscape is to give communities the tools they deserve to customi
9393But Landscape in early 2021 will likely still only come with a few modules out of the box. Our major next step during 2021 is to make it easy for anyone to add their own modules and for developers to build and publish their own. Enabling third-party development will really enable Urbit-centric communities to tailor their own software.
9494
9595
96−We can’t cover everything about Landscape in a short post, nor about how the community works or evolves what we do. If you’re curious to learn more, try [booting a node](https://urbit.org/using/install/) and joining the Urbit Community group where most of us hang out. That’s where we hang out most of the time, but you can also find us working in public on [GitHub](https://github.com/urbit) and on the [urbit-dev](https://groups.google.com/a/urbit.org/g/dev) mailing list.
96+We can’t cover everything about Landscape in a short post, nor about how the community works or evolves what we do. If you’re curious to learn more, try [booting a node](https://urbit.org/getting-started/) and joining the Urbit Community group where most of us hang out. That’s where we hang out most of the time, but you can also find us working in public on [GitHub](https://github.com/urbit) and on the [urbit-dev](https://groups.google.com/a/urbit.org/g/dev) mailing list.
9797
9898For now, let’s move on to who builds this thing and where it came from.
content/updates/2016-5-16-roadmap.md+2−2
@@ -117,8 +117,8 @@ We already use Urbit to publish documents about Urbit, to chat about
117117Urbit, and of course to deliver Urbit updates. With this release,
118118we're adding a public chat stream and public comments.
119119
120−The next dogfooding steps: using Github as a backup to Clay, not Clay
121−as downstream from Github; our own internal issue tracker; and
120+The next dogfooding steps: using GitHub as a backup to Clay, not Clay
121+as downstream from GitHub; our own internal issue tracker; and
122122replacing internal email with long-form `:talk` messages.
123123
124124### Optimization
content/updates/2017-10-7-update.md+1−1
@@ -11,6 +11,6 @@ ship = "tonlur-sarret"
1111`~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.
1212
1313- [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~/)
14−- [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~/)
14+- [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~/)
1515- [`~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~/)
1616- [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/updates/2018-4-14-update.md+1−1
@@ -23,7 +23,7 @@ We hired more people! Tlon is pleased to have with us:
2323Ford](https://fora.urbit.org/proposals/posts/~2018.3.15..04.24.35..a47f~/). They turbocharged the `+execute` algorithm to
2424use a worklist data structure. This will not only be simpler to reason about, but in the future, it will allow future
2525support for parallelization of builds at the Vere level in MapReduce fashion. Their work is on
26−[Github](https://github.com/urbit/arvo/tree/ford-turbo).
26+[GitHub](https://github.com/urbit/arvo/tree/ford-turbo).
2727
2828*Curtis* `~sorreg-namtyv` has been working hard to make Hoon's type system less confusing, as well as working on the
2929problem of data inspection in Hoon. Now that his "structure-to-type" code is mostly done (going from an abstract type
content/updates/2018-4-7-update.md+1−1
@@ -34,7 +34,7 @@ post](https://fora.urbit.org/posts/~2018.3.15..04.24.35..a47f~/). Their code can
3434Lastly, big shoutout to *Mikolaj* `~ponmep-litsem` for his work on [Plato](http://plato.urbitetorbi.org:8080/plato.html),
3535which now allows remote Hoon code execution without logging in. This is a big step towards improving our developer
3636onboarding, as it will allow newcomers to experience interactive Urbit programming in the browser quickly without having
37−to wait to boot their own ship. See Mikolaj's original thread on Github [here](https://github.com/urbit/docs/issues/239).
37+to wait to boot their own ship. See Mikolaj's original thread on GitHub [here](https://github.com/urbit/docs/issues/239).
3838
3939We look forward to teaching some of you this Sunday the beginnings of the art of Martian functional programming. To all
4040else, we'll see you on the network. Have a great weekend, everybody!
content/updates/2018-5-16-update.md+1−1
@@ -36,7 +36,7 @@ Isaac has solid Hoon and frontend chops, having already implemented server-side
3636documentation work done. They've seen several PR's go through to improve the Hoon standard library docs, simplify the
3737Hoon demo, update our examples to the latest syntax, improve the Urbit installation process, and more. Josh's
3838work-in-progress is happening [here](https://github.com/joshuareagan/doc-drafts/). The main docs are [on
39−Github](https://github.com/urbit/docs): if there's a piece of doc that's confusing to you, don't hesitate to file an
39+GitHub](https://github.com/urbit/docs): if there's a piece of doc that's confusing to you, don't hesitate to file an
4040issue. Or better, submit a pull request.
4141
4242*Joe* `~master-morzod` is making strides on full HTTPS support for individual ships. He's implemented LetsEncrypt
content/updates/2018-5-23-update.md+1−1
@@ -52,7 +52,7 @@ step towards making Urbit address-space ownership real, Mark's work-in-progress
5252Urbit documentation. Josh has been writing a [new Hoon tutorial series](https://github.com/joshuareagan/doc-drafts) to
5353supersede the current Urbytes, while Robert has been blazing a trail through the current standard library docs, making
5454sure they're up-to-date and [improving them](https://github.com/urbit/docs/tree/rmariani-patch-6) as he goes. There's
55−been a lot of activity on Github recently. Don't be shy: [submit your first docs pull
55+been a lot of activity on GitHub recently. Don't be shy: [submit your first docs pull
5656request](https://github.com/urbit/docs), a classic rite of passage for the neophyte Hoon programmer.
5757
5858Lastly, Josh, Ted, and Keaton will be live on Mars Talk tomorrow night, Wednesday at 8:30PM PST. We'll post the Hangouts
content/updates/2018-5-30-update.md+1−1
@@ -66,7 +66,7 @@ the libraries and necessary styling, then integrate this into current Arvo/Vere.
6666to his [new WIP Hoon tutorials](https://github.com/joshuareagan/doc-drafts), and both Josh and Rob have gifted us with
6767several [pull requests](https://github.com/urbit/docs/pulls) documenting the simple but elusive `=,` rune and refactoring
6868much of the existing standard library doc. The docs are a great place to start learning and contributing. [Check them
69−out](https://github.com/urbit/docs) on Github, and [submit an issue](https://github.com/urbit/docs/issues), tagging Josh
69+out](https://github.com/urbit/docs) on GitHub, and [submit an issue](https://github.com/urbit/docs/issues), tagging Josh
7070and Rob, if you're confused by anything, or think something is documented wrong.
7171
7272Josh and Ted also did a [Mars Talk](https://www.youtube.com/watch?v=IgQo5aSezK4) this week -- Season 2, Episode 6 -- to
content/updates/2019-3-4-update.md+1−1
@@ -27,7 +27,7 @@ The nice folks behind [@urbitlive](https://twitter.com/urbitlive) discovered a b
2727~morlyd-mogmev
2828```
2929
30−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!
30+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!
3131
3232Stay tuned for a post with a full report.
3333
content/updates/2019-4-11-update.md+1−1
@@ -18,7 +18,7 @@ Here’s a short update from the team as of `~2019.4.11`:
1818
1919## Community
2020
21−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`.
21+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`.
2222
2323## April Fools
2424
content/updates/2020-04-04-update.md+1−1
@@ -19,7 +19,7 @@ If you’re a Hoon School graduate, we’ve got a big announcement: The inaugura
1919
2020Haven’t done Hoon School? Don’t worry! We will be running more hackathons in the future, at least two a year. The next Hoon School session begins on Monday the 6th, so there’s still time to sign up. Go to [urbit.org/community/hoonschool/](https://urbit.org/community/hoonschool/) to enroll.
2121
22−OS1 is for [homesteaders and tinkerers](https://urbit.org/understanding-urbit/roadmap/). It’s profoundly new. It’s not our final destination, but it’s an important and foundational tool for getting there. And it’s a big leap towards allowing individuals and communities to use it for their needs. There’s already a growing constellation of public communities on Urbit. When you’re ready to launch OS1, check out our [install guide](https://urbit.org/using/install/).
22+OS1 is for [homesteaders and tinkerers](https://urbit.org/understanding-urbit/roadmap/). It’s profoundly new. It’s not our final destination, but it’s an important and foundational tool for getting there. And it’s a big leap towards allowing individuals and communities to use it for their needs. There’s already a growing constellation of public communities on Urbit. When you’re ready to launch OS1, check out our [install guide](https://urbit.org/getting-started/).
2323
2424If you need a planet, you can buy one from [Urbit Live](https://urbit.live).
2525
content/updates/2020-06-15-update.md+1−1
@@ -27,7 +27,7 @@ We’ve got two exciting lines of work coming together right now. The first is
2727
28283 -
2929
30−The Urbit Community group has been fun and engaging lately. If you’ve booted your Urbit and haven’t joined, we encourage it. We’re there talking about the future of Urbit, core development, and all things Urbit adjacent and related. Ask for an invite in /urbit-help once you’ve gotten [set up](https://urbit.org/using/install).
30+The Urbit Community group has been fun and engaging lately. If you’ve booted your Urbit and haven’t joined, we encourage it. We’re there talking about the future of Urbit, core development, and all things Urbit adjacent and related. Ask for an invite in /urbit-help once you’ve gotten [set up](https://urbit.org/getting-started).
3131
3232
33334 -
content/using/_index.md+31−3
@@ -1,5 +1,33 @@
11+++
2−title = "Using"
2+title = "Usage Docs"
33sort_by = "weight"
4−template = "list.html"
5−+++
4+template = "sections/docs/chapters.html"
5++++
6+
7+Welcome to the usage documentation for the Urbit project. This documentation is
8+maintained by [Tlon](https://tlon.io) and the Urbit community in a public
9+[Github repository](https://github.com/urbit/urbit.org). Issues and
10+contributions are welcome.
11+
12+This documentation provides a series of guides and reference material for
13+assisting you in the usage and operations of your ship. If you're looking for
14+documentation on how to *develop* on Urbit, see our [development docs](@/docs/_index.md).
15+
16+### [Urbit OS](@/using/os/_index.md)
17+
18+This section describes how to interact with your running Urbit ship: this
19+includes working with the filesystem, command line (`dojo`), resolving common
20+issues, and more.
21+
22+### [Urbit ID](@/using/id/_index.md)
23+
24+Urbit ID is our [public-key infrastructure](@/using/id/overview.md), which is
25+what allows you to truly own your identity. Here you'll find guides for
26+interacting with your Urbit ID via our [Bridge](https://bridge.urbit.org)
27+application.
28+
29+### [Running Urbit](@/using/running/_index.md)
30+
31+Urbit can be run in a variety of contexts. Our [Getting Started
32+Guide](@/getting-started.md) covers how to run an Urbit locally on your
33+computer; this section covers alternative ways of running Urbit.
content/using/develop.mddeleted−115
@@ -1,115 +0,0 @@
1−+++
2−title = "Developer's Guide"
3−description = "How to get started developing on Urbit."
4−weight = 3
5−template = "page_indiced.html"
6−aliases = ["/docs/using/creating-a-development-ship/", "/docs/getting-started/contributing"]
7−+++
8−
9−You can develop on Urbit in three ways:
10−
11−- [Applications using Urbit](#api), which use Urbit as the back-end to store data and communicate with others
12−- [Urbit Applications](#application), which are written in [Hoon](/docs/glossary/hoon/), and run as part of Urbit
13−- [Urbit Core](#core), which involves contributing to Urbit's operating system ([Arvo](https://github.com/urbit/urbit/tree/master/pkg/arvo)) or runtime ([Vere](https://github.com/urbit/urbit/tree/master/pkg/urbit))
14−
15−This guide will start by getting you set up to run an Urbit ship, and then tell you everything you need to know to do either.
16−
17−### Setting up your environment
18−
19−We assume you’ve gotten a basic introduction to Urbit. If you haven’t, read the [Understanding Urbit](@/understanding-urbit/_index.md) series.
20−
21−Once you’re ready, you can get started on the network right away and take some first steps, without acquiring an identity, by [creating a comet](@/using/install.md#comet).
22−
23−When developing, however, we recommend [booting a development ship](#creating-a-development-ship) and working locally -- you may need to make changes that could, in the wrong hands, destroy the ship’s environment, and it’s best to do so in a safe, separate place.
24−
25−## Applications using Urbit {#api}
26−
27−Urbit ships with its own set of apps written in its own language, Hoon. However it is also meant to integrate with applications written in other languages via an API. The clearest example of an application using Urbit is Landscape, the default client. Although it does currently ship with Urbit, its front-end is a separate piece of software that uses Urbit's HTTP APIs to interact with an Urbit ship. You can create your own application that uses Urbit to store data and interact with other Urbit ships without writing any Hoon code thanks to Urbit's HTTP APIs. This could be a chat client, a writing app, a game, or anything else that can communicate over HTTP.
28−
29−To get started quickly with the language of your choice, see the following libraries that provide HTTP interfaces to Urbit:
30−
31− - [Python](https://github.com/baudtack/urlock-py) (Stable)
32− - [Swift](https://github.com/dclelland/UrsusAirlock) (Under development)
33− - [Haskell](https://github.com/bsima/urbit-airlock) (Under active development)
34− - [JavaScript](https://www.npmjs.com/package/urbit) (Under active development)
35− - Go (Pending release)
36−
37−[View details about using the API or creating your own implementation here.](/using/integrating-api/)
38−
39−## Urbit Applications {#application}
40−
41−Urbit applications are still young, but can be fun to experiment with.
42−
43−When creating user applications on Urbit, you aren’t tied to any particular user interface. They can work without providing a response to the user, or by printing to the Dojo, or with an interface in Landscape, which uses [Eyre](@/docs/tutorials/arvo/eyre.md) (the Arvo vane that serves HTTP to serve a React-based interface to the application through a web browser).
44−
45−When writing applications, you will often make use of [Gall](@/docs/tutorials/hoon/hoon-school/gall.md), the Arvo vane that manages user applications.
46−
47−If you want to see examples of Urbit applications with common functionality requirements, you can see our [examples](https://github.com/urbit/examples) repository. If you want to get started building applications with a Landscape interface, check out our [create-landscape-app](https://github.com/urbit/create-landscape-app) repository.
48−
49−## Urbit Core {#core}
50−
51−Working on the core means improving the Urbit project itself, working with the existing community of Urbit developers. The kernel is much more stable, but generally more challenging from an engineering standpoint.
52−
53−Just arrived and unsure what to work on? An ideal way to get started is by experimenting with the system, talking to other developers, and reading (or [contributing to](https://github.com/urbit/docs)) the [documentation](/docs/).
54−
55−Prefer learning with an instructor? Our community runs an online course that covers the basics of Urbit development called [Hooniversity](https://hooniversity.org/). If course-based learning works well for you, we recommend you sign up.
56−
57−The Urbit developer community congregates around [the urbit-dev mailing list](https://groups.google.com/a/urbit.org/forum/#!forum/dev), the `~bitbet-bolbel/urbit-community` group on Landscape, and [Urbit’s GitHub repository](https://github.com/urbit/urbit). It’s a good idea to sign up, see what people are talking about, and introduce yourself.
58−
59−Once you’re comfortable working with Urbit, check out the [project’s issues on GitHub](https://github.com/urbit/urbit/issues) or some of our [contribution bounties](https://grants.urbit.org/).
60−
61−If you’re looking for some guidance, need help, or would prefer direct communication for your ideas, you can also always reach out to us directly at [support@urbit.org](mailto:support@urbit.org).
62−
63−## Creating a development ship {#creating-a-development-ship}
64−
65−To do work with Hoon and with the system, we recommended using a "fake" ship -- one not connected to the network.
66−
67−Because such a ship has no presence on the network, you don't need an Azimuth identity for its purposes. You just need to have [installed our software](/using/install).
68−
69−To create a fake ship named `~zod`, run the command below. You can replace `zod` with any valid Urbit ship-name.
70−
71−```
72−./urbit -F zod
73−```
74−
75−Now you should see a block of boot messages, starting with the Urbit version number. Welcome!
76−
77−## Community tutorials {#community-tutorials}
78−
79−Here are some tutorials written by members of the Urbit community. Some are a little outdated, but they may still prove useful.
80−
81−- [Generators](https://github.com/joemfb/mardev/tree/master/docs/gen) by `~master-morzod`
82−- [Urbit by Doing](https://github.com/Fang-/Urbit-By-Doing) by `~palfun-foslup`
83−- [Learning Hoon](https://github.com/knubie/learning-hoon) by `@knubie`
84−- [A Nock Interpreter](https://jtobin.io/nock) by `~nidsut-tomdun`
85−- [Basic Hoonery](https://jtobin.io/basic-hoonery) by `~nidsut-tomdun`
86−
87−If you want to add something to the list, [shoot us an email](mailto:support@urbit.org) or make a pull request in the [docs repository](https://github.com/urbit/docs).
88−
89−## How else can I contribute? {#how}
90−
91−The Urbit project is a global community of developers, users, and fans. If you’re interested in getting involved, there’s space for you; you don’t have to be a developer to be a part of the project.
92−
93−### Running stars and galaxies
94−
95−There are two ways to participate in the Arvo network: as a user running a planet and as an infrastructure provider running a galaxy or a star.
96−
97−For planets, Urbit is a peer-to-peer network where users can interact with each other via Landscape, or using custom applications that anyone can write.
98−
99−Running a planet helps build Urbit’s community, surfaces bugs, and helps core developers improve Urbit under realistic conditions.
100−
101−Stars and galaxies, however, have additional responsibilities and play a role in peer discovery as well as star and planet distribution. You can think of stars and galaxies as similar to the DNS system in the modern Internet. Most users don’t know it exists, but without it, the web wouldn’t work at all.
102−
103−Running a reliable galaxy or star, and spawning stars and planets from them, are excellent ways to help bootstrap the Urbit network.
104−
105−If you’re interested in running a galaxy or star, you’ll be reliably providing peer discovery for your children just by running your node – and we’re doing our best to make this both easy and profitable. If you’re interested in this, see [Star and Galaxy Operations](@/using/operations/stars-and-galaxies.md).
106−
107−If you’re interested in distributing planets, read on.
108−
109−### Distribute points
110−
111−Want to get your friends and family into Urbit? Distribute planets using Bridge with a feature called **delegated sending**.
112−
113−Here’s how it works: any star can grant a number of invites to any of its child planets. Those planets can then send one-time-use invite codes via email to anyone of their choosing.
114−
115−For instructions on how to grant and send invites, check out [Using Bridge](@/using/operations/using-bridge.md).
content/using/id/_index.mdnew file+33
@@ -0,0 +1,33 @@
1++++
2+title = "Urbit ID"
3+template = "sections/docs/chapters.html"
4+sort_by = "weight"
5+description = "How to interact with Urbit ID."
6+weight = 20
7++++
8+
9+Urbit ID is our [public-key infrastructure](@/using/id/overview.md), which is
10+what allows you to truly own your identity.
11+
12+### [Overview](@/using/id/overview.md)
13+
14+This document discusses what Urbit ID is, how it's built, and why it's been
15+built that way at a high level.
16+
17+### [Using Bridge](@/using/id/using-bridge.md)
18+
19+A guide to using [Bridge](https://bridge.urbit.org), our tool for managing your
20+Urbit ID.
21+
22+### [Bridge Troubleshooting](@/using/id/bridge-troubleshooting.md)
23+
24+How to resolve common issues in Bridge.
25+
26+### [Creating an Invite Pool](@/using/id/creating-an-invite-pool.md)
27+
28+If you own a star, invite pools allow your friends to invite others onto the
29+network.
30+
31+### [Guide to Breaches](@/using/id/guide-to-breaches.md)
32+
33+What to do when things go very wrong and you need to start over.
content/using/operations/bridge-troubleshooting.md → content/using/id/bridge-troubleshooting.mdrenamed+4−2
@@ -1,10 +1,12 @@
11+++
22title = "Bridge Troubleshooting"
3−template = "page_indiced.html"
3+template = "doc.html"
44description = "Troubleshooting Bridge if you are running into errors"
5−weight = 5
5+weight = 20
66+++
77
8+This page covers common issues encountered with the [Bridge](https://bridge.urbit.org) application.
9+
810### Canvas Issues
911
1012Bridge uses an HTML element called canvas to create your wallets. Unfortunately malicious websites can use canvas to identify and track users. As a result, some browsers and anti-tracking extensions can interfere with Bridge's ability to generate wallets.
content/using/id/creating-an-invite-pool.mdnew file+106
@@ -0,0 +1,106 @@
1++++
2+title = "Creating an Invite Pool"
3+weight = 30
4+template = "doc.html"
5++++
6+
7+If you're a star owner, you have the ability to create **invite pools**. These
8+invite pools let you give your friends a piece of the network in the form of a
9+planet. This document will give you an explanation of how to create an invite
10+pool and how to share it with your friends using our tool
11+[Bridge](https://bridge.urbit.org).
12+
13+For more general tips on using your star, check out the [Star and Galaxy
14+Operations page](@/using/_index.md).
15+
16+## Anatomy of an Invite Pool
17+
18+An invite pool is a set of planet invites that can be distributed via email or
19+URL; each invite is worth one planet when redeemed. An invite pool can be as big
20+as you'd like, providing that you have enough planets left to spawn. All invite
21+pools must be created by a star, but they must be given to a planet. If you're
22+interested in how this works technically, take a look at the
23+[DelegatedSending.sol
24+contract](https://github.com/urbit/azimuth/blob/master/contracts/DelegatedSending.sol).
25+
26+Keep in mind that all planets will have access to the invite pool until the
27+invite pool is exhausted.
28+
29+For example: As `~marzod`, I spawn `~wicdev-wisryt` and give it an invite pool
30+of 100 planets. `~wicdev-wisryt` can now send an invite to a friend at
31+galen@tlon.io. When Galen claims his planet (`~ravmel-ropdyl`), `~ravmel-ropdyl`
32+can now invite his friend — or 99 of them. `~wicdev-wisryt` may also continue to
33+use the invite pool, as can anybody they invite.
34+
35+## How To Create an Invite Pool
36+
37+Giving your friends a piece of Urbit only takes a few minutes: send an invite
38+pool to a planet, and then that planet can email an invite to a friend (or
39+friends)
40+
41+1. Log into Bridge using your ownership address for your star.
42+
43+2. Change the spawn proxy of your star to
44+ `0xF7908Ab1F1e352F83c5ebc75051c0565AEaea5FB`. This is a contract address that
45+ will handle the spawning of planets for invitees.
46+
47+3. Get the `@p` (like `~poldec-tonteg`) of the planet to whom you'd like to give
48+ access to the invite pool. It can be one you control or a friend's. It does
49+ not have to be a planet sponsored by your star.
50+
51+3. Click "Manage Invite Pools" to assign an invite pool to the planet. You may
52+ receive a notification that you need to assign your spawn proxy to the
53+ address of the Delegated Sending contract. This is so that the contract can
54+ send invites on your behalf when the recipient claims them. This address is
55+ `0xF7908Ab1F1e352F83c5ebc75051c0565AEaea5FB`, which is also displayed in Bridge.
56+
57+![](https://media.urbit.org/docs/invite-pool/browser-point.png)
58+
59+4. Enter the `@p` of the planet and the number of invites you'd like to assign to them.
60+
61+![](https://media.urbit.org/docs/invite-pool/browser-create-pool.png)
62+
63+Once the transaction is complete, the planet will have access to the invite pool.
64+
65+## How to Send an Invite
66+
67+1. Log into Bridge using the planet assigned an invite pool above using the
68+ planet's Master Ticket or ownership address.
69+
70+2. Under "Invite Group", click "Add Members" to unroll the invitation UI.
71+
72+3. Select either "Email" or "URL".
73+
74+4. If you selected "Email", enter the email address(es) of those you wish to
75+ invite to the dialog box. You may add more than one email address. Click "Add to
76+ Invite Group" when finished, and wait for the transaction to complete. Your
77+ friend(s) will get an email shortly with your gift of an identity for life!
78+
79+ If you selected "URL", click "Generate Invite URL" to create an invitation URL
80+ that you can then share.
81+
82+## FAQ
83+
84+Q. What happens if the spawn proxy address is changed away from
85+`0xF7908Ab1F1e352F83c5ebc75051c0565AEaea5FB` after an invite pool has been
86+created? Will outstanding invite pool(s) still function?
87+A. They won't. Existing balances will remain, but Bridge (and `azimuth-js`) won't
88+consider any of the invites from that star usable, and trying to send one of
89+their planets anyway will result in a failed transaction.
90+
91+Q. Can a star create more than one invite pool at a time?
92+A. Yes, a star can allow any given planet to send any number of invites
93+independently from one another.
94+
95+Q. Can an invite pool be revoked?
96+A. Yes, this may be done by assigning zero invites to a planet that had been
97+previously been given access to an invite pool.
98+
99+Q. Can a delegated planet have more than one invite pool assigned to it?
100+A. Yes, as a planet, multiple stars can give you invites to use.
101+
102+Q. What can you do if you send an invite to an email address by mistake?
103+A. Planets that have been sent but not yet claimed live at the
104+ownership address of the star that created the invite pool. Log into Bridge
105+using the ownership address for the star and you will be able to cancel the
106+pending invite. Once an invite has been accepted, nothing can be done!
content/using/id/guide-to-breaches.mdnew file+90
@@ -0,0 +1,90 @@
1++++
2+title = "Guide to Breaches"
3+weight = 40
4+template = "doc.html"
5++++
6+
7+An important concept on the [Ames](@/docs/arvo/ames/ames.md) network is that of continuity. Continuity refers to how ships remember the order of their own network messages and the network messages of others -- these messages are numbered, starting from zero. A _breach_ is when ships on the network agree to forget about this sequence and treat one or more ships like they are brand new.
8+
9+There are two kinds of breaches: **personal breaches** and **network breaches**.
10+
11+## Personal Breaches
12+
13+Ships on the Ames network sometimes need to reset their continuity. A personal breach is when an individual ship announces to the network: "I forgot who I am, let's start over from scratch." That is, it clears its own event log and sends an announcement to the network, asking all ships that have communicated with it to reset its networking information in their state. This makes it as though the ship was just started for the first time again, since everyone on the network has forgotten about it.
14+
15+Personal breaches often fix connectivity issues, but should only be used as a
16+last resort. Before performing a personal breach, look at alternative fixes in
17+the [Ship Troubleshooting](../ship-troubleshooting) guide. Also reach out for
18+help in the Help channel in the Urbit Community group
19+`~bitbet-bolbel/urbit-community`, or, failing that, in the
20+`#ship-starting-support` channel in our [Discord
21+server](https://discord.gg/n9xhMdz) to see if there is another option.
22+
23+There are two types of personal breaches - one where your Ethereum ownership address
24+remains the same, and one where you are switching to a new Ethereum ownership
25+address. We make the emphasis about the Ethereum _ownership_ address as
26+changing your [proxies](@/docs/glossary/proxies.md) does not require a breach.
27+
28+If you will be keeping the same Ethereum ownership address and would like to perform a
29+personal breach, follow the steps below.
30+
31+- Go to [bridge.urbit.org](https://bridge.urbit.org) and log into your identity.
32+- Click on `OS: Urbit OS Settings` at the bottom, then click `Reset Networking Keys`.
33+- Check the `Breach Continuity` box. Click `Reset Networking Keys`, and then click `Send Transaction` and wait for the progress bar to appear.
34+- Download your new keyfile following these instructions: [Generate your
35+ keyfile](@/using/id/using-bridge.md#generate-your-keyfile).
36+- Delete or archive your old [pier](@/docs/glossary/pier.md).
37+- Proceed to [boot your ship](@/getting-started.md#boot-your-planet) with the new keyfile.
38+- Delete your keyfile after successfully booting.
39+- Rejoin your favorite chat channels and subscriptions.
40+
41+If you are switching to a new Ethereum ownership address you will have the
42+choice as to whether or not you want to breach. This is to cover the case when
43+you are transferring to another address you own. The process here is slightly different.
44+
45+- Go to [bridge.urbit.org](https://bridge.urbit.org) and log into your identity.
46+- Click on `ID: Identity and security settings` at the bottom, then click
47+ `Transfer this point`.
48+- Enter the new Ethereum address you would like to transfer ownership to. Click
49+ `Generate & Sign Transaction`, then click `Send Transaction` and wait for the
50+ progress bar to complete.
51+- Logout of your current session in Bridge by clicking `Logout` at the top, and
52+ then login to your new ownership address.
53+- From here, following the directions on how to [Accept your
54+ transfer](@/using/id/using-bridge.md#accept-your-transfer), [Set your
55+ networking keys](@/using/id/using-bridge.md#set-your-networking-keys),
56+ and [Generate your
57+ keyfile](@/using/id/using-bridge.md#generate-your-keyfile). The option
58+ whether or not to breach is in the Accept your Transfer step.
59+- Delete or archive your old [pier](@/docs/glossary/pier.md).
60+- Proceed to [boot your ship](@/getting-started.md#boot-your-planet) with the new keyfile.
61+- Delete your keyfile after successfully booting.
62+- Rejoin your favorite chat channels and subscriptions.
63+
64+Performing a personal breach on your ship increments an integer value called
65+your ship's _life_ by one, which refers to your ship's [Azimuth](@/docs/azimuth/azimuth.md) _key
66+revision number_. This value is utilized by
67+Ames and Jael to ensure that you are
68+communicating with a ship created using its most recent set of keys. Your
69+ship's life is written at the end of the name of its keyfile, e.g.
70+`sampel-palnet-4.key`. Changing the Etherum address that holds the Urbit ID,
71+called _reticketing_, increments a number called the ship's _rift_ by one in
72+addition to incrementing your ship's life.
73+Rift refers to your ship's Azimuth _continuity number_.
74+
75+You can check your current life and rift number by running the
76+`+keys our` generator in Dojo. You can inspect another ship's life and rift can be checked by
77+running `+keys ~sampel-palnet`.
78+
79+
80+## Network Breaches
81+
82+A network breach is an event where all ships on the network are required to update to a new continuity era. Network breaches happen when an Arvo update is released that is too large to release over the air. The current continuity era is given by a value in Ames, our networking vane, that is incremented when a network breaches; only ships with the same such value are able to communicate with one another.
83+
84+If a network breach is happening, follow the steps below.
85+
86+- Delete your old Urbit binary.
87+- Delete or archive your old pier.
88+- Download the new Urbit binary by following the instructions in the [Install page](@/getting-started.md).
89+- Create a new pier by booting your ship with your key, according to the instructions on the install page. (Note: You do _not_ need to use a new key to boot into a new continuity era.)
90+- Rejoin your favorite chat channels and subscriptions.
content/using/id/overview.mdnew file+71
@@ -0,0 +1,71 @@
1++++
2+title = "Overview"
3+description = "A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included."
4+weight = 1
5+template = "doc.html"
6++++
7+
8+![](https://media.urbit.org/site/posts/essays/pki-maze.png)
9+
10+A public key infrastructure (PKI) is a system for binding a set of keys to a name. Sometimes a small amount of metadata is included.
11+
12+Existing PKIs include PGP-style ["web of trust"](https://en.wikipedia.org/wiki/Web_of_trust), [SSL certificates](https://en.wikipedia.org/wiki/Certificate_authority), [ZeroTier](https://www.zerotier.com/lf-announcement/), [Keybase](https://keybase.io/), [OpenID](https://openid.net/what-is-openid/), [Mozilla Persona](https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Persona), and [Login with Google](https://developers.google.com/identity). These take unique approaches to the problem and have achieved some degree of success, but none provide globally consistent, permanent, and completely self-owned identities. Exhaustive exploration and categorization is unfortunately out of scope for this post, so we'll just describe Urbit's approach to achieving these properties in our PKI.
13+
14+In Urbit, a "name" is often called a "ship" or an "address" because we use the metadata in the PKI to make names routable. The total data is two 256-bit asymmetric keys, a cryptographic suite number (to allow changing crypto algorithms), the revision number of the key, and the name of a ship that will route for it. This sums to less than 128 bytes of data.
15+
16+Each PKI trades off various properties. We chose a tripartite system so that appropriate choices can be made for different use cases. Here, we explore the various properties we chose by following a series of binary choices -- the idea maze.
17+
18+There are two sorts of PKI: either you can change your keys or not. If you cannot, then your name is impermanent, for no one can keep a set of keys secure forever. Even if your opsec never fails, eventually your crypto algorithms may be compromised.
19+
20+However, if you sacrifice the ability to change your keys, you can have a very nice property: self-attesting keys. If your name is a hash of your public key information, then no other source of information is required to verify you are who you say you are. This is a useful property since it requires no coordination at all. Many things are impermanent, especially during development. It also provides a way to try out the network without obtaining a permanent address.
21+
22+This is our first stop in the idea maze. We call this sort of name a "comet". A comet's name is the 128-bit hash of its public keys.
23+
24+However, Urbit is yours and it's forever. You shouldn't have to change your name every time you change your keys. So, we go back and take the other choice: you must be able to change your keys.
25+
26+To change keys, you must sign a message with the old keys revoking them and supplying the new ones[^0]. The question is what happens if the old keys also sign a second set of new keys. This could happen if an attacker obtained your old keys after the fact. This is important because one of the reasons to be able to change your keys is to invalidate the old ones so that they have no power.
27+
28+We have two options again: the PKI may be globally consistent or not. To be globally consistent means that if you believe a name is bound to a set of keys, then nobody on the network will disagree.
29+
30+If you don't require global consistency, you may sign this message and send it to all your neighbors, and they pass it on, and hopefully it gets to most of the network quickly. However, if one of those ships receives two contradictory versions of this message, the only thing it can do is trust the first one it heard, which may be different than what someone else heard. Thus, this is pairwise consistent but globally inconsistent. This is essentially how the pre-blockchain Ames network worked, though key changes were not actually implemented. Because global consistency is a valuable property, we looked at other options.
31+
32+For a globally consistent PKI that allows you to revoke keys, you need to be able to distinguish between two cryptographically valid messages to determine which was signed first. The dual problem could be solved easily — you can prove a message is signed after another by including the signature of the first in the second. This is equivalent to reading out a newspaper headline to prove a message was recorded after a given day.
33+
34+However, the problem of proving one message was sent before any later ones inverts the problem. You can solve this with newspapers by placing the message in the text of the newspaper. However, while reading a newspaper requires no central party, writing one does. For a long time, this sort of message was always handled by a central party. SSL revocations are managed by a few central parties. When you buy property, it's not sufficient to have the previous owner sign the title — this must be entered into a central land registry. Otherwise, the owner may sell their property to multiple people and there would be no way to determine who is the new owner. With the land registry, all you need to do is ask the registry which sale happened first, and that's the one that counts.
35+
36+However, Urbit is yours and it's forever. Trusting central registries jeopardizes both. The keen reader will notice that the problem of determining which key rotation happened first is exactly the double-spend problem that Satoshi solved with his proof of work algorithm for Bitcoin. His first block famously includes a newspaper headline to prove he didn't mine the block before that date. In a beautiful duality, his own algorithm proves that he didn't mine it after that date.[^1]
37+
38+Some argue that blockchain is only good for money. This is myopic and is generally based on the experience that its most valuable application so far has been money. However, blockchain is a cryptographic primitive to do what was previously impossible: prove that one message was signed before another without a central party. Blockchain was discovered by someone trying to create digital money, and he needed that primitive, but that doesn't mean that's all it's good for.
39+
40+Thus, we store our PKI data on a blockchain for our second kind of name: planets. A planet is a 32-bit address which has key information stored on the blockchain.[^2] The owner of a planet may broadcast new PKI data by adding it to the blockchain. Any later messages by the old keys will be rejected, and everyone on the network will listen to the blockchain for key data. Thus, we have global consistency, permanence, and self sovereignty. We know of no other solution that can provide these properties.
41+
42+However, while small individually, the aggregate PKI data for all nodes on the network may become very large. This is not an issue for comets because nobody needs to store comet keys except for those which they're talking with, and even those can be garbage-collected and re-requested and verified. For planets, there is a canonical set of keys, and somebody must store that. There are about 2<sup>32</sup>, or 4 billion planets. If the PKI data is about 100 bytes for each planet, this is about 400 GB of data. This may be more than most users wish to store, but it's small enough that it would be very cheap for someone to host this data for many users[^3].
43+
44+This information is currently stored directly on the Ethereum 1.0 blockchain, but as is well understood in blockchain circles this approach will not scale beyond a certain point. Many chains are pursing designs that allow the users of the smart contracts to store locally the data associated with the contracts they care about and only commit hashes to the chain. We expect there to be several viable options for this by the time our scaling needs exceed what's provided by Ethereum 1.0. This will free us from the cost of hosting the PKI data on all Ethereum nodes, but the data must still be stored somewhere. Any service that could handle such a large amount of data would inherently centralize the network.
45+
46+However, 4 billion is not enough addresses for every device on the planet today, much less in a few decades. So, we apply our maxim of re-examining our choices at each level for each use case. Examining the idea maze above, we cannot use the blockchain option for everything since the data is too big. However, it's not actually necessary for each of your devices to have its own self-sovereign identity separate from your planet. So we choose the option of using a central registry: your own planet.
47+
48+We allocate 4 billion "moons" to each of those planets. A moon is a 64-bit address whose 32-bit suffix is its planet. Your planet can easily store the keys for its own moons, and anyone who needs to talk to your moons can ask you for the keys.
49+
50+This is the sense in which moons are true ships: they're permanent names and you own them completely, as long as you own the planet. However, they're not independent ships — their keys can always be revoked by their planet.
51+
52+To create a sane network, we require global consistency for all our names. There are three other properties; pick any two:
53+
54+- Comets are impermanent, self sovereign, and plentiful.
55+
56+- Planets are permanent, self sovereign, and not plentiful.
57+
58+- Moons are permanent, not self sovereign, and plentiful.
59+
60+Fancifully, comets are wayward celestial bodies that are great for testing and miscellaneous low-value things that won't last for long. Planets are where you can build a home and shape it into anything you want it to be. People can always find your planet; it's not going anywhere. Moons are useful for special purposes, like storage, heavy industry, and anything else you might want to do off-planet.[^4]
61+
62+
63+[^0]: Or the equivalent with a hierarchical key structure. In practice, you want to have a master key which signs a junior key for everyday use. You use the master key to rotate the junior key.
64+
65+[^1]: More strictly: it proves that he didn't mine it after the other blocks currently on the Bitcoin blockchain. It only gives an ordering within the chain, not a literal timestamp.
66+
67+[^2]: In addition to planets, there are stars and galaxies. From a PKI perspective they're treated exactly like planets, but on the network they provide infrastructure services like routing.
68+
69+[^3]: In practice, this will likely be an included service by your sponsoring star. It could be a separate service, but it will be very cheap because it's a commodity and the "cost of production" is very cheap. At any rate, it should never rise above the capital cost of a 400GB hard drive.
70+
71+[^4]: To extend the metaphor, stars are a neighborhood to live in -- they're easier for other planets to see, so when they want to send you a message they look for your star first. If they don't even know where your star is, they can certainly find your star's galaxy, and that will be enough to locate the star. Of course, if your star is not providing satisfactory service, you can take your planet and move to another star.
content/using/operations/using-bridge.md → content/using/id/using-bridge.mdrenamed+5−5
@@ -1,8 +1,8 @@
11+++
22title = "Using Bridge"
3−template = "page_indiced.html"
3+template = "doc.html"
44description = "How to use Bridge to interact with Azimuth and manage your Urbit ID."
5−weight = 1
5+weight = 10
66aliases = ["/docs/getting-started/using-bridge/"]
77+++
88
@@ -14,7 +14,7 @@ This guide assumes that you have an Urbit ID, or that you have found someone to
1414
1515To connect to Bridge, go to [https://bridge.urbit.org](https://bridge.urbit.org) into your browser, and enter your identity's credentials in the appropriate fields. If you were invited to claim an Urbit ID, it's very likely that you received an email that would direct you to Bridge, and you can simply follow the hyperlink in that email.
1616
17−You'll arrive at a page and see two major choices: `ID` and `OS`. `OS` is the only option that you're interested in right now; click on it. On the `OS` page, click the `Download Arvo Keyfile` button. Once you have downloaded the keyfile, you can exit Bridge and proceed to [install the Urbit binary](@/using/install.md).
17+You'll arrive at a page and see two major choices: `ID` and `OS`. `OS` is the only option that you're interested in right now; click on it. On the `OS` page, click the `Download Arvo Keyfile` button. Once you have downloaded the keyfile, you can exit Bridge and proceed to [install the Urbit binary](@/getting-started.md).
1818
1919### Local Bridge
2020
@@ -72,9 +72,9 @@ It should be noted that setting your network keys is an event on the Ethereum ne
7272From the detail page associated with your point, click the `Generate Arvo Keyfile` link and you'll be taken to a page with a field titled `Network seed`. This field should already be filled in, and should match the hexadecimal string that you entered in the previous step. If it's not filled in or does not match, fill it in with the correct string.
7373Click `Generate ->`, which will download a keyfile onto your machine.
7474
75−With that keyfile in hand, you can now exit Bridge and continue to the guide to [install the Urbit binary](@/using/install.md).
75+With that keyfile in hand, you can now exit Bridge and continue to the guide to [install the Urbit binary](@/getting-started.md).
7676
77−### Escaping your sponsor
77+### Escaping your sponsor {#escaping-your-sponsor}
7878
7979As a planet or star, it behooves you to be sponsored by an active star or galaxy,
8080respectively. If your sponsor isn't suiting your needs, you can escape to a
content/using/install.mddeleted−370
@@ -1,370 +0,0 @@
1−+++
2−title = "Install + Setup"
3−weight = 1
4−description = "How to install Urbit."
5−template = "page_indiced.html"
6−aliases = ["/docs/getting-started/"]
7−+++
8−
9−Urbit is not for everyday users yet — but if you're technically inclined or generally intrepid, feel free to try it out. It's a good place to explore.
10−
11−## Overview
12−
13−There are two major components of the Urbit ecosystem: **Urbit OS** and **Urbit ID**.
14−
15−The Urbit peer-to-peer (P2P) network is composed of instances of Urbit OS — also called **ships** — that run as virtual machines on any Unix platform. The Urbit ID registry is deployed on the Ethereum blockchain, and individual IDs exist as non-fungible ([ERC-721](https://eips.ethereum.org/EIPS/eip-721)) tokens. On the network, Urbit IDs function as network addresses, represented by pronounceable names like `~padmyn-pasnux`.
16−
17−As we'll explain, there are a few types of Urbit ID, but everyday users tend to use **planets**, as full citizens of the network.
18−
19−Two other types of ships are **stars** and **galaxies**. Together these perform essential infrastructural roles for the Urbit network. Each galaxy can distribute 256 stars, and each star can distribute 65,536 planets. So any given planet ultimately came from a specific star, which itself came from a specific galaxy. On the Urbit OS side, stars help route packets; galaxies are more like DNS root servers or ICANN members. The difference with Urbit in the analogy is that Urbit IDs are owned cryptographically by individuals, collectives, and companies alike, and accrue reputation independently.
20−
21−If you just want to try Urbit out, there are also free IDs called **comets**. They are good for bots and people who are new to Urbit and want to check out the network, but they aren't good for building a reputation as a friendly and responsible peer. Their long names make them difficult to remember—and some communities ban comets to prevent spam—but they're still a good way to see what Urbit is about before buying your own planet.
22−
23−To start with a comet, continue below. For planet instructions, see [further below](#boot-your-planet). For star or galaxy instructions, see [this section](#supernode).
24−
25−## Installing Urbit
26−
27−Regardless of your Urbit ID, you'll want the Urbit binary installed first. The Urbit binary runs on a Unix-like operating system – Ubuntu, Fedora, or macOS, for example.
28−
29−### macOS and Linux
30−
31−```sh
32−#macOS:
33−mkdir urbit
34−cd urbit
35−wget --content-disposition https://urbit.org/install/mac/latest
36−tar zxvf ./darwin.tgz --strip=1
37−./urbit
38−
39−#Linux:
40−mkdir urbit
41−cd urbit
42−wget --content-disposition https://urbit.org/install/linux64/latest
43−tar zxvf ./linux64.tgz --strip=1
44−./urbit
45−```
46−
47−Once you've followed the appropriate install instructions, you can check if everything went right by running the `./urbit` command. Installation was successful if you get a block of output that begins with the line below:
48−
49−```
50−Urbit: a personal server operating function
51−```
52−
53−To access your Urbit via HTTP on port 80 on Ubuntu, you may need to run the following:
54−```sh
55−sudo apt-get install libcap2-bin
56−sudo setcap 'cap_net_bind_service=+ep' /path/to/urbit
57−```
58−(Where `urbit` is the urbit executable downloaded with `curl` prior)
59−
60−### Windows
61−
62−> Please note that this method of installing Urbit is experimental, and we may not be able to assist you if you encounter issues related to WSL 2.
63−
64−These instructions have been tested and verified for WSL 2 + Ubuntu 18.04 LTS.
65−
66−Urbit cannot run on Windows itself, but there is a convenient way to run a Linux distro using the [Windows Subsystem for Linux 2](https://docs.microsoft.com/en-us/windows/wsl/wsl2-install) on Windows 10. Install the Windows Subsystem for Linux 2 and open a Linux terminal in Windows, then follow the Linux installation instructions above.
67−
68−For performance reasons, do not install Urbit in the mounted Windows volume, but install it in the Linux file system. For example, in your home directory, which can be navigated to by entering `cd ~`.
69−
70−## Setting up a comet {#comet}
71−
72−**Comets** are 128-bit or 16 syllable Urbit IDs, that look like:
73−
74−`~dasres-ragnep-lislyt-ribpyl--mosnyx-bisdem-nidful-marzod`
75−
76−Comets are disposable, free identities that can be used to quickly join the network and try things out.
77−
78−### Booting a comet
79−
80−To boot a comet, go into the command line and run the following command from the `urbit` directory you created during [Urbit installation](#installing-urbit):
81−
82−```sh
83−#macOS:
84−./urbit-v0.10.8-darwin/urbit -c mycomet
85−
86−#Linux:
87−./urbit-v0.10.8-linux64/urbit -c mycomet
88−```
89−
90−Since your identity on the network is not verified, it may take up to an hour to generate your comet. As it boots, will spin out a bunch of boot messages and create a directory called `mycomet`. Toward the end of the boot process, you'll see something like:
91−
92−```
93−ames: on localhost, UDP 31337.
94−http: live (insecure, public) on 8080
95−http: live ("secure", public) on 8443
96−http: live (insecure, loopback) on 12321
97−~sampel_marzod:dojo>
98−```
99−
100−When your ship is finished booting, you will see either the `~sampel_marzod:dojo>` or `~sampel_marzod:chat-cli/` prompt. If you see `:chat-cli`, press `Ctrl-X` to switch into Dojo.
101−
102−To exit Urbit, use `Ctrl-D` or enter `|exit` into Dojo.
103−
104−To start your ship up again, run the following from your `urbit` directory (note the lack of `-c` argument):
105−
106−```sh
107−#macOS:
108−./urbit-v0.10.8-darwin/urbit mycomet
109−
110−#Linux:
111−./urbit-v0.10.8-linux64/urbit mycomet
112−```
113−
114−### The Dojo
115−
116−Let's try our first command in the Dojo, the Urbit OS command line and Hoon REPL, to get oriented.
117−
118−Type `(add 2 2)` into the Dojo. You should see the following:
119−
120−```
121−~sampel_marzod:dojo> (add 2 2)
122−```
123−
124−When you press Enter, you should see this:
125−
126−```
127−> (add 2 2)
128−4
129−```
130−
131−Good, your Dojo is working correctly. Now let's run our first useful command in the Dojo. The first thing you generally want to do with a new ship is to **mount** it. A ship being mounted means that it has a presence on your Unix filesystem, allowing files to be shared between Unix and your ship. To mount your ship, type `|mount %` at the Dojo prompt.
132−
133−```
134−|mount %
135−>=
136−```
137−
138−The `>=` output means that a command was successful. Now you can see your ship's files in its Unix directory.
139−
140−### Using Landscape
141−
142−Landscape is the Urbit web interface, and it's the best way to interact with your ship. To access Landscape:
143−
144−1. Start your ship. In the boot messages, look for a line that says something like `http: live (insecure, public) on 80`. The number given is the port that your ship is using.
145−2. If the port given is 80, simply type `localhost` into your browser's address bar. If the given port is a different number, such as `8080`, you would type `localhost:8080`. You'll be met with a login prompt.
146−3. Type `+code` into your comet's Dojo. Copy-paste the returned code into the field asking for it in the browser page.
147−4. You're in! Now you can explore apps such as Chat, Publish, and more.
148−
149−### Join a group
150−
151−Now that you're on Landscape, join the Urbit Community, a great place for newcomers to ask questions.
152−
153−Click the 'Groups' button on your Landscape home page, and then click the `Join Group` column. Then, enter `~bitbet-bolbel/urbit-community` into the field and press the `Join Group` button.
154−
155−From the Urbit Community group you can join a variety of chatrooms, notebooks, and collections.
156−
157−## Setting up a planet {#id}
158−
159−If you have an Urbit ID, you'll use the [Bridge](https://bridge.urbit.org) client to get your ship's *keyfile* before you can [boot your ship](#booting-your-ship). Your keyfile is a cryptographic secret that allows your Urbit instance to authenticate itself on the network, so it is required the first time you boot your ship. Your keyfile is deterministically derived from your other cryptographic secrets.
160−
161−### Purchase an Urbit ID
162−
163−Tlon doesn't currently sell or distribute Urbit IDs, but there are a few ways to get your own:
164−
165−- Getting an invitation from a friend.
166−- Purchasing an Urbit ID, including hosting, from a third-party turnkey solution such as [geturbitid.com](https://www.geturbitid.com/).
167−- Manually setting up and hosting an Urbit ID purchased from a third party such as [urbit.live](https://urbit.live), [OpenSea](https://opensea.io), [planet.market](https://planet.market/), or [Urbit Marketplace](https://urbitmarketplace.com/).
168−
169−Note that when you buy a planet, you should ensure with the provider that the star is operating. If you already have a planet and need to escape a non-operational star, see [Escaping A Sponsor](@/using/operations/using-your-ship.md#escape).
170−
171−Tlon occasionally selects candidates to distribute invitations, and users operating galaxies and stars can spawn and distribute a finite number of stars and planets, respectively.
172−
173−### About your Urbit ID wallet
174−
175−Your Urbit ID is actually yours. As long as you control its cryptographic secrets, nobody can take it away from you. That's why it's important to know a little bit about the cryptographic architecture of Urbit secrets.
176−
177−Urbit ID secrets operate as a system of separate but hierarchically related Ethereum key-pairs. For any given ID, this system of key-pairs is referred to as a **Hierarchical Deterministic (HD) Wallet**. the Urbit HD wallet. Each of these Ethereum addresses have different powers over the same identity, from setting networking keys for communicating in the Urbit network to transferring ownership of identities. Important elements of the HD wallet:
178−
179−- **Master Ticket**: The "password" at the top of the hierarchy that determines the ownership. All other secrets are derived from this. If the rest of the wallet is lost or compromised, the master ticket can derive everything. You'll log into Bridge with this. Always keep your master ticket extremely safe.
180−
181−- **Management Proxy**: Derived from the master ticket. Can perform non-ownership related operations such as configuring Urbit OS networking keys.
182−
183−- **Keyfile**: Derived from the management proxy. Used as cryptographic proof that your Urbit ship is who it says it is. You use it to start up your ship for the first time.
184−
185−### Get your keyfile {#keyfile}
186−
187−As mentioned previously, there are a few ways to acquire a planet. All methods,
188−however, should result in you receiving at least one secret, such as a **master
189−ticket**. If you received an email invite to Urbit, the master ticket should be
190−a `.pdf` file in the passport folder inside the archive that you downloaded.
191−
192−1. Connect to [Bridge](https://bridge.urbit.org).
193−2. Enter the name of your planet and the associated master ticket in the appropriate fields. Click the "Metamask, Mnemonic, Hardware Wallet..." button for alternate login methods if you don't have a master ticket.
194−3. Once you're logged in, click the "OS" option.
195−4. In resulting page, click the "Download Arvo Keyfile" button. You should
196− receive a `.key` file that contains the secret needed to boot your ship. Hold
197− onto this file. This may be grayed out if you are not using a master ticket.
198− If so, click on "Reset Networking Keys", then click on "Reset Networking Keys" on
199− the following page, validate the transaction using your wallet, and then
200− click Send Trasaction. Once the transaction is complete, the "Download Arvo
201− Keyfile" button should be available for you to press.
202−
203−### Choose to host or run your ship locally
204−
205−There are two supported ways of running an Urbit ship: using a cloud service, or running it locally on your own machine. Most users run things locally at first, but we recommend eventually using a cloud service for Urbit because it allows your ship to be accessed from anywhere on multiple devices. Hosting your ship in the cloud also allows it to always be online and ready for OTA updates. It's technically possible to run your Urbit ship on a home server, but ISPs often restrict this to business plans and opening up your home network to the internet can be unsafe if done improperly.
206−
207−We have a guide for [hosting your ship on DigitalOcean](@/using/operations/hosting.md) which we've found works well, but any cloud hosting service should work.
208−
209−### Boot your planet
210−
211−You'll be booting your ship with the keyfile that you downloaded from Bridge.
212−
213−#### Step 1: Find the path to your keyfile
214−
215−Find the absolute path to the keyfile that you downloaded from Bridge. Copy it.
216−
217−#### Step 2: Run the boot command
218−
219−Enter your `urbit` directory.
220−
221−Once you're inside, run the command below, except with `sampel-palnet` replaced by the name of your
222−Urbit identity, and `path/to/my-planet.key` replaced with the path to your keyfile:
223−
224−```sh
225−#macOS:
226−./urbit-v0.10.8-darwin/urbit -w sampel-palnet -k path/to/my-planet.key
227−
228−#Linux:
229−./urbit-v0.10.8-linux64/urbit -w sampel-palnet -k path/to/my-planet.key
230−```
231−
232−Or, if you'd prefer to copy your key in, you can run:
233−
234−```sh
235−#macOS:
236−./urbit-v0.10.8-darwin/urbit -w sampel-palnet -G rAnDoMkEy
237−
238−#Linux:
239−./urbit-v0.10.8-linux64/urbit -w sampel-palnet -G rAnDoMkEy
240−```
241−
242−Either command will create a directory called `sampel-palnet/` and begin building your ship. It may take a few minutes.
243−
244−When your ship is finished booting, you will see either the `~sampel-palnet:dojo>` or `~sampel-palnet:chat-cli/` prompt. If you're seeing `:chat-cli` press `Ctrl-X` to switch into Dojo.
245−
246−To shut down your ship, use `Ctrl-D`. To start your ship up again, run the following from your `urbit` directory:
247−
248−```sh
249−#macOS:
250−./urbit-v0.10.8-darwin/urbit sampel-palnet
251−
252−#Linux:
253−./urbit-v0.10.8-linux64/urbit sampel-palnet
254−```
255−
256−Note that `sampel-palnet/` is the path of a folder, which we just created in your `urbit` directory. This folder is called your ship's **pier**.
257−
258−Never boot multiple instances of your ship at the same time. You can prevent this from happening on accident by only ever keeping a single copy of your pier.
259−
260−**Important:** once a key has been used to boot a ship onto the network, it cannot be used to boot that ship again later - doing so will cause communication problems with other ships. For this reason you should **delete the keyfile from your machine once your ship has booted successfully**. If you do use the same key twice, you'll need to conduct a [personal breach](#breaches) to restore your ship to full functionality).
261−
262−Delete the keyfile with the command below:
263−
264−```sh
265−rm path/to/my-planet.key
266−```
267−
268−### Updating to the latest binary {#updating}
269−
270−Most updates to Urbit are downloaded and applied automatically as OTA (Over the Air) updates. Occasionally it would be infeasible to distribute an update this way, and a new `urbit` binary is released. This is announced in the [urbit-dev](https://groups.google.com/a/urbit.org/forum/#!forum/dev) Google Group when it occurs (as are all OTA updates).
271−
272−To update to the latest binary, download and extract it to replace your existing one. Then run it as before.
273−
274−For example, if in your current `urbit` directory you have an `urbit-v0.10.7-<OS>` directory along with a ship directory called `mycomet`, and a new `urbit-v0.10.8-<OS>` binary was just released, then you'd run the following commands from your `urbit` directory:
275−
276−First shut down your ship, by running the following in dojo (or `Ctrl-D`).
277−```
278−|exit
279−```
280−
281−**NOTE**: Your ship itself can be reused, only the binary needs to be changed. This is why we have the directory structure configured as an `urbit` directory that contains your ship and your binary. This structure makes it easy to swap in new binaries. If you have your ship *inside* the `urbit-vX.XX.X` directory, move it out before deleting that directory.
282−
283−Delete the old binary directory from your `urbit` directory:
284−
285−```sh
286−#macOS:
287−rm -rf urbit-v0.10.7-darwin
288−
289−#Linux:
290−rm -rf urbit-v0.10.7-linux64
291−```
292−
293−Next download and extract the most recent binary from inside your `urbit` directory:
294−```sh
295−#macOS:
296−curl -O https://bootstrap.urbit.org/urbit-v0.10.8-darwin.tgz
297−tar xzf urbit-v0.10.8-darwin.tgz
298−
299−#Linux:
300−curl -O https://bootstrap.urbit.org/urbit-v0.10.8-linux64.tgz
301−tar xzf urbit-v0.10.8-linux64.tgz
302−```
303−
304−Start up your ship with the new binary from your `urbit` directory:
305−```sh
306−#macOS:
307−./urbit-v0.10.8-darwin/urbit mycomet
308−
309−#Linux:
310−./urbit-v0.10.8-linux64/urbit mycomet
311−```
312−
313−Then you're good to go, in the future you'll just modify the version numbers in the example above to the most recent version.
314−
315−### Breaches {#breaches}
316−
317−An important concept on the Urbit network is that of continuity. Continuity refers to how ships remember the order of their own network messages and the network messages of others — these messages are numbered, starting from zero. A breach is when ships on the network agree to forget about this sequence and treat one or more ships like they are brand new.
318−
319−There are two kinds of breaches: personal breaches and network breaches.
320−
321−A personal breach can fix many problems with your ship, but should be used as a last resort. A network breach happens when there's a major software update and you must download a new binary.
322−
323−For details on breaching, please read the [Guide to Breaches](@/docs/tutorials/guide-to-breaches.md) documentation.
324−
325−## Running a star or galaxy {#supernode}
326−
327−Setting up and running a star or galaxy is a little bit different from setting up and running a planet.
328−
329−### Getting a star or galaxy
330−
331−Stars are valuable cryptographic assets. They can be bought in one of two ways.
332−
333−- Transacting privately with a star owner.
334−- Buying a star on a marketplace like [OpenSea](https://opensea.io/collection/urbit-id)
335−
336−Galaxies are rare and extremely valuable, meaning that there is no liquid market for them. If you want to buy a galaxy, you'll have to find an individual galaxy owner and transact with them.
337−
338−### A note on security
339−
340−As mentioned before, stars are valuable. You are solely responsible for safeguarding your seeds and secret keys, and arming yourself with the computer-security knowledge that is attendant upon that safeguarding. You act at your own risk in reliance upon the contents of the manual. In no way is the Tlon Corporation responsible for the actions, decisions, or other behavior taken or not taken by you in reliance upon this manual.
341−
342−It’s a good idea to store your keys redundantly in case one method fails. If you deem a key to be valuable enough, you can shard it into thirds and store each third in secure, geographically distributed locations. Consider these storage media options:
343−
344−- Storing the secret on a hardware wallet that is never connected to a networked machine.
345−- There are products that let you store the key on steel. This medium is resistant to both water damage and fire damage.
346−
347−### Getting a star's keyfile
348−
349−1. Connect to [Bridge](https://bridge.urbit.org).
350−2. Enter the name of your star and the associated master ticket in the appropriate fields. Click the "Metamask, Mnemonic, Hardware Wallet..." button for alternate login methods if you don't have a master ticket.
351−3. Once you're logged in, click the "OS" option.
352−4. In resulting page, click the "Download Arvo Keyfile" button. You should receive a `.key` file that contains the secret needed to boot your ship. Hold onto this file.
353−
354−### Boot your star
355−
356−Because of their need for near-perfect uptime Stars should be hosted on cloud services. We have a guide for [hosting on DigitalOcean](@/using/operations/hosting.md), but any cloud provider should work.
357−
358−Being an infrastructure node, a star has certain responsibilities to the Urbit network.
359−
360−By default, your star accepts software updates from its galaxy and routes them to its planets. You can use this mechanism to push custom software to your planets. Keep in mind that planets expect functional, non-breaking software updates, and generally want to be able to communicate with planets that are sponsored by other stars.
361−
362−To ensure new planets can connect to your ship, users are expected to participate in network-wide breaches by updating to the latest Urbit version, deleting (or archiving) your pier, and then booting your ship using the new binary. If you don’t participate, you won’t be able to communicate with anyone on the network who has updated to the new era.
363−
364−Network-wide breaches are distinct from personal breaches, wherein an individual ship cycles its personal network keys using bridge.
365−
366−See our [Guide to Breaches](@/docs/tutorials/guide-to-breaches.md) for more information and for instructions on breaching.
367−
368−### Running a galaxy
369−
370−A galaxy is at the top of the hierarchy in terms of importance. Thus, if you're interested in running one, please contact support@urbit.org, and we will give you personalized assistance in getting set up.
content/using/integrating-api.mddeleted−224
@@ -1,224 +0,0 @@
1−+++
2−title = "Integrating with Urbit for Developers"
3−description = "How to use Urbit's API."
4−weight = 4
5−template = "page_indiced.html"
6−+++
7−
8−This guide is aimed at developers who have a working knowledge of HTTP grammar (`PUT`, `GET`), and should not require any special knowledge of Urbit's internals. To learn more about a specific application within Urbit, please search for that with the docs once you have finished this guide.
9−
10−## Authentication
11−
12−The first step in creating an application *on* Urbit (to be distinguished from an Urbit application) is to authenticate with the desired ship. This can be a planet, comet, or any other Urbit ship. For the purposes of this example, we will be running a "fakezod" on port 8080. Run this code, substituting the appropriate path to your Urbit binary:
13−
14−```bash
15−/path/to/urbit -p 8080 -F zod
16−```
17−
18−(for the unfamiliar, this will create a folder named "zod" in your working directory, from which the ship will run. Use `/path/to/urbit -p 8080 zod` in the future)
19−
20−You can run `+code` in the dojo to get the key, but a fakezod's key is always `lidlut-tabwed-pillex-ridrup`. This is our password, our API token that we will use.
21−
22−Run this code in your bash terminal (requires cURL):
23−
24−```bash
25−curl -i localhost:8080/~/login -X POST -d "password=lidlut-tabwed-pillex-ridrup"
26−```
27−Let's explain what this does:
28−
29− - `-i` displays the headers, so that you can see the cookie that gets sent
30− - `localhost:8080/~/login` is the URL to which you are POSTing. You will note this is also the URL you visit when you log into Landscape.
31− - `-X POST` specifies that you are POSTing data, not GETting.
32− - `-d "password=lidlut-tabwed-pillex-ridrup"` specifies the key for your Urbit that we retrieved above. It is sent as form data, as if it were sent from an HTML form input field (which it is in Landscape)
33−
34−You should see the following:
35−
36−```bash
37−HTTP/1.1 200 ok
38−Date: Sun, 01 Jan 2020 00:00:00 GMT
39−Connection: keep-alive
40−Server: urbit/vere-0.10.8
41−set-cookie: urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg; Path=/; Max-Age=604800
42−transfer-encoding: chunked
43−```
44−
45−The `Date` and `set-cookie` will be slightly different of course.
46−
47−Take a look at the `set-cookie` line. This is now your session authentication, and will need to be sent with any future requests. It consists of three parts:
48−
49− - `urbauth` is a prefix that Eyre uses to check for presence of authentication
50− - `~zod` is the name of the ship you are logging in as
51− - `0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg` is the actual authentication token.
52−
53−At present there is no way to separate these parts — you must pass a cookie *as* a cookie. This string must be in the `Cookie` header. The `set-cookie` header is only used for this request upon response. It is what browsers expect when receiving a cookie.
54−
55−## Interacting with Urbit
56−
57−Once authenticated, you will perform all your operations on a channel. You may open as many channels as needed using the same authentication token, but this will increase complexity and memory usage on your Urbit ship.
58−
59−Interacting with Urbit comprises two parts:
60−
61−1. Sending information via PUT requests, which receive HTTP status code `204` (no content) upon success. We will not receive updated information (as in a POST request).
62−2. Receiving data on channels, which must first be subscribed to via an initial request. These come in the form of SSEs ([Server-Sent Events](https://www.w3.org/TR/eventsource/))
63−
64−These can be used independently, i.e. you may choose to only send information or only receive information from your Urbit, based on your application. Both can take place on the same channel.
65−
66−### Creating a Channel
67−
68−For this example, we will use the following channel:
69−
70−```
71−http://localhost:8080/~/channel/1601844290-ae45b
72−```
73−
74−Let's examine the parts. A channel is simply a URL in this pattern: `{url}/~/channel/{uid}` where `{uid}` is a string of your choosing. Most libraries default to the current unix time plus six hexadecimal characters. Your program should determine a channel for its current session and store that in its state.
75−
76−The channel does not yet exist in Urbit, however. To subscribe to events on this URL, you must first make a request (PUT) to Urbit on this URL. The simplest way to do this is to `hi` ourselves, as if we had entered `|hi our` in the dojo. A `hi` is analogous to a ping, and does not manipulate state. Let's learn how to make requests using this as an example.
77−
78−### Making Requests
79−
80−All requests will take the form of sending a message. Messages can take different forms, such as `subscribe`s, `ack`s, and `poke`s. These are called actions and there are more than these, but these will cover most basic use cases. You can think of them as a somewhat more sophisticated HTTP grammar. A message always requires an `id` and an `action`. Other fields depend on the specific action.
81−
82−Let's look at the structure of a message by examining the most basic `hi` we will send.
83−
84−```js
85−{
86− 'id': 1, // Required. A sequential ID. Keep track of which messages you have sent.
87− 'action': 'poke', // Required. The action to take. poke is the most basic way of sending data, like HTTP POST
88− 'ship': 'zod', // Required by poke. The ship on which to perform the poke. You can only poke foreign ships with JSON, but this is the authenticated ship.
89− 'app': 'hood', // Required by poke. The Urbit app to which to send the data.
90− 'mark': 'helm-hi', // Required by poke. The "mark," or type, of data being sent.
91− 'json': 'Opening airlock' // Required by poke. The actual data being sent.
92−}
93−```
94−
95−Let's open our channel by sending the following request using cURL (**remember to change the cookie**):
96−
97−```bash
98−curl --header "Content-Type: application/json" \
99− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
100− --request PUT \
101− --data '[{"id":1,"action":"poke","ship":"zod","app":"hood","mark":"helm-hi","json":"Opening airlock"}]' \
102− http://localhost:8080/~/channel/1601844290-ae45b
103−```
104−
105−If you switch to your fakezod's dojo, you should see `< ~zod: Opening airlock`.
106−
107−Note that in the JSON that we sent via `--data`, the payload is wrapped in `[]`. This is because we can send multiple messages in a single payload, and Eyre expects a list of items, even if we are only sending one.
108−
109−You will always receive a `204` status code if the `PUT` request successfully reached Urbit, authentication succeeded, and the payload was valid. This is merely an HTTP status code, however. If the request failed within Urbit itself, however, you will receive a "nack" event that you will have to process separately.
110−
111−Let's look at how to receive events from Urbit.
112−
113−### Subscribing to Events
114−
115−Now that Urbit has opened an Eyre channel at our URL, we can watch for events on that URL by sending a `subscribe` message. Let's look at the anatomy of a `susbcribe`:
116−
117−```js
118−{
119− 'id': 2, // Required. This is the next message we are sending, so we give it the next ID.
120− 'action': 'subscribe', // Required.
121− 'ship': 'zod', // Required by subscribe.
122− 'app': 'chat-view', // Required by subscribe. In this case, we want to watch events that occur in the chat-view app, which is responsible for handling incoming chats.
123− 'path': '/primary' // Required by subscribe. All apps have different path structures. In the case of chat-view, this is where we see all incoming chats.
124−}
125−```
126−
127−This is all we need to send Urbit to say "On this URL through which I am sending information, send me SSEs whenever something occurs on this app at this path."
128−
129−You should be able to send this information if you were able to send the above cURL example. However, we now need to be able to listen to the SSEs. The `EventSource` object is available for JavaScript in the browser context, as this is why SSEs were invented, but there should be a library for it in your chosen language. Take a look at a Browser JavaScript example:
130−
131−```js
132−const eventSource = new EventSource('http://localhost:8080/~/channel/1601844290-ae45b', {
133− withCredentials: true // Required, sends your cookie
134−});
135−
136−eventSource.addEventListener('message', function (event) {
137− ack(Number(event.lastEventId)); // See section below
138− const payload = JSON.parse(event.data); // Data is sent in JSON format
139− payload.id === event.lastEventId; // The SSE spec includes event IDs. This information is duplicated in the payload.
140− const data = payload.json; // Beyond this, the actual data will vary between apps
141−});
142−
143−eventSource.addEventListener('error', function (event) {
144− handleError(event);
145−});
146−
147−```
148−
149−### Handling Received Events
150−
151−Once you have received an event, it is expected that you will "ack" or "acknowledge" that you have received them. To do so, simply send a message in the following format:
152−
153−```js
154−{
155− 'id': 3, // Required. Picking up where we left off
156− 'action': 'ack', // Required.
157− 'event-id': 15, // Required by ack. Whichever SSE of which you are acknowledging receipt
158−}
159−```
160−
161−### Unsubscribing from Events
162−
163−You may want to stop receiving events from a particular app path, but you don't want to close the channel altogether yet. Let's look at how to do that. Take a look at the example for subscribing. We sent that message with `id: 2`. We will use that ID to cancel the relevant subscription:
164−
165−```javascript
166−{
167− 'id': 4, // Required. We always increment the ID as we send messages.
168− 'action': 'unsubscribe', // Required.
169− 'subscription': 2 // Required by unsubscribe. This corresponds to the id of a subscribe message sent earlier.
170−}
171−```
172−
173−### Deleting a Channel
174−
175−You should clean up your channel when able. To do so, simply send a `delete` message and Eyre will handle the rest so your program can safely exit.
176−
177−```javascript
178−{
179− 'id': 5, // Required.
180− 'action': 'delete' // Required.
181−}
182−```
183−
184−## Other Operations
185−
186−There are other operations which require authentication but do not require the use of a channel. Some operations are app-specific and will not be enumerated here, but there are two operations that exist across Urbit: `scry` and `spider`.
187−
188−### Scrying
189−
190−Scrying lets you see what an app has exposed at a particular path. It does not manipulate state.
191−
192−It takes the form `{url}/~/scry/{app}{path}.{mark}`
193−
194− Let's get the base hash of our fakezod in the same way that Landscape does it.
195−
196−```bash
197−curl --header "Content-Type: application/json" \
198− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
199− --request GET \
200− http://localhost:8080/~/scry/file-server/clay/base/hash.json
201−```
202−
203−Note the use of a `GET` request.
204−
205−In this example we're scrying the `file-server` app at the path `/clay/base/hash` and using the `json` mark, which is most common. We receive `"0"` which is correct because we are at the top level of the hierarchy using a fake ship.
206−
207−Scry will fail with a 500 or return a 404 if no data is found.
208−
209−### Running Threads with Spider
210−
211−Running threads is an exception to the rule that we outlined in the section on channels. It uses a `POST` request and both manipulates state and receives information back. It also exposes the ability to send a sequence of commands, i.e. a "thread," hence the name.
212−
213−It takes the form `{url}/spider/{inputMark}/{threadname}/{outputmark}.json`
214−
215−This should be considered an advanced technique, but the basic structure of a request can be seen here:
216−
217−```bash
218−curl --header "Content-Type: application/json" \
219− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
220− --request POST \
221− --data '[{"foo": "bar"}]' \
222− http://localhost:8080/spider/graph-view-action/graph-create/json.json
223−
224−```
content/using/operations/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Operations"
3−description = "Instructions on how to use Bridge, your Urbit ship, Stars and Galaxies, and more."
4−sort_by = "weight"
5−weight = 2
6−template = "list.html"
7−+++
content/using/operations/using-your-ship.mddeleted−1439
@@ -1,1439 +0,0 @@
1−+++
2−title = "Using Your Ship"
3−description = "How to operate your ship, including using your ship's filesystem and messaging applications, starting a moon, or requesting a DNS proxy."
4−template = "page_indiced.html"
5−weight = 2
6−aliases = ["docs/using/arvo-network-dns/", "docs/using/messaging/", "docs/using/shell/", "docs/using/admin/"]
7−[extra]
8−hidetitle = "true"
9−+++
10−
11−## Using your ship
12−
13−Your urbit (also called your _ship_) is a persistent Unix process that you mainly control from the console.
14−
15−### Shutdown
16−
17−You can turn your urbit off with `Ctrl-d` from the Chat or Dojo prompts.
18−
19−You can force-quit your urbit with `Ctrl-z` from anywhere.
20−
21−### Restart
22−
23−To restart your urbit simply pass the name of your pier:
24−
25−```sh
26−$ ./urbit some-planet
27−```
28−
29−or
30−
31−```sh
32−$ ./urbit comet
33−```
34−
35−### Logging
36−
37−To log an urbit's command line output to a file, use `script`:
38−
39−```sh
40−$ script urbit.log ./urbit your-urbit
41−```
42−
43−### Moving your pier
44−
45−Piers are designed to be portable, but it _must_ be done while the urbit
46−is not running. Urbit networking is stateful, so you can't run two copies
47−of the same urbit in two places.
48−
49−To move a pier, simply move the contents of the directory it lives in.
50−To keep these files as small as possible we usually use the `--sparse`
51−option in `tar`. With a pier `your-urbit/`, something like this should work:
52−
53−```sh
54−tar -Scvzf ~/your-urbit.tar.gz ~/your-urbit/
55−scp your-old-server:~/your-urbit.tar.gz your-new-server:~
56−```
57−
58−Then to unzip it, on your other Unix server, run:
59−
60−```sh
61−tar xfvz your-urbit.tar.gz
62−```
63−
64−Delete the tar file, and, after installing Urbit on your new server, start your urbit back up with:
65−
66−```sh
67−./urbit your-urbit
68−```
69−
70−### Console
71−
72−Your Urbit terminal is separated into two parts: the prompt (the bottom line) and the record (everything above that). The record is shared; all the output from all the apps in your command set appears in it. The prompt is multiplexed.
73−
74−In the CLI, Urbit apps can process your input before you hit return. To see this in action try entering `)` as the first character at the Dojo prompt. Since there is no Dojo command or Hoon expression that starts with ')', the Dojo rejects it.
75−
76−`Ctrl-x` - Switches the prompt between running console apps
77−
78−`Ctrl-c` - Crash current event. Processed at the Unix layer and prints a stack
79−trace.
80−
81−`Ctrl-d` - From Chat or Dojo, stops your Urbit process.
82−
83−`Ctrl-z` - Stops the Urbit process from _anywhere_.
84−
85−`↑` / `↓` - History navigation
86−
87−The following emacs-style key bindings are available:
88−
89−```
90−Ctrl-a Cursor to beginning of the line (Home)
91−Ctrl-b Cursor one character backward (left-arrow)
92−Ctrl-e Cursor to the end of the line (End)
93−Ctrl-f Cursor one character forward (right-arrow)
94−Ctrl-g Beep; cancel reverse-search
95−Ctrl-k Kill to end of line
96−Ctrl-l Clear the screen
97−Ctrl-n Next line in history (down-arrow)
98−Ctrl-p Previous line in history (up-arrow)
99−Ctrl-r Reverse-search
100−Ctrl-t Transpose characters
101−Ctrl-u Kill to beginning of line
102−Ctrl-y Yank from kill buffer
103−```
104−
105−### Updates
106−
107−By default, you will automatically receive updates ([OTAs](@/docs/glossary/ota-updates.md)) from your sponsor. To check your OTA source, run `|ota` in the [dojo](@/docs/glossary/dojo.md).
108−
109−If for some reason (for example, if your sponsor is out of date), you can switch OTA sources by running `|ota ~otasrc %kids` in the dojo, where `~otasrc` is the ship from which you want to receive updates. It is a good idea to contact the source ship and ask permission to sync from them.
110−
111−If OTAs are not succeeding, or if you are on an version of Urbit before the `|ota` command was introduced, you can run `|merge %home (sein:title our now our) %kids, =gem %take-that`. **Note:** This will wipe out any custom changes to the base distribution.
112−
113−### Landscape
114−
115−On startup Urbit tries to bind to `localhost:80`. If you're already running something on port `80` -- such as any other HTTP server, or another urbit -- you'll find the urbit that you just started on `8080`, `8081`, and so on. For planets only, we also proxy web domains through Urbit's own servers. Any planet `~your-urbit` is also at `your-urbit.arvo.network`, but only after you [set up DNS](#dns-proxying).
116−
117−Once running, you can sign into Landscape, your ship’s web interface, from `http://localhost` or `https://your-urbit.arvo.network`. Since our HTTPS isn't audited / battle tested, we just call it "secure" HTTPS. You can find that on `8443`. Or `8444` (and so on) if you're already running something on `8443`.
118−
119−### Moons {#moons}
120−
121−Planets can spawn moons, which are meant for connected devices: phones, smart TVs, digital thermostats. The basic idea is that your planet runs permanently in a data center somewhere, while moons run on all your devices. Each planet can issue ~4 billion (`2^32`) moons.
122−
123−To generate a random moon from your planet, run:
124−
125−```
126−~sampel-palnet:dojo> |moon
127−moon: ~faswep-navred-sampel-palnet
128−\/0w5cT5t.wCO6i.~e1xg.Oz0qb.QNO6I.3Kt2T.h9M9F.U3vU~.X3Qu0.gtb19.IYTkY.80kWZ.SI\/
129− EUE.DXa8i.TiDof.o3-1C.RHLKS.k81M0.ecz5o.ic0Bg.600g1
130−\/ \/
131−```
132−
133−You must manually edit the output of `|moon` to get the correct format for the `<key>`:
134−
135−- strip out the `\/`
136−
137−- combine into one line, omitting spaces
138−
139−`<key>` would be `0w5cT5t.wCO6i.~e1xg.Oz0qb.QNO6I.3Kt2T.h9M9F.U3vU~.X3Qu0.gtb19.IYTkY.80kWZ.SIEUE.DXa8i.TiDof.o3-1C.RHLKS.k81M0.ecz5o.ic0Bg.600g1`
140−in this example.
141−
142−Put `<key>` in a file and that file becomes `<keyfile>`.
143−
144−You can use the resulting output in the same installation flow from the [Installing Urbit](@/using/install.md) guide, following the same scheme as for booting a planet. That scheme is:
145−
146−```sh
147−$ ./urbit -w <moonname> -G <key> -c <piername>
148−```
149−
150−or
151−
152−```sh
153−$ ./urbit -w <moonname> -k <keyfile> -c <piername>
154−```
155−
156−The `-c <piername>` argument is not required, but it is recommended; otherwise,
157−the resulting directory is a rather unwieldy moon name.
158−
159−Here's how an example moon might be booted:
160−
161−```sh
162−$ ./urbit -w faswep-navred-sampel-palnet -G <key> -c mymoon
163−```
164−
165−or
166−
167−```sh
168−$ ./urbit -w faswep-navred-sampel-palnet -k <keyfile> -c mymoon
169−```
170−
171−Moons are automatically synced to their parent `%kids` desk, and can control applications on their parent planet using `|link`.
172−
173−To breach a moon -- that is, to reset its presence on the network so that it's treated as a freshly spawned ship by others -- run from the parent ship:
174−
175−```
176−|moon-breach ~faswep-navred-sampel-palnet
177−```
178−
179−To cycle the keys of a moon without breaching, run:
180−
181−```
182−|moon-cycle-keys ~sampel-sipnym-wicdev-wisryt
183−```
184−
185−
186−### Escaping A Sponsor {#escape}
187−
188−To use the network as a planet or star, you must be sponsored by an active star
189−or galaxy, respectively. If your sponsor isn't suiting your needs, you can
190−escape to a different one. This can be done with
191−[Bridge](https://bridge.urbit.org/) following the instructions
192−[here](@/using/operations/using-bridge.md#escaping-your-sponsor).
193−
194−### Continuity breaches
195−
196−While the Urbit network is in this alpha state, we sometimes have to reboot the whole network. This happens either when major changes need to be shipped or we hit a bug that can't be fixed over the air.
197−
198−Because Urbit networking is stateful we call this a _continuity breach_. Everything has to be restarted from scratch. Your pier will continue to function after we have breached, but it won’t connect to the rest of the Urbit network.
199−
200−When this happens, back up any files you'd like to save, shut down your urbit, and recreate it (as if you were starting for the first time).
201−
202−### Life and rift number
203−
204−You can check your ship's _life_ and _rift_ number by running `+keys our` in
205−dojo. You can inspect another ship's life and rift number by running `+keys
206−~sampel-palnet`. For information on what life and rift are, see [Guide to Breaches](@/docs/tutorials/guide-to-breaches.md).
207−
208−## DNS proxying {#dns-proxying}
209−
210−We have a system that lets you request a domain name for your ship in the form of `ship.arvo.network`, where `ship` is your ship's name minus the `~`. This allows users to access their ships remotely using Landscape, our graphical web interface.
211−
212−Stars and planets follow the same process DNS proxying process, and galaxies have their own requirements. Moons and comets are not supported.
213−
214−### Planets and Stars
215−
216−For a planet or star's DNS proxying request to be made and fulfilled, they must be hosting their ship someplace with a public IP address, and its HTTP server must be listening on port 80.
217−
218−To get `ship.arvo.network` on a planet or star, you must set up DNS routing with its parent ship by starting the `:dns` app.
219−
220−To do so, simply run this command in your ship's Dojo, passing the IP address as an argument, using the .0.0.0.0 (`@if`) syntax. For example:
221−
222−```
223−> -dns-address &dns-address [%if .1.2.3.4]
224−```
225−
226−`:dns`, running locally, will make an HTTP request to that IP address on port 80 to confirm that it is itself available at that IP and port. If that fails, you'll receive a `%bail-early` message in `:chat-cli`; this request will retry a few times. If the self-check is successful, the request is relayed to `~zod`, and you'll receive a message saying, `request for DNS sent to ~zod`. Once `~zod` has acknowledged receipt of the request, your local `:dns` app will send a `:chat-cli` message saying `awaiting response from ~zod`.
227−
228−The request will be picked up shortly, and the `ship.arvo.network` DNS record will be set to the given IP address. Once that's set up, `~zod` will be notified and `~zod` will, in turn, notify your ship. That ship will now try to verify that it can reach itself on `ship.arvo.network` over port 80. If it can't, it'll send a message saying, `unable to access via ship.arvo.network`. If it can, it will configure itself with that domain and say `confirmed access via ship.arvo.network`.
229−
230−Great! You're set up now. Try accessing your `ship.arvo.network` in your browser to use Landscape; we recommend Chrome or Brave.
231−
232−### Galaxies
233−
234−Galaxies are already required to have separate DNS entry at galaxy.urbit.org. There's no automated process for getting that binding, so if you're a galaxy-holder, get in touch with us at support@urbit.org.
235−
236−There is a command for galaxies that will try to re-use their already-necessary Ames DNS entry for HTTPS:
237−
238−```
239−> -dns-auto
240−```
241−
242−This will make HTTP-requests to self-check availability over `galaxy.$AMES-DOMAIN` (currently galaxy.urbit.org), where `galaxy` is the galaxy's name minus the `~`.
243−
244−Otherwise, `-dns-auto` works the same as `:dns|ip` does with stars and planets: if it's available or unavailable, Chat messages, and so on.
245−
246−### More information
247−
248−Configuring a ship's domain causes the `:acme` app to request an HTTPS certificate for that domain from LetsEncrypt. Note that LetsEncrypt also requires that the HTTP server be listening on port 80. If the certificate request fails, `:acme` will send a `:chat-cli` message with an explanation. Once the certificate is successfully retrieved, `:acme` will install it, causing the HTTP servers to restart. A secure server will be started on port 443 (the HTTPS default) if it's available. Otherwise, it will try 8443, and then increment to the next port until it can successfully bind one.
249−
250−The built-in logic for listening on port 80 is similar. Urbit tries to bind port 80; if it cannot, it tries 8080, then increments until it can bind a port. Port 80 is available to unprivileged process on recent version of macOS. Otherwise, the process needs to either be run as root, or be given special permission (CAP\_NET_BIND on Linux).
251−
252−## Messaging {#messaging}
253−
254−Let’s get started using the `:chat-cli` application, also known more simply as _Chat_. It's the simplest way to talk to people using the command line interface.
255−
256−### Quickstart
257−
258−The most common use for `:chat-cli` right now is, of course, communicating in group chats.
259−
260−### Joining a chat
261−
262−In `:chat-cli`, any kind of medium for a message is called a _chat_. There are four "types" of chats, but for now we'll be dealing with the _channel_, a publicly accessible chatroom for general use. We'll discuss the other three kinds in the [chat management](#chat-management) section later on.
263−
264−Join the Urbit Community from Dojo using `:group-store|join ~bitbet-bolbel/urbit-community`. Once you've joined, join the General chat from chat-cli. Use `ctrl-x` to switch from the Dojo prompt to the Chat prompt.
265−
266−Then:
267−
268−```
269−~sampel-palnet:chat-cli/ ;join ~darrux-landes/general
270−```
271−
272−Now that you're in, try post a line to `~darrux-landes/general`:
273−
274−```
275−~sampel-palnet:chat-cli= Hello, world!
276−```
277−
278−You'll see your message printed below messages from others that came before it. You can always type `;chats` in the `chat-cli` prompt to list all the chats you're in:
279−
280−```
281−~sampel-palnet:chat-cli= ;chats
282−~darrux-landes/general
283−```
284−
285−Glyphs will be automatically assigned to channels, but have the option of binding a glyph (single non-alphanumeric character) to the channel you're joining; the syntax is in the form of `;join ~/~dopzod/books +`. The chosen glyph will be the symbol that ends your prompt, and it will be what you use as a shortcut to switch to this channel.
286−
287−```
288−~sampel-palnet:chat-cli= ;+
289−~sampel-palnet:chat-cli+
290−```
291−
292−Use `;leave` to unsubscribe from a channel:
293−
294−```
295−~sampel-palnet:chat-cli= ;leave ~darrux-landes/general
296−```
297−
298−Now, let's create a channel we can invite some friends to:
299−
300−```
301−~sampel-palnet:chat-cli= ;create channel /my-channel
302−```
303−
304−Now you can tell your friends to `;join ~your-urbit/my-channel`.
305−
306−In order to see messages in `:chat-cli` you may need to do the following in Dojo:
307−
308−```
309−:chat-cli %connect
310−```
311−
312−### Hoon
313−
314−You can use Chat to evaluate Hoon code and share the results with everyone in a chat. To do so, preface your Hoon with `#`.
315−
316−```
317−~sampel-palnet:chat-cli= #(add 2 2)
318−```
319−
320−This will print as:
321−
322−```
323−~sampel-palnet# (add 2 2)
324− 4
325−```
326−
327−### URLs
328−
329−To share a URL, send it as its own message, with no content before or after it.
330−
331−```
332−~sampel-palnet:chat-cli= https://urbit.org/
333−```
334−
335−This will print as:
336−
337−```
338−~sampel-palnet/ https://urbit.org/
339−```
340−
341−### Expanding messages
342−
343−In the case of URLs, they may be too long to display on a single message line. For Hoon code, the code or result could be big. In `:chat-cli`, these get shortened when initially printed out. To view the entire contents, you can select the message in various ways.
344−
345−```
346−~sampel-palnet+ some message
347−----------[240]
348−~sampel-palnet+ let's try selecting this message!
349−~sampel-palnet+ another message
350−~sampel-palnet:chat-cli=
351−```
352−
353−In the above example, we can select the middle message by issuing any of the following command:
354−
355−```
356−;240
357−;40
358−;;
359−```
360−
361−`;n` looks for the last message whose sequence number ends in `n`. `;;` simply picks the second-to-last message.
362−
363−Detailed message output will look something like this:
364−
365−```
366−? 240
367− 0v5.g7r7l.n0d7m.mp4bn.gp6vr.sm5lj at ~2019.10.17..22.08.27..8a03
368− ~sampel-palnet
369− to ~dopzod/urbit-help
370−let's try selecting this message!
371−```
372−
373−### Creating and managing chats {#chat-management}
374−
375−As mentioned before, any urbit can host any number of chats. Existing chats can be deleted or modified with various commands. All commands in this section should be sent from the `chat-cli>` prompt.
376−
377−#### Create
378−
379−Syntax: `;create [type] /name +`, where `+` represents an optional glyph.
380−
381−Creates and joins a chat, where `[type]` is any of the following:
382−- `channel`: public chat. Has a blacklist for write control.
383−- `village`: invite-only chat.
384−- `journal`: publicly readable, invite-only for writing.
385−- `mailbox`: publicly writeable, invite-only for reading.
386−
387−Let's create an example mailbox:
388−
389−```
390−~sampel-palnet:chat-cli> ;create mailbox /coolbox ^
391−```
392−
393−#### Delete
394−
395−Syntax: `;delete /name`
396−
397−Deletes a chat.
398−
399−#### Permission management
400−
401−You can permit and ban people from reading and/or writing to the chats you host, using `;invite` and `;banish` command respectively.
402−
403−Syntax: `;invite [rw] /name ~ships`
404−
405−Where `rw` is either `r`, `w`, or `rw`, representing "read" and "write" permissions.
406−And where `~ships` is a comma-seperated list of ships to invite.
407−
408−For example, to grant two people full access to a `village` we created:
409−
410−```
411−~sampel-palnet:chat-cli> ;invite rw /hidden-village ~ravmel-ropdyl, ~rapfyr-diglyt
412−```
413−
414−Similarly, if we later want to revoke the writing permissions for one of them, but still allow them to read new messages, we can run:
415−
416−```
417−~sampel-palnet:chat-cli> ;banish w /hidden-village ~rapfyr-diglyt
418−```
419−
420−#### Chat glyphs
421−
422−Glyphs are found at the end of your prompt, as a quick indicator of where
423−your messages will be sent.
424−
425−Glyphs are assigned by chat hash out of the following list:
426−
427−```
428−! @ # $ % ^ & ( ) - = _ + [ ] { } ; ' \ : " , . < > ?
429−```
430−
431−Alphanumeric characters and `|#/*~` are reserved; all others can be manually assigned.
432−
433−For example, `-` the glyph at the end of the prompt below might indicates that
434−messages sent from this prompt will go to some chat with that glyph:
435−
436−```
437−~sampel-palnet:chat-cli-
438−```
439−
440−To see what chat is bound to a glyph, use the `;what` command followed by the
441−glyph in question, or use `;what` without specifying a glyph to see all of your
442−subscriptions which are bound to glyphs. For example, to see `=`:
443−
444−```
445−~sampel-palnet:chat-cli> ;what =
446−~dopzod/urbit-help
447−```
448−
449−To see all of your glyph bindings:
450−
451−```
452−~sampel-palnet:chat-cli> ;what
453−> ~paldev/numismatic-forum
454−. ~middev/ny-martians
455−= ~dopzod/urbit-help
456−```
457−
458−When the messaging target doesn't have a glyph, we see their name at the end of
459−the prompt instead. Here we're talking into `~dannum-mitryl/homework`:
460−
461−```
462−~sampel-palnet:chat-cli[~dannum-mitryl/homework]
463−```
464−
465−#### Bind
466−
467−Syntax: `;bind [glyph] ~host/chat-name`
468−
469−Assigns the chosen glyph to a chat.
470−
471−For example:
472−
473−```
474−~sampel-palnet:chat-cli> ;bind + ~dopzod/urbit-help
475−```
476−
477−#### Unbind
478−
479−Syntax: `;unbind [glyph] ~host/chat-name`
480−
481−Unassigns the chosen glyph from a chat owned by your ship.
482−
483−For example:
484−
485−```
486−~sampel-palnet:chat-cli> ;unbind + ~dopzod/urbit-help
487−```
488−
489−If you don't specify a chat, all bindings for that glyph are removed.
490−
491−#### Prefixes
492−
493−Received posts are prefixed with a glyph to let you know what the
494−audience is. You can activate an individual post to see the full
495−audience.
496−
497−There are a few special-purpose "glyphs":
498−
499−- `|` - Informational messages
500−- `*` - Posts to a target you don't have a glyph binding for
501−
502−
503−### Configuration
504−
505−#### Set audience
506−
507−`;~ship/chat`
508−
509−Set audience to `~ship/chat`.
510−
511−#### Set audience by glyph
512−
513−Syntax: `;[glyph]`
514−
515−Set audience to the chat previously bound to the chosen glyph.
516−
517−#### Set audience to own chat
518−
519−Syntax: `;/chat`
520−
521−Set audience to a chat on your own ship.
522−
523−### Miscellaneous configuration
524−
525−#### Change timezone
526−
527−Syntax: `;set timezone [+/-][hours]`
528−
529−Adjust the display of timestamps to a specific timezone. Relative to UTC.
530−
531−#### Set width
532−
533−Syntax: `;set width [number]`
534−
535−Set the rendering width of `:chat-cli` to a specific number of characters.
536−(Minimum of 30.)
537−
538−#### Show timestamps
539−
540−Syntax: `;set showtime`
541−
542−Show the timestamp for each message. This is set by default.
543−
544−#### Hide timestamps
545−
546−Syntax: `;unset showtime`
547−
548−Stop showing the timestamp for each message.
549−
550−#### Sound notification on
551−
552−Syntax: `;set notify`
553−
554−Emit a terminal bell sound if your six-syllable ship name is mentioned in
555−a message. This is set by default.
556−
557−#### Sound notification off
558−
559−Syntax `;unset notify`
560−
561−Do not notify when your ship name is mentioned.
562−
563−
564−## S3 {#s3}
565−
566−Amazon S3, which stands for Amazon Simple Storage Service, is a technology that was introduced by Amazon Web Services for cloud storage that has since been extended more broadly into a [standard programming interface](https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services).
567−
568−Our S3 support lets you store credentials for your S3 object storage buckets on your Urbit ship; once you have done so, you will get additional functionality for uploading your own media within Chat and Groups (for avatars).
569−
570−To enable S3 support on your ship you'll need to first set up a bucket, and then add its credentials to Landscape using *either* Landscape or the Dojo.
571−
572−### Bucket Setup
573−
574−If you’re using AWS, it will have to support signature v2, not v4. We've found DigitalOcean's Spaces to work well also. The bucket has to be publicly readable, allow CORS from `*` origins, allow GET and PUT methods, and allow `*` headers. Your provider should have details on setting access permissions and CORS.
575−
576−### Add your credentials: Landscape
577−
578−Navigate to your `https://<your-ship-url>/~profile/settings`, or click your sigil in the upper-right corner of the window. Fill out the **S3 Credentials** and **S3 Buckets** sections and you're all set!
579−
580−### Add your credentials: Dojo
581−
582−Once you have gotten your bucket setup, poke the `s3-store` on your ship with your details. You can do this in Dojo or in web Dojo.
583−
584−```
585−:s3-store|set-endpoint 'endpoint.mys3provider.com'
586−:: AWS endpoint example: s3-us-west-2.amazonaws.com
587−:: Digital Ocean endpoint example: sfo2.digitaloceanspaces.com
588−:s3-store|set-access-key-id 'MYACCESSKEYID'
589−:s3-store|set-secret-access-key 'MYSECRETACCESSKEY'
590−:s3-store|set-current-bucket 'yourbucketname'
591−```
592−
593−Done! If you need to peek at s3-store’s state, you can always run :s3-store +dbug (inside Dojo, not web Dojo, unfortunately). You’ll see the additional functionality appear in Groups and Chat.
594−
595−## Shell {#using-the-shell}
596−
597−The Dojo is our shell; it processes system commands and returns output. It's a
598−good place to quickly experiment with Urbit. On the surface the Dojo is just a
599−Hoon REPL. On the inside, the Dojo is a system for operating on and transforming
600−data in Urbit.
601−
602−### Quickstart
603−
604−You can use the Dojo to run arbitrary Hoon code, as well as non-Hoon system
605−commands.
606−
607−#### Math
608−
609−Evaluate a Hoon expression (whitespace matters):
610−
611−```
612−~your-urbit:dojo> (add 2 2)
613−~your-urbit:dojo> %+ add 2 2
614−```
615−
616−Tall-form Hoon may require multiple lines:
617−
618−```
619−~your-urbit:dojo> %+ add
620−~your-urbit:dojo< 2
621−~your-urbit:dojo< 2
622−```
623−
624−Hoon uses something called [the subject](@/docs/tutorials/hoon/hoon-school/the-subject-and-its-legs.md).
625−The Dojo has its own subject and that's where Hoon's equivalent of variables,
626−called faces, are stored.
627−
628−Use `=var` to save faces to the Dojo subject.
629−
630−```
631−~your-urbit:dojo> =foo (add 2 2)
632−```
633−
634−Note, however, that `=var` is Dojo syntax, not Hoon syntax. You cannot bind a
635−face in a `.hoon` file in this way.
636−
637−#### System commands
638−
639−Use `=dir` to set the current working directory:
640−
641−```
642−~your-urbit:dojo> =dir %/gen
643−```
644−
645−(`%` represents your current directory. For a complete explanation on urbit
646−paths, see the [filesystem section](#filesystem).)
647−
648−Generators (files in `/gen`) are run with `+`:
649−
650−```
651−~your-urbit:dojo> +hello 'world'
652−```
653−
654−Save output to a file in `%clay` with `*`:
655−
656−```
657−~your-urbit:dojo> *some/file/path/hoon 'hello world'
658−```
659−
660−Run system commands from `:hood`, like `reload`, using `|`:
661−
662−```
663−~your-urbit:dojo> |reload %eyre
664−```
665−
666−### Generators
667−
668−Generators are short Hoon scripts, saved as `.hoon` files in the `/gen`
669−directory. Many Dojo commands exist in the form of generators. The syntax for
670−running a generator is `+genname` for a generator saved as `genname.hoon`.
671−
672−#### `+cat`
673−
674−Accepts a path and displays the file. Similar to Unix `cat`.
675−
676−```
677−~your-urbit:dojo> +cat %/gen/curl/hoon
678−```
679−
680−#### `+code`
681−
682−Generates a code that is used to remotely log into your ship. No
683−arguments.
684−
685−```
686−~your-urbit:dojo> +code
687−```
688−
689−You can change your code to a new randomly generated one by entering `|code
690−%reset`. Please note that this will prevent [Bridge](@/docs/glossary/bridge.md)
691−from being able to derive your code in the future.
692−
693−#### `+curl`
694−
695−Retrieves data from a URL. Accepts a `tape`. Similar to Unix `curl`.
696−
697−```
698−~your-urbit:dojo> +curl "http://nyt.com"
699−```
700−
701−#### `+hello`
702−
703−Just prints the argument. Accepts a `@ta`.
704−
705−```
706−~your-urbit:dojo> +hello 'mars'
707−```
708−
709−#### `+ls`
710−
711−Similar to Unix `ls`. Accepts a path.
712−
713−```
714−~your-urbit:dojo> +ls %/gen
715−~your-urbit:dojo> +ls /~talsur-todres/home/2/gen/program
716−```
717−
718−#### `+solid`
719−
720−Compile the current state of the kernel and output a
721−noun. Usually downloaded to a file in unix. No arguments.
722−
723−```
724−~your-urbit:dojo> .urbit/pill +solid
725−```
726−
727−#### `+test`
728−
729−Testrunner. Can test multiple generators at once, conventionally ones
730−in the `/test` folder. Takes a path.
731−
732−```
733−~your-urbit:dojo> +test /lib
734−```
735−
736−#### `+ticket`
737−
738−Generate a ticket for an urbit ship. Takes an urbit name (`@p`).
739−
740−
741−```
742−~your-urbit:dojo> +ticket ~talsur-todres-your-urbit
743−```
744−
745−#### `+tree`
746−
747−Generate a recursive directory listing. Takes a path.
748−
749−```
750−~your-urbit:dojo> +tree %/sys
751−```
752−
753−### Hood
754−
755−The hood is the system daemon. See `gen/hood` and `app/hood`.
756−
757−`|hi` - Sends a direct message. Sort of like Unix `write`. Accepts
758−an urbit name (`@p`) and a string (`tape`, which is text wrapped with double-quotes).
759−
760−```
761−~your-urbit:dojo> |hi ~binzod "you there?"
762−```
763−
764−`|link` / `|unlink` - Link / unlink a remote app. Accepts an
765−Urbit name and an app name.
766−
767−```
768−~your-urbit:dojo> |link ~talsur-todres %octo
769−```
770−
771−`|mass` - Prints the current memory usage of all the kernel modules.
772−No arguments.
773−
774−```
775−~your-urbit:dojo> |mass
776−```
777−
778−`|reload` - Reloads a kernel module (vane) from source. Accepts any
779−number of vane names.
780−
781−```
782−~your-urbit:dojo> |reload %clay %eyre
783−```
784−
785−`|reset` - Reloads `hoon.hoon` and all modules. No arguments.
786−
787−```
788−~your-urbit:dojo> |reset
789−```
790−
791−`|start` - Starts an app. Accepts an app name.
792−
793−```
794−~your-urbit:dojo> |start %curl
795−```
796−
797−---
798−
799−### Dojo manual
800−
801−#### Sources and sinks
802−
803−A Dojo command is either a **source** or a **sink**. A source is just something
804−that can be printed to your console or the result of some computation. A
805−sink is an **effect**: a change to the filesystem, a network message, a
806−change to your environment, or a typed message to an app.
807−
808−Sources can be chained together, but we can only produce one effect per
809−command.
810−
811−#### Sinks
812−
813−#### `=` - Set variable
814−
815−Set any environment variable:
816−
817−```
818−~your-urbit:dojo> =foo 42
819−~your-urbit:dojo> (add 2 foo)
820−
821−44
822−```
823−
824−Make sure to note that `=var` is Dojo syntax, not Hoon syntax. You cannot bind a
825−variable in a `.hoon` file in this way.
826−
827−#### Special variables
828−
829−There are a few special variables that the Dojo maintains.
830−
831−#### `:` - Send to app
832−
833−`:app` goes to a local `app`, `:~ship/app` goes to the `app` on `~ship`.
834−
835−Send a `helm-hi` message to `hood`:
836−
837−```
838−~your-urbit:dojo> :hood &helm-hi 'hi'
839−```
840−
841−Apps usually expect marked data, so `&` is often used here.
842−
843−#### `*` - Save in `%clay`
844−
845−Save a new `.hoon` file in `gen`:
846−
847−```
848−~your-urbit:dojo> *%/gen/foo/hoon '# hello'
849−```
850−
851−The last component of the path is expected to be the mark (or mime
852−type).
853−
854−#### `.` - Export to Unix
855−
856−Export a noun to Unix with `.`:
857−
858−```
859−~your-urbit:dojo> .foo/bar/baz (add 2 2)
860−```
861−
862−Which creates a file at `pier/.urb/put/foo/bar.baz`.
863−
864−This is very often used with `+solid`:
865−
866−```
867−~your-urbit:dojo> .urbit/pill +solid
868−```
869−
870−Which outputs a new `urbit.pill` to `pier/.urb/put/urbit.pill`
871−
872−### Sources
873−
874−#### `_` - Run a function
875−
876−Use `_` to run a gate (or function):
877−
878−Write an arbitrary function and pass data to it:
879−
880−```
881−~your-urbit:dojo> _|=([a=@] (mul a 3)) 3
882−9
883−```
884−
885−Use a function to get the status code from an http request:
886−
887−```
888−~your-urbit:dojo> _|=([p=@ud q=* r=*] p) +http://google.com
889−301
890−```
891−
892−#### `+` `-` - HTTP requests
893−
894−`+http[s]://example.com` - sends a GET request
895−
896−`+http[s]://example.com &json [%s 'hi']` - sends a POST request with the
897−JSON `"hi"` in the body.
898−
899−`-http[s]://example.com &json [%s 'hi']` - sends a PUT request with the
900−JSON `"hi"` in the body.
901−
902−Note that the first of these is a source while the last two are sinks.
903−
904−#### `+` - Generators
905−
906−Generators are simple Hoon scripts loaded from the filesystem. They live
907−in `gen/`.
908−
909−An example of a generator that is built into your urbit is `+code`. It produces
910−the code needed to log into your ship remotely.
911−
912−```
913−~your-urbit:dojo> +code
914−fintyr-haldet-fassev-solhex
915−```
916−
917−### Variables
918−
919−You can use `=` to set an environment variable in Dojo, but there are
920−a few reserved names that have special uses.
921−
922−#### `dir`
923−
924−Current working `%clay` desk and revision. Read / write.
925−
926−**Examples:**
927−
928−```
929−~your-urbit:dojo> =dir %/gen
930−~your-urbit:dojo> +ls %
931−404/hoon docs/ dojo/hoon lib/ listen/hoon md static/udon talk/ testing/udon tree/main/ unmark/ womb/
932−```
933−
934−#### `lib`
935−
936−Current set of libraries (`/lib`) in your environment. Can be set
937−with `/+`. Read / write.
938−
939−**Examples:**
940−
941−```
942−~your-urbit:dojo> /+ number-to-words
943−```
944−Now we can use arms from lib/number-to-words.hoon
945−```
946−~your-urbit:dojo> (to-words:eng-us:number-to-words 123.456)
947−```
948−
949−#### `sur`
950−
951−Current set of structures (`/sur`) in your environment. Can be set
952−with `/-`. Read / write.
953−
954−**Examples:**
955−
956−```
957−~your-urbit:dojo> /- sole
958−```
959−Now we can use arms in sur/sole.hoon.
960−```
961−~your-urbit:dojo> `sole-effect:sole`[%bel ~]
962−```
963−
964−#### `now`
965−
966−The current (128-bit `@da`) time. Read-only.
967−
968−**Example:**
969−
970−```
971−~your-urbit:dojo> now
972−~2016.3.21..21.10.57..429a
973−```
974−
975−#### `our`
976−
977−The current urbit ship. Read-only.
978−
979−**Example:**
980−
981−```
982−~your-urbit:dojo> our
983−~your-urbit
984−```
985−
986−#### `eny`
987−
988−512 bits of entropy. Read-only.
989−
990−**Example:**
991−
992−```
993−~your-urbit:dojo> eny
994−\/0vnt.d474o.gpahj.jcf3o.448fh.2lamb.82ljm.8ol8u.b02vi.mrvvp.b7et2.knb7m.l8he\/
995− 8.8qb9s.drm36.77n9b.a0qst.30g03.l5lb5.nvsbc.v39tn
996−\/
997−```
998−
999−### Troubleshooting
1000−
1001−If you encounter `%dy-edit-busy` while entering commands, it is
1002−because your Dojo is blocked on a timer or an HTTP request. Type backspace
1003−and your Dojo will end the blocked command.
1004−
1005−
1006−## Filesystem {#filesystem}
1007−
1008−Urbit has its own revision-controlled filesystem, Clay. Clay is a typed, global,
1009−referentially transparent namespace. An easy way to think about it is like typed
1010−`git`.
1011−
1012−The most common way to use Clay is to mount a Clay node in a Unix directory. The mounted directory is always at the root of your pier directory.
1013−
1014−### Quickstart
1015−
1016−This quick-start guide will walk you through some common commands. Follow along
1017−using your Dojo. When you get a `>=` message after entering a command, this means
1018−that the command was successful.
1019−
1020−It's important to note that whenever you want to sync changes from your Unix
1021−directory to your ship, you must use the `|commit %desk` command, where `%desk`
1022−is the desk that you'd like to sync to.
1023−
1024−When developing it's a good idea to use a separate desk. Create a `%sandbox`
1025−desk based on the `%home` desk:
1026−
1027−```
1028−~your-urbit:dojo> |merge %sandbox ~your-urbit %home
1029−```
1030−
1031−Running `our` produces your ship-name, meaning that you can run the following
1032−command instead of typing out the entire thing. Useful for comets due to their
1033−very long names.
1034−
1035−```
1036−~your-urbit:dojo> |merge %sandbox our %home
1037−```
1038−
1039−Most of the time we want to use Clay from Unix. Mount the entire contents of
1040−your `sandbox` desk to Unix:
1041−
1042−```
1043−~your-urbit:dojo> |mount /=sandbox=
1044−```
1045−
1046−To explore the filesystem from inside Urbit `+ls` and `+cat` are useful. `+ls`
1047−displays files in the current directory, and `+cat` displays the contents of
1048−a file.
1049−
1050−We can use `%` to mean "current directory." The result of the command below
1051−is just like using `ls` in a Unix terminal.
1052−
1053−```
1054−~your-urbit:dojo> +ls %
1055−```
1056−
1057−Notice how `+cat %` does the same thing. That's because everything in Clay,
1058−including directories, is a file.
1059−
1060−Sync from your friend `~some-ship`'s `%experiment` desk to your
1061−`%sandbox` desk:
1062−
1063−```
1064−~your-urbit:dojo> |sync %sandbox ~some-ship %experiment
1065−```
1066−
1067−If and when your sync is successful, you will receive a message:
1068−
1069−```
1070−activated sync from %experiment on ~some-ship to %sandbox
1071−```
1072−
1073−The ship that you sync from will get their own message indicating that you're
1074−both connected as peers:
1075−
1076−```
1077−; ~your-urbit is your neighbor.
1078−```
1079−
1080−---
1081−
1082−### Clay manual
1083−
1084−#### Paths
1085−
1086−A path in Clay is a list of URL-safe text, restricted to the characters
1087−`[a z]`,`[0 9]`, `.`, `-`, `_`, and `~`. Formally this is a `(list knot)`,
1088−meaning that each segment, delineated by `/`, is of the `knot` ASCII-text type.
1089−In other words, paths are expressed as `/foo/bar/baz`. File extensions are
1090−separated from file names with `/`, not `.`. Extensions are syntactically
1091−identical to subdirectories, except that they must terminate the path.
1092−
1093−Paths begin with a piece of data called a `beak`. A beak is formally a
1094−`(p=ship q=desk r=case)`; it has three components, and might look like
1095−`/~dozbud-namsep/home/11`.
1096−
1097−The first `beak` component is `ship`, which is, as you might guess, the name of
1098−an Urbit ship. The second component is `desk`, which is a workspace meant to
1099−contain other directories; the default desk is `%home`. The third component is
1100−`case`, which represents version information in various ways: date and time;
1101−a version sequence, which is a value incremented by one whenever a file on the
1102−given `desk` is modified; or an arbitrary plaintext label.
1103−
1104−You can find what your `beak` is at any given moment by
1105−typing `%` in the Dojo and looking at the first three results.
1106−
1107−We use `beak`s because, unlike the current internet, the Urbit network uses a
1108−global namespace. That means that a file named `example.hoon` in the `/gen`
1109−directory on the `%home` desk of your ship `~lodleb-ritrul` would have a
1110−universal address to anyone else on the network:
1111−`/~lodleb-ritrul/home/186/gen/example/hoon`. That, of
1112−course, doesn't mean that everyone on the network has privileges to access that
1113−path.
1114−
1115−The structure that combines a `beak` with further path information is called a
1116−`beam`.
1117−
1118−#### Relative paths
1119−
1120−The `%` command, which we gestured at in the above section, represents the
1121−**relative path**, which is the path where you are currently working. If your
1122−working directory is just your home desk, indicated by the
1123−prompt `~your-planet:dojo>`, then running the command below will print your
1124−working directory's `beam` information: your `beak`, and a `~` that represents
1125−the empty list since no path is present.
1126−
1127−```
1128−~your-urbit:dojo> %
1129−```
1130−
1131−`%`s can be stacked to indicate one level further up in the hierarchy for each
1132−additional `%`. Try the following command:
1133−
1134−```
1135−~your-planet:dojo> %%%
1136−```
1137−
1138−You'll probably notice that it only has your ship name and the empty list. The
1139−two additional `%`s abandoned the `case` and the `desk` information by moving
1140−up twice the hierarchy.
1141−
1142−There are no local relative paths. `/foo/bar` must be written as
1143−`%/foo/bar`.
1144−
1145−#### Substitution
1146−
1147−You don't need to write out the explicit path every time you want to reference
1148−somewhere outside of your working directory. You can substitute `=` for the
1149−segments of a path.
1150−
1151−Recall that a full address in the the Urbit namespace is a `beam`: the
1152−`/ship/desk/case/path`. If you've switched to another desk before, you're
1153−already familiar with substitution syntax:
1154−
1155−```
1156−~your-urbit:dojo> =dir /=sandbox=
1157−```
1158−
1159−The above command uses substitution to use your current `ship` and
1160−`case`; only the `desk` argument, which is located between the other two, is
1161−given something new. Without substitution, you would need to write:
1162−
1163−```
1164−~your-urbit:dojo> =dir /~your-urbit/sandbox/85
1165−```
1166−
1167−Substitutions work the same way in `beak`s (the `ship/desk/case` part) and
1168−paths. For example, if you are in the `/gen` directory, you can reference a file
1169−in the `/app` directory like below. (`+cat` displays the contents of a file).
1170−
1171−```
1172−~your-urbit:dojo> =dir %/gen
1173−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen> +cat /===/app/curl/hoon
1174−```
1175−
1176−Note what was substituted out, and note that we don't need to separate `=` with
1177−`/`.
1178−
1179−If we changed our working directory to something called `/gen/gmail`, we could
1180−access a file called
1181−
1182−```
1183−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen> =dir %/gmail
1184−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen/gmail> +cat /===/app/=/split/hoon
1185−```
1186−
1187−Because both paths share a directory named `/gmail` at the same position in the
1188−address hierarchy – which, if you recall, is just a `list` – the above command
1189−works!
1190−
1191−We can do the same thing between desks. If `%sandbox` has been merged with
1192−`%home`, the following command will produce the same results as the above
1193−command.
1194−
1195−```
1196−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen/gmail> +cat /=sandbox=/app/=/split/hoon
1197−```
1198−
1199−Most commonly this is used to avoid having to know the current revision
1200−number in the `dojo`: `/~lodleb-ritrul/home/~2018.10.2..00.35.44..d7e8/gen/example/hoon`
1201−
1202−#### Changing directories
1203−
1204−Change the working directory with `=dir`. It's our equivalent of the Unix `cd`.
1205−
1206−For example, the syntax to navigate to `/home/gen/ask` is:
1207−
1208−```
1209−~your-urbit:dojo> =dir /=home=/gen/ask
1210−```
1211−
1212−This command will turn your prompt into something like this:
1213−
1214−```
1215−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen/ask>
1216−```
1217−
1218−Using `=dir` without anything else uses the null path, which returns you to
1219−your home desk.
1220−
1221−```
1222−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen/ask> =dir
1223−```
1224−
1225−Your dojo prompt will turn back into `~your-urbit:dojo>`.
1226−
1227−To go up levels in the path hierarchy, recall the relative path expression
1228−`%`. Stacking them represents another level higher in the hierarchy than
1229−the current working directory for each `%` beyond the initial. The command below
1230−brings you one level up:
1231−
1232−```
1233−~your-urbit:dojo> =dir %/gen
1234−~your-urbit:dojo/=/=/~2018.10.2..00.35.44..d7e8/gen> =dir %%
1235−```
1236−
1237−### Revision-control
1238−
1239−#### Mount
1240−
1241−Syntax: `|mount /clay/path [Unix-name]`
1242−
1243−Mount the `clay-path` at the Unix mount point `Unix-name`.
1244−
1245−**Examples:**
1246−
1247−```
1248−|mount %/gen generators
1249−```
1250−
1251−Mounts `%/gen` to `/generators` inside your pier directory.
1252−
1253−#### Unmount
1254−
1255−```
1256−|unmount [clay-path || Unix-name]
1257−```
1258−
1259−Unmount the path or name from Unix.
1260−
1261−**Examples:**
1262−
1263−```
1264−|unmount %/gen
1265−```
1266−
1267−Unmounts the Clay path `%/gen` from whatever name it was mounted as.
1268−
1269−```
1270−|unmount %generators
1271−```
1272−
1273−Unmounts the Unix path `/generators`.
1274−
1275−#### Merge
1276−
1277−```
1278−|merge desk beak[, =gem strategy]
1279−```
1280−
1281−Merges a `beak` into a `desk` using an optional merge `strategy`.
1282−
1283−A `beak` is a ship-desk-case triple, encoded as a
1284−path(`/~dozbud/home/2`)
1285−
1286−**Examples:**
1287−
1288−```
1289−|merge %home-work /=home=, =gem %fine
1290−```
1291−
1292−Merge `/=home=` into `%home-work` using merge strategy `%fine`.
1293−
1294−```
1295−|merge %examples ~wacbex-ribmex %examples
1296−```
1297−
1298−Merge the `%examples` desk from `~waxbex-ribmex`
1299−
1300−#### Sync
1301−
1302−```
1303−|sync desk plot [plot-desk]
1304−```
1305−
1306−Subscribe to continuous updates from remote `plot` on local `desk`.
1307−`plot-desk` can specify the remote `desk` name. When omitted it defaults
1308−to being the same as `desk`. Non-comet urbits have
1309−`|sync %home ~parent %kids` automatically set up (where `~parent` is the
1310−planet that issued a moon, the star that issued a planet, or the galaxy
1311−that issued a star).
1312−
1313−**Examples:**
1314−
1315−```
1316−|sync %home-local ~dozbud %home
1317−
1318−|sync %home ~doznec
1319−```
1320−
1321−#### Unsync
1322−
1323−```
1324−|unsync desk plot [plot-desk]
1325−```
1326−
1327−Unsubscribe from updates from remote `plot` on local `desk` with
1328−optional `plot-desk`. Arguments must match original `|sync` command.
1329−
1330−Example:
1331−
1332−```
1333−|unsync %home-local ~dozbud %home
1334−```
1335−
1336−#### Label
1337−
1338−```
1339−|label desk name
1340−```
1341−
1342−Label the current version of `desk` `name`.
1343−
1344−Example:
1345−
1346−```
1347−|label %home release
1348−```
1349−
1350−### Merge strategies
1351−
1352−`%init` - used if it's the first commit to a desk. Also can be used to
1353−"reinitialize" a desk – revision numbers keep going up, but the new
1354−revision isn't necessarily a descendent of the previously numbered
1355−version, allowing merges to be rerun.
1356−
1357−`%this` - keep what's in Bob's desk, but join the ancestry.
1358−
1359−`%that` - take what's in Alice's desk, but join the ancestry. This is
1360−the reverse of `%this`. This is different from `%init` because the new
1361−commit has both sides in its ancestry.
1362−
1363−`%fine` - "fast-forward" merge. This succeeds if and only if one head is in the
1364−ancestry of the other.
1365−
1366−`%meet`, `%mate`, and `%meld` - find the most recent common ancestor to
1367−use as our merge base.
1368−
1369−A `%meet` merge only succeeds if the changes from the merge base to
1370−Alice's head (hereafter, "Alice's changes") are in different files than
1371−Bob's changes. In this case, the parents are both Alice's and Bob's
1372−heads, and the data is the merge base plus Alice's changed files plus
1373−Bob's changed files.
1374−
1375−A `%mate` merge attempts to merge changes to the same file when both
1376−Alice and Bob change it. If the merge is clean, we use it; otherwise, we
1377−fail. A merge between different types of changes – for example,
1378−deleting a file vs changing it – is always a conflict. If we succeed,
1379−the parents are both Alice's and Bob's heads, and the data is the merge
1380−base plus Alice's changed files plus Bob's changed files plus the merged
1381−files.
1382−
1383−A `%meld` merge will succeed even if there are conflicts. If there are
1384−conflicts in a file, then we use the merge base's version of that file,
1385−and we produce a set of files with conflicts. The parents are both
1386−Alice's and Bob's heads, and the data is the merge base plus Alice's
1387−changed files plus Bob's changed files plus the successfully merged
1388−files plus the merge base's version of the conflicting files.
1389−
1390−`%auto` - meta-strategy. Check to see if Bob's desk exists, and if it
1391−doesn't we use an `%init` merge. Otherwise, we progressively try
1392−`%fine`, `%meet`, and `%mate` until one succeeds. If none succeed, we
1393−merge Bob's desk into a scratch desk. Then, we merge Alice's desk into
1394−the scratch desk with the `%meld` option to force the merge. Finally, we
1395−annotate any conflicts, if we know how.
1396−
1397−### Manipulation
1398−
1399−#### `+cat`
1400−
1401−Syntax: `+cat path [path ...]`
1402−
1403−Similar to Unix `cat`. `+cat` takes one or more `path`s, and prints their
1404−contents. If that `path` is a file, the contents of the file is printed. If the
1405−`path` terminates in a directory, the list of names at that path is produced.
1406−
1407−#### `+ls`
1408−
1409−Syntax: `+ls path`
1410−
1411−Similar to Unix `ls`. `+ls` takes a single `path`.
1412−
1413−Produces a list of names at the `path`.
1414−
1415−```
1416−~your-urbit:dojo> +cat %/our/home/gen/curl/hoon
1417−```
1418−
1419−#### `|rm`
1420−
1421−Syntax: `|rm path`
1422−
1423−Remove the data at `path`. `Path` must be a path to the actual node, not a
1424−'directory'.
1425−
1426−#### `|cp`
1427−
1428−Syntax: `|cp to from`
1429−
1430−Copy the file at `from` into the path `to`.
1431−
1432−#### `|mv`
1433−
1434−Syntax: `|mv to from`
1435−
1436−Move the file at `from` into the path `to`.
1437−
1438−In Clay, `|mv` is just a shorthand for `|cp` then `|rm`. The `|rm`
1439−doesn't happen unless the `|cp` succeeds.
content/using/os/_index.mdnew file+36
@@ -0,0 +1,36 @@
1++++
2+title = "Urbit OS"
3+sort_by = "weight"
4+description = "How to use Urbit OS"
5+template = "sections/docs/chapters.html"
6+weight = 10
7++++
8+
9+This section describes how to interact with your running Urbit ship: this
10+includes working with the filesystem, command line (`dojo`), resolving common
11+issues, and more.
12+
13+### [Getting Started](@/using/os/getting-started.md)
14+
15+An overview of common commands and useful general knowledge for operating your
16+ship.
17+
18+### [Messaging](@/using/os/messaging.md)
19+
20+Using chat from its command-line interface.
21+
22+### [Configuring S3 Storage](@/using/os/s3.md)
23+
24+How to set up S3 storage so you can share files in Landscape.
25+
26+### [Shell](@/using/os/shell.md)
27+
28+A comprehensive overview of `dojo` commands.
29+
30+### [Star and Galaxy Operations](@/using/os/stars-and-galaxies.md)
31+
32+How to run an infrastructure node.
33+
34+### [Ship Troubleshooting](@/using/os/ship-troubleshooting.md)
35+
36+How to resolve common problems.
content/using/os/filesystem.mdnew file+397
@@ -0,0 +1,397 @@
1++++
2+title = "Filesystem"
3+template = "doc.html"
4+weight = 3
5++++
6+
7+Urbit has its own revision-controlled filesystem, Clay. Clay is a typed, global,
8+referentially transparent namespace. An easy way to think about it is like typed
9+`git`.
10+
11+The most common way to use Clay is to mount a Clay node in a Unix directory. The mounted directory is always at the root of your pier directory.
12+
13+For more information on Clay, see the [Overview](@/docs/arvo/clay/clay.md), and
14+additional usage information at [Using Clay](@/docs/arvo/clay/using.md).
15+
16+### Quickstart
17+
18+This quick-start guide will walk you through some common commands. Follow along
19+using your Dojo. When you get a `>=` message after entering a command, this means
20+that the command was successful.
21+
22+A [`desk`](@/docs/glossary/desk.md) is something like an independently
23+revision-controlled branch of your urbit's file-system. Your urbit's system
24+files live in the `%home` `desk`.
25+
26+It's important to note that whenever you want to sync changes from your Unix
27+directory to your ship, you must use the `|commit %desk` command, where `%desk`
28+is the `desk` that you'd like to sync to.
29+
30+When developing it's a good idea to use a separate `desk`. Create a `%sandbox`
31+`desk` based on the `%home` `desk`:
32+
33+```
34+~zod:dojo> |merge %sandbox ~zod %home
35+```
36+
37+Running `our` produces your ship-name, meaning that you can run the following
38+command instead of typing out the entire thing. This is especially useful for
39+comets due to their very long names.
40+
41+```
42+~zod:dojo> |merge %sandbox our %home
43+```
44+
45+Most of the time we want to use Clay from Unix. Mount the entire contents of
46+your `sandbox` desk to Unix:
47+
48+```
49+~zod:dojo> |mount /=sandbox=
50+```
51+
52+To explore the filesystem from inside Urbit `+ls` and `+cat` are useful. `+ls`
53+displays files in the current directory, and `+cat` displays the contents of
54+a file.
55+
56+We use `%` to mean "current directory." The result of the command below
57+is just like using `ls` in a Unix terminal.
58+
59+```
60+~zod:dojo> +ls %
61+```
62+
63+Notice how `+cat %` does the same thing. That's because everything in Clay,
64+including directories, is a file.
65+
66+Sync from your friend `~bus`'s `%experiment` desk to your `%sandbox` desk:
67+
68+```
69+~zod:dojo> |sync %sandbox ~bus %experiment
70+```
71+
72+If and when your sync is successful, you will receive a message:
73+
74+```
75+kiln: sync succeeded from %experiment on ~bus to %sandbox
76+```
77+
78+The ship that you sync from will get their own message indicating that you're
79+both connected as peers:
80+
81+```
82+; ~zod is your neighbor.
83+```
84+
85+---
86+
87+### Clay manual
88+
89+The following constitutes an explanation of handy commands that most Urbit
90+pilots will want to know at some point. Reading this section will get you to the
91+point that you can navigate the file system, sync with Unix, merge your desk,
92+and other basic tasks familiar to novice users of the Unix terminal.
93+
94+#### Paths
95+
96+A path in Clay is a list of URL-safe text, restricted to the characters `[a
97+z]`,`[0 9]`, `.`, `-`, `_`, and `~`. This path is a list of strings each
98+prepended by `/`. In other words, paths are expressed as `/foo/bar/baz`. File
99+extensions are separated from file names with `/`, not `.`. Extensions are
100+syntactically identical to subdirectories, except that they must terminate the
101+path.
102+
103+Paths begin with three strings indicating the ship, desk, and revision, and
104+might look like `/~dozbud-namsep/home/11`.
105+
106+The first component is `ship`, which is, as you might guess, the name of
107+an Urbit ship. The second component is `desk`, which is a workspace meant to
108+contain other directories; the default `desk` is `%home`. The third component is
109+the revision, which represents version information in various ways: date and time;
110+a version sequence, which is a value incremented by one whenever a file on the
111+given `desk` is modified; or an arbitrary plaintext label.
112+
113+You can find what your current ship, desk, and revision is at any given moment by
114+typing `%` in the Dojo and looking at the first three results. This will display
115+as a cell rather than a path, like
116+```
117+[~.~zod ~.home ~.~2021.3.19..16.11.20..0c60]
118+```
119+Here we see that the revision consists of the date, time, and a short hash.
120+
121+We use this format because, unlike the current internet, the Urbit network uses a
122+global namespace. That means that a file named `example.hoon` in the `/gen`
123+directory on the `%home` desk of your ship `~lodleb-ritrul` would have a
124+universal address to anyone else on the network:
125+`/~lodleb-ritrul/home/186/gen/example/hoon`. That, of
126+course, doesn't mean that everyone on the network has privileges to access that
127+path. But given the revision-controlled and immutable nature of Urbit, this
128+means that if the file requested is available, it will always be the same. This
129+means that if an Urbit is serving a webpage, that exact version will always be
130+retrievable (assuming you have access to it).
131+
132+
133+#### Relative paths
134+
135+The `%` command, which we gestured at in the above section, represents the
136+**relative path**, which is the path where you are currently working.
137+
138+`%`s can be stacked to indicate one level further up in the hierarchy for each
139+additional `%`. Try the following command:
140+
141+```
142+~zod:dojo> %%%
143+```
144+
145+You'll notice that it only has your ship name and the empty list. The
146+two additional `%`s abandoned the revision and the `desk` information by moving
147+up twice the hierarchy.
148+
149+There are no local relative paths. `/foo/bar` must be written as
150+`%/foo/bar`.
151+
152+#### Substitution
153+
154+You don't need to write out the explicit path every time you want to reference
155+somewhere outside of your working directory. You can substitute `=` for the
156+segments of a path.
157+
158+Recall that a full address in the the Urbit namespace is of the form
159+`/ship/desk/case/path`. To switch to the `%sandbox` `desk`, you would enter
160+
161+```
162+~sampel-palnet:dojo> =dir /=sandbox=
163+```
164+
165+`=dir` is used to change the working directory - we will see more on it
166+[below](#changing-directories.)
167+
168+The above command uses substitution to use your current `ship` and
169+revision; only the `desk` argument, which is located between the other two, is
170+given something new. Without substitution, you would need to write:
171+
172+```
173+~sampel-palnet:dojo> =dir /~sampel-palnet/sandbox/85
174+```
175+
176+Substitutions work the same way in the `ship/desk/case` and
177+paths. For example, if you are in the `/gen` directory, you can reference a file
178+in the `/app` directory like below. (`+cat` displays the contents of a file).
179+
180+```
181+~sampel-palnet:dojo> =dir %/gen
182+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen> +cat /===/app/curl/hoon
183+```
184+
185+Note what was substituted out, and note that we don't need to separate `=` with
186+`/`.
187+
188+If we changed our working directory to something called `/gen/gmail`, we could
189+access a file called
190+
191+```
192+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen> =dir %/gmail
193+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen/gmail> +cat /===/app/=/split/hoon
194+```
195+
196+Because both paths share a directory named `/gmail` at the same position in the
197+address hierarchy – which, if you recall, is just a `list` – the above command
198+works!
199+
200+We can do the same thing between desks. If `%sandbox` has been merged with
201+`%home`, the following command will produce the same results as the above
202+command.
203+
204+```
205+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen/gmail> +cat /=sandbox=/app/=/split/hoon
206+```
207+
208+Most commonly this is used to avoid having to know the current revision
209+number in the `dojo`: `/~lodleb-ritrul/home/~2021.3.19..16.11.20..0c60/gen/example/hoon`
210+
211+#### Changing directories
212+
213+Change the working directory with `=dir`. It's our equivalent of the Unix `cd`.
214+
215+For example, the syntax to navigate to `/home/gen/ask` is:
216+
217+```
218+~sampel-palnet:dojo> =dir /=home=/gen/ask
219+```
220+
221+This command will turn your prompt into something like this:
222+
223+```
224+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen/ask>
225+```
226+
227+Using `=dir` without anything else uses the null path, which returns you to
228+your home desk.
229+
230+```
231+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen/ask> =dir
232+```
233+
234+Your dojo prompt will turn back into `~sampel-palnet:dojo>`.
235+
236+To go up levels in the path hierarchy, recall the relative path expression
237+`%`. Stacking them represents another level higher in the hierarchy than
238+the current working directory for each `%` beyond the initial. The command below
239+brings you one level up:
240+
241+```
242+~sampel-palnet:dojo> =dir %/gen
243+~sampel-palnet:dojo/=/=/~2021.3.19..16.11.20..0c60/gen> =dir %%
244+```
245+
246+### Revision-control
247+
248+#### Mount
249+
250+Syntax: `|mount %/clay/path %mount-point`
251+
252+Mount the `/clay/path` at the Unix mount point `mount-point` with your pier as
253+root directory.
254+
255+**Examples:**
256+
257+```
258+|mount %/gen %generators
259+```
260+
261+Mounts `%/gen` to `/generators` inside your pier directory.
262+
263+#### Unmount
264+
265+```
266+|unmount [clay-path || Unix-name]
267+```
268+
269+Unmount the path or name from Unix.
270+
271+**Examples:**
272+
273+```
274+|unmount %/gen
275+```
276+
277+Unmounts the Clay path `%/gen` from whatever name it was mounted as.
278+
279+```
280+|unmount %generators
281+```
282+
283+Unmounts the Unix path `/generators`.
284+
285+#### Merge
286+
287+```
288+|merge %target-desk ~source-ship %source-desk
289+```
290+
291+Merges a source `desk` into a target `desk`.
292+
293+This can optionally include a [merge
294+strategy](@/docs/arvo/clay/using.md#strategies):
295+
296+```
297+|merge %target-desk ~source-ship %source-desk, =gem %strategy
298+```
299+
300+You may also merge a Clay path on your own ship to a `desk`, along with an
301+optional strategy.
302+
303+```
304+|merge %target-get %/clay/path, =gem %strategy
305+```
306+
307+**Examples:**
308+
309+```
310+|merge %examples ~wacbex-ribmex %examples
311+```
312+
313+Merge the `%examples` `desk` from `~waxbex-ribmex`
314+
315+```
316+|merge %home-work /=home=, =gem %fine
317+```
318+
319+Merge `/=home=` into `%home-work` using merge strategy `%fine`.
320+
321+
322+#### Sync
323+
324+```
325+|sync %target-desk ~source-ship %target-desk
326+```
327+
328+Subscribe to continuous updates from remote `desk` on local `desk`. Non-comet
329+urbits have `|sync %home ~sponsor %kids` automatically set up (where `~sponsor`
330+is the planet that issued a moon, the star that issued a planet, or the galaxy
331+that issued a star).
332+
333+**Examples:**
334+
335+```
336+|sync %home-local ~dozbud %home
337+```
338+
339+#### Unsync
340+
341+```
342+|unsync %target-desk ~source-ship %source-desk
343+```
344+
345+Unsubscribe from updates from remote `desk` on local `desk`. Arguments must
346+match original `|sync` command.
347+
348+Example:
349+
350+```
351+|unsync %home-local ~dozbud %home
352+```
353+
354+
355+### Manipulation
356+
357+#### `+cat`
358+
359+Syntax: `+cat path [path ...]`
360+
361+Similar to Unix `cat`. `+cat` takes one or more `path`s, and prints their
362+contents. If that `path` is a file, the contents of the file is printed. If the
363+`path` terminates in a directory, the list of names at that path is produced.
364+
365+#### `+ls`
366+
367+Syntax: `+ls path`
368+
369+Similar to Unix `ls`. `+ls` takes a single `path`.
370+
371+Produces a list of names at the `path`.
372+
373+```
374+~sampel-palnet:dojo> +cat %/our/home/gen/curl/hoon
375+```
376+
377+#### `|rm`
378+
379+Syntax: `|rm path`
380+
381+Remove the data at `path`. `Path` must be a path to the actual node, not a
382+'directory'.
383+
384+#### `|cp`
385+
386+Syntax: `|cp to from`
387+
388+Copy the file at `from` into the path `to`.
389+
390+#### `|mv`
391+
392+Syntax: `|mv to from`
393+
394+Move the file at `from` into the path `to`.
395+
396+In Clay, `|mv` is just a shorthand for `|cp` then `|rm`. The `|rm`
397+doesn't happen unless the `|cp` succeeds.
content/using/os/getting-started.mdnew file+337
@@ -0,0 +1,337 @@
1++++
2+title = "Getting Started"
3+description = "How to operate your ship, including using your ship's filesystem and messaging applications, starting a moon, or requesting a DNS proxy."
4+template = "doc.html"
5+weight = 1
6+aliases = ["docs/using/messaging/", "docs/using/admin/"]
7+[extra]
8+hidetitle = "true"
9++++
10+
11+Your urbit (also called your _ship_) is a persistent Unix process that you
12+mainly control from its console, called the `dojo`.
13+
14+### Shutdown
15+
16+You can turn your urbit off with `Ctrl-d` from the Chat or Dojo prompts.
17+
18+You can force-quit your urbit with `Ctrl-z` from anywhere.
19+
20+### Restart
21+
22+To restart your urbit simply pass the name of your pier:
23+
24+```sh
25+$ ./urbit some-planet
26+```
27+
28+or
29+
30+```sh
31+$ ./urbit comet
32+```
33+
34+### Logging
35+
36+To log an urbit's command line output to a file, use `script`:
37+
38+```sh
39+$ script urbit.log ./urbit your-urbit
40+```
41+
42+### Moving your pier
43+
44+Piers are designed to be portable, but it _must_ be done while the urbit
45+is not running. Urbit networking is stateful, so you can't run two copies
46+of the same urbit in two places.
47+
48+To move a pier, simply move the contents of the directory it lives in.
49+To keep these files as small as possible we usually use the `--sparse`
50+option in `tar`. With a pier `your-urbit/`, something like this should work:
51+
52+```sh
53+tar -Scvzf ~/your-urbit.tar.gz ~/your-urbit/
54+scp your-old-server:~/your-urbit.tar.gz your-new-server:~
55+```
56+
57+Then to unzip it, on your other Unix server, run:
58+
59+```sh
60+tar xfvz your-urbit.tar.gz
61+```
62+
63+Delete the tar file, and, after installing Urbit on your new server, start your urbit back up with:
64+
65+```sh
66+./urbit your-urbit
67+```
68+
69+### Hardware requirements
70+
71+Urbit can run on any x86 computer (unofficial, unsupported [ARM binaries](https://botter-nidnul.github.io/AArch64_Urbit_Static_Binaries.html) are also available), ideally with at least 2GB of RAM.
72+
73+Urbit maintains a persistent log of the history of your ship. Eventually this log will be automatically trimmed when necessary, but for now it only increases in size. An actively used planet will consume 5-50 GB of storage space per year of operation.
74+
75+### Console
76+
77+Your Urbit terminal is separated into two parts: the prompt (the bottom line) and the record (everything above that). The record is shared; all the output from all the apps in your command set appears in it. The prompt is multiplexed.
78+
79+In the CLI, Urbit apps can process your input before you hit return. To see this in action try entering `)` as the first character at the Dojo prompt. Since there is no Dojo command or Hoon expression that starts with ')', the Dojo rejects it.
80+
81+`Ctrl-x` - Switches the prompt between running console apps
82+
83+`Ctrl-c` - Crash current event. Processed at the Unix layer and prints a stack
84+trace.
85+
86+`Ctrl-d` - From Chat or Dojo, stops your Urbit process.
87+
88+`Ctrl-z` - Stops the Urbit process from _anywhere_.
89+
90+`↑` / `↓` - History navigation
91+
92+The following emacs-style key bindings are available:
93+
94+```
95+Ctrl-a Cursor to beginning of the line (Home)
96+Ctrl-b Cursor one character backward (left-arrow)
97+Ctrl-e Cursor to the end of the line (End)
98+Ctrl-f Cursor one character forward (right-arrow)
99+Ctrl-g Beep; cancel reverse-search
100+Ctrl-k Kill to end of line
101+Ctrl-l Clear the screen
102+Ctrl-n Next line in history (down-arrow)
103+Ctrl-p Previous line in history (up-arrow)
104+Ctrl-r Reverse-search
105+Ctrl-t Transpose characters
106+Ctrl-u Kill to beginning of line
107+Ctrl-y Yank from kill buffer
108+```
109+
110+### Updates
111+
112+By default, you will automatically receive updates ([OTAs](@/docs/glossary/ota-updates.md)) from your sponsor. To check your OTA source, run `|ota` in the [dojo](@/docs/glossary/dojo.md).
113+
114+If for some reason (for example, if your sponsor is out of date), you can switch OTA sources by running `|ota ~otasrc %kids` in the dojo, where `~otasrc` is the ship from which you want to receive updates. It is a good idea to contact the source ship and ask permission to sync from them.
115+
116+If OTAs are not succeeding, or if you are on an version of Urbit before the `|ota` command was introduced, you can run `|merge %home (sein:title our now our) %kids, =gem %take-that`. **Note:** This will wipe out any custom changes to the base distribution.
117+
118+#### Additional OTA Troubleshooting
119+Please check the Support Wiki for additional OTA troubleshooting, such as:
120+[OTA 1.0.71 failed](https://github.com/urbit/support/wiki/OTA-1.0.71-failed),
121+[Missing OTA](https://github.com/urbit/support/wiki/Missing-OTA),
122+[Stuck flow preventing planets from receiving
123+OTAs](https://github.com/urbit/support/wiki/Stuck-flow-preventing-planets-from-receiving-OTAs),
124+and [No content shows in Links page after OTA](https://github.com/urbit/support/wiki/No-content-shows-in-Links-page-after-OTA).
125+
126+### Landscape
127+
128+On startup Urbit tries to bind to `localhost:80`. If you're already running something on port `80` -- such as any other HTTP server, or another urbit -- you'll find the urbit that you just started on `8080`, `8081`, and so on. For planets only, we also proxy web domains through Urbit's own servers. Any planet `~your-urbit` is also at `your-urbit.arvo.network`, but only after you [set up DNS](#dns-proxying).
129+
130+Once running, you can sign into Landscape, your ship’s web interface, from `http://localhost` or `https://your-urbit.arvo.network`. Since our HTTPS isn't audited / battle tested, we just call it "secure" HTTPS. You can find that on `8443`. Or `8444` (and so on) if you're already running something on `8443`.
131+
132+### Moons {#moons}
133+
134+Planets can spawn moons, which are meant for connected devices: phones, smart TVs, digital thermostats. The basic idea is that your planet runs permanently in a data center somewhere, while moons run on all your devices. Each planet can issue ~4 billion (`2^32`) moons.
135+
136+To generate a random moon from your planet, run:
137+
138+```
139+~sampel-palnet:dojo> |moon
140+moon: ~faswep-navred-sampel-palnet
141+\/0w5cT5t.wCO6i.~e1xg.Oz0qb.QNO6I.3Kt2T.h9M9F.U3vU~.X3Qu0.gtb19.IYTkY.80kWZ.SI\/
142+ EUE.DXa8i.TiDof.o3-1C.RHLKS.k81M0.ecz5o.ic0Bg.600g1
143+\/ \/
144+```
145+
146+You must manually edit the output of `|moon` to get the correct format for the `<key>`:
147+
148+- strip out the `\/`
149+
150+- combine into one line, omitting spaces
151+
152+`<key>` would be `0w5cT5t.wCO6i.~e1xg.Oz0qb.QNO6I.3Kt2T.h9M9F.U3vU~.X3Qu0.gtb19.IYTkY.80kWZ.SIEUE.DXa8i.TiDof.o3-1C.RHLKS.k81M0.ecz5o.ic0Bg.600g1`
153+in this example.
154+
155+Put `<key>` in a file and that file becomes `<keyfile>`.
156+
157+You can use the resulting output in the same installation flow from the [Installing Urbit](@/getting-started.md) guide, following the same scheme as for booting a planet. That scheme is:
158+
159+```sh
160+$ ./urbit -w <moonname> -G <key> -c <piername>
161+```
162+
163+or
164+
165+```sh
166+$ ./urbit -w <moonname> -k <keyfile> -c <piername>
167+```
168+
169+The `-c <piername>` argument is not required, but it is recommended; otherwise,
170+the resulting directory is a rather unwieldy moon name.
171+
172+Here's how an example moon might be booted:
173+
174+```sh
175+$ ./urbit -w faswep-navred-sampel-palnet -G <key> -c mymoon
176+```
177+
178+or
179+
180+```sh
181+$ ./urbit -w faswep-navred-sampel-palnet -k <keyfile> -c mymoon
182+```
183+
184+Moons are automatically synced to their parent `%kids` desk, and can control applications on their parent planet using `|link`.
185+
186+To breach a moon -- that is, to reset its presence on the network so that it's treated as a freshly spawned ship by others -- run from the parent ship:
187+
188+```
189+|moon-breach ~faswep-navred-sampel-palnet
190+```
191+
192+To cycle the keys of a moon without breaching, run:
193+
194+```
195+|moon-cycle-keys ~sampel-sipnym-wicdev-wisryt
196+```
197+
198+
199+### Escaping A Sponsor {#escape}
200+
201+To use the network as a planet or star, you must be sponsored by an active star
202+or galaxy, respectively. If your sponsor isn't suiting your needs, you can
203+escape to a different one. This can be done with
204+[Bridge](https://bridge.urbit.org/) following the instructions
205+[here](@/using/id/using-bridge.md#escaping-your-sponsor).
206+
207+### Continuity breaches
208+
209+While the Urbit network is in this alpha state, we sometimes have to reboot the whole network. This happens either when major changes need to be shipped or we hit a bug that can't be fixed over the air.
210+
211+Because Urbit networking is stateful we call this a _continuity breach_. Everything has to be restarted from scratch. Your pier will continue to function after we have breached, but it won’t connect to the rest of the Urbit network.
212+
213+When this happens, back up any files you'd like to save, shut down your urbit, and recreate it (as if you were starting for the first time).
214+
215+### Life and rift number
216+
217+You can check your ship's _life_ and _rift_ number by running `+keys our` in
218+dojo. You can inspect another ship's life and rift number by running `+keys
219+~sampel-palnet`. For information on what life and rift are, see [Guide to Breaches](@/using/id/guide-to-breaches.md).
220+
221+## DNS proxying {#dns-proxying}
222+
223+We have a system that lets you request a domain name for your ship in the form of `ship.arvo.network`, where `ship` is your ship's name minus the `~`. This allows users to access their ships remotely using Landscape, our graphical web interface.
224+
225+Stars and planets follow the same process DNS proxying process, and galaxies have their own requirements. Moons and comets are not supported.
226+
227+### Planets and Stars
228+
229+For a planet or star's DNS proxying request to be made and fulfilled, they must be hosting their ship someplace with a public IP address, and its HTTP server must be listening on port 80.
230+
231+To get `ship.arvo.network` on a planet or star, you must set up DNS routing with its parent ship by starting the `:dns` app.
232+
233+To do so, simply run this command in your ship's Dojo, passing the IP address as an argument, using the .0.0.0.0 (`@if`) syntax. For example:
234+
235+```
236+> -dns-address &dns-address [%if .1.2.3.4]
237+```
238+
239+`:dns`, running locally, will make an HTTP request to that IP address on port 80 to confirm that it is itself available at that IP and port. If that fails, you'll receive a `%bail-early` message in `:chat-cli`; this request will retry a few times. If the self-check is successful, the request is relayed to `~zod`, and you'll receive a message saying, `request for DNS sent to ~zod`. Once `~zod` has acknowledged receipt of the request, your local `:dns` app will send a `:chat-cli` message saying `awaiting response from ~zod`.
240+
241+The request will be picked up shortly, and the `ship.arvo.network` DNS record will be set to the given IP address. Once that's set up, `~zod` will be notified and `~zod` will, in turn, notify your ship. That ship will now try to verify that it can reach itself on `ship.arvo.network` over port 80. If it can't, it'll send a message saying, `unable to access via ship.arvo.network`. If it can, it will configure itself with that domain and say `confirmed access via ship.arvo.network`.
242+
243+Great! You're set up now. Try accessing your `ship.arvo.network` in your browser to use Landscape; we recommend Chrome or Brave.
244+
245+### Configuring SSL
246+
247+To enable SSL on your ship, use the `acme` agent, which will request a certificate through Let's Encrypt. First, make sure the agent is started:
248+
249+```
250+> |start %acme
251+```
252+
253+Next, provide the path for the SSL certificate by poking the `acme` agent. The path format is `/tld/your_domain/your_subdomain`, so if your domain is `sampel-palnet.arvo.network`, you'd use it like so:
254+
255+```
256+> :acme &path /network/arvo/sampel-palnet
257+```
258+
259+### Galaxies
260+
261+Galaxies are already required to have separate DNS entry at galaxy.urbit.org. There's no automated process for getting that binding, so if you're a galaxy-holder, get in touch with us at support@urbit.org.
262+
263+There is a command for galaxies that will try to re-use their already-necessary Ames DNS entry for HTTPS:
264+
265+```
266+> -dns-auto
267+```
268+
269+This will make HTTP-requests to self-check availability over `galaxy.$AMES-DOMAIN` (currently galaxy.urbit.org), where `galaxy` is the galaxy's name minus the `~`.
270+
271+Otherwise, `-dns-auto` works the same as `:dns|ip` does with stars and planets: if it's available or unavailable, Chat messages, and so on.
272+
273+### Ports
274+
275+The built-in logic for listening on port 80 is to try to bind to port 80; if it cannot, it tries 8080, then increments until it can bind a port. Port 80 is available to unprivileged process on recent version of macOS. Otherwise, the process needs to either be run as root, or be given special permission (CAP\_NET_BIND on Linux).
276+
277+### Hoon
278+
279+You can use Chat to evaluate Hoon code and share the results with everyone in a chat. To do so, preface your Hoon with `#`.
280+
281+```
282+~sampel-palnet:chat-cli= #(add 2 2)
283+```
284+
285+This will print as:
286+
287+```
288+~sampel-palnet# (add 2 2)
289+ 4
290+```
291+
292+### URLs
293+
294+To share a URL, send it as its own message, with no content before or after it.
295+
296+```
297+~sampel-palnet:chat-cli= https://urbit.org/
298+```
299+
300+This will print as:
301+
302+```
303+~sampel-palnet/ https://urbit.org/
304+```
305+
306+### Expanding messages
307+
308+In the case of URLs, they may be too long to display on a single message line. For Hoon code, the code or result could be big. In `:chat-cli`, these get shortened when initially printed out. To view the entire contents, you can select the message in various ways.
309+
310+```
311+~sampel-palnet+ some message
312+----------[240]
313+~sampel-palnet+ let's try selecting this message!
314+~sampel-palnet+ another message
315+~sampel-palnet:chat-cli=
316+```
317+
318+In the above example, we can select the middle message by issuing any of the following command:
319+
320+```
321+;240
322+;40
323+;;
324+```
325+
326+`;n` looks for the last message whose sequence number ends in `n`. `;;` simply picks the second-to-last message.
327+
328+Detailed message output will look something like this:
329+
330+```
331+? 240
332+ 0v5.g7r7l.n0d7m.mp4bn.gp6vr.sm5lj at ~2019.10.17..22.08.27..8a03
333+ ~sampel-palnet
334+ to ~dopzod/urbit-help
335+let's try selecting this message!
336+```
337+
content/using/os/messaging.mdnew file+254
@@ -0,0 +1,254 @@
1++++
2+title = "Messaging"
3+template = "doc.html"
4+weight = 2
5++++
6+
7+Let’s get started using the `:chat-cli` application, also known more simply as
8+_Chat_. It's the simplest way to talk to people using the command line
9+interface.
10+
11+### Quickstart
12+
13+The most common use for `:chat-cli` right now is, of course, communicating in group chats.
14+
15+### Joining a chat
16+
17+In `:chat-cli`, any kind of medium for a message is called a _chat_. There are four "types" of chats, but for now we'll be dealing with the _channel_, a publicly accessible chatroom for general use. We'll discuss the other three kinds in the [chat management](#chat-management) section later on.
18+
19+Join the Urbit Community from Dojo using `:group-view &group-view-action [%join [~bitbet-bolbel %urbit-community] ~bitbet-bolbel]`. Once you've joined, join the General chat from chat-cli. Use `ctrl-x` to switch from the Dojo prompt to the Chat prompt.
20+
21+Then:
22+
23+```
24+~sampel-palnet:chat-cli/ ;join ~darrux-landes/general
25+```
26+
27+Now that you're in, try post a line to `~darrux-landes/general`:
28+
29+```
30+~sampel-palnet:chat-cli= Hello, world!
31+```
32+
33+You'll see your message printed below messages from others that came before it. You can always type `;chats` in the `chat-cli` prompt to list all the chats you're in:
34+
35+```
36+~sampel-palnet:chat-cli= ;chats
37+~darrux-landes/general
38+```
39+
40+Glyphs will be automatically assigned to channels, but have the option of binding a glyph (single non-alphanumeric character) to the channel you're joining; the syntax is in the form of `;join ~/~dopzod/books +`. The chosen glyph will be the symbol that ends your prompt, and it will be what you use as a shortcut to switch to this channel.
41+
42+```
43+~sampel-palnet:chat-cli= ;+
44+~sampel-palnet:chat-cli+
45+```
46+
47+Use `;leave` to unsubscribe from a channel:
48+
49+```
50+~sampel-palnet:chat-cli= ;leave ~darrux-landes/general
51+```
52+
53+Now, let's create a channel we can invite some friends to:
54+
55+```
56+~sampel-palnet:chat-cli= ;create channel /my-channel
57+```
58+
59+Now you can tell your friends to `;join ~your-urbit/my-channel`.
60+
61+In order to see messages in `:chat-cli` you may need to do the following in Dojo:
62+
63+```
64+:chat-cli %connect
65+```
66+ ### Creating and managing chats {#chat-management}
67+
68+As mentioned before, any urbit can host any number of chats. Existing chats can be deleted or modified with various commands. All commands in this section should be sent from the `chat-cli>` prompt.
69+
70+#### Create
71+
72+Syntax: `;create [type] /name +`, where `+` represents an optional glyph.
73+
74+Creates and joins a chat, where `[type]` is any of the following:
75+- `channel`: public chat. Has a blacklist for write control.
76+- `village`: invite-only chat.
77+- `journal`: publicly readable, invite-only for writing.
78+- `mailbox`: publicly writeable, invite-only for reading.
79+
80+Let's create an example mailbox:
81+
82+```
83+~sampel-palnet:chat-cli> ;create mailbox /coolbox ^
84+```
85+
86+#### Delete
87+
88+Syntax: `;delete /name`
89+
90+Deletes a chat.
91+
92+#### Permission management
93+
94+You can permit and ban people from reading and/or writing to the chats you host, using `;invite` and `;banish` command respectively.
95+
96+Syntax: `;invite [rw] /name ~ships`
97+
98+Where `rw` is either `r`, `w`, or `rw`, representing "read" and "write" permissions.
99+And where `~ships` is a comma-seperated list of ships to invite.
100+
101+For example, to grant two people full access to a `village` we created:
102+
103+```
104+~sampel-palnet:chat-cli> ;invite rw /hidden-village ~ravmel-ropdyl, ~rapfyr-diglyt
105+```
106+
107+Similarly, if we later want to revoke the writing permissions for one of them, but still allow them to read new messages, we can run:
108+
109+```
110+~sampel-palnet:chat-cli> ;banish w /hidden-village ~rapfyr-diglyt
111+```
112+
113+#### Chat glyphs
114+
115+Glyphs are found at the end of your prompt, as a quick indicator of where
116+your messages will be sent.
117+
118+Glyphs are assigned by chat hash out of the following list:
119+
120+```
121+! @ # $ % ^ & ( ) - = _ + [ ] { } ; ' \ : " , . < > ?
122+```
123+
124+Alphanumeric characters and `|#/*~` are reserved; all others can be manually assigned.
125+
126+For example, `-` the glyph at the end of the prompt below might indicates that
127+messages sent from this prompt will go to some chat with that glyph:
128+
129+```
130+~sampel-palnet:chat-cli-
131+```
132+
133+To see what chat is bound to a glyph, use the `;what` command followed by the
134+glyph in question, or use `;what` without specifying a glyph to see all of your
135+subscriptions which are bound to glyphs. For example, to see `=`:
136+
137+```
138+~sampel-palnet:chat-cli> ;what =
139+~dopzod/urbit-help
140+```
141+
142+To see all of your glyph bindings:
143+
144+```
145+~sampel-palnet:chat-cli> ;what
146+> ~paldev/numismatic-forum
147+. ~middev/ny-martians
148+= ~dopzod/urbit-help
149+```
150+
151+When the messaging target doesn't have a glyph, we see their name at the end of
152+the prompt instead. Here we're talking into `~dannum-mitryl/homework`:
153+
154+```
155+~sampel-palnet:chat-cli[~dannum-mitryl/homework]
156+```
157+
158+#### Bind
159+
160+Syntax: `;bind [glyph] ~host/chat-name`
161+
162+Assigns the chosen glyph to a chat.
163+
164+For example:
165+
166+```
167+~sampel-palnet:chat-cli> ;bind + ~dopzod/urbit-help
168+```
169+
170+#### Unbind
171+
172+Syntax: `;unbind [glyph] ~host/chat-name`
173+
174+Unassigns the chosen glyph from a chat owned by your ship.
175+
176+For example:
177+
178+```
179+~sampel-palnet:chat-cli> ;unbind + ~dopzod/urbit-help
180+```
181+
182+If you don't specify a chat, all bindings for that glyph are removed.
183+
184+#### Prefixes
185+
186+Received posts are prefixed with a glyph to let you know what the
187+audience is. You can activate an individual post to see the full
188+audience.
189+
190+There are a few special-purpose "glyphs":
191+
192+- `|` - Informational messages
193+- `*` - Posts to a target you don't have a glyph binding for
194+
195+
196+### Configuration
197+
198+#### Set audience
199+
200+`;~ship/chat`
201+
202+Set audience to `~ship/chat`.
203+
204+#### Set audience by glyph
205+
206+Syntax: `;[glyph]`
207+
208+Set audience to the chat previously bound to the chosen glyph.
209+
210+#### Set audience to own chat
211+
212+Syntax: `;/chat`
213+
214+Set audience to a chat on your own ship.
215+
216+### Miscellaneous configuration
217+
218+#### Change timezone
219+
220+Syntax: `;set timezone [+/-][hours]`
221+
222+Adjust the display of timestamps to a specific timezone. Relative to UTC.
223+
224+#### Set width
225+
226+Syntax: `;set width [number]`
227+
228+Set the rendering width of `:chat-cli` to a specific number of characters.
229+(Minimum of 30.)
230+
231+#### Show timestamps
232+
233+Syntax: `;set showtime`
234+
235+Show the timestamp for each message. This is set by default.
236+
237+#### Hide timestamps
238+
239+Syntax: `;unset showtime`
240+
241+Stop showing the timestamp for each message.
242+
243+#### Sound notification on
244+
245+Syntax: `;set notify`
246+
247+Emit a terminal bell sound if your six-syllable ship name is mentioned in
248+a message. This is set by default.
249+
250+#### Sound notification off
251+
252+Syntax `;unset notify`
253+
254+Do not notify when your ship name is mentioned.
content/using/os/s3.mdnew file+34
@@ -0,0 +1,34 @@
1++++
2+title = "Configuring S3 Storage"
3+template = "doc.html"
4+weight = 2
5++++
6+
7+Amazon S3, which stands for Amazon Simple Storage Service, is a technology that was introduced by Amazon Web Services for cloud storage that has since been extended more broadly into a [standard programming interface](https://en.wikipedia.org/wiki/Amazon_S3#S3_API_and_competing_services).
8+
9+Our S3 support lets you store credentials for your S3 object storage buckets on your Urbit ship; once you have done so, you will get additional functionality for uploading your own media within Chat and Groups (for avatars).
10+
11+To enable S3 support on your ship you'll need to first set up a bucket, and then add its credentials to Landscape using *either* Landscape or the Dojo.
12+
13+### Bucket Setup
14+
15+If you’re using AWS, it will have to support signature v2, not v4. We've found DigitalOcean's Spaces to work well also. The bucket has to be publicly readable, allow CORS from `*` origins, allow GET and PUT methods, and allow `*` headers. Your provider should have details on setting access permissions and CORS.
16+
17+### Add your credentials: Landscape
18+
19+Navigate to your `https://<your-ship-url>/~profile/settings`, or click your sigil in the upper-right corner of the window. Fill out the **S3 Credentials** and **S3 Buckets** sections and you're all set!
20+
21+### Add your credentials: Dojo
22+
23+Once you have gotten your bucket setup, poke the `s3-store` on your ship with your details. You can do this in Dojo or in web Dojo.
24+
25+```
26+:s3-store|set-endpoint 'endpoint.mys3provider.com'
27+:: AWS endpoint example: s3-us-west-2.amazonaws.com
28+:: Digital Ocean endpoint example: sfo2.digitaloceanspaces.com
29+:s3-store|set-access-key-id 'MYACCESSKEYID'
30+:s3-store|set-secret-access-key 'MYSECRETACCESSKEY'
31+:s3-store|set-current-bucket 'yourbucketname'
32+```
33+
34+Done! If you need to peek at s3-store’s state, you can always run :s3-store +dbug (inside Dojo, not web Dojo, unfortunately). You’ll see the additional functionality appear in Groups and Chat.
content/using/os/shell.mdnew file+413
@@ -0,0 +1,413 @@
1++++
2+title = "Shell"
3+template = "doc.html"
4+weight = 2
5++++
6+
7+The Dojo is our shell; it processes system commands and returns output. It's a
8+good place to quickly experiment with Urbit. On the surface the Dojo is just a
9+Hoon REPL. On the inside, the Dojo is a system for operating on and transforming
10+data in Urbit.
11+
12+### Quickstart
13+
14+You can use the Dojo to run arbitrary Hoon code, as well as non-Hoon system
15+commands.
16+
17+#### Math
18+
19+Evaluate a Hoon expression (whitespace matters):
20+
21+```
22+~your-urbit:dojo> (add 2 2)
23+~your-urbit:dojo> %+ add 2 2
24+```
25+
26+Tall-form Hoon may require multiple lines:
27+
28+```
29+~your-urbit:dojo> %+ add
30+~your-urbit:dojo< 2
31+~your-urbit:dojo< 2
32+```
33+
34+Hoon uses something called [the subject](@/docs/hoon/hoon-school/the-subject-and-its-legs.md).
35+The Dojo has its own subject and that's where Hoon's equivalent of variables,
36+called faces, are stored.
37+
38+Use `=var` to save faces to the Dojo subject.
39+
40+```
41+~your-urbit:dojo> =foo (add 2 2)
42+```
43+
44+Note, however, that `=var` is Dojo syntax, not Hoon syntax. You cannot bind a
45+face in a `.hoon` file in this way.
46+
47+#### System commands
48+
49+Use `=dir` to set the current working directory:
50+
51+```
52+~your-urbit:dojo> =dir %/gen
53+```
54+
55+(`%` represents your current directory. For a complete explanation on urbit
56+paths, see the [filesystem section](#filesystem).)
57+
58+Generators (files in `/gen`) are run with `+`:
59+
60+```
61+~your-urbit:dojo> +hello 'world'
62+```
63+
64+Save output to a file in `%clay` with `*`:
65+
66+```
67+~your-urbit:dojo> *some/file/path/hoon 'hello world'
68+```
69+
70+Run system commands from `:hood`, like `reload`, using `|`:
71+
72+```
73+~your-urbit:dojo> |reload %eyre
74+```
75+
76+### Generators
77+
78+Generators are short Hoon scripts, saved as `.hoon` files in the `/gen`
79+directory. Many Dojo commands exist in the form of generators. The syntax for
80+running a generator is `+genname` for a generator saved as `genname.hoon`.
81+
82+#### `+cat`
83+
84+Accepts a path and displays the file. Similar to Unix `cat`.
85+
86+```
87+~your-urbit:dojo> +cat %/gen/curl/hoon
88+```
89+
90+#### `+code`
91+
92+Generates a code that is used to remotely log into your ship. No
93+arguments.
94+
95+```
96+~your-urbit:dojo> +code
97+```
98+
99+You can change your code to a new randomly generated one by entering `|code
100+%reset`. Please note that this will prevent [Bridge](@/docs/glossary/bridge.md)
101+from being able to derive your code in the future.
102+
103+#### `+curl`
104+
105+Retrieves data from a URL. Accepts a `tape`. Similar to Unix `curl`.
106+
107+```
108+~your-urbit:dojo> +curl "http://nyt.com"
109+```
110+
111+#### `+hello`
112+
113+Just prints the argument. Accepts a `@ta`.
114+
115+```
116+~your-urbit:dojo> +hello 'mars'
117+```
118+
119+#### `+ls`
120+
121+Similar to Unix `ls`. Accepts a path.
122+
123+```
124+~your-urbit:dojo> +ls %/gen
125+~your-urbit:dojo> +ls /~talsur-todres/home/2/gen/program
126+```
127+
128+#### `+solid`
129+
130+Compile the current state of the kernel and output a
131+noun. Usually downloaded to a file in unix. No arguments.
132+
133+```
134+~your-urbit:dojo> .urbit/pill +solid
135+```
136+
137+#### `+test`
138+
139+Testrunner. Can test multiple generators at once, conventionally ones
140+in the `/test` folder. Takes a path.
141+
142+```
143+~your-urbit:dojo> +test /lib
144+```
145+
146+#### `+ticket`
147+
148+Generate a ticket for an urbit ship. Takes an urbit name (`@p`).
149+
150+
151+```
152+~your-urbit:dojo> +ticket ~talsur-todres-your-urbit
153+```
154+
155+#### `+tree`
156+
157+Generate a recursive directory listing. Takes a path.
158+
159+```
160+~your-urbit:dojo> +tree %/sys
161+```
162+
163+### Hood
164+
165+The hood is the system daemon. See `gen/hood` and `app/hood`.
166+
167+`|hi` - Sends a direct message. Sort of like Unix `write`. Accepts
168+an urbit name (`@p`) and a string (`tape`, which is text wrapped with double-quotes).
169+
170+```
171+~your-urbit:dojo> |hi ~binzod "you there?"
172+```
173+
174+`|link` / `|unlink` - Link / unlink a remote app. Accepts an
175+Urbit name and an app name.
176+
177+```
178+~your-urbit:dojo> |link ~talsur-todres %octo
179+```
180+
181+`|mass` - Prints the current memory usage of all the kernel modules.
182+No arguments.
183+
184+```
185+~your-urbit:dojo> |mass
186+```
187+
188+`|reload` - Reloads a kernel module (vane) from source. Accepts any
189+number of vane names.
190+
191+```
192+~your-urbit:dojo> |reload %clay %eyre
193+```
194+
195+`|reset` - Reloads `hoon.hoon` and all modules. No arguments.
196+
197+```
198+~your-urbit:dojo> |reset
199+```
200+
201+`|start` - Starts an app. Accepts an app name.
202+
203+```
204+~your-urbit:dojo> |start %curl
205+```
206+
207+---
208+
209+### Dojo manual
210+
211+#### Sources and sinks
212+
213+A Dojo command is either a **source** or a **sink**. A source is just something
214+that can be printed to your console or the result of some computation. A
215+sink is an **effect**: a change to the filesystem, a network message, a
216+change to your environment, or a typed message to an app.
217+
218+Sources can be chained together, but we can only produce one effect per
219+command.
220+
221+#### Sinks
222+
223+#### `=` - Set variable
224+
225+Set any environment variable:
226+
227+```
228+~your-urbit:dojo> =foo 42
229+~your-urbit:dojo> (add 2 foo)
230+
231+44
232+```
233+
234+Make sure to note that `=var` is Dojo syntax, not Hoon syntax. You cannot bind a
235+variable in a `.hoon` file in this way.
236+
237+#### Special variables
238+
239+There are a few special variables that the Dojo maintains.
240+
241+#### `:` - Send to app
242+
243+`:app` goes to a local `app`, `:~ship/app` goes to the `app` on `~ship`.
244+
245+Send a `helm-hi` message to `hood`:
246+
247+```
248+~your-urbit:dojo> :hood &helm-hi 'hi'
249+```
250+
251+Apps usually expect marked data, so `&` is often used here.
252+
253+#### `*` - Save in `%clay`
254+
255+Save a new `.hoon` file in `gen`:
256+
257+```
258+~your-urbit:dojo> *%/gen/foo/hoon '# hello'
259+```
260+
261+The last component of the path is expected to be the mark (or mime
262+type).
263+
264+#### `.` - Export to Unix
265+
266+Export a noun to Unix with `.`:
267+
268+```
269+~your-urbit:dojo> .foo/bar/baz (add 2 2)
270+```
271+
272+Which creates a file at `pier/.urb/put/foo/bar.baz`.
273+
274+This is very often used with `+solid`:
275+
276+```
277+~your-urbit:dojo> .urbit/pill +solid
278+```
279+
280+Which outputs a new `urbit.pill` to `pier/.urb/put/urbit.pill`
281+
282+### Sources
283+
284+#### `_` - Run a function
285+
286+Use `_` to run a gate (or function):
287+
288+Write an arbitrary function and pass data to it:
289+
290+```
291+~your-urbit:dojo> _|=([a=@] (mul a 3)) 3
292+9
293+```
294+
295+Use a function to get the status code from an http request:
296+
297+```
298+~your-urbit:dojo> _|=([p=@ud q=* r=*] p) +http://google.com
299+301
300+```
301+
302+#### `+` `-` - HTTP requests
303+
304+`+http[s]://example.com` - sends a GET request
305+
306+`+http[s]://example.com &json [%s 'hi']` - sends a POST request with the
307+JSON `"hi"` in the body.
308+
309+`-http[s]://example.com &json [%s 'hi']` - sends a PUT request with the
310+JSON `"hi"` in the body.
311+
312+Note that the first of these is a source while the last two are sinks.
313+
314+#### `+` - Generators
315+
316+Generators are simple Hoon scripts loaded from the filesystem. They live
317+in `gen/`.
318+
319+An example of a generator that is built into your urbit is `+code`. It produces
320+the code needed to log into your ship remotely.
321+
322+```
323+~your-urbit:dojo> +code
324+fintyr-haldet-fassev-solhex
325+```
326+
327+### Variables
328+
329+You can use `=` to set an environment variable in Dojo, but there are
330+a few reserved names that have special uses.
331+
332+#### `dir`
333+
334+Current working `%clay` desk and revision. Read / write.
335+
336+**Examples:**
337+
338+```
339+~your-urbit:dojo> =dir %/gen
340+~your-urbit:dojo> +ls %
341+404/hoon docs/ dojo/hoon lib/ listen/hoon md static/udon talk/ testing/udon tree/main/ unmark/ womb/
342+```
343+
344+#### `lib`
345+
346+Current set of libraries (`/lib`) in your environment. Can be set
347+with `/+`. Read / write.
348+
349+**Examples:**
350+
351+```
352+~your-urbit:dojo> /+ number-to-words
353+```
354+Now we can use arms from lib/number-to-words.hoon
355+```
356+~your-urbit:dojo> (to-words:eng-us:number-to-words 123.456)
357+```
358+
359+#### `sur`
360+
361+Current set of structures (`/sur`) in your environment. Can be set
362+with `/-`. Read / write.
363+
364+**Examples:**
365+
366+```
367+~your-urbit:dojo> /- sole
368+```
369+Now we can use arms in sur/sole.hoon.
370+```
371+~your-urbit:dojo> `sole-effect:sole`[%bel ~]
372+```
373+
374+#### `now`
375+
376+The current (128-bit `@da`) time. Read-only.
377+
378+**Example:**
379+
380+```
381+~your-urbit:dojo> now
382+~2016.3.21..21.10.57..429a
383+```
384+
385+#### `our`
386+
387+The current urbit ship. Read-only.
388+
389+**Example:**
390+
391+```
392+~your-urbit:dojo> our
393+~your-urbit
394+```
395+
396+#### `eny`
397+
398+512 bits of entropy. Read-only.
399+
400+**Example:**
401+
402+```
403+~your-urbit:dojo> eny
404+\/0vnt.d474o.gpahj.jcf3o.448fh.2lamb.82ljm.8ol8u.b02vi.mrvvp.b7et2.knb7m.l8he\/
405+ 8.8qb9s.drm36.77n9b.a0qst.30g03.l5lb5.nvsbc.v39tn
406+\/
407+```
408+
409+### Troubleshooting
410+
411+If you encounter `%dy-edit-busy` while entering commands, it is
412+because your Dojo is blocked on a timer or an HTTP request. Type backspace
413+and your Dojo will end the blocked command.
content/using/os/ship-troubleshooting.mdnew file+212
@@ -0,0 +1,212 @@
1++++
2+title = "Ship Troubleshooting"
3+weight = 8
4+template = "doc.html"
5+aliases = ["docs/using/ship-troubleshooting/"]
6++++
7+
8+Urbit is still in the development stage, so there's a chance that your ship won't start properly, or will stop working properly when you're running it. That's ok! This document is intended to help you in such an event.
9+
10+This page contains resolutions to many of the most commonly encountered issues.
11+If your issue is not covered here, please check out our [Troubleshooting Knowledgebase](https://github.com/urbit/support/wiki).
12+
13+## Table of Contents
14+
15+- [Best practices](#best-practices)
16+- [Operation issues](#operation-issues)
17+- [Connectivity issues](#connectivity-issues)
18+- [Booting issues](#booting-issues)
19+- [Crashing issues](#crashing-issues)
20+
21+## Best Practices {#best-practices}
22+
23+An ounce of prevention is worth a pound of cure, so let's first go over some best practices to keep your ship in working order.
24+
25+### Only initialize your ship once
26+
27+Once your ship has been initialized (with the `-w` variation of the `./urbit` command), you should never do so a second time. If you do initialize it anew without special measures, you will experience trouble communicating with ships on the network you had talked to before.
28+
29+If you accidentally did this a second time, or want to intentionally start fresh, you need to perform a [personal breach](#personal-breach), which is explained in the next section.
30+
31+### Do not delete your pier
32+
33+Urbit is stateful, meaning that it needs to hold onto all your data. If you delete your pier and start your ship again, you won't be able to talk to any ship you've talked to before. The only solution to this is performing a [personal breach](#personal-breach).
34+
35+### Keep track of the directory that you put your ship in
36+
37+When you first start your ship, you should make sure you put it a place where you can find it again and where it won't get accidentally deleted.
38+
39+### Keep up-to-date builds
40+
41+Check for latest Urbit version at https://github.com/urbit/urbit/releases. If you're behind, update using [this guide](@/getting-started.md#updating).
42+
43+### `|hi` your star to see if you're connected
44+
45+Find out who your star is by running `(sein:title our now our)` in the Dojo. Then, run `|hi ~star`, where `~star` is the star's name, and if things are working properly, you should get the message `hi ~star successful`. It could also be helpful to use `|hi` to check connectivity with `~zod` or another planet that you're in a Chat channel with.
46+
47+### Turn your ship off and on again
48+
49+Use `ctrl-d` to gracefully exit your ship, and then start it again. This can solve many issues.
50+
51+### Use the `|knob` command to customize your error messages
52+
53+Error messages can be by overwhelming, so the `|knob` command is intended to remedy this. It's used to silence errors that aren't important.
54+
55+The command takes two arguments, and comes in the form of `|knob %error-tag %level`.
56+
57+`%error-tag` is the name of the error in question. It's usually printed at the top of the stack trace, such as in `crud: %hole event failed` -- `%hole` here is an example of an error tag.
58+
59+`%level` determines how much you will see of errors with your chosen `%error-tag`. There are three levels:
60+
61+- `%hush`: no output.
62+- `%soft`: one line of output, just containing the error tag.
63+- `%loud`: full output.
64+
65+So for example, to silence all Ames packet-related errors, try `|knob %hole %hush`.
66+
67+### Perform a personal breach. {#personal-breach}
68+
69+A personal breach is when a ship tells the rest of the network to treat it as though the ship was just started for the first time again. Any ongoing or outstanding communication is forgotten and connections are reestablished from scratch.
70+
71+Personal breaches often fix connectivity issues, but should only be used as a
72+last resort. To find out how to perform a personal breach, check out our [Guide
73+to Breaches](../guide-to-breaches). Before taking such a drastic measure, try
74+other methods in this guide. You can also ask for help on
75+in the Help channel in the Urbit Community group at `~bitbet-bolbel/urbit-community` or, failing that, in the `#ship-starting-support`
76+channel in our [Discord server](https://discord.gg/n9xhMdz).
77+
78+### Reset `+code`
79+
80+You login to Landscape using the camel-case phrase obtained from dojo by
81+entering `+code`. For security reasons you may wish to change this code
82+regularly. You may do so by entering `|code %reset` into dojo. Doing this
83+will prevent [Bridge](@/docs/glossary/bridge.md) from being able to derive your code,
84+meaning you will only be able to check it from dojo in the future.
85+
86+## Operation Issues {#operation-issues}
87+
88+### My urbit is frozen
89+
90+Sometimes this happens if you're processing a very large event, or if you're in an infinite loop, or for a variety of other reasons.
91+
92+Before doing anything, try waiting for a minute: an event might finish processing. If it doesn't clear up, then use the Unix kill-command, `ctrl-z`, to end your ship's process. Then restart your ship.
93+
94+### When I try to type into the Dojo, it prints `dy-noprompt`
95+
96+This happens when your Dojo is waiting on a request, such as an HTTP request. You can fix it simply by typing `backspace` or (`delete` on Mac).
97+
98+### My ship doesn't recognize file changes that I make in my pier
99+
100+Since version `0.8.0`, changes no longer automatically sync between the Unix side (your pier) and your ship. To sync your file changes, you must run `|commit %desk` in your Dojo, where `%desk` is the desk you'd like to sync.
101+
102+## Connectivity Issues {#connectivity-issues}
103+
104+### I can't communicate with anyone
105+
106+Maybe you booted your ship twice, or ran it using old files. If this is the case, you must perform a [personal breach](#personal-breach).
107+
108+### I don't have the latest OTA
109+
110+You can check what build your ship is on by entering `+trouble` into dojo and
111+reading the `%base` hash. If this does not match the latest hash published in
112+the `urbit-dev` mailing list, you are behind.
113+
114+Your sponsor may just be lagging behind, so sometimes this will resolve on its
115+own with patience. Otherwise, try the procedure outlined [here](https://github.com/urbit/support/wiki/Missing-OTA).
116+
117+### I keep getting an `ames` error stack-trace
118+
119+You may see a message like this one: `/~zod/home/~2019.7.22..18.55.46..83a3/sys/vane/ames:<[line column].[line column]>`. This is a clay path to a Hoon file, pointing to the line and column where an expression crashed. This kind of error might be accompanied by a `crud` message.
120+
121+This means that another ship is sending invalid packets to you. This could be because one of the ships has not updated the other ship's "life number", which is the number that starts at one and increments every time that ship performs a personal breach.
122+
123+This can happen if they have the wrong keys of yours, or if you have the wrong keys of theirs. You can figure out who has the wrong keys by running this scry command in your dojo: `.^(* %j /=life=/shipname)`, where shipname is the other ship's name. Save that information. Then, go to the [Azimuth contract on Etherscan](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb#readContract), scroll down to `32. points`, and put in the hexadecimal representation of the other ship's `@p`. You can find the hexadecimal representation by running ...
124+
125+```
126+`@ux`~sampel-palnet
127+```
128+
129+... in the Dojo, where `~sampel-palnet` is the other ship's name. Then, compare it to the scry information that you saved. If that information matches up, it means that the other ship is the problem. If it **doesn't** match up, your ship has wrong information about the other ship. If you have such wrong information, you can fix this by running:
130+
131+```
132+:azimuth-tracker|listen ~ %app %azimuth-tracker
133+```
134+
135+The last line above syncs from an Ethereum node for _all_ ships on the network. If you only wanted to sync with certain ships, run:
136+
137+```
138+:azimuth-tracker|listen ~[~sampel-palnet ~zod ~marzod] %app %azimuth-tracker
139+```
140+
141+`~sampel-palnet ~zod ~marzod` are example ship-names; replace these with any number of desired ship-names.
142+
143+The above commands work if you have the wrong keys of other ships. If other ships have wrong keys of _yours_, you need to somehow ask them to to run such a command.
144+
145+### I can talk to some ships, but I can't talk to my sponsor and some other ships
146+
147+This is the result of deleting your pier and starting your ship again. To fix this, you must perform a [personal breach](#personal-breach).
148+
149+## Booting Issues {#booting-issues}
150+
151+### My ship booted for the first time, but it turned into a comet instead of my planet or star
152+
153+You may have used the wrong arguments when booting your ship for the first time. Delete this comet and try again.
154+
155+### My development ship ("fakezod") gets a `boot: malformed` failure
156+
157+This means that you gave your development ship an invalid `@p`. So, you will get this error if you write, for example, `urbit -F zodzod` instead of `urbit -F zod`.
158+
159+## Crashing Issues {#crashing-issues}
160+
161+### I got a `bail` error and my ship crashed
162+
163+Try bringing it back up; it will often start working just fine again.
164+
165+However, if you get a `bail` error again, this is a serious issue and should be reported (see below). It's advised to keep the old files around to assist issue research. If you want to get back on the network immediately, you might want to perform a [personal breach](#personal-breach).
166+
167+#### Making a GitHub issue out of your `bail`
168+
169+You can get help with you problem by creating an issue at [github.com/urbit/urbit](https://github.com/urbit/urbit/issues). But to make a good issue, you need to include some information.
170+
171+When your urbit crashes with a `bail`, you'll probably get a core dump, which is a file that contains the program state of your urbit when it crashed. On Mac, core dumps can be found in `/cores`. On Linux, cores can often be found in `/var/crash`, or the home directory.
172+
173+Navigate to the folder containing your core dumps. Find the most recent core dump by looking at the dates after you run `ls -l`. Then `lldb -c <corename>`. Once that loads, you'll be at an `(lldb)` prompt; type `bt` at this prompt. This will create a stack trace that looks like this:
174+
175+```
176+(lldb) bt
177+* thread #1, stop reason = signal SIGSTOP
178+ * frame #0: 0x000000010583d871 urbit`_box_free + 17
179+ frame #1: 0x0000000105845ee6 urbit`u3j_boot + 182
180+ frame #2: 0x000000010584d1f9 urbit`u3m_boot + 89
181+ frame #3: 0x000000010583d15d urbit`main + 2765
182+ frame #4: 0x00007fff75cb83d5 libdyld.dylib`start + 1
183+(lldb)
184+```
185+
186+Copy this stack trace and include it in your GitHub issue.
187+
188+### My ship crashed with a `bail: meme` error.
189+
190+This means that your ship ran out of memory.
191+
192+1. Make sure you are running the latest binary if you are not already on it.
193+
194+2. Restart your ship. If you don't crash again, everything may be fine.
195+
196+3. If you **do** crash again, try running the following after your ship has shut down:
197+ `./urbit-worker meld your-ship` (Replacing `your-ship` with the name/directory of your ship.)
198+ This will attempt to compact the memory of your ship. Note that this may use large amounts of memory on the machine you are running it on, and will be very slow if the machine has little memory available.
199+
200+4. If the above succeeds, but you still get `bail: meme` immediately, or after running for a little while, please [file an issue](https://github.com/urbit/urbit/issues). If you can, run `|mass` and share its output.
201+
202+5. As a last resort, you may perform a [personal breach](#personal-breach).
203+
204+### My ship crashed with a `bail: oops` error
205+
206+Restart your ship. These issues often just go away on their own. If this error repeats after restart two or more times, post the messages in an issue at [github.com/urbit/urbit](https://github.com/urbit/urbit/issues).
207+
208+This same error might also appear with a message like `Assertion '0'`.
209+
210+### My ship crashed with an `pier: work error` error
211+
212+This means that the Urbit worker process has shut down for one reason or another. Just restart your ship; this is not a notable or reportable error.
content/using/operations/stars-and-galaxies.md → content/using/os/stars-and-galaxies.mdrenamed+6−6
@@ -1,12 +1,12 @@
11+++
22title = "Star and Galaxy Operations"
33description = "Additional information and suggested ettiquette for Star and Galaxy owners."
4−weight = 3
4+weight = 4
55aliases = ["/docs/using/operating-a-star/"]
6−template = "page_indiced.html"
6+template = "doc.html"
77+++
88
9−To boot your galaxy or star, follow our [installation instructions](@/using/install.md).
9+To boot your galaxy or star, follow our [installation instructions](@/getting-started.md).
1010
1111### Hosting your star
1212
@@ -14,7 +14,7 @@ If you plan to distribute planets in any capacity, we ask that you keep your sta
1414running. If you fail to do so, those planets will become orphans that are unable
1515to communicate with the network unless they transfer to a new star.
1616
17−See our [cloud hosting instructions](@/using/operations/hosting.md) for
17+See our [cloud hosting instructions](@/using/running/hosting.md) for
1818instructions on settings up a Digital Ocean droplet.
1919
2020### Distributing planets
@@ -27,7 +27,7 @@ By default, your star accepts software updates from its galaxy and routes them t
2727
2828#### Breaches
2929
30−To ensure new planets can connect to your ship, users are expected to participate in network-wide breaches by [updating to the latest Urbit version](@/using/install.md), deleting (or archiving) your pier, and then booting your ship using the new binary. If you don’t participate, you won’t be able to communicate with anyone on the network who has updated to the new era.
30+To ensure new planets can connect to your ship, users are expected to participate in network-wide breaches by [updating to the latest Urbit version](@/getting-started.md), deleting (or archiving) your pier, and then booting your ship using the new binary. If you don’t participate, you won’t be able to communicate with anyone on the network who has updated to the new era.
3131
3232Network-wide breaches are distinct from personal breaches, wherein an individual ship cycles its personal network keys using Bridge, and then follows the same steps outlined above.
3333
@@ -38,7 +38,7 @@ See our [Guide to Breaches](https://urbit.org/docs/tutorials/guide-to-breaches)
3838- If you distribute planets, boot and run your star on the Arvo network, or the
3939 planets won't be able to boot for the first time or connect unless they
4040 transfer to a different star.
41−- A star is networking infrastructure. For that reason, the machine running your star or galaxy must have sufficient bandwidth and processing power for your dependent planets.
41+- A star is networking infrastructure. For that reason, the machine running your star or galaxy must have sufficient bandwidth, storage, and processing power for your dependent planets. Until event log pruning is implemented, expect ships to consume more disk space every year; stars looking to serve around 100 planets will want to ensure around 50GB of space per year of operation.
4242- When messaging others, communicate using your star only when speaking in an official/infrastructural capacity. Otherwise, use your personal planet.
4343
4444### Taxes
content/using/running/_index.mdnew file+16
@@ -0,0 +1,16 @@
1++++
2+title = "Running Urbit"
3+sort_by = "weight"
4+description = "How to run Urbit in various environments."
5+template = "sections/docs/chapters.html"
6+weight = 30
7++++
8+
9+Urbit can be run in a variety of contexts. Our [Getting Started
10+Guide](@/getting-started.md) covers how to run an Urbit locally on your
11+computer; this section covers alternative ways of running Urbit.
12+
13+### [Cloud Hosting](@/using/running/hosting.md)
14+
15+This guide covers the provisioning and setup of a cloud server in Digital Ocean
16+running your Urbit. This enables your Urbit to be accessed from anywhere.
content/using/operations/hosting.md → content/using/running/hosting.mdrenamed+25−18
@@ -1,13 +1,12 @@
11+++
2−title = "Hosting Your Ship In The Cloud"
2+title = "Cloud Hosting"
33description = "How to host your ship in the cloud so you can access it from any device."
4−template = "page_indiced.html"
4+template = "doc.html"
55weight = 2
66[extra]
77hidetitle = "true"
88+++
99
10−## Hosting Your Ship In The Cloud
1110The goal of this guide is to have clear and easy to follow best practices for deploying an Urbit node to a server you control in the cloud. Deploying in the cloud allows you to access your Urbit from any device.
1211
1312Most Urbit users start out running their ship locally on one machine in order to play with it, but this means when your machine is offline your Urbit node is offline too (and can't get updates). You can also only access your Urbit from that one machine.
@@ -83,11 +82,17 @@ Continuing to follow the DO docs we're going to configure the ufw firewall.
8382 ```
8483 $ sudo ufw app list
8584 ```
86− - Next we'll configure ufw to allow connections via ssh and to allow Urbit to use the standard web port when the firewall is enabled.
85+
86+ - Next we'll configure ufw to allow connections via ssh and to allow Urbit to use the standard web port when the firewall is enabled,
87+ as well as opening a port that we'll later specify for your urbit to use to communicate directly with other ships.
8788 ```
8889 $ sudo ufw allow OpenSSH
8990 $ sudo ufw allow www
91+ $ sudo ufw allow https
92+ $ sudo ufw allow 34543/udp
9093 ```
94+ Note that you can choose any port in place of 34543 for Ames. Just be sure to pass the same port via the `-p` option when starting your ship.
95+
9196 - Next we'll turn on the firewall.
9297 ```
9398 $ sudo ufw enable
@@ -98,37 +103,39 @@ Continuing to follow the DO docs we're going to configure the ufw firewall.
98103 ```
99104
100105## Installing Urbit
101−Finally we're ready to install Urbit on your very own server. This part is actually pretty easy, if you haven't installed Urbit locally then the instructions are the exact same as the ones in the Urbit [install doc](@/using/install.md). If you have a local ship already, we're going to install Urbit on the server and then send your local ship up.
102− - **WARN**: Since Urbit is p2p you don't want to ever run two copies of your ship simultaneously. This is because other nodes that interact with each of your copies will be confused by which one is the most up to date. If you end up accidentally doing this you'll have to do a 'personal breach' described in the [guide to breaches](@/docs/tutorials/guide-to-breaches.md) to fix things.
106+Finally we're ready to install Urbit on your very own server. This part is actually pretty easy, if you haven't installed Urbit locally then the instructions are the exact same as the ones in the Urbit [install doc](@/getting-started.md). If you have a local ship already, we're going to install Urbit on the server and then send your local ship up.
107+ - **WARN**: Since Urbit is p2p you don't want to ever run two copies of your ship simultaneously. This is because other nodes that interact with each of your copies will be confused by which one is the most up to date. If you end up accidentally doing this you'll have to do a 'personal breach' described in the [guide to breaches](@/using/id/guide-to-breaches.md) to fix things.
103108 - The first thing you're going to want to do is shut down your local ship, either with control-d or `|exit` in dojo.
104− - Next we're going to install Urbit on the server and permit it to bind to the web port:
109+ - Next we're going to install Urbit on the server and permit it to bind to the web ports:
105110 ```
106111 $ ssh your_user@your_domain
107112 $ mkdir urbit
108113 $ cd urbit
109− $ curl -O https://bootstrap.urbit.org/urbit-v0.10.8-linux64.tgz
110− $ tar xzf urbit-v0.10.8-linux64.tgz
111− $ cd urbit-v0.10.8-linux64
114+ $ wget --content-disposition https://urbit.org/install/linux64/latest
115+ $ tar zxf ./linux64.tgz --strip=1
112116 $ sudo setcap 'cap_net_bind_service=+ep' urbit
113117 ```
114118 - Now we're going to tar up your local ship and send it to your server, from your local machine's urbit directory:
115119 ```
116120 $ tar -zcvf <ship_dir_name>.tar.gz <ship_dir_name>
117− $ scp <ship_dir_name>.tar.gz your_user@your_domain:/home/your_user/urbit
121+ $ scp <ship_dir_name>.tar.gz your_user@your_domain:urbit
118122 ```
119123 - Back on your server let's untar your ship and start it up with the Ames port we allowed through the firewall:
120124 ```
121125 $ ssh your_user@your_domain
122126 $ cd urbit
123127 $ tar -zxvf <ship_dir_name>.tar.gz
124− $ ./urbit-v0.10.8-linux64/urbit <ship_dir_name>
128+ $ ./urbit -p 34543 <ship_dir_name>
125129 ```
126− - Now we run a few commands in Dojo to request a Let’s Encrypt cert for your domain (replace `tld` with whatever your top-level domain is e.g. `com` in `example.com`:
130+ - Now we run a few commands in Dojo to request a Let’s Encrypt cert for your
131+ domain. Replace `tld` with whatever your top-level domain is e.g. `com` in
132+ `example.com`. `your_subdomain` is optional and that part of the command
133+ should be omitted if you are not using it):
127134 ```
128135 ~sampel-palnet:dojo> |start %acme
129− ~sampel-palnet:dojo> :acme &path /tld/your_domain
136+ ~sampel-palnet:dojo> :acme &path /tld/your_domain/your_subdomain
130137 ```
131− - Your ship should now be sailing on the digital ocean. Check `https://your_domain`, if everything is working properly you should see a login page.
138+ - Your ship should now be sailing on the digital ocean. Check `https://your_subdomain.your_domain.tld`, if everything is working properly you should see a login page.
132139 - Log in with the code from `+code` in dojo like normal and you should see all of your applications.
133140
134141## Leaving your Urbit running in a Screen session
@@ -139,7 +146,7 @@ Finally, to leave your Urbit running after you disconnect we can leave it in a S
139146 ```
140147 - This will start a screen session, we can now start up the Urbit ship from the `urbit` directory in this session:
141148 ```
142− $ ./urbit-v0.10.8-linux64/urbit <ship_dir_name>
149+ $ ./urbit <ship_dir_name>
143150 ```
144151 - Then we can disconnect from the screen session and leave the ship running with `control-a d`
145152 - To get back into the screen session:
@@ -159,7 +166,7 @@ On iOS you can save a website to your homescreen as an icon. If you do this for
159166 - [Digital Ocean Nginx Installation][DO Nginx Install]
160167 - [Digital Ocean Nginx Config][DO Nginx Config]
161168 - [Digital Ocean SSL Cert Setup][DO SSL Config]
162− - [Urbit Install Docs](@/using/install.md)
169+ - [Urbit Install Docs](@/getting-started.md)
163170 - [Urbit Basic Cloud Install][Urbit Basic Cloud Install]
164171
165172 [Gandi]: https://www.gandi.net/
@@ -170,5 +177,5 @@ On iOS you can save a website to your homescreen as an icon. If you do this for
170177 [DO SSL Config]: https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-18-04
171178 [Urbit Basic Cloud Install]: https://medium.com/@urbitlive/hello-world-urbit-edition-install-boot-and-run-your-urbit-planet-on-a-10-cloud-server-b9579745b9a8
172179 [DO Initial Setup]: https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04
173− [Blog Github]: https://github.com/zalberico/zalberico.github.io
180+ [Blog GitHub]: https://github.com/zalberico/zalberico.github.io
174181
content/voting-instructions.md+8−8
@@ -5,11 +5,11 @@ template = "page_indiced.html"
55hidetitle = "true"
66+++
77
8−## Arvo Stability Vote
8+## Urbit Continuity & Security Vote
99
10−As a galaxy owner, you have the opportunity to participate in one of the first votes conducted on the Azimuth network – a vote on whether Tlon has designated Arvo as stable, the second component in the [roadmap](https://github.com/urbit/azimuth/blob/master/proposals/0xcb1f81e42b5e75f000f94fc71a3ea70cab4bfc6f236b91e717f1b9516e5596b5.txt) embedded in Azimuth.
10+As a galaxy owner, you have the opportunity to participate in one of the first votes conducted on the Azimuth network – a vote on whether Tlon has designated the Urbit network as continuous and confirmed to be secure by a third-party auditer, the third component in the [roadmap](https://github.com/urbit/azimuth/blob/master/proposals/0xcb1f81e42b5e75f000f94fc71a3ea70cab4bfc6f236b91e717f1b9516e5596b5.txt) embedded in Azimuth.
1111
12−You can read more about this milestone [here](/blog/stable-arvo/).
12+You can read more about this milestone [here](/blog/security-and-continuity/).
1313
1414Below are instructions on how to support this document proposal.
1515
@@ -18,19 +18,19 @@ Below are instructions on how to support this document proposal.
1818- Log into [Bridge](https://bridge.urbit.org) with your Voting Proxy (you can use your Ownership Key as well, but that is probably harder to access)
1919- If you're presented with a list of assets, click on your galaxy.
2020- On the asset's overview screen, click Senate.
21−- The page will show a list of the documents that have previously achieved majority, as well as currently open polls. Tlon's latest proposal has the hash of `0x00000000000000000000000000000000000000000000000000000000000000a0`.
22−- For more information on the text of this proposal, see [here](https://github.com/urbit/azimuth/pull/24).
21+- The page will show a list of the documents that have previously achieved majority, as well as currently open polls. Tlon's latest proposal has the hash of `0x00000000000000000000000000000000000000000000000000000000000000e0`.
22+- For more information on the text of this proposal, see [here](https://github.com/urbit/azimuth/pull/34).
2323- Click "support" or "reject" under the hash, then "generate & sign transaction", then "send transaction", to vote on the proposal.
2424- If this proposal achieves majority support, you can see the result by coming back to this page.
2525
2626## Vote using Etherscan (or other explorers)
2727
28−- Read the document being proposed [here](https://github.com/urbit/azimuth/pull/24).
28+- Read the document being proposed [here](https://github.com/urbit/azimuth/pull/34).
2929- If you're going to use Etherscan, you need to have Metamask installed and authenticate with either your Voting Proxy or your Ownership Key.
30−- Create and sign a transaction using your Galaxy Ownership or Voting Proxy on the [Polls contract](https://etherscan.io/address/0x7fecab617c868bb5996d99d95200d2fa708218e4#writeContract) in castDocumentVote with your galaxy number, the document hash from the above document (`0x00000000000000000000000000000000000000000000000000000000000000a0`) and vote as "true" for yes and "false" for no.
30+- Create and sign a transaction using your Galaxy Ownership or Voting Proxy on the [Polls contract](https://etherscan.io/address/0x7fecab617c868bb5996d99d95200d2fa708218e4#writeContract) in castDocumentVote with your galaxy number, the document hash from the above document (`0x00000000000000000000000000000000000000000000000000000000000000e0`) and vote as "true" for yes and "false" for no.
3131- Submit the transaction.
3232
3333## Verify that this proposal has passed
3434
35−- The Polls contract is [here](https://etherscan.io/dapp/0x7fecab617c868bb5996d99d95200d2fa708218e4#readContract). Input the hash (`0x00000000000000000000000000000000000000000000000000000000000000a0`) into "documentHasAchievedMajority." If this returns "true," it means the proposal was passed by the galactic senate.
35+- The Polls contract is [here](https://etherscan.io/dapp/0x7fecab617c868bb5996d99d95200d2fa708218e4#readContract). Input the hash (`0x00000000000000000000000000000000000000000000000000000000000000e0`) into "documentHasAchievedMajority." If this returns "true," it means the proposal was passed by the galactic senate.
3636- If desired, you can verify the above is in fact the real Polls contract by checking "polls" [here](https://etherscan.io/dapp/ecliptic.eth#readContract).
sass/_main.scss+34−14
@@ -215,20 +215,21 @@ body.essay {
215215 img {
216216 display: block;
217217 }
218− div.footnote-definition {
219− &[id="1"] {
220− margin-top: 4rem;
221− padding-top: 2rem;
222− border-top: 1px solid black;
223− }
224− &:not([id="1"]) {
225− margin: 1rem 0;
226− }
227− p {
228− display: inline;
229− font-size: smaller;
230− }
231− }
218+}
219+
220+div.footnote-definition {
221+ &[id="0"] {
222+ margin-top: 4rem;
223+ padding-top: 2rem;
224+ border-top: 1px solid black;
225+ }
226+ &:not([id="0"]) {
227+ margin: 1rem 0;
228+ }
229+ p {
230+ display: inline;
231+ font-size: smaller;
232+ }
232233}
233234
234235// components
@@ -650,3 +651,22 @@ hr {
650651nav::-webkit-scrollbar {
651652 display: none;
652653}
654+
655+
656+// custom anchor styling
657+a.zola-anchor {
658+ visibility: hidden;
659+ padding: 0 0.1rem;
660+ &:hover {
661+ background-color: black;
662+ color: white;
663+ }
664+}
665+
666+h1, h2, h3, h4, h5, h6 {
667+ &:hover > a.zola-anchor {
668+ visibility: visible;
669+ border-bottom-style: none;
670+ }
671+}
672+
static/_redirects+163−12
@@ -1,12 +1,163 @@
1−/docs/introduction /docs 301!
2−/docs/getting-started /using/install 301!
3−/docs/getting-started/azimuth /understanding-urbit/urbit-id 301!
4−/landscape /using/develop 301!
5−/docs/getting-started/using-a-star /using/operations/stars-and-galaxies/ 301!
6−/docs/bridge /using/operations/using-bridge/ 301!
7−/docs/pki /docs/concepts/azimuth/ 301!
8−/docs/arvo/internals/ /docs/tutorials/arvo/ 301!
9−/primer /understanding-urbit/ 301!
10−/install /using/install 301!
11−/install/mac/latest http://github.com/urbit/urbit/releases/latest/download/darwin.tgz
12−/install/linux64/latest http://github.com/urbit/urbit/releases/latest/download/linux64.tgz
1+/primer /understanding-urbit/ 301!
2+/breach /reset 301!
3+/landscape /docs/development/develop 301!
4+/install /getting-started 301!
5+/install/mac/latest http://github.com/urbit/urbit/releases/latest/download/darwin.tgz
6+/install/linux64/latest http://github.com/urbit/urbit/releases/latest/download/linux64.tgz
7+/using/install /getting-started 301!
8+/using/planet /getting-started/planet 301!
9+/using/develop /docs/development/develop 301!
10+/using/integrating-api /docs/arvo/eyre/using-eyre 301!
11+/using/operations /using 301!
12+/using/operations/bridge /using/id/using-bridge 301!
13+/using/operations/hosting /using/running/hosting 301!
14+/using/operations/using-your-ship /using/os/getting-started 301!
15+/using/operations/stars-and-galaxies /using/os/stars-and-galaxies 301!
16+/using/operations/bridge-troubleshooting /using/os/bridge-troubleshooting 301!
17+/docs/getting-started/using-a-star /using/os/stars-and-galaxies/ 301!
18+/docs/bridge /using/id/using-bridge/ 301!
19+/docs/pki /docs/system-overview/azimuth 301!
20+/docs/getting-started/azimuth /understanding-urbit/urbit-id 301!
21+/docs/arvo/internals/ /docs/arvo/overview/ 301!
22+/docs/reference/vane-apis/airlock /docs/arvo/eyre/using-eyre 301!
23+/docs/introduction /docs 301!
24+/docs/getting-started /getting-started 301!
25+/docs/tutorials/concepts/technical-overview /docs/system-overview 301!
26+/docs/tutorials/ship-troubleshooting /using/os/ship-troubleshooting 301!
27+/docs/tutorials/creating-an-invite-pool /using/id/creating-an-invite-pool 301!
28+/docs/tutorials/guide-to-breaches/ /using/id/guide-to-breaches 301!
29+/docs/tutorials/arvo/arvo /docs/arvo/overview 301!
30+/docs/tutorials/arvo/ames /docs/arvo/ames/ames 301!
31+/docs/reference/vane-apis/ames /docs/arvo/ames/ames-api 301!
32+/docs/tutorials/arvo/behn /docs/arvo/behn/behn 301!
33+/docs/reference/vane-apis/behn /docs/arvo/behn/behn-api 301!
34+/docs/tutorials/arvo/clay /docs/arvo/clay/clay 301!
35+/docs/tutorials/arvo/dill /docs/arvo/dill/dill 301!
36+/docs/reference/vane-apis/dill /docs/arvo/dill/dill-api 301!
37+/docs/tutorials/arvo/eyre /docs/arvo/eyre/eyre 301!
38+/docs/tutorials/arvo/gall /docs/arvo/gall/gall 301!
39+/docs/reference/vane-apis/gall /docs/arvo/gall/gall-api 301!
40+/docs/reference/vane-apis/iris /docs/arvo/iris/iris-api 301!
41+/docs/reference/vane-apis/jael /docs/arvo/jael/jael-api 301!
42+/docs/tutorials/arvo/move-trace /docs/arvo/tutorials/move-trace 301!
43+/docs/tutorials/advanced-azimuth-tools /docs/azimuth/advanced-azimuth-tools 301!
44+/docs/tutorials/hoon/hoon-school/aqua /docs/hoon/guides/aqua 301!
45+/docs/tutorials/hoon/cli-tutorial /docs/hoon/guides/cli-tutorial 301!
46+/docs/tutorials/hoon/parsing /docs/hoon/guides/parsing 301!
47+/docs/tutorials/hoon/hoon-school/ackermann /docs/hoon/hoon-school/ackermann 301!
48+/docs/tutorials/hoon/hoon-school/arms-and-cores /docs/hoon/hoon-school/arms-and-cores 301!
49+/docs/tutorials/hoon/hoon-school/atoms-auras-and-simple-cell-types /docs/hoon/hoon-school/atoms-auras-and-simple-cell-types 301!
50+/docs/tutorials/hoon/hoon-school/bank-account /docs/hoon/hoon-school/bank-account 301!
51+/docs/tutorials/hoon/hoon-school/behn /docs/hoon/hoon-school/behn 301!
52+/docs/tutorials/hoon/hoon-school/caesar /docs/hoon/hoon-school/caesar 301!
53+/docs/tutorials/hoon/hoon-school/conditionals /docs/hoon/hoon-school/conditionals 301!
54+/docs/tutorials/hoon/hoon-school/doors /docs/hoon/hoon-school/doors 301!
55+/docs/tutorials/hoon/hoon-school/egg-timer /docs/hoon/hoon-school/egg-timer 301!
56+/docs/tutorials/hoon/hoon-school/fibonacci /docs/hoon/hoon-school/fibonacci 301!
57+/docs/tutorials/hoon/hoon-school/gall /docs/hoon/hoon-school/gall 301!
58+/docs/tutorials/hoon/hoon-school/gates /docs/hoon/hoon-school/gates 301!
59+/docs/tutorials/hoon/hoon-school/generators /docs/hoon/hoon-school/generators 301!
60+/docs/tutorials/hoon/hoon-school/hoon-syntax /docs/hoon/hoon-school/hoon-syntax 301!
61+/docs/tutorials/hoon/hoon-school/iron-polymorphism /docs/hoon/hoon-school/iron-polymorphism 301!
62+/docs/tutorials/hoon/hoon-school/lead-polymorphism /docs/hoon/hoon-school/lead-polymorphism 301!
63+/docs/tutorials/hoon/hoon-school/libraries /docs/hoon/hoon-school/libraries 301!
64+/docs/tutorials/hoon/hoon-school/lists /docs/hoon/hoon-school/lists 301!
65+/docs/tutorials/hoon/hoon-school/list-of-numbers /docs/hoon/hoon-school/list-of-numbers 301!
66+/docs/tutorials/hoon/hoon-school/molds /docs/hoon/hoon-school/molds 301!
67+/docs/tutorials/hoon/hoon-school/nouns /docs/hoon/hoon-school/nouns 301!
68+/docs/tutorials/hoon/hoon-school/recursion /docs/hoon/hoon-school/recursion 301!
69+/docs/tutorials/hoon/hoon-school/setup /docs/hoon/hoon-school/setup 301!
70+/docs/tutorials/hoon/hoon-school/structures-and-complex-types /docs/hoon/hoon-school/structures-and-complex-types 301!
71+/docs/tutorials/hoon/hoon-school/the-subject-and-its-legs /docs/hoon/hoon-school/the-subject-and-its-legs 301!
72+/docs/tutorials/hoon/hoon-school/trees-sets-and-maps /docs/hoon/hoon-school/trees-sets-and-maps 301!
73+/docs/tutorials/hoon/hoon-school/type-checking-and-type-inference /docs/hoon/hoon-school/type-checking-and-type-inference 301!
74+/docs/tutorials/hoon/hoon-school/type-polymorphism /docs/hoon/hoon-school/type-polymorphism 301!
75+/docs/tutorials/hoon/hoon-school/_index /docs/hoon/hoon-school/_index 301!
76+/docs/reference/hoon-expressions/advanced /docs/hoon/reference/advanced 301!
77+/docs/reference/hoon-expressions/basic /docs/hoon/reference/basic 301!
78+/docs/reference/cheat-sheet /docs/hoon/reference/cheat-sheet 301!
79+/docs/tutorials/hoon/hoon-errors /docs/hoon/reference/hoon-errors 301!
80+/docs/reference/hoon-expressions/irregular /docs/hoon/reference/irregular 301!
81+/docs/tutorials/hoon/hoon-school/style /docs/hoon/reference/style 301!
82+/docs/reference/hoon-expressions/limb/limb /docs/hoon/reference/limbs/limb 301!
83+/docs/reference/hoon-expressions/rune/bar /docs/hoon/reference/rune/bar 301!
84+/docs/reference/hoon-expressions/rune/buc /docs/hoon/reference/rune/buc 301!
85+/docs/reference/hoon-expressions/rune/cen /docs/hoon/reference/rune/cen 301!
86+/docs/reference/hoon-expressions/rune/col /docs/hoon/reference/rune/col 301!
87+/docs/reference/hoon-expressions/rune/constants /docs/hoon/reference/rune/constants 301!
88+/docs/reference/hoon-expressions/rune/dot /docs/hoon/reference/rune/dot 301!
89+/docs/reference/hoon-expressions/rune/ket /docs/hoon/reference/rune/ket 301!
90+/docs/reference/hoon-expressions/rune/lus /docs/hoon/reference/rune/lus 301!
91+/docs/reference/hoon-expressions/rune/mic /docs/hoon/reference/rune/mic 301!
92+/docs/reference/hoon-expressions/rune/sig /docs/hoon/reference/rune/sig 301!
93+/docs/reference/hoon-expressions/rune/terminators /docs/hoon/reference/rune/terminators 301!
94+/docs/reference/hoon-expressions/rune/tis /docs/hoon/reference/rune/tis 301!
95+/docs/reference/hoon-expressions/rune/wut /docs/hoon/reference/rune/wut 301!
96+/docs/reference/hoon-expressions/rune/zap /docs/hoon/reference/rune/zap 301!
97+/docs/reference/hoon-expressions/rune/_index /docs/hoon/reference/rune/_index 301!
98+/docs/reference/library/1a /docs/hoon/reference/stdlib/1a 301!
99+/docs/reference/library/1b /docs/hoon/reference/stdlib/1b 301!
100+/docs/reference/library/1c /docs/hoon/reference/stdlib/1c 301!
101+/docs/reference/library/2a /docs/hoon/reference/stdlib/2a 301!
102+/docs/reference/library/2b /docs/hoon/reference/stdlib/2b 301!
103+/docs/reference/library/2c /docs/hoon/reference/stdlib/2c 301!
104+/docs/reference/library/2d /docs/hoon/reference/stdlib/2d 301!
105+/docs/reference/library/2e /docs/hoon/reference/stdlib/2e 301!
106+/docs/reference/library/2f /docs/hoon/reference/stdlib/2f 301!
107+/docs/reference/library/2g /docs/hoon/reference/stdlib/2g 301!
108+/docs/reference/library/2h /docs/hoon/reference/stdlib/2h 301!
109+/docs/reference/library/2i /docs/hoon/reference/stdlib/2i 301!
110+/docs/reference/library/2j /docs/hoon/reference/stdlib/2j 301!
111+/docs/reference/library/2k /docs/hoon/reference/stdlib/2k 301!
112+/docs/reference/library/2l /docs/hoon/reference/stdlib/2l 301!
113+/docs/reference/library/2m /docs/hoon/reference/stdlib/2m 301!
114+/docs/reference/library/2n /docs/hoon/reference/stdlib/2n 301!
115+/docs/reference/library/2o /docs/hoon/reference/stdlib/2o 301!
116+/docs/reference/library/2p /docs/hoon/reference/stdlib/2p 301!
117+/docs/reference/library/2q /docs/hoon/reference/stdlib/2q 301!
118+/docs/reference/library/3a /docs/hoon/reference/stdlib/3a 301!
119+/docs/reference/library/3b /docs/hoon/reference/stdlib/3b 301!
120+/docs/reference/library/3c /docs/hoon/reference/stdlib/3c 301!
121+/docs/reference/library/3d /docs/hoon/reference/stdlib/3d 301!
122+/docs/reference/library/3e /docs/hoon/reference/stdlib/3e 301!
123+/docs/reference/library/3f /docs/hoon/reference/stdlib/3f 301!
124+/docs/reference/library/3g /docs/hoon/reference/stdlib/3g 301!
125+/docs/reference/library/4a /docs/hoon/reference/stdlib/4a 301!
126+/docs/reference/library/4b /docs/hoon/reference/stdlib/4b 301!
127+/docs/reference/library/4c /docs/hoon/reference/stdlib/4c 301!
128+/docs/reference/library/4d /docs/hoon/reference/stdlib/4d 301!
129+/docs/reference/library/4e /docs/hoon/reference/stdlib/4e 301!
130+/docs/reference/library/4f /docs/hoon/reference/stdlib/4f 301!
131+/docs/reference/library/4g /docs/hoon/reference/stdlib/4g 301!
132+/docs/reference/library/4h /docs/hoon/reference/stdlib/4h 301!
133+/docs/reference/library/4i /docs/hoon/reference/stdlib/4i 301!
134+/docs/reference/library/4j /docs/hoon/reference/stdlib/4j 301!
135+/docs/reference/library/4k /docs/hoon/reference/stdlib/4k 301!
136+/docs/reference/library/4l /docs/hoon/reference/stdlib/4l 301!
137+/docs/reference/library/4m /docs/hoon/reference/stdlib/4m 301!
138+/docs/reference/library/4n /docs/hoon/reference/stdlib/4n 301!
139+/docs/reference/library/4o /docs/hoon/reference/stdlib/4o 301!
140+/docs/reference/library/5a /docs/hoon/reference/stdlib/5a 301!
141+/docs/reference/library/5b /docs/hoon/reference/stdlib/5b 301!
142+/docs/reference/library/5c /docs/hoon/reference/stdlib/5c 301!
143+/docs/reference/library/5d /docs/hoon/reference/stdlib/5d 301!
144+/docs/reference/library/5e /docs/hoon/reference/stdlib/5e 301!
145+/docs/reference/library/5f /docs/hoon/reference/stdlib/5f 301!
146+/docs/reference/library/5g /docs/hoon/reference/stdlib/5g 301!
147+/docs/reference/library/table-of-contents /docs/hoon/reference/stdlib/table-of-contents 301!
148+/docs/reference/library/_index /docs/hoon/reference/stdlib/_index 301!
149+/docs/tutorials/concepts/arch /docs/landscape/overview 301!
150+/docs/tutorials/hoon/graph /docs/landscape/reference/graph-store 301!
151+/docs/tutorials/nock/definition /docs/nock/definition 301!
152+/docs/tutorials/nock/example /docs/nock/example 301!
153+/docs/tutorials/nock/explanation /docs/nock/explanation 301!
154+/docs/tutorials/nock/implementations /docs/nock/implementations 301!
155+/docs/tutorials/nock/_index /docs/nock/_index 301!
156+/docs/tutorials/vere/api /docs/vere/api 301!
157+/docs/tutorials/vere/c /docs/vere/c 301!
158+/docs/tutorials/vere/jetting /docs/vere/jetting 301!
159+/docs/tutorials/vere/nouns /docs/vere/nouns 301!
160+/docs/tutorials/vere/runtime /docs/vere/runtime 301!
161+/docs/tutorials/vere/_index /docs/vere/_index 301!
162+/docs/tutorials/concepts/azimuth /docs/azimuth/azimuth 301!
163+/docs/tutorials/advanced-azimuth-tools /docs/azimuth/advanced-azimuth-tools 301!
static/glossary.js+15−99
@@ -637,6 +637,13 @@ var glossary = [
637637 "link": "/docs/reference/hoon-expressions/rune/buc/",
638638 "desc": "Runes used for defining custom types."
639639 },
640+ {
641+ "name": "bucbar",
642+ "symbol": "$|",
643+ "usage": "Structures",
644+ "link": "/docs/reference/hoon-expressions/rune/buc/#bucbar",
645+ "desc": "<code>[%bsbr p=spec q=hoon]</code>: structure that satisfies a validator."
646+ },
640647 {
641648 "name": "buccab",
642649 "symbol": "$_",
@@ -893,128 +900,37 @@ var glossary = [
893900 "name": "fas",
894901 "symbol": "/",
895902 "usage": "Ford",
896− "link": "/docs/tutorials/arvo/ford/#ford-runes",
903+ "link": "/docs/arvo/ford/#ford-runes",
897904 "desc": "Runes specific to Ford, not considered to be Hoon runes."
898905 },
899906 {
900907 "name": "faslus",
901908 "symbol": "/+",
902909 "usage": "Ford",
903− "link": "/docs/tutorials/arvo/ford/#faslus",
910+ "link": "/docs/arvo/ford/#ford-runes",
904911 "desc": "Ford rune. Import from <code>lib/</code>"
905912 },
906913 {
907914 "name": "fashep",
908915 "symbol": "/-",
909916 "usage": "Ford",
910− "link": "/docs/tutorials/arvo/ford/#fashep",
917+ "link": "/docs/arvo/ford/#ford-runes",
911918 "desc": "Ford rune. Import from <code>sur/</code>"
912919 },
913− {
914− "name": "fassig",
915− "symbol": "/~",
916− "usage": "Ford",
917− "link": "/docs/tutorials/arvo/ford/#fassig",
918− "desc": "Ford rune. Twig by hand."
919− },
920− {
921− "name": "fasfas",
922− "symbol": "//",
923− "usage": "Ford",
924− "link": "/docs/tutorials/arvo/ford/#fasfas",
925− "desc": "Ford rune. Include a file by relative path."
926− },
927920 {
928921 "name": "fastis",
929922 "symbol": "/=",
930923 "usage": "Ford",
931− "link": "/docs/tutorials/arvo/ford/#fastis",
924+ "link": "/docs/arvo/ford/#ford-runes",
932925 "desc": "Ford rune. Wrap a face around an included horn."
933926 },
934927 {
935− "name": "fascol",
936− "symbol": "/:",
937− "usage": "Ford",
938− "link": "/docs/tutorials/arvo/ford/#fascol",
939− "desc": "Ford rune. Evaluate at path, and <code>/mark/</code> at current path"
940− },
941− {
942− "name": "faszap",
943− "symbol": "/!",
944− "usage": "Ford",
945− "link": "/docs/tutorials/arvo/ford/#faszap",
946− "desc": "Ford rune. <code>/!mark/</code> evaluates as Hoon, then passes through mark."
947− },
948− {
949− "name": "faspam",
950− "symbol": "/&",
951− "usage": "Ford",
952− "link": "/docs/tutorials/arvo/ford/#faspam",
953− "desc": "Ford rune. Pass through a series of marks."
954− },
955− {
956− "name": "fasbar",
957− "symbol": "/|",
958− "usage": "Ford",
959− "link": "/docs/tutorials/arvo/ford/#fasbar",
960− "desc": "Ford rune. Short-circuiting 'or' "
961− },
962− {
963− "name": "fascab",
964− "symbol": "/_",
928+ "name": "fastar",
929+ "symbol": "/*",
965930 "usage": "Ford",
966− "link": "/docs/tutorials/arvo/ford/#fascab",
967− "desc": "Ford rune. Runs horns on files in the current directory."
931+ "link": "/docs/arvo/ford/#ford-runes",
932+ "desc": "Ford rune. Import file, convert to mark, and wrap a face."
968933 },
969− {
970− "name": "fasmic",
971− "symbol": "/;",
972− "usage": "Ford",
973− "link": "/docs/tutorials/arvo/ford/#fasmic",
974− "desc": "Ford rune. Operate on."
975− },
976− {
977− "name": "fascom",
978− "symbol": "/,",
979− "usage": "Ford",
980− "link": "/docs/tutorials/arvo/ford/#fascom",
981− "desc": "Ford rune. Switch by path."
982− },
983− {
984− "name": "fasdot",
985− "symbol": "/.",
986− "usage": "Ford",
987− "link": "/docs/tutorials/arvo/ford/#fasdot",
988− "desc": "Ford rune. Produces a list from a sequence of horns."
989− },
990− {
991− "name": "fasket",
992− "symbol": "/^",
993− "usage": "Ford",
994− "link": "/docs/tutorials/arvo/ford/#fasket",
995− "desc": "Ford rune. Casts the result of a horn to a mold."
996− },
997− {
998− "name": "fashax",
999− "symbol": "/#",
1000− "usage": "Ford",
1001− "link": "/docs/tutorials/arvo/ford/#fashax",
1002− "desc": "Ford rune. Inserts a dependency hash."
1003− },
1004− {
1005− "name": "fasbuc",
1006− "symbol": "/$",
1007− "usage": "Ford",
1008− "link": "/docs/tutorials/arvo/ford/#fasbuc",
1009− "desc": "Ford rune. Process extra arguments."
1010− },
1011− {
1012− "name": "fascen",
1013− "symbol": "/%",
1014− "usage": "Ford",
1015− "link": "/docs/tutorials/arvo/ford/#fascen",
1016− "desc": "Ford rune. Propagate extra arguments into renderers."
1017− },
1018934 // glossary starts here
1019935 {
1020936 "name": "ames",
templates/anchor-link.htmlnew file+2
@@ -0,0 +1,2 @@
1+<!-- original at https://github.com/getzola/zola/blob/29b073640e26d96ab167c88ca70b18660f176cb4/docs/sass/_docs.scss#L48 -->
2+<a class="zola-anchor" href="#{{ id }}" aria-label="Anchor link for: {{ id }}">¶</a>
templates/essays/post.html+1−1
@@ -95,7 +95,7 @@
9595 </div>
9696 </div>
9797 </form>
98− <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">Github</a>.</p>
98+ <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">GitHub</a>.</p>
9999 <p class="mt0 mb3 mb4-xl lh-copy">Or talk to us on Urbit: <code>~bitbet-bolbel/urbit-community</code></p>
100100</section>
101101{% endblock content %}
templates/index.html+10−10
@@ -19,10 +19,6 @@
1919 <meta name="description" content="Urbit is a simple, durable system for running a personal server that you own 100% and forever.">
2020{% endblock description %}
2121{% block content %}
22−<header class="full ph4 full-bleed-banner f9" style="background-color: #ffc700;">
23− <p>A network-wide breach is scheduled for <b>today</b> at 10am PST. Please visit <a class="bb" href="/breach">urbit.org/breach</a> for more information.</p>
24−</header>
25−
2622<section class="full lh-copy c2-7-md c3-7-lg mt6 mb6">
2723 <p class="mt0 mb4"><strong>Urbit</strong> is a clean-slate OS and network for the 21st century.</p>
2824 <p><strong>Urbit OS</strong> is a reimagining of the operating system as an ‘overlay OS.’</p>
@@ -42,16 +38,20 @@
4238<section class="full lh-copy c2-7-md c3-7-lg mb6">
4339 <ul class="list mt0">
4440 <li class="mt0">
45− <a class="bb" href="/understanding-urbit">Introduction</a><br />
46− Never heard of Urbit before? Start here to read a bit about the project.
41+ <a class="b--blue2 blue2 bb" href="/getting-started/">Get Started</a><br />
42+ Learn more about how to run Urbit and join the network.
4743 </li>
4844 <li class="mt3">
49− <a class="b--blue2 blue2 bb" href="/using/install/">Install + Setup</a><br />
50− If you're comfortable in the command-line, feel free to boot a node and try Urbit.
45+ <a class="b--green2 green2 bb" href="/docs/">Documentation</a><br />
46+ Read our documentation to learn more about the technology.
5147 </li>
5248 <li class="mt3">
53− <a class="b--green2 green2 bb" href="/docs/">Documentation</a><br />
54− To learn more about the technology, head to the docs.
49+ <a class="bb" href="/understanding-urbit">Introduction</a><br />
50+ Never heard of Urbit before? Start here to read a bit about the project.
51+ </li>
52+ <li class="mt3">
53+ <a class="bb" href="/faq">FAQ</a> <br />
54+ Answers to commonly asked questions.
5555 </li>
5656 </ul>
5757</section>
templates/list.html+1
@@ -21,6 +21,7 @@
2121 {{ section.title }}
2222 </a>
2323 {% include "partials/navigation-search.html" %}
24+ <a href="using/install/">Install / Get Started -></a>
2425</nav>
2526<!-- content -->
2627<article class="mt4 mb4 c1-13 c4-12-lg measure-wide">
templates/page/getting_started.htmlnew file+68
@@ -0,0 +1,68 @@
1+{% extends "base.html" %}
2+<!-- JAL(2021.3.12) This page is a hack in order to get the title set properly in the /getting-started/planet route because I'm a Zola noob. -->
3+{% block bodyclasses %}class="page-indiced"{% endblock bodyclasses %}
4+
5+{% block title %}
6+ <meta name="og:title" content="{{ page.title }} - {{ config.title }}">
7+ <title>{{ page.title }} - {{ config.title }}</title>
8+{% endblock title %}
9+
10+{% block description %}
11+ {% if page.description %}
12+ <meta name="og:description" content="{{ page.description }}">
13+ <meta name="description" content="{{ page.description }}">
14+ {% else %}
15+ <meta name="og:description" content="{{ config.description }}">
16+ <meta name="description" content="{{ config.description }}">
17+ {% endif %}
18+{% endblock description %}
19+
20+{% block image %}
21+ {% if page.extra.image %}
22+ <meta name="twitter:image" content="{{ page.extra.image }}">
23+ {% else %}
24+ <meta name="twitter:image" content="https://media.urbit.org/logo/urbit-logo-card.png">
25+ {% endif %}
26+{% endblock image %}
27+
28+{% block content %}
29+
30+<!-- header -->
31+<!-- content -->
32+<nav class="mt4 fixed-xl full fourth-1-lg page-indiced mb3 mb0-m mb0-l mb0-xl">
33+ <a class="gray3" href="/">Urbit</a>
34+ <span class="gray3"> / </span>
35+ <a href="/{{ page.components[0] }}{% if page.components[2] %}/{{ page.components[1] }}{% endif %}">
36+ Getting Started
37+ </a>
38+
39+ {% include "partials/navigation-search.html" %}
40+
41+{% for h2 in toc %}
42+{% if h2.children %}
43+<details class="dn mw5-xl mt2 mw5-l db-xl page-indiced f6"><summary>{{ h2.title }}</summary>
44+ {% for h3 in h2.children %}
45+ <li class="ml3 mv1"><a href="{{h3.permalink | safe}}">{{h3.title}}</a></li>
46+ {% endfor %}
47+</details>
48+{% else %}
49+ <li class="dn mw5-xl mw5-l db-xl page-indiced mv2"><a class="f6" href="{{h2.permalink}}">{{h2.title}}</a></li>
50+{% endif %}
51+{% endfor %}
52+</nav>
53+ <article class="mt4 mb6 c1-13 c4-12-lg measure-wide">
54+ {% if page.extra.hidetitle %} {% else %}<h1>{{ page.title }}</h1>{% endif %}
55+ {% if page.extra.author %}
56+ <span class="mt2 dib" rel="author"> {{ page.extra.author }} </span>
57+ {% if page.extra.ship %}
58+ <address class="mono">{{ page.extra.ship }}</address>
59+ {% endif %}
60+ {% if page.date %}
61+ <time class="mono db mv1 gray4 f5">{{page.date | date(format="~%Y.%-m.%-d") }}</time>
62+ {% endif %}
63+ {% endif %}
64+ <!-- body -->
65+ {{ page.content | safe }}
66+ {% include "partials/pagination.html" %}
67+ </article>
68+{% endblock content %}
templates/page_indiced.html+2−1
@@ -44,7 +44,8 @@
4444 <a class="gray3" href="/">Urbit</a>
4545 <span class="gray3"> / </span>
4646 <a href="/{{ page.components[0] }}{% if page.components[2] %}/{{ page.components[1] }}{% endif %}">
47− {% if page.components[2] %}{{ page.components[1] | capitalize }}
47+ {% if page.components[2] %}
48+ {{ page.components[1] | capitalize }}
4849 {% else %}
4950 {{ page.components[0] | capitalize }}
5051 {% endif %}
templates/partials/footer.html+5−5
@@ -18,9 +18,9 @@
1818
1919 <nav class="c7-10-md c7-9-lg half-1 mt5">
2020 <h3 class="mt0 mb3 pt0 pb0">Using + Contributing</h3>
21− <li class="mt2 f6"><a href="/using/install">Install + Setup</a></li>
22− <li class="mt2 f6"><a href="/using/develop">Developer's Guide</a></li>
23− <li class="mt2 f6"><a href="/using/operations">Operations Manual</a></li>
21+ <li class="mt2 f6"><a href="/getting-started">Getting Started</a></li>
22+ <li class="mt2 f6"><a href="/using">Operations Manual</a></li>
23+ <li class="mt2 f6"><a href="/docs/development/develop">Developer's Guide</a></li>
2424 </nav>
2525 <nav class="c10-13-md c9-11-lg half-2 mt5">
2626 <h3 class="mt0 mb3 pt0 pb0">Community</h3>
@@ -34,7 +34,7 @@
3434 <section class="full-bleed full grid12">
3535 <nav class="c1-4-md c3-5-lg half-1 mt4 mb5">
3636 <h3 class="mt0 mb3 pt0 pb0">Developers</h3>
37− <li class="mt2 f6"><a href="/docs">Documentation</a></li>
37+ <li class="mt2 f6"><a href="/docs">Developer Documentation</a></li>
3838 <li class="mt2 f6"><a href="https://grants.urbit.org">Developer Grants</a></li>
3939 <li class="mt2 f6"><a href="/bounties">Security Bounties</a></li>
4040 </nav>
@@ -47,7 +47,7 @@
4747 <h2 class="mb3">Need help?</h2>
4848 <li class="mt2 f6"><a href="mailto:support@urbit.org">support@urbit.org </a></li>
4949 <li class="mt2 f6"><a href="https://discord.gg/Mae2bk7">Discord</a></li>
50− <li class="mt2 f6"><a href="https://github.com/urbit">Github</a></li>
50+ <li class="mt2 f6"><a href="https://github.com/urbit">GitHub</a></li>
5151 </nav>
5252 </section>
5353</footer>
templates/partials/navigation-docs.html+58−10
@@ -1,9 +1,12 @@
11<!-- First nav is desktop-specific. Second nav is dropdown version for mobile. -->
22
33{% set sectionTitle = "urbit.org" %}
4+{% set directory = "docs" %}
45{% if page %}
56 {% if "docs" in page.components %}
67 {% set sectionTitle = "Docs" %}
8+ {% elif "using" in page.components %}
9+ {% set directory = "using" %}
710 {% endif %}
811 {% if "updates" in page.components %}
912 {% set sectionTitle = "Updates" %}
@@ -16,6 +19,8 @@
1619{% if section %}
1720 {% if "docs" in section.components %}
1821 {% set sectionTitle = "Docs" %}
22+ {% elif "using" in section.components %}
23+ {% set directory = "using" %}
1924 {% endif %}
2025 {% if "updates" in section.components %}
2126 {% set sectionTitle = "Updates" %}
@@ -26,27 +31,70 @@
2631{% endif %}
2732
2833{% block content %}
34+{% if section %}
35+ {%- set base = section.components[0] -%}
36+{% elif page %}
37+ {%- set base = page.components[0] -%}
38+{% endif %}
2939<nav class="bg-gray5 dn db-xl pt4 full-left no-break docs pr4">
3040 <a class="gray3" href="{{config.base_url}}">Urbit</a>
3141 <span class="gray3"> / </span>
42+ {% if base == "docs" %}
3243 <a href="{{config.base_url}}/docs/">
33− Documentation
44+ Development Docs
3445 </a>
35−<button id="js-search-window-toggle" class="pointer pa0 pv3 dn db-m db-l db-xl bw-0 relative" type="button"
46+ {% elif base == "using" %}
47+ <a href="{{config.base_url}}/using/">
48+ Usage Docs
49+ </a>
50+ {% endif %}
51+ <button id="js-search-window-toggle" class="pointer pa0 pv3 dn db-m db-l db-xl bw-0 relative" type="button"
3652 style="outline:none">
37− <span class="dib pv1 v-mid gray3">Search {{sectionTitle}}</span>
53+ <span class="dib pv1 v-mid gray3">Search Docs</span>
3854 <span class="ml1 pa1 dib v-mid ba br1 b--gray3 gray3 f7" id="keyhint">Ctrl + /</span>
3955</button>
4056 <ul class="lh-copy">
41− <li class="ml2 mt1"><a href="/using/install">Install -> </a></li>
42− <li class="ml2 mt1"><a href="/using/operations/">Operations Manual -></a></li>
43− <li class="ml2 mt1 mb4"><a href="/using/develop/">Developer's Guide -></a></li>
57+ <li class="ml2 mt1"><a href="/getting-started">Install / Get Started -> </a></li>
58+ <li class="ml2 mt1">
59+ <a href="/using/"
60+ {% if base == "using" %}
61+ class="fw6"
62+ {% endif %}
63+ >
64+ Usage Docs ->
65+ </a>
66+ </li>
67+ <li class="ml2 mt1 mb4">
68+ <a href="/docs/"
69+ {% if base == "docs" %}
70+ class="fw6"
71+ {% endif %}
72+ >
73+ Development Docs ->
74+ </a>
75+ </li>
4476 {% block menu %}
45− {% set index = get_section(path="docs/_index.md") %}
77+ <li class="ml3 mt1">
78+ <a
79+ {% if section and section.relative_path == "docs/_index.md" %}
80+ class="fw6"
81+ {% elif section and section.relative_path == "using/_index.md" %}
82+ class="fw6"
83+ {% endif %}
84+ {% if base == "docs" %}
85+ href="/docs"
86+ {% elif base == "using" %}
87+ href="/using"
88+ {% endif %}
89+ >
90+ Introduction
91+ </a>
92+ </li>
93+ {% set index = get_section(path=directory ~ "/_index.md") %}
4694 {% for s in index.subsections %}
4795 {% set subsection = get_section(path=s) %}
4896 {% if subsection.extra.nav %}
49− <li class="ml3 mt1"><a
97+ <li class="ml3 mt2"><a
5098 {% if current_url == subsection.permalink %}
5199 class="fw6"
52100 {% endif %}
@@ -126,8 +174,8 @@
126174 <select class="db mt4 pa2 b--black ba br0 mw4 f6 fw5" id="docsSelect" style="text-indent: 0.725rem;">
127175 <option>Navigation ↓</option>
128176 <option> </option>
129− <option value="https://urbit.org/using/install">Install</option>
130− <option value="https://urbit.org/using/operations/">Operations Manual</option>
177+ <option value="https://urbit.org/getting-started">Install</option>
178+ <option value="https://urbit.org/using">Operations Manual</option>
131179 <option value="https://urbit.org/using/develop">Developer's Guide</option>
132180 {% set index = get_section(path="docs/_index.md") %}
133181 {% for s in index.subsections %}
templates/sections/docs/hoon.html+1−1
@@ -25,7 +25,7 @@
2525<div class="measure-wide mb4">
2626{{ section.content | safe }}
2727
28−{% set lessons = get_section(path="docs/tutorials/hoon/hoon-school/_index.md") %}
28+{% set lessons = get_section(path="docs/hoon/hoon-school/_index.md") %}
2929
3030<ul>
3131 <h2 class="mv4">Chapter 1</h2>
templates/understanding-urbit/list.html+2−2
@@ -57,7 +57,7 @@
5757 <p class="full mt0 mb4 mb4-xl lh-copy b">2 - User experience</p>
5858 <p class="full mt0 mb4 mb4-xl lh-copy">We want Urbit to be a single, simple interface for your whole digital life.</p>
5959 <img class="full ba mb4" src="https://media.urbit.org/site/understanding-urbit/uu-intro-4.png"/>
60− <p class="full mt0 mb4 mb4-xl lh-copy">Over the years, Urbit has been built in public as an open source project. Anyone can <a class="bb" href="/using/install/">join the network</a> and check out what we’re up to. It’s a bit like signing on to IRC in the early 90s. </p>
60+ <p class="full mt0 mb4 mb4-xl lh-copy">Over the years, Urbit has been built in public as an open source project. Anyone can <a class="bb" href="/getting-started/">join the network</a> and check out what we’re up to. It’s a bit like signing on to IRC in the early 90s. </p>
6161 <p class="full mt0 mb4 mb4-xl lh-copy">In early 2020, we released Urbit OS 1: a minimal interface for group communication, and our first complete interface. OS 1 is a tool to chat, share notes and links, and stay connected. </p>
6262 <p class="full mt0 mb4 mb4-xl lh-copy">OS 1 is the first step toward a truly complete OS for a networked world. </p>
6363 <p class="full mt0 mb4 mb4-xl lh-copy">Over time, Urbit will grow into a system that can bring together all our different modes of communicating: chat, payments, documents, images, biometric data. We want individuals and their communities to be able to both control their software in fact, through the source code, and in action, through a simple interface.</p>
@@ -110,7 +110,7 @@
110110 </div>
111111 </div>
112112 </form>
113− <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">Github</a>.</p>
113+ <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">GitHub</a>.</p>
114114 <p class="mt0 mb3 mb4-xl lh-copy">Or, preferably, on Urbit itself in the <code>~bitbet-bolbel/urbit-community</code></p>
115115</section>
116116{% endblock content %}
templates/understanding-urbit/post.html+1−1
@@ -104,7 +104,7 @@
104104 </div>
105105 </div>
106106 </form>
107− <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">Github</a>.</p>
107+ <p class="mt3 mb3 mb3-xl lh-copy">You can also follow us on <a class="bb" href="https://twitter.com/urbit">Twitter</a> or <a class="bb" href="https://github.com/urbit">GitHub</a>.</p>
108108 <p class="mt0 mb3 mb4-xl lh-copy">Or talk to us on Urbit: <code>~bitbet-bolbel/urbit-community</code></p>
109109 </section>
110110{% endblock content %}