1202 files changed+60218−71122
.gitignore+45−3
@@ -1,4 +1,46 @@
1−# OS
1+# See https://help.github.com/articles/ignoring-files/ for more about ignoring files.
2+
3+# dependencies
4+/node_modules
5+/.pnp
6+.pnp.js
7+
8+# testing
9+/coverage
10+
11+# next.js
12+/.next/
13+/out/
14+.next
15+
16+# production
17+/build
18+/cache
19+
20+# misc
221.DS_Store
3−# etc
4−*.swn
22+*.pem
23+
24+# debug
25+npm-debug.log*
26+yarn-debug.log*
27+yarn-error.log*
28+
29+# local env files
30+.env
31+.env.local
32+.env.development.local
33+.env.test.local
34+.env.production.local
35+
36+# vercel
37+.vercel
38+
39+# editors
40+/.nova/
41+
42+# rss
43+public/rss.xml
44+
45+yarn.lock
46+
.gitmodulesdeleted−3
@@ -1,3 +0,0 @@
1−[submodule "docs/hoon/workbook"]
2− path = docs/hoon/workbook
3− url = git@github.com:urbit/hoon-workbook.git
.npmrcnew file+1
@@ -0,0 +1 @@
1+unsafe-perm = true
.prettierrcnew file+5
@@ -0,0 +1,5 @@
1+{
2+ "tabWidth": 2,
3+ "useTabs": false,
4+ "printWidth": 80
5+}
README.markdowndeleted−3
@@ -1,3 +0,0 @@
1−# Urbit Docs
2−
3−Urbit documentation as it appears on [urbit.org](https://urbit.org/docs/).
README.mdnew file+58
@@ -0,0 +1,58 @@
1+The website for Urbit is maintained by the Urbit Foundation and the Urbit community. Issues and contributions are welcome.
2+
3+## Getting Started
4+
5+1. Fork the [Urbit site repository](https://github.com/urbit/urbit.org).
6+
7+2. [Create a local clone](https://help.github.com/articles/cloning-a-repository/) of your fork.
8+
9+3. Navigate to the `urbit.org` directory and install Node 14 using [nvm](https://github.com/nvm-sh/nvm):
10+
11+ ```shell
12+ cd urbit.org
13+ nvm install 14
14+ ```
15+ You can then run `nvm use` whenever in the repository (or automate it with a script - see [here](https://github.com/nvm-sh/nvm#deeper-shell-integration)).
16+
17+4. Install our dependencies:
18+
19+ ```shell
20+ npm install
21+ ```
22+
23+ If running an arm64 Mac (M1 or later), you may need to install some dependencies to compile canvas, one of our dependencies. Assuming you have [Homebrew](https://brew.sh):
24+
25+ ```shell
26+ arch -arm64 brew install pkg-config cairo pango libpng jpeg giflib librsvg
27+ ```
28+
29+5. Run the development server:
30+
31+ ```shell
32+ npm run dev
33+ # or
34+ yarn dev
35+ ```
36+
37+ Open [http://localhost:3000](http://localhost:3000) with your browser to see the result.
38+
39+To learn more about contributing, see GitHub's [documentation](https://docs.github.com/en/get-started/quickstart/contributing-to-projects).
40+
41+## Framework and Library Documentation
42+
43+To learn more about Next.js, take a look at the following resources:
44+
45+- [Next.js Documentation](https://nextjs.org/docs) - learn about Next.js features and API.
46+- [Learn Next.js](https://nextjs.org/learn) - an interactive Next.js tutorial.
47+
48+To learn more about Tailwind CSS, take a look at the docs:
49+
50+- [Tailwind CSS Docs](https://tailwindcss.com/docs) - Docs
51+
52+## Deployment
53+
54+We deploy using Vercel. All pull requests will show a deployment preview via the same.
55+
56+## Upgrades
57+
58+The `/scripts` contains scripts used to programmatically upgrade site content data.
_index.mddeleted−56
@@ -1,56 +0,0 @@
1−+++
2−title = "Development Docs"
3−weight = 1
4−template = "sections/docs.html"
5−+++
6−
7−Welcome to the developer documentation for the Urbit project. This documentation
8−is maintained by [Tlon](https://tlon.io) and the Urbit community in a public
9−[Github repository](https://github.com/urbit/docs). Issues and contributions are
10−welcome.
11−
12−This documentation provides a series of explainers, guides, tutorials and
13−reference material for assisting you in developing on the Urbit platform, or
14−contributing to the Urbit project. If you're looking for documentation on how to
15−*use* your Urbit ship, see our [usage docs](@/using/_index.md).
16−
17−### [Development](@/docs/development/_index.md)
18−
19−The Development section is recommended reading for developers interested in
20−contributing to Urbit itself, or building apps on top of Urbit. It serves as a
21−high-level orientation to how to set up a development environment, the various
22−codebases that comprise the project, our grants program, and the precepts that
23−drive the development of Urbit.
24−
25−### [System Overview](@/docs/system-overview/_index.md)
26−
27−This section gives a high-level overview to all the major components of the
28−Urbit tech stack - namely, the operating system Arvo, the programming languages
29−Nock and Hoon, the runtime Vere, and the decentralized ID system Azimuth.
30−
31−### [Arvo (Urbit OS)](@/docs/arvo/_index.md)
32−
33−This section covers the kernel of Urbit OS, called Arvo, as well as its kernel modules.
34−
35−### [Hoon (High-level Language)](@/docs/hoon/_index.md)
36−
37−Here is contained all official documentation on Hoon, the high-level purely
38−functional programming language in which Arvo and much of userspace is written.
39−
40−### [Nock (Low-level Language)](@/docs/nock/_index.md)
41−
42−Official guidance on Nock, the functional assembly-level language which serves
43−as the basis for Hoon.
44−
45−### [Vere (Interpreter)](@/docs/vere/_index.md)
46−
47−Documentation on Vere, the Nock virtual machine which serves as the interface
48−between Urbit and Unix.
49−
50−### [Azimuth (Urbit ID)](@/docs/azimuth/_index.md)
51−
52−The workings of Azimuth, the decentralized ID system utilized by Urbit.
53−
54−### [Userspace](@/docs/userspace/_index.md)
55−
56−Developer guides for Gall (the vane for controlling userspace apps), Landscape (the web client by which most users interact with their ship), and Threads (transient apps for IO).
anchors.pydeleted−135
@@ -1,135 +0,0 @@
1−#!/usr/bin/env python3
2−
3−import os
4−import sys
5−from pathlib import Path
6−from typing import List, Tuple
7−
8−
9−# inspired by weights.sh
10−
11−# NOTE: This script does not prevent you from shooting yourself in the foot.
12−# If you manually set a bogus value for insert_anchor_links it will not fix it for you
13−"""
14−1. get a list of all .md files
15−2. for each md file
16− a. get front matter
17− b. get value of key `insert_anchor_links`, default to none if not present
18− c. output a tuple of (setting, file)
19−3. accumulate all anchor setting values for all md files
20−4. write tuple to 'anchors' file, prompt to edit, open in preferred editor
21−5. once prompt is answered, read back file
22−6. read edited 'anchors' file, overwrite new setting for each file
23−"""
24−
25−ANCHOR_KEY = "insert_anchor_links = "
26−ANCHOR_FILE = "anchors"
27−
28−def nth_occurrence(arr, target_value, wanted_idx):
29− return [idx for idx, val in enumerate(arr) if val == target_value][wanted_idx - 1]
30−
31−def validate_entry(setting: str, file: str):
32− if not setting in ["left", "right", "none"]:
33− sys.exit(f"Invalid setting '{setting}' provided for file '{file}'")
34−
35−
36−def find_all_mds() -> List[str]:
37− # the `insert_anchor_links` is only applicable on `_index.md` files (i.e. sections)
38− return [str(p) for p in Path('./').rglob('**/_index.md')]
39−
40−def setting_from_frontmatter(lines: List[str]) -> str:
41− # 'insert_anchor_links = "none"' -> 'none'
42− for line in lines:
43− if line.startswith(ANCHOR_KEY):
44− # 1. 'insert_anchor_links = "none"\n'
45− # 2. ['insert_anchor_links = ' '"none"\n'][1] => '"none"\n'
46− # 3. "none\n"
47− # 4. "none"
48− return line \
49− .split(ANCHOR_KEY)[1] \
50− .replace('\"', '') \
51− .replace('\n', '')
52−
53− return "none" # default setting if key not present
54−
55−def anchors_from_frontmatter(md_files: List[str]) -> List[Tuple[str, str]]:
56− # returns tuple(setting, file)
57− anchor_settings = []
58−
59− for md_file in md_files:
60− with open(md_file, "r") as f:
61− lines = f.readlines()
62− setting = setting_from_frontmatter(lines)
63− anchor_settings.append((setting, md_file))
64−
65− return anchor_settings
66−
67−def write_anchor_file(anchor_settings: List[Tuple[str, str]]):
68− with open(ANCHOR_FILE, "w+") as f:
69− for setting, file in anchor_settings:
70− f.write(f"{setting} {file}\n")
71−
72−
73−def prompt_editor():
74− editor = os.getenv('EDITOR', 'nano')
75− os.system(f"{editor} {ANCHOR_FILE}")
76− input("Edit the anchor settings and press enter...")
77−
78−def read_anchor_file() -> List[Tuple[str, str]]:
79− anchor_settings = []
80−
81− with open(ANCHOR_FILE, "r") as f:
82− for line in f:
83− line = line.replace('\n', '')
84− setting, file = line.split(' ')
85− anchor_settings.append((setting, file))
86−
87− return anchor_settings
88−
89−
90−def write_entry(setting: str, file: str):
91− validate_entry(setting, file)
92−
93−
94− # not optimized
95− with open(file, "r+") as f:
96− lines = f.readlines()
97− # lines = list(filter(bool, text.split('\n'))) # split text by lines,
98− fm_end = nth_occurrence(lines, "+++\n", 2) # get index of end of front matter (signaled by second '+++')
99−
100− # remove existing setting if it exists
101− for line in lines[:fm_end]:
102− if line.startswith(ANCHOR_KEY):
103− lines.remove(line)
104− fm_end -= 1 # correct the index for the removal
105−
106− if setting != "none":
107− # by default, there is no need to specify "none"
108− lines.insert(fm_end, ANCHOR_KEY + f'"{setting}"' + '\n') # insert the setting right before the end of front matter
109− f.seek(0) # go to beginning of file
110− f.writelines(lines) # overwrite with new contents
111− f.truncate() # idk why but necessary for bug-free behviour (otherwise it adds excess newlines and stuff)
112−
113−
114−
115−def anchors_to_frontmatter(anchor_settings: List[Tuple[str, str]]):
116− for setting, file in anchor_settings:
117− write_entry(setting, file)
118−
119−def cleanup():
120− os.remove("anchors")
121−
122−
123−def main():
124− files = find_all_mds()
125− print(f'found {len(files)} .md files')
126− write_anchor_file(anchors_from_frontmatter(files))
127− prompt_editor()
128− anchors_to_frontmatter(read_anchor_file())
129− cleanup()
130− print('done')
131−
132−
133−if __name__ == '__main__':
134− main()
135−
arvo/_index.mddeleted−55
@@ -1,55 +0,0 @@
1−+++
2−title = "Arvo"
3−weight = 300
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−aliases = ["/docs/learn/arvo/"]
7−+++
8−
9−Resources about the Urbit OS.
10−
11−## [Overview](@/docs/arvo/overview.md)
12−
13−Arvo is Urbit's functional operating system, written in [Hoon](@/docs/hoon/hoon-school/_index.md). It's composed of modules called _vanes_, each of which has its own folder:
14−
15−## [Ames](@/docs/arvo/ames/ames.md)
16−
17−Ames is the name of our network and the vane that communicates over it. It's an encrypted P2P network composed of instances of the Arvo operating system.
18−
19−## [Behn](@/docs/arvo/behn/behn.md)
20−
21−Behn is our timer. It allows vanes and applications to set and timer events, which are managed in a simple priority queue.
22−
23−## [Clay](@/docs/arvo/clay/clay.md)
24−
25−Clay is our filesystem and revision-control system.
26−
27−## [Dill](@/docs/arvo/dill/dill.md)
28−
29−Dill is our terminal driver. Unix sends keyboard events to dill from the terminal, and dill produces terminal output.
30−
31−## [Eyre](@/docs/arvo/eyre/eyre.md)
32−
33−Eyre is our HTTP server. Unix sends HTTP messages to `%eyre`, and `%eyre` produces HTTP messages in response.
34−
35−## [Ford](@/docs/arvo/ford/ford.md)
36−
37−Ford is our build system. It handles resources and publishing.
38−
39−## [Gall](@/docs/arvo/gall/overview.md)
40−
41−Gall is the vane for controlling userspace apps.
42−
43−## [Iris](@/docs/arvo/iris/iris-api.md)
44−
45−Iris is our HTTP client.
46−
47−## [Concepts](@/docs/arvo/concepts/_index.md)
48−
49−Explanations of design decisions that are pervasive throughout Arvo.
50−
51−## [Tutorials](@/docs/arvo/tutorials/_index.md)
52−
53−Walkthroughs that teach you more about how Arvo works.
54−
55−
arvo/ames/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Ames"
3−weight = 10
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/ames/ames-api.mddeleted−292
@@ -1,292 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 10
4−template = "doc.html"
5−+++
6−
7−In this document we describe the public interface for Ames. Namely, we describe
8−each `task` that Ames can be `%pass`ed, and which `gift`(s) Ames can `%give` in return.
9−
10−Some `task`s appear to have more than one arm associated to them, e.g. there are
11−four `+on-hear` arms. We denote this where it occurs, but always refer to the
12−`on-hear:event-core` arm.
13−
14−Ames `task`s can be naturally divided into two categories: messaging tasks and
15−system/lifecycle tasks.
16−
17−## Messaging Tasks
18−
19−### `%hear`
20−
21−`%hear` handles raw packet receipt. This `task` only ever originates from Unix.
22−It does the initial processing of a packet, namely by passing the raw packet
23−information to `+decode-packet` which deserializes the packet and giving that data and the origin of the
24−packet to `+on-hear-packet`, which begins the transformation of the packet into
25−a new event in the form of a `+event-core`.
26−
27−There are multiple `+on-hear` arms in `ames.hoon`. Here we refer to
28−`on-hear:event-core`, as that is the one called by a `%hear` `task`. The other ones are used
29−primarily for ack and nack processing, or receiving message fragments.
30−
31−#### Accepts
32−
33−```hoon
34−[=lane =blob]
35−```
36−
37−`%hear` takes in a `blob`, which is essentially a large atom (around 1kB or less)
38−that is the raw data of the message, and a `lane`, which is the origin of the
39−message (typically an IP address).
40−
41−#### Returns
42−
43−`%hear` can trigger a number of possible returns. It can trigger the release of
44−zero or more additional packets via `%send` `gift`s. It may also trigger a `%boon`
45−or `%plea` `gift` (collectively referred to as a `%memo` within Ames) to a local vane in the case of a completed message.
46−
47−
48−### `%heed`
49−
50−A vane can pass Ames a `%heed` `task` to request Ames track a peer's
51−responsiveness. If our `%boon`s to it start backing up locally,
52−Ames will `give` a `%clog` back to the requesting vane containing the
53−unresponsive peer's Urbit address.
54−
55−Stop tracking a peer by sending Ames a
56−`%jilt` `task`.
57−
58−
59−#### Accepts
60−
61−```hoon
62−=ship
63−```
64−
65−The ship to be tracked.
66−
67−#### Returns
68−
69−If the `ship` is indeed being unresponsive, as measured by backed up `%boon`s,
70−Ames will `give` a `%clog` `gift` to the requesting vane containing the
71−unresponsive peer's urbit address.
72−
73−
74−### `%hole`
75−
76−`%hole` handles packet crash notification. `%hole` works much like `%hear`, in
77−that it passes an incoming raw packet to `+decode-packet` to be deserialized,
78−and then passes that data along with the source of the packet to
79−`+on-hear-packet` along with a `?` set to `%.n` denoting that there is something wrong with
80−the packet.
81−
82−#### Accepts
83−
84−```hoon
85−[=lane =blob]
86−```
87−`%hole` takes in a `blob`, which is essentially a large atom (around 1kB or less)
88−that is the raw data of the message, and a `lane`, which is the origin of the
89−message (typically an IP address).
90−
91−#### Returns
92−
93−Like `%hear`, `%hole` can trigger additional packets in the form of `%send`
94−`gift`s, and may also yield a `%boon` or `%plea` `gift` to a local vane.
95−
96−
97−### `%jilt`
98−
99−`%jilt` stops tracking a potentially unresponsive peer that was previously being
100−tracked as a result of the `%heed` `task`.
101−
102−There are two `+on-jilt` arms, this `task` utilizes `on-hear:event-core`.
103−
104−#### Accepts
105−
106−```hoon
107−=ship
108−```
109−
110−The `ship` we no longer wish to track.
111−
112−#### Returns
113−
114−This `task` returns no `gift`s.
115−
116−
117−### `%plea`
118−
119−`%plea` is the `task` used to instruct Ames to send a message. It extends the
120−`%pass`/`%give` semantics across the network. As such, it is the most
121−fundamental `task` in Ames and the primary reason for its existence.
122−
123−Ames also `pass`es a `%plea` `note` to another vane when it receives a message on a
124−"forward flow" from a peer, originally passed from one of the peer's vanes to the
125−peer's Ames.
126−
127−Ultimately `%plea` causes `%send` `gift`(s) to be sent to Unix, which tells
128−Unix to send packets. In terms of `%pass`/`%give` semantics, this is in
129−response to the `%born` `task`, which came along the Unix `duct`, rather than a
130−response to the `%plea`.
131−
132−#### Accepts
133−
134−```hoon
135−[=ship =plea]
136−```
137−
138−A `%plea` `task` takes in the `ship` the `plea` is addressed to, and a `$plea`,
139−which is
140−
141−```hoon
142− +$ plea [vane=@tas =path payload=*]
143−```
144−Here, `vane` is the destination vane on the remote ship, `path` is the internal
145−route on the receiving ship, and `payload` is the semantic message content.
146−
147−#### Returns
148−
149−This `task` returns no `gift`s.
150−
151−## System and Lifecycle Tasks
152−
153−### `%born`
154−
155−Each time you start your Urbit, the Arvo kernel calls the `%born` task for Ames.
156−
157−#### Accepts
158−
159−`%born` takes no arguments.
160−
161−#### Returns
162−
163−In response to a `%born` `task`, Ames `%give`s Jael a `%turf` `gift`.
164−
165−The `duct` along which `%born` comes is Ames' only duct to Unix, so `%send`
166−`gift`s (which are instructions for Unix to send a packet) are also returned in
167−response to `%born`.
168−
169−
170−### `%crud`
171−
172−`%crud` is called whenever an error involving Ames occurs. It produces a crash
173−report in response.
174−
175−#### Accepts
176−
177−```hoon
178−=error
179−```
180−
181−A `$error` is a `[tag=@tas =tang]`.
182−
183−#### Returns
184−
185−Ames does not `give` a `gift` in response to a `%crud` `task`, but it does
186−`%pass` Dill a `%flog` `task` instructing it to print `error`.
187−
188−
189−## `%init`
190−
191−`%init` is called a single time during the very first boot process, immediately
192−after the [larval stage](@/docs/arvo/overview.md#larval-stage-core)
193−is completed. This initializes the vane. Jael is initialized first, followed by
194−other vanes such as Ames.
195−
196−In response to receiving the `%init` `task`, Ames subscribes to the information
197−contained by Jael.
198−
199−#### Accepts
200−
201−```hoon
202−our=ship
203−```
204−
205−`%init` takes in the name of our ship, which is a `@p`.
206−
207−#### Returns
208−
209−```hoon
210− =~ (emit duct %pass /turf %j %turf ~)
211− (emit duct %pass /private-keys %j %private-keys ~)
212−```
213−
214−`%init` sends two moves that subscribe to `%turf` and `%private-keys` in Jael.
215−
216−
217−### `%sift`
218−
219−This `task` filters debug output by ship.
220−
221−#### Accepts
222−
223−```hoon
224−ships=(list ship)
225−```
226−
227−The list of ships for which debug output is desired.
228−
229−#### Returns
230−
231−This `task` returns no `gift`s.
232−
233−
234−### `%spew`
235−
236−Sets verbosity toggles on debug output. These toggles are as follows.
237−
238−* `%snd` - sending packets
239−* `%rcv` - receiving packets
240−* `%odd` - unusual events
241−* `%msg` - message-level events
242−* `%ges` - congestion control
243−* `%for` - packet forwarding
244−* `%rot` - routing attempts
245−
246−Each toggle is a flag set to `%.n` by default.
247−
248−#### Accepts
249−
250−```hoon
251−verbs=(list verb)
252−```
253−
254−`%spew` takes in a `list` of `verb`, which are verbosity flags for Ames.
255−
256−```hoon
257−+$ verb ?(%snd %rcv %odd %msg %ges %for %rot)
258−```
259−
260−`%spew` flips each toggle given in `verbs`.
261−
262−#### Returns
263−
264−This `task` returns no `gift`s.
265−
266−
267−### `%vega`
268−
269−`%vega` is called whenever the kernel is updated. Ames currently does not do
270−anything in response to this.
271−
272−#### Accepts
273−
274−`%vega` takes no arguments.
275−
276−#### Returns
277−
278−This `task` returns no `gift`s.
279−
280−
281−### `%wegh`
282−
283−This `task` is a request to Ames to produce a memory usage report.
284−
285−#### Accepts
286−
287−This `task` has no arguments.
288−
289−#### Returns
290−
291−In response to this `task,` Ames `%give`s a `%mass` `gift` containing Ames'
292−current memory usage.
arvo/ames/ames.mddeleted−423
@@ -1,423 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−aliases = ["/docs/learn/arvo/ames/"]
6−+++
7−Our networking protocol.
8−
9−Ames is the name of both our network and the vane that communicates
10−over it. When Unix receives a packet over the correct UDP port, it pipes
11−it straight into Ames for handling. Also, all packets sent over the
12−Ames network are sent by the Ames vane. Apps and vanes may use
13−Ames to directly send messages to other ships. In general, apps use
14−[Gall](@/docs/userspace/gall/gall.md) and [Clay](@/docs/arvo/clay/clay.md)
15−to communicate with other ships rather than using Ames
16−directly, but this isn't a requirement. Of course, Gall and Clay use
17−Ames behind the scenes to communicate across the network. Jael is the only other
18−vane to utilize Ames.
19−
20−Ames includes several significant components. Although the actual
21−crypto algorithms are defined in `zuse`, they're used extensively in
22−Ames for encrypting and decrypting packets. Congestion control and
23−routing is handled entirely in Ames. Finally, the actual Ames
24−protocol itself, including how to route incoming packets to the correct
25−vane or app, is defined in Ames.
26−
27−## Technical Overview
28−This section summarizes the design of Ames. Beyond this section are deeper
29−elaborations on the concepts presented here.
30−
31−Ames extends [Arvo's](@/docs/arvo/overview.md) `%pass`/`%give` `move` semantics across the network.
32−
33−Ames receives packets as Arvo events and emits packets as Arvo
34−effects. The runtime is responsible for transferring the bytes in
35−an Ames packet across a physical network to another ship.
36−
37−The runtime tells Ames which physical address a packet came from,
38−represented as an opaque atom. Ames can emit a packet effect to
39−one of those opaque atoms or to the Urbit address of a galaxy
40−(root node), which the runtime is responsible for translating to a
41−physical address. One runtime implementation sends UDP packets
42−using IPv4 addresses for ships and DNS lookups for galaxies, but
43−other implementations may overlay over other kinds of networks.
44−
45−A local vane can pass Ames a `%plea` request message. Ames
46−transmits the message over the wire to the peer ship's Ames, which
47−passes the message to the destination vane.
48−
49−Once the peer has processed the `%plea` message, it sends a
50−message-acknowledgment packet over the wire back to the local
51−Ames. This "ack" can either be positive to indicate the request was
52−processed, or negative to indicate the request failed, in which
53−case it's called a "nack". (Don't confuse Ames nacks with TCP
54−nacks, which are a different concept).
55−
56−When the local Ames receives either a positive message-ack or a
57−combination of a nack and "naxplanation" (explained in more detail
58−below), it gives an `%done` `move` to the local vane that had
59−requested the original `%plea` message be sent.
60−
61−A local vane can give Ames zero or more `%boon` response messages in
62−response to a `%plea`, on the same duct that Ames used to pass the
63−`%plea` to the vane. Ames transmits a `%boon` over the wire to the
64−peer's Ames, which gives it to the destination vane on the same
65−duct the vane had used to pass the original `%plea` to Ames.
66−
67−`%boon` messages are acked automatically by the receiver Ames. They
68−cannot be nacked, and Ames only uses the ack internally, without
69−notifying the client vane that gave Ames the `%boon`.
70−
71−If the Arvo event that completed receipt of a `%boon` message
72−crashes, Ames instead sends the client vane a `%lost` message
73−indicating the `%boon` was missed.
74−
75−`%plea` messages can be nacked, in which case the peer will send
76−both a message-nack packet and a naxplanation message, which is
77−sent in a way that does not interfere with normal operation. The
78−naxplanation is sent as a full Ames message, instead of just a
79−packet, because the contained error information can be arbitrarily
80−large. A naxplanation can only give rise to a positive ack --
81−never ack an ack, and never nack a naxplanation.
82−
83−Ames guarantees a total ordering of messages within a "flow",
84−identified in other vanes by a duct and over the wire by a `bone`:
85−an opaque number. Each flow has a FIFO (first-in-first-out) queue of `%plea` requests
86−from the requesting ship to the responding ship and a FIFO queue
87−of `%boon`'s in the other direction.
88−
89−Message order across flows is not specified and may vary based on
90−network conditions.
91−
92−Ames guarantees that a message will only be delivered once to the
93−destination vane.
94−
95−Ames encrypts every message using symmetric-key encryption by
96−performing an elliptic curve Diffie-Hellman using our private key
97−and the public key of the peer. For ships in the Jael PKI
98−(public-key infrastructure), Ames looks up the peer's public key
99−from Jael. Comets (128-bit ephemeral addresses) are not
100−cryptographic assets and must self-attest over Ames by sending a
101−single self-signed packet containing their public key.
102−
103−When a peer suffers a continuity breach, Ames removes all
104−messaging state related to it. Ames does not guarantee that all
105−messages will be fully delivered to the now-stale peer. From
106−Ames's perspective, the newly restarted peer is a new ship.
107−Ames's guarantees are not maintained across a breach.
108−
109−A vane can pass Ames a `%heed` `$task` to request Ames track a peer's
110−responsiveness. If our `%boon`'s to it start backing up locally,
111−Ames will give a `%clog` back to the requesting vane containing the
112−unresponsive peer's urbit address. This interaction does not use
113−ducts as unique keys. Stop tracking a peer by sending Ames a
114−`%jilt` `$task`.
115−
116−Debug output can be adjusted using `%sift` and `%spew` `$task`'s.
117−
118−## Packets
119−
120−Ames datagram packets are handled as nouns internally by Arvo but as serial data
121−by Unix. In this section we describe how packets are formed, serialized, and relayed.
122−
123−### Packet format
124−
125−There is a 32-bit header followed by a variable width body.
126−
127−#### Header
128−
129−The 32-bit header is given by the following data, presented in order:
130−
131− - 3 bits: Ames `protocol-version`,
132− - 20 bits: a checksum as a truncated insecure hash of the body, done with
133− [`+mug`](@/docs/hoon/reference/stdlib/2e.md#mug),
134− - 2 bits: the bit width of the sender address encoded as a 2-bit enum,
135− - 2 bits: the bit width of the receiver address encoded as a 2-bit enum,
136− - 1 bit: whether the packet is encrypted or not,
137− - 4 bits: unused.
138−
139− Every packet sent between ships is encrypted except for self-signed attestation packets from 128-bit comets.
140−
141−#### Body
142−
143−The body is of variable length and consists of three parts in this order:
144−
145− - The `@p` of the sending ship,
146− - The `@p` of the receiving ship,
147− - The payload, which is the [`+jam`](@/docs/hoon/reference/stdlib/2p.md#jam) (i.e. serialization) of the noun `[origin content]`.
148−
149− `origin` is the IP and port of the original sender if the packet was proxied
150− through a relay and null otherwise. `content` is a noun that is either an encrypted ack or an
151− encrypted message fragment, unless it is a comet attestation packet in which
152− case it is unencrypted. `content` is always 1kB in size or less.
153−
154− The sender and receiver live outside of the jammed data section to simplify
155− packet filtering for the interpreter.
156−
157−### Packeting
158−
159−When Ames has a message to be sent it must first determine how many packets are
160−required to send the message. To do this, it first `+jam`s the
161−message, producing an atom. Ames checks how large the atom is, and if it is
162−bigger than a kilobyte it will split it into packets whose payloads are 1 kB or
163−less. It then numbers each one - this is message 17, packet 12, this is message
164−17, packet 13, etc., so that when the receiver receives these packets it knows
165−which number they are. Finally it encrypts each individual packet and enqueues
166−them to be sent along their stated flow.
167−
168−Network packets aren't always received in order, so this numbering is important
169−for reconstruction, and also packets may get lost. So Ames does transmission
170−control (the TC in TCP) to solve this problem. It makes sure that all packets
171−eventually get through, and when the other side gets them it can put them in the
172−correct order. If Ames doesn't get an ack on a packet then it will resend it
173−until it does. The logic for determining how many packets to send or re-send at what time is performed by an Ames-specific variant of TCP's "NewReno" congestion control algorithm.
174−
175−As each packet in a message is received, Ames decrypts it and stores the message fragment. Once it's received every packet for a message, Ames concatenates the fragments back into a single large atom and uses `+cue` to deserialize that back into the original message noun.
176−
177−
178−
179−### Acks and Nacks
180−
181−In this section we discuss acks and nacks. In Ames, an "ack", short for "acknowledgment", is a small packet attesting that a piece of information (either a packet or a whole message) was received. Ames makes use of
182−acks to maintain synchronization between two communicating parties. Nacks are 'negative
183−acknowledgments' and are used when something goes wrong.
184−
185−#### Acks
186−
187−Every message (i.e. a `%plea` or `%boon`) is split up by Ames into some number
188−of _fragments_ that are 1kB in size or less. The fragments are then encrypted
189−and encapsulated into
190−packets and sent along a flow. The message will be considered successfully
191−received once the sender has received the appropriate set of acks in response,
192−defined as follows.
193−
194−There are two types of acks: fragment acks and message acks. Acks are
195−not considered messages, and thus are not `%plea`s or `%boon`s. Given a message split into N
196−fragments, the sender of the message will expect N-1 fragment acks followed
197−by exactly one message ack (ignoring any duplicate packets, which are idempotent
198−from the perspective of the application). This is because the receiver
199−will send a fragment ack for the first N-1 packets it received, and what
200−would have been the final fragment ack will instead be a message ack.
201−
202−Acks are considered to be part of the flow in which that `%plea` or
203−`%boon` lives, as the packets containing their fragments and packets acking the
204−receipt of those packets are considered to be what makes up a given message.
205−Thus a message-level ack must be received before the next message on the flow
206−can begin. The full story is more complicated than this; see the section on
207−[flows](#flows).
208−
209−
210−#### Nacks
211−
212−A nack indicates a negative acknowledgement to a `%plea`, meaning that the
213−requested action was not performed.
214−
215−`%boon`s and naxplanations are never nacked.
216−Individual packets are also never nacked, only complete `%plea` messages are.
217−Whether a malformed packet causes a `%plea` to be nacked depends on its content.
218−In the case of an incorrect checksum or a failure to decrypt then Ames drops the
219−packet and it is as though it never happened. However, if the packet does
220−decrypt and has invalid ciphertext (i.e. something other than a jammed
221−`$shutpacket` data structure), then Ames will nack the whole `%plea` since that
222−indicates that the peer is misbehaving. Eventually Ames should also present a
223−warning to the user that the peer is untrustworthy.
224−
225−A nack will be accompanied by a naxplanation, which is a special type of`%boon`
226−that uses its own `bone` (see [flows](#flows)). Ames won't give the vane that requested the
227−initial `%plea` a nack until it also receives the naxplanation, which it will send to
228−the vane as a `%done` gift. Naxplanations may only be acked, never nacked.
229−Furthermore, naxplanations can only ever be sent as a rejection of a `%plea` -
230−the receiver will never both perform a `%plea` and return a naxplanation.
231−
232−#### (N)ack packets
233−
234−A fragment ack's contents (before encryption) are a pure function of the
235−following noun:
236−```hoon
237−[our-life her-life bone message-num fragment-num]
238−```
239−This means all re-sends of an ack packet will be bitwise identical to each other, unless one of the peers changes its encryption keys.
240−
241−Each datum in this noun is an atom with the aura `@ud` or an aura that nests
242−under `@ud`.
243−
244−Here, `our-life` refers to the [`life`](@/docs/glossary/breach.md), or revision
245−number, of the acking ship's networking keys, and `her-life` is the `life` of
246−the ack-receiving ship's networking keys. `bone` is an opaque number identifying
247−the flow. `message-num` denotes the number of the
248−message in the flow identified by `bone`. `fragment-num` denotes the number of
249−the fragment of the message identified by `message-num` that is being acked.
250−
251−A message (n)ack is a different kind of ack that is obtained by encrypting the
252−`+jam` of the following noun:
253−
254−```hoon
255−[our-life her-life bone message-num ok=? lag=@dr]
256−```
257−`ok` is a flag that is set to `%.y` for a message ack and `%.n` for a message
258−nack. In the future, `lag` will be used to
259−describe the time it took to process a message, but for now it is always zero.
260−
261−
262−### Flows
263−
264−Flows are asymmetric communication channels along which two ships send and
265−receive packets, and all Ames packets are part of some flow.
266−
267−To create a new flow, a ship sends a
268−`%plea` to another ship. Only the creator of the flow may send `%plea`s, and the
269−other party may only send `%boon`s. In this sense flows are asymmetric.
270−
271−The sequence of `%plea`s in a flow is totally ordered, though
272−the packets which make them up need not be. `%boon`s are totally ordered in the
273−same fashion, but there is not a coordinated ordering between `%plea`s and
274−`%boon`s in a given flow beyond the implicit one arising from the fact that a
275−`%boon` is always a response to a `%plea`. A `%plea` can give rise to zero, one,
276−or many `%boon`s.
277−
278−Inside of Ames, each flow has four sequential opaque `@ud`s
279−called bones that are unique to that flow. Thus the flow itself is often
280−referred to by its first bone. Each bone is a one-way street
281−for packets to travel along, so e.g. acks to packets making up a `%plea` are
282−sent along a different bone than the `%plea`.
283−
284−We give an example of such a partition. Let flow 12 be a flow between `~bacbel-tagfeg` and `~worwel-sipnum` with
285−`~bacbel-tagfeg` as the `%plea` sender. Then bones 12-15 are associated with the
286−flow, and the types of packets for each bone are:
287−
288− - bone 12, `%plea`s and acks to `~worwel-sipnum`,
289− - bone 13, `%boon`s and (n)acks to `~bacbel-tagfeg`,
290− - bone 14, acks of naxplanations to `~worwel-sipnum`,
291− - bone 15, naxplanations to `~bacbel-tagfeg`.
292−
293−Each bone is handled separately by congestion control, and this is one reason
294−for their segregation. For example, say a two-packet `%plea` is sent on bone 12,
295−with `~bacbel-tagfeg` requesting to join a group on `~worwel-sipnum`.
296−Then `~worwel-sipnum` can ack the first packet on bone 13, and then send a nack
297−on bone 13 as well. A nack by itself contains no information as to why the nack
298−happened. Then `~worwel-sipnum` can also send a naxplanation on bone 15 saying
299−to `~bacbel-tagfeg` that they cannot join the group, to which an ack is received
300−on bone 14.
301−
302−Another reason to separate bones is to avoid race conditions. If
303−`~worwel-sipnum` and `~bacbel-tagfeg` attempt to start a flow with each other at
304−the same time we do not wish there to be a conflict when they receive each
305−others' packets. Flipping the last bit of the bone based on whether a packet is
306−an ack or a message fragment allows for `~worwel-sipnum` to create flow 8 with
307−`~bacbel-tagfeg` without coming into conflict with the flow 8 `~bacbel-tagfeg`
308−created for `~worwel-sipnum`.
309−
310−`%plea`s and `%boon`s are handled on separate bones so that e.g. sending a large
311−`%boon` doesn't stop an additional `%plea` from being received. It is also
312−simply cleaner to make each bone one-way. Acks and nacks are very small packets
313−as well as integral to controlling the total orderings on `%plea`s and `%boon`s
314−and so they are included on these bones as well.
315−
316−Naxplanations can potentially be very large, as they often contain things like stack
317−traces or other crash reports. Thus it is undesirable to have them share a bone
318−with `%boon`s and create congestion there. So naxplanations have their own bone,
319−and so do acks to packets that make up a naxplanation, as well as the
320−message-level naxplanation ack.
321−
322−### Packet relaying
323−
324−Here we describes how the Ames network relays packets. We ignore all details
325−about UDP, which occurs at a lower layer than Ames.
326−
327−When a ship first contacts another ship, it may only know its `@p`, but an IP
328−address and port are necessary for peer-to-peer communication to occur.
329−Thus the initial correspondence between two ships, or additional correspondence
330−following a change in IP or port of one of the parties, will need to be relayed
331−by an intermediary that knows the IP and port of the receiving ship.
332−
333−For now packet relaying is handled entirely by galaxies. Every galaxy is
334−responsible for knowing the IP and port of every planet underneath it. In the
335−future, galaxies will only need to know the star sponsoring a planet, and stars
336−will be responsible for the final step of the relay.
337−
338−The following diagram summarizes the packet creation and forwarding process.
339−
340−<div style="text-align:center">
341−<img src="https://media.urbit.org/docs/arvo/datagram-long.png">
342−</div>
343−
344−We elaborate on the above diagram.
345−
346−A typical relay will look something like this: `~bacbel-tagfeb` wishes to
347−contact `~worwel-sipnum` but does not know the IP address and port at which
348−`~worwel-sipnum` resides. Both planets live under `~zod`, which knows both of
349−their IP and port numbers by virtue of being the galaxy that both live under.
350−
351−To prepare, `~bacbel-tagfeb` forms a Diffie-Hellman symmetric key with their own
352−private key and the public key of `~worwel-sipnum`, obtained via Jael. Then
353−`~bacbel-tagfeb` sends a packet addressed to `~worwel-sipnum` to `~zod`.
354−
355−The packet has the following format:
356− - The standard Ames header described in [header](#header), where the checksum
357− is the `+mug` of the body, and the sender and receiver ship types are `01`,
358− denoting that the sender and receiver are planets. The remainder of the
359− packet is the body.
360− - The body of this packet will be the `@p` of the
361−sender `~bacbel-tagfeb`, followed by the `@p` of the receiver `~worwel-sipnum`,
362−followed by the payload.
363− - The payload of this packet will be the `+jam` of `[origin content]`. `origin`
364−for this initial packet will be `~`, which implies that the packet is
365−originating from the sender. `content` is the `+jam` of the message, encrypted
366−using the Diffie-Hellman symmetric key that was previously computed.
367−
368−`~zod` receives the packet and reads the body. It sees that it is not the
369−intended recipient of the packet, and so gets ready to forward it to
370−`~worwel-sipnum`. First, it [`+cue`s](@/docs/hoon/reference/stdlib/2p.md#cue)
371−(deserializes) the payload and changes the `origin` to the IP and port of
372−`~bacbel-tagfeb`. Then it `+jam`s `[origin content]` to form a new payload, and
373−`+mug`s that payload to get a new checksum. It replaces the old payload and
374−checksum with the new, and then sends the packet along to `~worwel-sipnum`.
375−
376−Once `~worwel-sipnum` processes the packet, it will know the IP and port of
377−`~bacbel-tagfeb` since `~zod` included it when it forwarded the packet. Thus
378−`~worwel-sipnum` will send an ack packet directly to `~bacbel-tagfeb`, unless a
379−NAT and/or firewall prevents a direct peer-to-peer connection, in which case
380−`~zod` will continue to relay packets. Absent these factors preventing a
381−peer-to-peer connection, communication between the two ships will now be direct
382−until one of them changes their IP address, port, or networking keys.
383−
384−
385−## The Serf and the King
386−
387−Urbit's functionality is split between the two binaries `urbit-worker` (sometimes
388−called the Serf) and `urbit-king` (sometimes called the King). This division of
389−labor is currently not well-documented outside of the [Vere documents](@/docs/vere/_index.md), but we summarize it here.
390−
391−In short, the Serf is the Nock runtime and so keeps track of the current state
392−of Arvo as a Nock noun and updates the state by `%poke`ing it with nouns, and
393−then informs the King of the new state. The King manages snapshots of the Arvo
394−state and handles I/O with Unix, among other things. The Serf only ever talks to
395−the King, while the King talks with both the Serf and Unix.
396−
397−### Ames I/O submodule
398−
399−The King has several submodules, one of them being an Ames I/O submodule. This
400−submodule is responsible for wrapping outgoing Ames packets as UDP packets, and
401−unwrapping incoming UDP packets into Ames packets and forwarding them to the
402−worker. It also maintains an incoming packet queue.
403−
404−This division is summarized in the following diagram, describing how
405−`~bacbel-tagfeb` requests a subscription to the `recipes` notebook of
406−`~worwel-sipnum` in the Publish app.
407−
408−<div style="text-align:center">
409−<img src="https://media.urbit.org/docs/arvo/packet.png">
410−</div>
411−
412−Ames, as a part of Arvo, handles `+jam`ming, packetizing, encryption, and
413−forming Ames packets. Once it is ready to send an Ames packet, it `%give`s to
414−Unix a `%send` `gift` containing that packet. This will be a Nock noun
415−containing the `@tas` `%send` as well as the serialized packet.
416−
417−"Unix", in this case, is actually the King. The King receives the `%send`
418−instruction, wraps the packet contained within as a UDP packet, and immediately
419−hands it off the the Unix network interface to be sent.
420−
421−Now the receiving King is handed a UDP packet by Unix. The King removes the UDP
422−wrapper, `+jam`s the `lane` on which it heard the packet, and delivers the packet
423−to the Ames vane as an atom by copying the bytes it heard on the UDP port.
arvo/behn/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Behn"
3−weight = 20
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/behn/behn-api.mddeleted−246
@@ -1,246 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 10
4−template = "doc.html"
5−+++
6−
7−In this document we describe the public interface for Behn. Namely, we describe
8−each `task` that Behn can be `pass`ed, and which `gift`(s) Behn can `give` in return.
9−
10−
11−## Tasks
12−
13−### `%born`
14−
15−Each time you start your Urbit, the Arvo kernel calls the `%born` task for Behn. When
16−called, Behn gets the current time from Unix and updates its list of timers
17−accordingly.
18−
19−#### Accepts
20−
21−```hoon
22−[~]
23−```
24−
25−#### Returns
26−
27−`%born` does not return a `gift`.
28−
29−
30−### `%crud`
31−
32−`%crud` is called whenever an error involving Behn occurs, such as trying to
33−`%wake` a program that has crashed.
34−
35−When called, it checks to see if the set of timers is empty. If so, it prints
36−an error report containing `error`, otherwise it passes the error to `+wake`.
37−
38−#### Accepts
39−
40−```hoon
41−[tag=@tas error=tang]
42−```
43−Here, `tag` is a `@tas` denoting the type of error, and `error` is an error message.
44−
45−#### Returns
46−
47−```hoon
48−[%wake %behn-crud-no-timer tag error]
49−```
50−
51−If the set of timers is nonempty when Behn is `%pass`ed a `%crud` `task`, Behn
52−`%give`s a `%wake` `card` containing the error to the next client in the set of timers.
53−
54−
55−#### Example
56−
57−The most common error that occurs is when Behn tries to `%wake` up a program that has crashed. When this happens
58−the entire event (i.e. sequence of `move`s) that led up to the `%wake` is thrown
59−away, and Vere then causes the kernel to `pass` Behn a `%crud` `task` containing
60−the stack trace.
61−
62−
63−### `%drip`
64−
65−`%drip` allows one to delay a `gift` until a timer set for `now` fires.
66−
67−A Client `%slip`s Behn a `%drip` task wrapping a `gift` to be `give`n to a Target.
68−This launches a sequence of `move`s as written here:
69−
70−```
71−Client -- %slip %drip --> Behn -- %pass %wait --> Behn -- %give %wake --> Behn -- %give %meta --> Target
72−```
73−Here the `%meta` `move` is a wrapper for the `%gift` inside of the initial `%drip` wrapper.
74−
75−`%drip` only handles `gift`s, and can only schedule `gift`s for as soon as
76−possible after the prescribed timer fires.
77−
78−
79−#### Accepts
80−
81−```hoon
82−mov=vase
83−```
84−
85−`%drip` takes in a `%give` `move` in a `vase`.
86−
87−#### Returns
88−
89−In response to a `%drip` `task`, Behn will `%pass` a `%wait` to itself, which
90−then triggers a `%wake` `gift` to itself, which then causes Behn to `%give` a `%meta` `gift` containing
91−the `gift` originally `%give`n to Behn when `%drip` was first called. That makes
92−Behn its own client for `%drip`.
93−
94−#### Example
95−
96−
97−Say an app (the Target) is subscribed to updates from Clay (the Client). If Clay `%give`s
98−updates to the app directly and the app crashes, this may cause Clay to crash as
99−well. If instead Clay `%pass`es Behn a `%drip` `task` wrapping the update
100−`gift`, Behn will set a timer for `now` that, when fired, will cause the update
101−`gift` to be given. If it causes a crash then it will have been in response to
102−the `%drip` move, thereby isolating Clay from the crash. Thus `%drip` acts as a sort of buffer against cascading
103−sequences of crashes.
104−
105−
106−
107−### `%huck`
108−
109−Immediately gives back an input move.
110−
111−#### Accepts
112−
113−```hoon
114−mov=vase
115−```
116−
117−Behn takes in a `move` contained in a `vase`.
118−
119−#### Returns
120−
121−```hoon
122−[%give %meta mov]
123−```
124−
125−Behn returns the input `move` as a `%meta` `gift`.
126−
127−
128−
129−### `%rest`
130−
131−Cancels a timer that was previously set.
132−
133−Behn takes in a `@da` and cancels the timer at that time if it exists, then
134−adjusts the next wakeup call from Unix if necessary.
135−
136−#### Task
137−
138−```hoon
139−@da
140−```
141−
142−
143−#### Gift
144−
145−This `task` returns no `gift`s.
146−
147−
148−
149−### `%trim`
150−
151−This `task` is sent by the interpreter in order to free up memory.
152− This `task` is empty for Behn, since it is not a good idea to forget your timers.
153−
154−#### Accepts
155−
156−This `task` has no arguments.
157−
158−#### Returns
159−
160−This task returns nothing.
161−
162−### `%vega`
163−
164−This `task` informs the vane that the kernel has been upgraded. Behn does not do
165−anything in response to this.
166−
167−#### Accepts
168−
169−This `task` has no arguments.
170−
171−#### Returns
172−
173−This `task` returns nothing.
174−
175−
176−
177−### `%wait`
178−
179−This `task` takes in a `@da` which Behn then adds to `timers.state`, the list of timers.
180−
181−#### Accepts
182−
183−```hoon
184−@da
185−```
186−
187−#### Returns
188−
189−This `task` returns a `%wake` `gift` once the timer has fired.
190−
191−
192−### `%wake`
193−
194−This `task` is sent by the kernel when the Unix timer tells the kernel that it
195−is time for Behn to wake up. This is often caused by a `%doze` `gift` that
196−Behn originally sent to the kernel that is then forwarded to Unix, which is
197−where the real timekeeping occurs.
198−
199−Upon receiving this `task`, Behn processes the elapsed timer and then sets
200−`:next-wake`.
201−
202−`%wake` is also a `gift` that Behn can `%give`. This is done to inform other
203−vanes or apps that a timer has expired, and may include an error message.
204−
205−#### Accepts
206−
207−As a `task`, `%wake` takes in `~`.
208−
209−As a `gift`, `%wake` may include an error message.
210−
211−```hoon
212−error=(unit tang)
213−```
214−
215−
216−#### Returns
217−
218−In response to receiving this `task`, Behn may `%give` a `%doze` `gift`
219−containing the `@da` of the next timer to elapse. Behn may also `%give` a
220−`%wake` `gift` to itself.
221−
222−
223−
224−### `%wegh`
225−
226−This `task` asks Behn to product a memory usage report.
227−
228−#### Accepts
229−
230−This `task` has no arguments.
231−
232−#### Returns
233−
234−```hoon
235−:_ state :_ ~
236− :^ duct %give %mass
237− :+ %behn %|
238− :~ timers+&+timers.state
239− dot+&+state
240−```
241−
242−When Behn is `%pass`ed this `task`, it will `%give` a `%mass` `gift` in response
243−containing Behn's current memory usage.
244−
245−
246−
arvo/behn/behn.mddeleted−21
@@ -1,21 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−+++
6−Our simple timer.
7−
8−It allows vanes and applications to set and timer events, which are
9−managed in a simple priority queue. `%behn` produces effects to start
10−the unix timer, and when the requested `%behn` passes, unix sends wake
11−events to `%behn`, which time routes back to original sender. We don't
12−guarantee that a timer event will happen at exactly the `%behn` it was
13−set for, or even that it'll be particularly close. A timer event is a
14−request to not be woken until after the given time.
15−
16−`%eyre` uses `%behn` for timing out sessions, and `%clay` uses `%behn`
17−for keeping track of time-specified file requests. `%ames` should
18−probably use `%behn` to keep track of things like network timeouts and
19−retry timing, but it currently uses its own alarm system.
20−
21−This article is a stub. For more information, see either `behn.hoon` or [Lesson 2.6 - Behn](@/docs/hoon/hoon-school/behn.md) of the Hoon tutorial.
arvo/clay/_index.mddeleted−36
@@ -1,36 +0,0 @@
1−+++
2−title = "Clay"
3−weight = 30
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
8−
9−[Overview](@/docs/arvo/clay/clay.md)
10−
11−High-level overview of Clay.
12−
13−[Architecture](@/docs/arvo/clay/architecture.md)
14−
15−A conceptual overview of how Clay was designed.
16−
17−[Using Clay](@/docs/arvo/clay/using.md)
18−
19−A quick overview of how the most common tasks involving Clay are performed:
20−reading and subscribing, syncing to Unix, and merging.
21−
22−[Data Types](@/docs/arvo/clay/data-types.md)
23−
24−Explanations of the many data types found throughout Clay.
25−
26−[Scry Reference](@/docs/arvo/clay/scry.md)
27−
28−Reference for Clay's various scry endpoints.
29−
30−[API Reference](@/docs/arvo/clay/tasks.md)
31−
32−Details of the various `task`s you can use to interact with Clay.
33−
34−[Examples](@/docs/arvo/clay/examples.md)
35−
36−Example usage of the various Clay `task`s.
arvo/clay/architecture.mddeleted−254
@@ -1,254 +0,0 @@
1−+++
2−title = "Architecture"
3−weight = 2
4−template = "doc.html"
5−+++
6−
7−Clay is the primary filesystem for the [Arvo](@/docs/arvo/overview.md) operating system,
8−which is the [core](/docs/glossary/core/) of an urbit. The architecture of Clay is
9−intrinsically connected with Arvo, but for this section we assume no knowledge of
10−either Arvo or Urbit. We will point out only those features of
11−Arvo that are necessary for an understanding of Clay, and we will
12−do so only when they arise.
13−
14−The first relevant feature of Arvo is that it is a deterministic
15−system where input and output are defined as a series of events
16−and effects. The state of Arvo is simply a pure function of its event
17−log. None of the effects from an event are emitted until the
18−event is entered in the log and persisted, either to disk or
19−another trusted source of persistence, such as a Kafka cluster.
20−Consequently, Arvo is a single-level store: everything in its
21−state is persistent.
22−
23−In a more traditional OS, everything in RAM can be erased at any
24−time by power failure, and is always erased on reboot. Thus, a
25−primary purpose of a filesystem is to ensure files persist across
26−power failures and reboots. In Arvo, both power failures and
27−reboots are special cases of suspending computation, which is
28−done safely since our event log is already persistent. Therefore,
29−Clay is not needed in Arvo for persistence. Why, then, do we have a
30−filesystem? There are two answers to this question.
31−
32−First, Clay provides a filesystem tree, which is a convenient
33−user interface for some applications. Unix has the useful concept
34−of virtual filesystems, which are used for everything from direct
35−access to devices, to random number generators, to the /proc
36−tree. It is easy and intuitive to read from and write to a
37−filesystem tree.
38−
39−Second, Clay has a distributed revision-control system baked into
40−it. Traditional filesystems are not revision controlled, so
41−userspace software -- such as git -- is written on top of them to
42−do so. Clay natively provides the same functionality as modern
43−DVCSes, and more.
44−
45−Clay has two other unique properties that we'll cover later on:
46−it supports typed data and is referentially transparent.
47−
48−### Revision Control
49−
50−Every urbit has one or more `desk`s, which are independently
51−revision-controlled branches. Each `desk` contains its own `mark`
52−definitions, apps, and so forth.
53−
54−Traditionally, an urbit has at least a `%home` `desk` and `%kids` `desk`. The
55−`%home` `desk` has all the system software from the distribution, along with your
56−personal files. The `%home` `desk` is a fork of the `%kids` desk of whichever ship
57−you download [OTAs](@/docs/glossary/ota-updates.md) from - typically your sponsor,
58−but theoretically may be any ship. You will also find references to a `%base`
59−`desk` - which is not a real `desk`, rather it just a hash associated to the
60−`desk` from which your `%home` `desk` was forked.
61−
62−A `desk` is a series of numbered commits, the most recent of which
63−represents the current state of the `desk`. A commit is composed of
64−(1) an absolute time when it was created, (2) a list of zero or
65−more parents, and (3) a map from paths to data.
66−
67−Most commits have exactly one parent, but the initial commit on a
68−`desk` may have zero parents, and merge commits have more than one
69−parent.
70−
71−The non-metadata is stored as a `map` of `path`s to data. It's
72−worth noting that no constraints are put on this `map`, so, for
73−example, both `/a/b` and `/a/b/c` could have data. This is impossible
74−in a traditional Unix filesystem since it means that `/a/b` is both
75−a file and a directory. Conventionally, the final element in the
76−path is its `mark` -- much like a filename extension in Unix. Thus,
77−`/doc/readme.md` in Unix is stored as `/doc/readme/md` in urbit.
78−
79−The data is not stored directly in the `map`; rather, a hash of the
80−data is stored, and we maintain a master blob store. Thus, if the
81−same data is referred to in multiple commits (as, for example,
82−when a file doesn't change between commits), only the hash is
83−duplicated.
84−
85−In the master blob store, we either store the data directly, or
86−else we store a diff against another blob. The hash is dependent
87−only on the data within and not on whether or not it's stored
88−directly, so we may on occasion rearrange the contents of the
89−blob store for performance reasons.
90−
91−Recall that a `desk` is a series of numbered commits. Not every
92−commit in a `desk` must be numbered. For example, if the base `desk`
93−has had 50 commits since home was forked from it, then a merge
94−from base to home will only add a single revision number to home,
95−although the full commit history will be accessible by traversing
96−the parentage of the individual commits.
97−
98−We do guarantee that the first commit is numbered 1, commits are
99−numbered consecutively after that (i.e. there are no "holes"),
100−the topmost commit is always numbered, and every numbered commit
101−is an ancestor of every later numbered commit.
102−
103−There are three ways to refer to particular commits in the
104−revision history. Firstly, one can use the revision number.
105−Secondly, one can use any absolute time between the one numbered
106−commit and the next (inclusive of the first, exclusive of the
107−second). Thirdly, every `desk` has a `map` of labels to revision
108−numbers. These labels may be used to refer to specific commits.
109−
110−Additionally, Clay is a global filesystem, so data on other urbits
111−is easily accessible the same way as data on our local urbit. In
112−general, the path to a particular revision of a `desk` is
113−`/~urbit-name/desk-name/revision`. Thus, to get `/try/readme/md`
114−from revision 5 of the home `desk` on `~sampel-sipnym`, we refer to
115−`/~sampel-sipnym/home/5/try/readme/md`. Clay's namespace is thus
116−global and referentially transparent.
117−
118−### A Typed Filesystem
119−
120−Since Clay is a general filesystem for storing data of arbitrary
121−types, in order to revision control correctly it needs to be
122−aware of types all the way through. Traditional revision control
123−does an excellent job of handling source code, so for source code
124−we act very similar to traditional revision control. The
125−challenge is to handle other data similarly well.
126−
127−For example, modern VCSs generally support "binary files", which
128−are files for which the standard textual diffing, patching, and
129−merging algorithms are not helpful. A "diff" of two binary files
130−is just a pair of the files, "patching" this diff is just
131−replacing the old file with the new one, and "merging"
132−non-identical diffs is always a conflict, which can't even be
133−helpfully annotated. Without knowing anything about the structure
134−of a blob of data, this is the best we can do.
135−
136−Often, though, "binary" files have some internal structure, and
137−it is possible to create diff, patch, and merge algorithms that
138−take advantage of this structure. An image may be the result of a
139−base image with some set of operations applied. With algorithms
140−aware of this set of operations, not only can revision control
141−software save space by not having to save every revision of the
142−image individually, these transformations can be made on parallel
143−branches and merged at will.
144−
145−Suppose Alice is tasked with touching up a picture, improving the
146−color balance, adjusting the contrast, and so forth, while Bob
147−has the job of cropping the picture to fit where it's needed and
148−adding textual overlay. Without type-aware revision control,
149−these changes must be made serially, requiring Alice and Bob to
150−explicitly coordinate their efforts. With type-aware revision
151−control, these operations may be performed in parallel, and then
152−the two changesets can be merged programmatically.
153−
154−Of course, even some kinds of text files may be better served by
155−diff, patch, and merge algorithms aware of the structure of the
156−files. Consider a file containing a pretty-printed JSON object.
157−Small changes in the JSON object may result in rather significant
158−changes in how the object is pretty-printed (for example, by
159−addding an indentation level, splitting a single line into
160−multiple lines).
161−
162−A text file wrapped at 80 columns also reacts suboptimally with
163−unadorned Hunt-McIlroy diffs. A single word inserted in a
164−paragraph may push the final word or two of the line onto the
165−next line, and the entire rest of the paragraph may be flagged as
166−a change. Two diffs consisting of a single added word to
167−different sentences may be flagged as a conflict. In general,
168−prose should be diffed by sentence, not by line.
169−
170−As far as we are aware, Clay is the first generalized,
171−type-aware revision control system. We'll go into the workings
172−of this system in some detail.
173−
174−### Marks
175−
176−Central to a typed filesystem is the idea of types. In Clay, we
177−call these `mark`s. A `mark` is a file that defines a type,
178−conversion routines to and from the `mark`, and diff, patch, and
179−merge routines.
180−
181−For example, a `%txt` mark may be a list of lines of text, and it
182−may include conversions to `%mime` to allow it to be serialized
183−and sent to a browser or to the Unix filesystem. It will also
184−include Hunt-McIlroy diff, patch, and merge algorithms.
185−
186−A `%json` `mark` would be defined as a JSON object in the code, and
187−it would have a parser to convert from `%txt` and a printer to
188−convert back to `%txt`. The diff, patch, and merge algorithms are
189−fairly straightforward for JSON, though they're very different
190−from the text ones.
191−
192−More formally, a `mark` is a core with three [arms](/docs/glossary/arm/): `+grab`,
193−`+grow`, and `+grad`. In `+grab` is a series of functions to
194−convert from other `mark`s to the given `mark`. In `+grow` is a
195−series of functions to convert from the given `mark` to other
196−`mark`s. In `+grad` is `+diff`, `+pact`, `+join`, and `+mash`, and
197−`+form`.
198−
199−The types are as follows, in an informal pseudocode:
200−
201−```
202− ++ grab:
203− ++ mime: <mime> -> <mark-type>
204− ++ txt: <txt> -> <mark-type>
205− ...
206− ++ grow:
207− ++ mime: <mark-type> -> <mime>
208− ++ txt: <mark-type> -> <txt>
209− ...
210− ++ grad
211− ++ form: <mark-type>
212− ++ diff: (<mark-type>, <mark-type>) -> <diff-type>
213− ++ pact: (<mark-type>, <diff-type>) -> <mark-type>
214− ++ join: (<diff-type>, <diff-type>) -> <diff-type> or NULL
215− ++ mash: (<diff-type>, <diff-type>) -> <diff-type>
216−```
217−
218−These types are basically what you would expect. Not every `mark`
219−has each of these functions defined -- all of them are optional
220−in the general case.
221−
222−In general, for a particular `mark`, the `+grab` and `+grow` entries
223−(if they exist) should be inverses of each other.
224−
225−In `+grad`, `+diff` takes two instances of a `mark` and produces a diff of them
226−whose `mark` is given by `+form`. `+pact` takes an instance of a `mark` and
227−patches it with the given diff. `+join` takes two diffs and attempts to merge
228−them into a single diff. If there are conflicts, it produces null. `+mash` takes
229−two diffs and forces a merge, annotating any conflicts.
230−
231−In general, if `+diff` called with A and B produces diff D, then
232−`+pact` called with A and D should produce B. Also, if `+join`
233−of two diffs does not produce null, then `+mash` of the same
234−diffs should produce the same result.
235−
236−Alternately, instead of `+diff`, `+pact`, `+join`, and
237−`+mash`, a `mark` can provide the same functionality by defining
238−`+grad` to be the name of another `mark` to which we wish to
239−delegate the revision control responsibilities. Then, before
240−running any of those functions, Clay will convert to the other
241−`mark`, and convert back afterward. For example, the `%hoon` `mark`
242−is revision-controlled in the same way as `%txt`, so its `+grad`
243−is simply `++ grad %txt`. Of course, `+txt` must be defined in
244−`+grow` and `+grab` as well.
245−
246−Every file in Clay has a `mark`, and that `mark` must have a
247−fully-functioning `+grad`. `Mark`s are used for more than just
248−Clay, and other `mark`s don't need a `+grad`, but if a piece of
249−data is to be saved to Clay, we must know how to revision-control
250−it.
251−
252−Additionally, if a file is to be synced out to Unix, then it must
253−have conversion routines to and from the `%mime` `mark`.
254−
arvo/clay/clay.mddeleted−58
@@ -1,58 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−aliases = ["/docs/learn/arvo/clay/"]
6−+++
7−
8−
9−Our filesystem.
10−
11−`%clay` is version-controlled, referentially-transparent, and global.
12−While this filesystem is stored in `%clay`, it is mirrored to Unix for
13−convenience. Unix tells `%clay`s whenever a file changes in the Unix
14−copy of the filesystem so that the change may be applied. `%clay` tells
15−unix whenever an app or vane changes the filesystem so that the change
16−can be effected in Unix. Apps and vanes may use `%clay` to write to the
17−filesystem, query it, and subscribe to changes in it. Ford and gall use
18−`%clay` to serve up apps and web pages.
19−
20−`%clay` includes three components. First is the filesystem/version
21−control algorithms, which are mostly defined in `++ze` and `++zu` in
22−zuse. Second is the write, query, and subscription logic. Finally, there
23−is the logic for communicating requests to, and receiving requests from,
24−foreign ships.
25−
26−### User documentation
27−
28−[Filesystem](@/using/os/filesystem.md)
29−
30−How to interact with the Clay filesystem via Dojo. This includes basics such as
31−mounting to Unix, changing directory, merging, and listing files.
32−
33−### Developer Documentation
34−
35−[Architecture](@/docs/arvo/clay/architecture.md)
36−
37−A conceptual overview of how Clay was designed.
38−
39−[Using Clay](@/docs/arvo/clay/using.md)
40−
41−A quick overview of how the most common tasks involving Clay are performed:
42−reading and subscribing, syncing to Unix, and merging.
43−
44−[Data Types](@/docs/arvo/clay/data-types.md)
45−
46−Explanations of the many data types found throughout Clay.
47−
48−[Scry Reference](@/docs/arvo/clay/scry.md)
49−
50−Reference for Clay's various scry endpoints.
51−
52−[API Reference](@/docs/arvo/clay/tasks.md)
53−
54−Details of the various `task`s you can use to interact with Clay.
55−
56−[Examples](@/docs/arvo/clay/examples.md)
57−
58−Example usage of the various Clay `task`s.
arvo/clay/data-types.mddeleted−688
@@ -1,688 +0,0 @@
1−+++
2−title = "Data Types"
3−weight = 4
4−template = "doc.html"
5−+++
6−
7−This section will be reference documentation for the data types used by our
8−filesystem.
9−
10−As a general guide, we recommend reading and attempting to understand the data
11−structures used in any Hoon code before you try to read the code itself.
12−Although complete understanding of the data structures is impossible without
13−seeing them used in the code, an 80% understanding greatly clarifies the code.
14−As another general guide, when reading Hoon, it rarely pays off to understand
15−every line of code when it appears. Try to get the gist of it, and then move on.
16−The next time you come back to it, it'll likely make a lot more sense.
17−
18−### Data Models
19−
20−As you're reading through this section, remember you can always come
21−back to this when you run into these types later on. You're not going to
22−remember everything the first time through, but it is worth reading, or
23−at least skimming, this so that you get a rough idea of how our state is
24−organized.
25−
26−The types that are certainly worth reading are `++raft`, `++room`,
27−`++dome:clay`, `++ankh:clay`, `++rung:clay`, `++rang:clay`, `++blob:clay`,
28−`++yaki:clay`, and `++nori:clay` (possibly in that order). All in all, though,
29−this section isn't too long, so many readers may wish to quickly read through
30−all of it. If you get bored, though, just skip to the next section. You can
31−always come back when you need to.
32−
33−### `$raft`, formal state
34−
35−```hoon
36−+$ raft :: filesystem
37− $: rom=room :: domestic
38− hoy=(map ship rung) :: foreign
39− ran=rang :: hashes
40− mon=(map term beam) :: mount points
41− hez=(unit duct) :: sync duct
42− cez=(map @ta crew) :: permission groups
43− pud=(unit [=desk =yoki]) :: pending update
44− == ::
45−```
46−
47−This is the state of the vane. Anything that must be remembered between
48−calls to Clay is stored in this state.
49−
50−`ran` is the store of all commits and deltas, keyed by hash. The is
51−where all the "real" data we know is stored; the rest is "just
52−bookkeeping".
53−
54−`rom` is the state for all local desks. It consists of a `duct` to
55−[Dill](@/docs/arvo/dill/dill.md) and a collection of `desk`s.
56−
57−`hoy` is the state for all foreign desks.
58−
59−`ran` is the global, hash-addressed object store. It has maps of commit hashes
60−to commits and content hashes to content.
61−
62−`mon` is a collection of Unix mount points. `term` is the mount point (relative
63−to th pier) and `beam` is a domestic Clay directory.
64−
65−`hez` is the duct used to sync with Unix.
66−
67−`cez` is a collection of named permission groups.
68−
69−`pud` is an update that's waiting on a kernel upgrade.
70−
71−
72−#### `$room`, filesystem per domestic ship
73−
74−```hoon
75−+$ room :: fs per ship
76− $: hun=duct :: terminal duct
77− dos=(map desk dojo) :: native desk
78− == ::
79−```
80−
81−This is the representation of the filesystem of a ship on our pier.
82−
83−`hun` is the duct we use to send messages to [Dill](@/docs/arvo/dill/dill.md) to
84−display notifications of filesystem changes. Only `%note` `%gift`s should be
85−produced along this `duct`. This is set by the `%init` `move`.
86−
87−`dos` is a well-known operating system released in 1981. It is also the
88−set of `desk`s on this ship, mapped to their `desk` state.
89−
90−#### `$desk`, filesystem branch
91−
92−```hoon
93−+$ desk @tas
94−```
95−
96−This is the name of a branch of the filesystem. The default `desk`s are `%home`
97−and `%kids`. More may be created by simply referencing them. `desk`s have
98−independent histories and states, and they may be
99−[merged](@/docs/arvo/clay/using.md#merging) into each other.
100−
101−### `$dojo`, domestic desk state
102−
103−```hoon
104−+$ dojo
105− $: qyx=cult :: subscribers
106− dom=dome :: desk state
107− per=regs :: read perms per path
108− pew=regs :: write perms per path
109− ==
110−```
111−
112−This is the all the data that is specific to a particular `desk` on a domestic
113−ship. `qyx` is the set of subscribers to this `desk`, and `dom` is the data in
114−the `desk`. `regs` are `(map path rule)`, and so `per` is a `map` of read
115−permissions by `path` and `pew` is a `map` of write permissions by `path`.
116−
117−#### `$cult`, subscriptions
118−
119−```hoon
120−+$ cult (jug wove duct)
121−```
122−
123−`cult`s keep track of subscribers. `wove`s are associated to requests, and each
124−`wove` is mapped to a set of `duct`s associated to subscribers who should be
125−notified when the request is filled/updated.
126−
127−#### `$rave:clay`, general subscription request
128−
129−```hoon
130− +$ rave :: general request
131− $% [%sing =mood] :: single request
132− [%next =mood] :: await next version
133− [%mult =mool] :: next version of any
134− [%many track=? =moat] :: track range
135− == ::
136−```
137−
138−This represents a subscription request for a `desk`.
139−
140−A `%sing` request asks for data at single revision.
141−
142−A `%next` request asks to be notified the next time there’s a change to the
143−specified file.
144−
145−A `%mult` request asks to be notified the next time there's a change to a
146−specified set of files.
147−
148−A `%many` request asks to be notified on every change in a `desk` for a range of changes (including into the future).
149−
150−### `$rove`, stored general subscription request
151−
152−```hoon
153− +$ rove :: stored request
154− $% [%sing =mood] :: single request
155− [%next =mood aeon=(unit aeon) =cach] :: next version of one
156− $: %mult :: next version of any
157− =mool :: original request
158− aeon=(unit aeon) :: checking for change
159− old-cach=(map [=care =path] cach) :: old version
160− new-cach=(map [=care =path] cach) :: new version
161− == ::
162− [%many track=? =moat lobes=(map path lobe)] :: change range
163− == ::
164−```
165−
166−Like a `rave` but with provisions to store current versions for `%next` and `%many`.
167−Generally used when we store a request in our state somewhere. This is so that
168−we can determine whether new versions actually affect the path we're subscribed to.
169−
170−
171−#### `$mood:clay`, single subscription request
172−
173−```hoon
174− +$ mood [=care =case =path] :: request in desk
175−```
176−
177−This represents a request for data related to the state of the `desk` at a
178−particular commit, specfied by `case`. `care` specifies what kind of information
179−is desired, and `path` specifies the path we are requesting.
180−
181−#### `$moat:clay`, range subscription request
182−
183−```hoon
184− +$ moat [from=case to=case =path] :: change range
185−```
186−
187−This represents a request for all changes between `from` and `to` on `path`. You
188−will be notified when a change is made to the node referenced by the `path` or to
189−any of its children.
190−
191−### `$care:clay`, Clay submode
192−
193−```hoon
194− +$ care ?(%a %b %c %d %e %f %p %r %s %t %u %v %w %x %y %z) :: clay submode
195−```
196−
197−
198−This specifies what type of information is requested in a subscription
199−or a scry.
200−
201−`%a` build a Hoon file at a `path`.
202−
203−`%b` build a dynamically typed `mark` by name (a `$dais` mark-interface core).
204−
205−`%c` build a dynamically typed `mark` conversion gate (a `$tube`) by "from" and
206−"to" `mark` names.
207−
208−`%d` returns a `(set desk)` of the `desk`s that exist on your ship.
209−
210−`%e` builds a statically typed `mark` by name (a `$nave` mark-interface core).
211−
212−`%f` builds a statically typed mark converstion gate.
213−
214−`%p` produces the permissions for a directory, returned as a `[dict:clay dict:clay]`.
215−
216−`%r` requests the file in the same fashion as `%x`, but wraps the result in a `vase`.
217−
218−`%s` has miscellaneous debug endpoints.
219−
220−`%t` produces a `(list path)` of descendent `path`s for a directory within a `yaki`.
221−
222−`%u` produces a `?` depending on whether or not the specified file exists. It
223−does not check any of its children.
224−
225−`%v` requests the entire `dome` for a specified `desk` at a particular `aeon`.
226−When used on a foreign `desk`, this get us up-to-date to the requested version.
227−
228−`%w` requests the revision number and date of the specified path, returned as a `cass:clay`.
229−
230−`%x` requests the file at a specified path at the specified commit, returned as
231−an `@`. If there is no node at that path or if the node has no contents (that
232−is, if `fil:ankh` is null), then this crashes.
233−
234−`%y` requests an `arch` of the specfied commit at the specified path. It will
235−return the bunt of an `arch` if the file or directory is not found.
236−
237−`%z` requests a recursive hash of a node and all its children, returned as a `@uxI`.
238−
239−#### `$ankh`, filesystem node
240−
241−```hoon
242−+$ ankh :: expanded node
243− $~ [~ ~]
244− $: fil=(unit [p=lobe q=cage]) :: file
245− dir=(map @ta ankh) :: folders
246− == ::
247−```
248−
249−This is a recursive filesystem node type that can describe a whole tree of
250−folders and files, with subtrees organized by path prefix. In Earth filesystems,
251−a node is a file xor a directory. On Mars, we're inclusive, so a node is a file
252−ior a directory.
253−
254−`fil` is the contents of this file, if any. `p.fil` is a hash of the
255−contents while `q.fil` is the data itself.
256−
257−`dir` is the set of children of this node. In the case of a pure file,
258−this is empty. The keys are the names of the children and the values
259−are, recursively, the nodes themselves.
260−
261−
262−### `$arch`, shallow filesystem node
263−
264−```hoon
265−+$ arch (axil @uvI)
266−++ axil
267− |$ [item]
268− [fil=(unit item) dir=(map @ta ~)]
269−```
270−
271−An `arch` is a lightweight version of an `ankh` that only contains the hash
272−of the associated file and a `map` of child directories, but not the children of
273−those directories.
274−
275−The child directories are given by a `map` to null rather than a `set` so that the
276−ordering of the `map` will be the same as it is for an `axal`, allowing
277−efficient conversion for when the heavier node is needed.
278−```hoon
279−++ axal
280− |$ [item]
281− [fil=(unit item) dir=(map @ta $)]
282−```
283−
284−#### `$case`, specifying a commit
285−
286−```hoon
287−+$ case
288− $% :: %da: date
289− :: %tas: label
290− :: %ud: sequence
291− ::
292− [%da p=@da]
293− [%tas p=@tas]
294− [%ud p=@ud]
295− ==
296−```
297−
298−A commit can be referred to in three ways: `%da` refers to the commit
299−that was at the head on date `p`, `%tas` refers to the commit labeled
300−`p`, and `%ud` refers to the commit numbered `p`. Note that since these
301−all can be reduced down to a `%ud`, only numbered commits may be
302−referenced with a `++case:clay`.
303−
304−#### `$dome`, desk data
305−
306−```hoon
307−+$ dome
308− $: ank=ankh :: state
309− let=aeon :: top id
310− hit=(map aeon tako) :: versions by id
311− lab=(map @tas aeon) :: labels
312− mim=(map path mime) :: mime cache
313− fod=ford-cache :: ford cache
314− fer=(unit reef-cache) :: reef cache
315− == ::
316−```
317−
318−A `dome` is the state of a `desk` and associated data.
319−
320−`ank` is the current state of the desk. Thus, it is the state of the
321−filesystem at revison `let`. The head of a `desk` is always a numbered
322−commit.
323−
324−`let` is the number of the most recently numbered commit. This is also
325−the total number of numbered commits.
326−
327−`hit` is a map of numerical ids to commit hashes. These hashes are mapped into
328−their associated commits in `hut.rang` in the `raft` of Clay. In general, the
329−keys of this map are exactly the numbers from 1 to `let`, with no gaps. Of
330−course, when there are no numbered commits, `let` is 0, so `hit` is null.
331−Additionally, each of the commits is an ancestor of every commit numbered
332−greater than this one. Thus, each is a descendant of every commit numbered less
333−than this one. Since it is true that the date in each commit (`t:yaki`) is no
334−earlier than that of each of its parents, the numbered commits are totally
335−ordered in the same way by both pedigree and date. Of course, not every commit
336−is numbered. If that sounds too complicated to you, don't worry about it. It
337−basically behaves exactly as you would expect.
338−
339−`lab` is a map of textual labels to numbered commits. Note that labels
340−can only be applied to numbered commits. Labels must be unique across a
341−desk.
342−
343−`mim` is a cache of the content in the directories that are mounted to Unix.
344−
345−`fod` is the Ford cache, which keeps a cache of the results of builds performed
346−at this `desk`'s current revision, including a full transitive closure of
347−dependencies for each completed build.
348−
349−`fer` is the system file cache, which consists of `vase`s for `hoon.hoon`,
350−`arvo.hoon`, `lull.hoon`, and `zuse.hoon`.
351−
352−#### `++rung`, filesystem per neighbor ship
353−
354−```hoon
355−+$ rung
356− $: rus=(map desk rede) :: neighbor desks
357− ==
358−```
359−
360−This is the filesystem of a neighbor ship. The keys to this `map` are all
361−the `desk`s we know about on their ship.
362−
363−#### `++rede`, generic desk state
364−
365−```hoon
366− ++ rede :: universal project
367− $: lim=@da :: complete to
368− qyx=cult :: subscribers
369− ref=(unit rind) :: outgoing requests
370− dom=dome :: revision state
371− == ::
372−+$ rede :: universal project
373− $: lim=@da :: complete to
374− ref=(unit rind) :: outgoing requests
375− qyx=cult :: subscribers
376− dom=dome :: revision state
377− per=regs :: read perms per path
378− pew=regs :: write perms per path
379− == ::
380−```
381−
382−This is our knowledge of the state of a desk, either foreign or
383−domestic.
384−
385−`lim` is the most recent `@da` for which we're confident we have all the
386−information for. For local `desk`s, this is always `now`. For foriegn `desk`s,
387−this is the last time we got a full update from the foreign ship.
388−
389−`ref` is the request manager for the desk. For domestic `desk`s, this is
390−null since we handle requests ourselves. For foreign `desk`s, this keeps track
391−of all pending foriegn requests plus a cache of the responses to previous requests.
392−
393−`qyx` is the `set` of subscriptions to this desk, with listening `duct`s. These
394−subscriptions exist only until they've been filled. For domestic `desk`s, this
395−is simply `qyx:dojo` - all subscribers to the `desk`. For foreign `desk`s this
396−is all the subscribers from our ship to the foreign `desk`.
397−
398−`dom` is the data in the `desk`.
399−
400−`regs` are `(map path rule)`, and so `per` is a `map` of read permissions by
401−`path` and `pew` is a `map` of write permissions by `path`.
402−
403−
404−#### `$rind`, foreign request manager
405−
406−```hoon
407−+$ rind :: request manager
408− $: nix=@ud :: request index
409− bom=(map @ud update-state) :: outstanding
410− fod=(map duct @ud) :: current requests
411− haw=(map mood (unit cage)) :: simple cache
412− == ::
413−```
414−
415−This is the request manager for a foreign `desk`. When we send a request to a
416−foreign ship, we keep track of it in here.
417−
418−`nix` is one more than the index of the most recent request. Thus, it is the
419−next available request number.
420−
421−`bom` is the set of outstanding requests. The keys of this `map` are some subset
422−of the numbers between 0 and one less than `nix`. The members of the `map` are
423−exactly those requests that have not yet been fully satisfied.
424−
425−`fod` is the same set as `bom`, but from a different perspective. In particular,
426−the values of `fod` are the same as the keys of `bom`, and the `duct` of the
427−values of `bom` are the same as the keys of `fod`. Thus, we can map `duct`s to
428−their associated request number and `update-state`, and we can map request
429−numbers to their associated `duct`.
430−
431−`haw` is a map from `%sing` requests to their values. This acts as a cache for
432−requests that have already been filled.
433−
434−#### `$update-state`, status of outstanding foreign request
435−
436−```hoon
437−+$ update-state
438− $: =duct
439− =rave
440− have=(map lobe blob)
441− need=(list lobe)
442− nako=(qeu (unit nako))
443− busy=_|
444− ==
445−```
446−
447−An `update-state` is used to represent the status of an outstanding request to a
448−foreign `desk`.
449−
450−`duct` and `rave` are the `duct` along which the request was made and the
451−request itself.
452−
453−`have` is a map of hashes thus far acquired in the request to the data
454−associated with those hashes.
455−
456−`need` is a list of hashes yet to be acquired.
457−
458−`nako` is a queue of data yet to be validated.
459−
460−`busy` tracks whether or not the request is currently being fulfilled.
461−
462−#### `$rang:clay`, data repository
463−
464−```hoon
465− +$ rang :: repository
466− $: hut=(map tako yaki) :: changes
467− lat=(map lobe blob) :: data
468− == ::
469−```
470−
471−This is a data repository keyed by hash. Thus, this is where the "real" data
472−is stored, but it is only meaningful if we know the hash of what we're
473−looking for.
474−
475−`hut` is a `map` from commit hashes (`tako`s) to commits (`yaki`s). We often get
476−the hashes from `hit:dome`, which keys them by numerical id. Not every commit
477−has an numerical id.
478−
479−`lat` is a `map` from content hashes (`lobe`s) to the actual content (`blob`s).
480−We often get the hashes from a `yaki`, which references this `map` to get the
481−data. There is no `blob` in `yaki:clay`. They are only accessible through
482−`lat`.
483−
484−#### `$tako:clay`, commit reference
485−
486−```hoon
487− +$ tako @ :: yaki ref
488−```
489−
490−This is a hash of a `yaki:clay`, a commit. These are most notably used as the
491−keys in `hut:rang:clay`, where they are associated with the actual `yaki:clay`,
492−and as the values in `hit:dome:clay`, where sequential numerical ids are
493−associated with these.
494−
495−#### `$yaki:clay`, commit
496−
497−```hoon
498− +$ yaki :: commit
499− $: p=(list tako) :: parents
500− q=(map path lobe) :: namespace
501− r=tako :: self-reference
502− t=@da :: date
503− == ::
504−```
505−
506−This is a single commit.
507−
508−`p` is a `list` of the hashes of the parents of this commit. In most
509−cases, this will be a single commit, but in a merge there may be more
510−parents. In theory, there may be an arbitrary number of parents, but in
511−practice merges have exactly two parents. This may change in the future.
512−For commit 1, there is no parent.
513−
514−`q` is a `map` of the `path`s on a desk to the content hashes at that location.
515−If you understand what a `lobe:clay` and a `blob:clay` is, then the type
516−signature here tells the whole story.
517−
518−`r` is the hash associated with this commit.
519−
520−`t` is the date at which this commit was made.
521−
522−#### `$lobe:clay`, data reference
523−
524−```hoon
525− +$ lobe @uvI :: blob ref
526−```
527−
528−This is a hash of a `blob:clay`. These are most notably used in `lat:rang:clay`,
529−where they are associated with the actual `blob:clay`, and as the values in
530−`q:yaki:clay`, where `path`s are associated with their content hashes in a commit.
531−
532−#### `$blob:clay`, data
533−
534−```hoon
535− +$ blob :: fs blob
536− $% [%delta p=lobe q=[p=mark q=lobe] r=page] :: delta on q
537− [%direct p=lobe q=page] :: immediate
538−```
539−
540−This is a node of data. In both cases, `p` is the hash of the blob.
541−
542−`%delta` is the case where we define the data by a delta on other data. In
543−practice, the other data is always the previous commit, but nothing depends on
544−this. `p.q` is the `mark` of the parent blob, `q.q` is the hash of the parent
545−blob, and `r` is the delta.
546−
547−`%direct` is the case where we simply have the data directly. `q` is the data.
548−These almost always come from the creation of a file.
549−
550−
551−#### `+urge`, list change
552−
553−```hoon
554− ++ urge |*(a=mold (list (unce a))) :: list change
555−```
556−
557−This is a parametrized type for list changes. For example, `(urge @t)`
558−is a list change for lines of text.
559−
560−#### `+unce`, change part of a list.
561−
562−```hoon
563− ++ unce :: change part
564− |* a=mold ::
565− $% [%& p=@ud] :: skip[copy]
566− [%| p=(list a) q=(list a)] :: p -> q[chunk]
567− == ::
568−```
569−
570−This is a single change in a list of elements of type `a`. For example,
571−`(unce @t)` is a single change in lines of text.
572−
573−`%&` means the next `p` lines are unchanged.
574−
575−`%|` means the lines `p` have changed to `q`.
576−
577−#### `$nori:clay`, repository action
578−
579−```hoon
580− +$ nori :: repository action
581− $% [%& p=soba] :: delta
582− [%| p=@tas] :: label
583− == ::
584−```
585−
586−This describes a change that we are asking Clay to make to the `desk`.
587−There are two kinds of changes that may be made: we can modify files or
588−we can apply a label to a commit.
589−
590−In the `|` case, we will simply label the current commit with the given
591−label. In the `&` case, we will apply the given changes.
592−
593−#### `$soba:clay`, delta
594−
595−```hoon
596− +$ soba (list [p=path q=miso]) :: delta
597−```
598−
599−This describes a `list` of changes to make to a `desk`. The `path`s are `path`s
600−to files to be changed, and the corresponding `miso` value is a description of
601−the change itself.
602−
603−#### `$miso:clay`, ankh delta
604−
605−```hoon
606− +$ miso :: ankh delta
607− $% [%del ~] :: delete
608− [%ins p=cage] :: insert
609− [%dif p=cage] :: mutate from diff
610− [%mut p=cage] :: mutate from raw
611− == ::
612−```
613−
614−There are four kinds of changes that may be made to a node in a `desk`.
615−
616−`%del` deletes the node.
617−
618−`%ins` inserts a file given by `p`.
619−
620−`%dif` is currently unimplemented. This may seem strange, so we remark that
621−diffs for individual files are implemented using `+diff` and `+pact` in `mark`s.
622−So for an `ankh`, which may include both files and directories, `%dif` being
623−unimplemented really just means that we do not yet have a formal concept of
624−changes in directory structure.
625−
626−`%mut` mutates the file using raw data given by `p`.
627−
628−#### `$riff:clay`, request/desist
629−
630−```hoon
631− +$ riff [p=desk q=(unit rave)] :: request+desist
632−```
633−
634−This represents a request for data about a particular `desk`. If `q`
635−contains a `rave`, then this opens a subscription to the `desk` for that
636−data. If `q` is null, then this tells Clay to cancel the subscription
637−along this duct.
638−
639−#### `$riot:clay`, response
640−
641−```hoon
642− +$ riot (unit rant) :: response+complete
643−```
644−
645−A `riot` is a response to a subscription. If null, the subscription has
646−been completed, and no more responses will be sent. Otherwise, the
647−`rant` is the produced data.
648−
649−#### `$rant:clay`, response data
650−
651−```hoon
652− +$ rant :: response to request
653− $: p=[p=care q=case r=desk] :: clade release book
654− q=path :: spur
655− r=cage :: data
656− == ::
657−```
658−
659−This is the data associated to the response to a request. `p.p` specifies
660−the type of data that was requested (and is produced). `q.p` gives the
661−specific version reported (since a range of versions may be requested in
662−a subscription). `r.p` is the `desk`. `q` is the path to the filesystem
663−node. `r` is the data itself (in the format specified by `p.p`).
664−
665−### `$nako`, subscription response data
666−
667−```hoon
668−+$ nako :: subscription state
669− $: gar=(map aeon tako) :: new ids
670− let=aeon :: next id
671− lar=(set yaki) :: new commits
672− bar=(set plop) :: new content
673− == ::
674−```
675−
676−This is the data that is produced by a request for a range of revisions
677−of a `desk`. This allows us to easily keep track of a remote repository --
678−all the new information we need is contained in the `nako`.
679−
680−`gar` is a map of the revisions in the range to the hash of the commit
681−at that revision. These hashes can be used with `hut:rang:clay` to find the
682−commit itself.
683−
684−`let` is either the last revision number in the range or the most recent
685−revision number, whichever is smaller.
686−
687−`lar` is the set of new commits, and `bar` is the set of new content.
688−
arvo/clay/examples.mddeleted−824
@@ -1,824 +0,0 @@
1−+++
2−title = "Examples"
3−weight = 7
4−template = "doc.html"
5−+++
6−
7−# Contents
8−
9−- [Introduction](#introduction)
10−- [%warp](#warp) - Read and Subscribe.
11− - [%sing](#sing) - Read a file or directory.
12− - [%next](#next) - Subscribe for the next change to a file or directory.
13− - [%mult](#mult) - Subscribe for the next change to a set of files and/or directories.
14− - [%many](#many) - Track changes to a `desk` for the specified range of revisions.
15− - [Cancel Subscription](#cancel-subscription)
16−- [%info](#info) - Write and Modify.
17− - [%ins](#ins) - Add a file.
18− - [%del](#del) - Delete a file.
19− - [%mut](#mut) - Change a file.
20− - [Multiple Changes](#multiple-changes) - Change multiple files.
21−- [Manage Mounts](#manage-mounts)
22− - [%boat](#boat) - List mounts.
23− - [%mont](#mont) - Mount something.
24− - [%ogre](#ogre) - Unmount something.
25− - [%dirk](#dirk) - Commit changes.
26−- [Merge Desks](#merge-desks)
27− - [%merg](#merg)
28−- [Permissions](#permissions)
29− - [%perm](#perm) - Set file permissions.
30− - [%cred](#cred) - Add permission group.
31− - [%crew](#crew) - Get permission groups.
32− - [%crow](#crow) - Get group usage.
33−- [Foreign Ships](#foreign-ships)
34− - [%warp](#warp-remote) - Read a file on a foreign ship.
35− - [%merg](#merg-remote) - Merge from a foreign `desk`.
36−
37−# Introduction
38−
39−This document contains a number of examples of interacting with Clay using its various `task`s. Sections correspond to the general details in the [API Reference](@/docs/arvo/clay/tasks.md) document.
40−
41−Most examples will either use `|pass` to just send a `task` or the following thread to send a `task` and take the resulting `gift`. You can save the following thread to the `ted` directory of your `%home` `desk`:
42−
43−`send-task-take-gift.hoon`
44−
45−```hoon
46−/- spider
47−/+ strandio
48−=, strand=strand:spider
49−^- thread:spider
50−|= arg=vase
51−=/ m (strand ,vase)
52−^- form:m
53−=/ uarg !< (unit task:clay) arg
54−?~ uarg
55− (strand-fail:strand %no-arg ~)
56−=/ =task:clay u.uarg
57−=/ =card:agent:gall [%pass /foo %arvo %c task]
58−;< ~ bind:m (send-raw-card:strandio card)
59−;< res=[wire sign-arvo] bind:m take-sign-arvo:strandio
60−~& +>:res
61−(pure:m !>(~))
62−```
63−
64−# `%warp`
65−
66−See the [Read and Subscribe](@/docs/arvo/clay/tasks.md#warp) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
67−
68−## `%sing`
69−
70−Here we'll look at reading files by passing Clay a `%warp` `task` with a `%sing` `rave` and receiving a `%writ` `gift` containing the data in response.
71−
72−
73−Using the `send-task-take-gift.hoon` thread, let's try reading `gen/hood/hi.hoon`:
74−
75−```
76−> -send-task-take-gift [%warp our %home ~ %sing %x da+now /gen/hood/hi/hoon]
77−```
78−
79−You should see something like this as the output:
80−
81−```
82−[ %writ
83− p
84− [ ~
85− [ p=[p=%x q=[%da p=~2021.5.20..23.37.50..e79b] r=%home]
86− q=/gen/hood/hi/hoon
87− r
88− [ p=%hoon
89− q
90− [ #t/@
91− q
92− 3.548.750.706.400.251.607.252.023.288.575.526.190.856.734.474.077.821.289.791.377.301.707.878.697.553.411.219.689.905.949.957.893.633.811.025.757.107.990.477.902.858.170.125.439.223.250.551.937.540.468.638.902.955.378.837.954.792.031.592.462.617.422.136.386.332.469.076.584.061.249.923.938.374.214.925.312.954.606.277.212.923.859.309.330.556.730.410.200.952.056.760.727.611.447.500.996.168.035.027.753.417.869.213.425.113.257.514.474.700.810.203.348.784.547.006.707.150.406.298.809.062.567.217.447.347.357.039.994.339.342.906
93− ]
94− ]
95− ]
96− ]
97−]
98−```
99−
100−The `cage` in the `riot` of the `%writ` contains the file's data due to our use of an `%x` `care`. It needn't be `%x` though. If we change it to `%u`, for example, we'll get a `?` `cage` instead:
101−
102−```
103−> -send-task-take-gift [%warp our %home ~ %sing %x da+now /gen/hood/hi/hoon]
104−[ %writ
105− p
106− [ ~
107− [ p=[p=%u q=[%da p=~2021.5.20..23.42.21..bb33] r=%home]
108− q=/gen/hood/hi/hoon
109− r=[p=%flag q=[#t/?(%.y %.n) q=0]]
110− ]
111− ]
112−]
113−```
114−
115−Here's a breakdown of the `task` we sent:
116−
117−
118−
119−## `%next`
120−
121−Here we'll look at subscribing to the next version of a file by passing Clay a `%warp` `task` with a `%next` `rave` and receiving a `%writ` `gift` when the file changes.
122−
123−Using the `send-task-take-gift.hoon` thread, let's subscribe to the next version of `foo.txt`:
124−
125−```
126−> -send-task-take-gift [%warp our %home ~ %next %x da+now /foo/txt]
127−```
128−
129−Now, in unix, create a file called `foo.txt` in the root of the `home` directory of your ship. In the dojo, hit backspace to disconnect the thread from the dojo prompt and run `|commit %home`. You should see something like:
130−
131−```
132−> |commit %home
133−>=
134−[%writ p=[~ [p=[p=%x q=[%ud p=3] r=%home] q=/foo/txt r=[p=%txt q=[#t/*'' q=0]]]]]
135−+ /~zod/home/3/foo/txt
136−```
137−
138−As you can see, the `riot` in the `%writ` includes a `cage` with the data of `/foo/txt` due to our use of an `%x` `care`.
139−
140−Now run the thread again, and this time delete the file in unix and again `|commit %home` in the dojo. You should see:
141−
142−```
143−> |commit %home
144−>=
145−[%writ p=~]
146−- /~zod/home/4/foo/txt
147−```
148−
149−You can see the `riot` is just `~` due to the file being deleted.
150−
151−Here's a breakdown of the task we sent:
152−
153−
154−
155−## `%mult`
156−
157−Here we'll look at subscribing to the next version of multiple files by passing Clay a `%warp` `task` with a `%mult` `rave` and receiving a `%wris` `gift` when any of the files change.
158−
159−This thread will subscribe to `/foo/txt` with an `%x` `care` and `/bar/txt` with a `%u` `care`. It will print out the `%wris` it gets back from Clay.
160−
161−`sub-mult.hoon`
162−
163−```hoon
164−/- spider
165−/+ strandio
166−=, strand=strand:spider
167−^- thread:spider
168−|= arg=vase
169−=/ m (strand ,vase)
170−^- form:m
171−=/ files=(set (pair care:clay path))
172− %- sy :~
173− [%x /foo/txt]
174− [%u /bar/txt]
175− ==
176−;< =bowl:strand bind:m get-bowl:strandio
177−=/ =task:clay [%warp our.bowl %home ~ %mult da+now.bowl files]
178−=/ =card:agent:gall [%pass /mult %arvo %c task]
179−;< ~ bind:m (send-raw-card:strandio card)
180−;< response=(pair wire sign-arvo) bind:m take-sign-arvo:strandio
181−~& +.q.response
182−(pure:m !>(~))
183−```
184−
185−Save the above to `ted/sub-mult.hoon`, `|commit %home` and run with `-sub-mult`. Now, create `foo.txt` and `bar.txt` in your home directory, hit backspace in the dojo to disconnect the thread and run `|commit %home`. You should see something like:
186−
187−```
188−> |commit %home
189−>=
190−[%wris p=[%da p=~2021.4.27..06.07.08..5ec4] q={[p=%u q=/bar/txt] [p=%x q=/foo/txt]}]
191−+ /~zod/home/151/foo/txt
192−+ /~zod/home/151/bar/txt
193−```
194−
195−You'll notice that, unlike a `%writ`, the `%wris` doesn't give you the data. It merely tells you the `care`s and `path`s of the files that changed. If you need to actually get the data, you can just scry or send a request for the files in question.
196−
197−Now, run the thread again, open `bar.txt` in an editor, modify its contents, save it and `|commit %home`. You'll notice you didn't receive a `%wris`. This is because we subscribed to `/bar/txt` with `%u` care and its existence didn't change.
198−
199−Lastly, delete `foo.txt` and `|commit %home`. You should see something like:
200−
201−```
202−> |commit %home
203−>=
204−[%wris p=[%da p=~2021.4.27..06.15.03..0da4] q={[p=%x q=/foo/txt]}]
205−- /~zod/home/153/foo/txt
206−```
207−
208−As you can see, a relevant change to any of the subscribed files will trigger a response, not just when all of them change.
209−
210−Here's a breakdown of the `task` we sent:
211−
212−
213−
214−## `%many`
215−
216−Here we'll look at subscribing to a range of changes to a `desk` by passing Clay a `%warp` `task` with a `%many` `rave` and receiving `%writ` `gift`s when changes occur.
217−
218−This thread will subscribe to changes to your `%home` `desk` for the next three minutes. The `track` is `%.y` so it will only inform you of changes, not send the full `nako`. It will only get updates if the specified file exists. It contains a `main-loop` that will take an arbitrary number of `sign`s and print them out in the dojo. Since it never ends, you'll need to stop it with the `:spider|kill` command in the dojo.
219−
220−`sub-many.hoon`
221−
222−```hoon
223−/- spider
224−/+ strandio
225−=, strand=strand:spider
226−|%
227−++ take-sign-loop
228− =/ m (strand ,~)
229− ^- form:m
230− %- (main-loop:strandio ,~)
231− :~ |= ~
232− ^- form:m
233− ;< res=(pair wire sign-arvo)
234− bind:m
235− ((handle:strandio ,(pair wire sign-arvo)) take-sign-arvo:strandio)
236− ~& res
237− (pure:m ~)
238− ==
239−--
240−^- thread:spider
241−|= arg=vase
242−=/ m (strand ,vase)
243−^- form:m
244−=/ uarg !< (unit path) arg
245−?~ uarg
246− (strand-fail:strand %no-arg ~)
247−=/ =path u.uarg
248−;< =bowl:strand bind:m get-bowl:strandio
249−=/ =task:clay [%warp our.bowl %home ~ %many %.y da+now.bowl da+(add ~m3 now.bowl) path]
250−=/ =card:agent:gall [%pass /many %arvo %c task]
251−;< ~ bind:m (send-raw-card:strandio card)
252−;< ~ bind:m take-sign-loop
253−(pure:m !>(~))
254−```
255−
256−Make sure `foo.txt` doesn't exist in the root of your `%home` `desk`. Save this to `ted/sub-many.hoon`, `|commit %home`, run it like `-sub-many /foo/txt`, and hit backspace in the dojo to free up the dojo prompt. Now, add a file called `bar.txt` to your `desk` and `|commit %home`. You should see something like:
257−
258−```
259−> |commit %home
260−>=
261−+ /~zod/home/260/bar/txt
262−```
263−
264−Notice you've received no `%writ` from Clay. This is because `/foo/txt` doesn't exist. Now, create `foo.txt` and `|commit %home` again. You should see:
265−
266−```
267−> |commit %home
268−>=
269−[ p=/many
270− q=[%clay [%writ p=[~ [p=[p=%w q=[%ud p=261] r=%home] q=/ r=[p=%null q=[#t/@n q=0]]]]]]
271−]
272−+ /~zod/home/261/foo/txt
273−```
274−
275−Now that `/foo/txt` exists it will inform you of updates. Note that if you delete `/foo/txt` again it will again stop sending updates.
276−
277−Now try adding `baz.txt`:
278−
279−```
280−> |commit %home
281−>=
282−[ p=/many
283− q=[%clay [%writ p=[~ [p=[p=%w q=[%ud p=262] r=%home] q=/ r=[p=%null q=[#t/@n q=0]]]]]]
284−]
285−+ /~zod/home/262/baz/txt
286−```
287−
288−Now wait until the three minutes is up and try making a change, for example deleting `baz.txt`:
289−
290−```
291−> |commit %home
292−>=
293−[ p=/many
294− q=[%clay [%writ p=[~ [p=[p=%w q=[%ud p=264] r=%home] q=/ r=[p=%null q=[#t/@n q=0]]]]]]
295−]
296−[p=/many q=[%clay [%writ p=~]]]
297−- /~zod/home/263/baz/txt
298−```
299−
300−You can see that along with the normal `%writ` it's also sent a second `%writ` with a null `riot` to indicate the subscription has ended. This is because it has now passed the end of the range of `case`s to which you subscribed.
301−
302−Run `:spider|kill` to stop the thread.
303−
304−Here's a breakdown of the `task` we sent:
305−
306−
307−
308−## Cancel Subscription
309−
310−Here we'll look at cancelling a subscription by sending Clay a `%warp` `task` with a null `(unit rave)` in the `riff`.
311−
312−This thread will subscribe to the `%next` version of `/foo/txt`, then immediately cancel the subscription and wait for a response to print (which it will never receive).
313−
314−`stop-sub.hoon`
315−
316−```hoon
317−/- spider
318−/+ strandio
319−=, strand=strand:spider
320−^- thread:spider
321−|= arg=vase
322−=/ m (strand ,vase)
323−^- form:m
324−;< =bowl:strand bind:m get-bowl:strandio
325−=/ =task:clay [%warp our.bowl %home ~ %next %x da+now.bowl /foo/txt]
326−=/ =card:agent:gall [%pass /next %arvo %c task]
327−;< ~ bind:m (send-raw-card:strandio card)
328−=. task [%warp our.bowl %home ~]
329−=. card [%pass /next %arvo %c task]
330−;< ~ bind:m (send-raw-card:strandio card)
331−;< =riot:clay bind:m (take-writ:strandio /next)
332−~& riot
333−(pure:m !>(~))
334−```
335−
336−Save the above to `ted/stop-sub.hoon`, `|commit %home`, run it with `-stop-sub` and hit backspace to detach it from the dojo prompt. Now, add `foo.txt` to the root of your `%home` `desk` and `|commit %home`. You should see:
337−
338−```
339−> |commit %home
340−>=
341−+ /~zod/home/266/foo/txt
342−```
343−
344−As you can see we've received no `%writ`. We can thus conclude the subscription has successfully been cancelled.
345−
346−Run `:spider|kill` to stop the thread.
347−
348−Here's a breakdown of the `task` we sent:
349−
350−
351−
352−# `%info`
353−
354−See the [Write and Modify](@/docs/arvo/clay/tasks.md#write-and-modify) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
355−
356−## `%ins`
357−
358−Here we'll look at adding a file by sending Clay a `%info` `task` containing a `%ins` `miso`.
359−
360−Let's try adding a `foo.txt` file with 'foo' as its contents:
361−
362−```
363−> |pass [%c [%info %home %& [/foo/txt %ins %txt !>(~['foo'])]~]]
364−+ /~zod/home/5/foo/txt
365−```
366−
367−If you have a look in the home of your pier you'll see there's now a file called `foo.txt` with the text `foo` in it.
368−
369−We've created the `cage` of the content like `[%txt !>(~['foo'])]`, if you want to write something besides a text file you'd just give it the appropriate `mark` and `vase`.
370−
371−Here's a breakdown of the `task` we sent:
372−
373−
374−
375−## `%del`
376−
377−Here we'll look at deleting a file by sending Clay a `%info` `task` containing a `%del` `miso`.
378−
379−Let's try deleting the `foo.txt` file created in the [previous example](#ins):
380−
381−```
382−> |pass [%c [%info %home %& [/foo/txt %del ~]~]]
383−- /~zod/home/6/foo/txt
384−```
385−
386−If you have a look in the home of your pier you'll see the `foo.txt` file is now gone.
387−
388−Here's a breakdown of the `task` we sent:
389−
390−
391−
392−## `%mut`
393−
394−Identical to the [%ins](#ins) example, just replace `%ins` with `%mut`.
395−
396−## Multiple Changes
397−
398−Here we'll look at changing multiple files in one request by sending Clay a `%info` `task` containing multiple `miso` in the `soba`.
399−
400−Since `soba` is just a `list` of `miso`, you can add a bunch of `miso` and they'll all be applied. This thread adds three files and then deletes them. Here there's only one type of `miso` in each request but you could mix different types together too.
401−
402−`multi-change.hoon`
403−
404−```hoon
405−/- spider
406−/+ strandio
407−=, strand=strand:spider
408−^- thread:spider
409−|= arg=vase
410−=/ m (strand ,vase)
411−^- form:m
412−=/ soba-a :~ [/foo/txt %ins %txt !>(['foo' ~])]
413− [/bar/txt %ins %txt !>(['bar' ~])]
414− [/baz/txt %ins %txt !>(['baz' ~])]
415− ==
416−=/ soba-b :~ [/foo/txt %del ~]
417− [/bar/txt %del ~]
418− [/baz/txt %del ~]
419− ==
420−;< ~ bind:m (send-raw-card:strandio [%pass /info %arvo %c %info %home %& soba-a])
421−;< ~ bind:m (send-raw-card:strandio [%pass /info %arvo %c %info %home %& soba-b])
422−(pure:m !>(~))
423−```
424−
425−Save to `ted/multi-change.hoon`, `|commit %home`, and run:
426−
427−```
428−> -multi-change
429−+ /~zod/home/37/foo/txt
430−+ /~zod/home/37/bar/txt
431−+ /~zod/home/37/baz/txt
432−- /~zod/home/38/foo/txt
433−- /~zod/home/38/bar/txt
434−- /~zod/home/38/baz/txt
435−```
436−
437−# Manage Mounts
438−
439−See the [Manage Mounts](@/docs/arvo/clay/tasks.md#manage-mounts) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
440−
441−## `%boat`
442−
443−Here we'll look at requesting the list of existing mount points on a ship by sending Clay a `%boat` `task` and receiving a `%hill` `gift`.
444−
445−Using the `send-task-take-gift.hoon` thread, let's make such a request:
446−
447−```
448−> -send-task-take-gift [%boat ~]
449−[%hill p=~[%home]]
450−```
451−
452−## `%mont`
453−
454−Here we'll look at mounting `desk`s, directories and files to unix by sending Clay a `%mont` `task`.
455−
456−Let's first try mounting our `%kids` desk:
457−
458−```
459−> |pass [%c [%mont %kids [our %kids da+now] /]]
460−```
461−
462−If you look in your pier, you should now see a `kids` folder which contains the contents of that `desk`.
463−
464−If we make a `%boat` request as detailed in the [%boat](#boat) section, we'll now see the mount point listed:
465−
466−```
467−> -send-task-take-gift [%boat ~]
468−[%hill p=~[%kids %home]]cruz gift. It looks like:
469−
470−[%cruz cez=(map @ta crew)] :: permission groups
471−The cez is just a map from group name to crew
472−```
473−
474−Note the mount point doesn't need to match a `desk`, file or directory. We can also do:
475−
476−```
477−> |pass [%c [%mont %wibbly-wobbly [our %home da+now] /]]
478−```
479−
480−And you'll now see that there's a `wibbly-wobbly` folder with the contents of the `%home` `desk`. You'll also notice we can mount the same file or directory more than once. There's no problem having `%home` mounted to both `home` and `wibbly-wobbly`. The only requirement is that their mount points be unique.
481−
482−Let's try mounting a subdirectory and a single folder:
483−
484−```
485−> |pass [%c [%mont %gen [our %home da+now] /gen]]
486−> |pass [%c [%mont %hi [our %home da+now] /gen/hood/hi]]
487−```
488−
489−If you look in your pier you'll now see a `gen` folder with the contents of `/gen` and a `hi.hoon` file by itself. Notice how the file extension has been automatically added.
490−
491−## `%ogre`
492−
493−Here we'll look at unmounting `desk`s, directories and files by sending Clay a `%ogre` `task`.
494−
495−Let's unmount what we mounted in the [%mont](#mont) section. First we'll unmount the `%kids` desk:
496−
497−```
498−|pass [%c [%ogre %kids]]
499−```
500−
501−Our custom mount point `%wibbly-wobbly`:
502−
503−```
504−|pass [%c [%ogre %wibbly-wobbly]]
505−```
506−
507−And the single `hi.hoon` we previously mounted by specifying its mount point `%hi`:
508−
509−```
510−|pass [%c [%ogre %hi]]
511−```
512−
513−If we specify a non-existent mount point it will fail with an error printed to the dojo like:
514−
515−```
516−> |pass [%c [%ogre %kids]]
517−[%not-mounted %kids]
518−```
519−
520−If we give it an unmounted `beam` it will not print an error but still won't work.
521−
522−## `%dirk`
523−
524−Here we'll look at committing changed files by sending Clay a `%dirk` `task`.
525−
526−This `task` performs the same function as the `|commit` dojo command.
527−
528−With your `%home` `desk` mounted, try adding a file and send a `%dirk` to commit the change:
529−
530−```
531−> |pass [%c [%dirk %home]]
532−+ /~zod/home/12/foo/txt
533−```
534−
535−Clay will print the changed files to the dojo with a leading `+`, `-` or `:` to indicate a new file, deleted file and changed file respectively.
536−
537−If you have the same `desk` mounted to multiple points, a committed change in one mount will also update the others.
538−
539−# Merge Desks
540−
541−See the [Merge Desks](@/docs/arvo/clay/tasks.md#merge-desks) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
542−
543−## `%merg`
544−
545−Here we'll look at merging `desk`s by sending Clay a `%merg` `task` and receiving a `%mere` `gift` in response.
546−
547−First, using the `send-task-take-gift.hoon` thread, let's try creating a new `desk`:
548−
549−```
550−> -send-task-take-gift [%merg %foo our %home da+now %init]
551−[%mere p=[%.y p={}]]
552−```
553−
554−Now if we scry for our `desk`s we'll see `%foo` is there:
555−
556−```
557−> .^((set desk) %cd /===)
558−{%home %foo %kids}
559−```
560−
561−Next, we'll create a merge conflict and try a couple of things. Mount `%foo` with `|mount /=foo=`, then add a `foo.txt` to both `desk`s but with different text in each and `|commit` them.
562−
563−Now we'll try merging `%home` into `%foo` with a `%mate` strategy:
564−
565−```
566−> -send-task-take-gift [%merg %foo our %home da+now %mate]
567−[ /foo
568− [ %clay
569− [ %mere
570− p
571− [ %.n
572− p
573− [ p=%mate-conflict
574− q=~[[%rose p=[p="/" q="/" r=""] q=[i=[%leaf p="foo"] t=[i=[%leaf p="txt"] t=~]]]]
575− ]
576− ]
577− ]
578− ]
579−]
580−```
581−
582−As you can see, the merge has failed. Let's try again with a `%meld` strategy:
583−
584−```
585−> -send-task-take-gift [%merg %foo our %home da+now %meld]
586−[/foo [%clay [%mere p=[%.y p={/foo/txt}]]]]
587−```
588−
589−Now the merge has succeeded and the `%mere` notes the file with a merge conflict. If we try with a `%only-that` strategy:
590−
591−```
592−> -send-task-take-gift [%merg %foo our %home da+now %only-that]
593−[/foo [%clay [%mere p=[%.y p={}]]]]
594−: /~zod/foo/6/foo/txt
595−```
596−
597−...you can see it's overwritten the `foo/txt` in the `%foo` `desk` and the `%mere` now has an empty `set`, indicating no merge conflicts.
598−
599−Next, let's look at subscribing for future changes. Since the `case` is specified explicitly in the `%merge` `task`, we can set it in the future:
600−
601−```
602−> -send-task-take-gift [%merg %foo our %home da+(add ~m2 now) %only-that]
603−```
604−
605−Now change the text in the `foo.txt` in the `%home` `desk`, hit backspace to detach the thread and `|commit %home`. After the two minutes pass you should see:
606−
607−```
608−[/foo [%clay [%mere p=[%.y p={}]]]]
609−: /~zod/foo/7/foo/txt
610−```
611−
612−You can also specify it by revision number or label.
613−
614−# Permissions
615−
616−See the [Permissions](@/docs/arvo/clay/tasks.md#permissions) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
617−
618−## `%perm`
619−
620−Here we'll look at setting permissions by sending Clay a `%perm` `task`.
621−
622−First, let's allow `~nes` to read `/gen/hood/hi/hoon`:
623−
624−```
625−> |pass [%c [%perm %home /gen/hood/hi/hoon %r ~ %white (sy [%.y ~nes]~)]]
626−```
627−
628−...and we'll do a `%p` scry to see that the permission was set:
629−
630−```
631−> .^([r=dict:clay w=dict:clay] %cp /===/gen/hood/hi/hoon)
632−[r=[src=/gen/hood/hi/hoon rul=[mod=%white who=[p={~nes} q={}]]] w=[src=/ rul=[mod=%white who=[p={} q={}]]]]
633−```
634−
635−You can see that `~nes` is now in the read whitelist. Next, let's try a write permission:
636−
637−```
638−> |pass [%c [%perm %home /ted %w ~ %white (sy [%.y ~nes]~)]]
639−```
640−
641−You can see `~nes` can now write to `/ted`:
642−
643−```
644−> .^([r=dict:clay w=dict:clay] %cp /===/ted)
645−[r=[src=/ rul=[mod=%white who=[p={} q={}]]] w=[src=/ted rul=[mod=%white who=[p={~nes} q={}]]]]
646−```
647−
648−Since we've set it for the whole `/ted` directory, if we check a file inside it we'll see it also has this permission:
649−
650−```
651−> .^([r=dict:clay w=dict:clay] %cp /===/ted/aqua/ames/hoon)
652−[r=[src=/ rul=[mod=%white who=[p={} q={}]]] w=[src=/ted rul=[mod=%white who=[p={~nes} q={}]]]]
653−```
654−
655−...and you'll notice that `src` tells us it's inherited the rule from `/ted`.
656−
657−Now let's try setting both read and write permissions:
658−
659−```
660−> |pass [%c [%perm %home /gen/help/hoon %rw `[%black (sy [%.y ~nes]~)] `[%white (sy [%.y ~nes]~)]]]
661−```
662−
663−```
664− .^([r=dict:clay w=dict:clay] %cp /===/gen/help/hoon)
665−[r=[src=/gen/help/hoon rul=[mod=%black who=[p={~nes} q={}]]] w=[src=/gen/help/hoon rul=[mod=%white who=[p={~nes} q={}]]]]
666−```
667−
668−Lastly, let's look at deleting a permission rule we've previously set. To do that, we just send a null `(unit rule)` in the `rite`.
669−
670−For example, to remove a read permission (or write if you specify `%w`):
671−
672−```
673−> |pass [%c [%perm %home /gen/help/hoon %r ~]]
674−```
675−
676−```
677−> .^([r=dict:clay w=dict:clay] %cp /===/gen/help/hoon)
678−[r=[src=/ rul=[mod=%white who=[p={} q={}]]] w=[src=/gen/help/hoon rul=[mod=%white who=[p={~nes} q={}]]]]
679−```
680−
681−...and to remove both read and write at the same time:
682−
683−```
684−> |pass [%c [%perm %home /gen/help/hoon %rw ~ ~]]
685−```
686−
687−```
688−> .^([r=dict:clay w=dict:clay] %cp /===/gen/help/hoon)
689−[r=[src=/ rul=[mod=%white who=[p={} q={}]]] w=[src=/ rul=[mod=%white who=[p={} q={}]]]]
690−```
691−
692−As you can see it's back to the default inherited from `/`.
693−
694−Here's a breakdown of a `%perm` task:
695−
696−
697−
698−## `%cred`
699−
700−Here we'll look at creating a permission group by sending Clay a `%cred` `task`.
701−
702−Let's create a group called `'foo'` with a few ships:
703−
704−```
705−|pass [%c [%crew 'foo' (sy ~[~zod ~nec ~bud ~wes ~sev])]]
706−```
707−
708−We'll check it with the next kind of `task`: [%crew](#crew).
709−
710−## `%crew`
711−
712−Here we'll look at retrieving permission groups by sending Clay a `%crew` `task` and receiving a `%cruz` `gift` in response.
713−
714−Let's check, using the `send-task-take-gift.hoon` thread, for the permission group created in the [%cred](#cred) example:
715−
716−```
717−> -send-task-take-gift [%crew ~]
718−[%cruz cez={[p=~.foo q={~nec ~bud ~wes ~zod ~sev}]}]
719−```
720−
721−## `%crow`
722−
723−Here we'll look at retrieving a list of all files and directories in all `desk`s which have permissions set for a group by sending Clay a `%crow` `task` and receiving a `%croz` `gift` in response.
724−
725−First we'll set a couple of permissions for the `foo` group we created in the [%cred](#cred) section:
726−
727−```
728−> |pass [%c [%perm %home /gen/hood/hi/hoon %w ~ %white (sy [%.n 'foo']~)]]
729−> |pass [%c [%perm %home /ted %w ~ %white (sy [%.n 'foo']~)]]
730−```
731−
732−Notice we use a `%.n` in the `whom` to indicate a group rather than the `%.y` of a ship.
733−
734−Now we'll use the `send-task-take-gift.hoon` thread to try `%crow`:
735−
736−```
737−> -send-task-take-gift [%crow 'foo']
738−[ %croz
739− rus
740− { [ p=%home
741− q
742− [ r={}
743− w
744− { [p=/gen/hood/hi/hoon q=[mod=%white who={[%.n p=~.foo]}]]
745− [p=/ted q=[mod=%white who={[%.n p=~.foo]}]]
746− }
747− ]
748− ]
749− }
750−]
751−```
752−
753−# Foreign Ships
754−
755−See the [Foreign Ships](@/docs/arvo/clay/tasks.md#foreign-ships) section of the [API Reference](@/docs/arvo/clay/tasks.md) document for general details.
756−
757−## `%warp` - Remote
758−
759−Here we'll look at reading files on a foreign ship by sending Clay a `%warp` `task` with a foreign ship in the `wer` field and receiving a `%writ` `gift` in response.
760−
761−We'll use a fake ~nes as the the foreign ship and a fake ~zod as the local ship.
762−
763−First we'll set permissions on the foreign ship. Create a file called `foo.txt` in the `%home` of ~nes, then send a `%perm` request to allow ~zod to read and write the file:
764−
765−```
766−> |pass [%c [%perm %home /foo/txt %rw `[%white (sy [%.y ~zod]~)] `[%white (sy [%.y ~zod]~)]]]
767−```
768−
769−If we scry the file for its permissions with a `%p` `care`, we'll see ~zod is now whitelisted:
770−
771−```
772−> .^([r=dict:clay w=dict:clay] %cp /===/foo/txt)
773−[r=[src=/foo/txt rul=[mod=%white who=[p={~zod} q={}]]] w=[src=/foo/txt rul=[mod=%white who=[p={~zod} q={}]]]]
774−```
775−
776−Back on ~zod: Using the `send-task-take-gift.hoon` thread, send a `%x` read request for `/foo/txt` on ~nes like:
777−
778−```
779−> -send-task-take-gift [%warp ~nes %home ~ %sing %x da+now /foo/txt]
780−[ %writ
781− p
782− [ ~
783− [ p=[p=%x q=[%da p=~2021.5.3..08.24.22..9ce7] r=%home]
784− q=/foo/txt
785− r=[p=%txt q=[#t/txt=*'' q=[7.303.014 0]]]
786− ]
787− ]
788−]
789−```
790−
791−As you can see, we've received a `%writ` containing the requested data just as we would with a local request. Let's try a `%u`:
792−
793−```
794−> -send-task-take-gift [%warp ~nes %home ~ %sing %u da+now /foo/txt]
795−[ %writ
796− p
797− [ ~
798− [ p=[p=%u q=[%da p=~2021.5.3..08.26.32..88cf] r=%home]
799− q=/foo/txt
800− r=[p=%flag q=[#t/?(%.y %.n) q=0]]
801− ]
802− ]
803−]
804−```
805−
806−If we send a `%d` request however, it will crash:
807−
808−```
809−> -send-task-take-gift [%warp ~nes %home ~ %sing %d da+now /foo/txt]
810−call: failed
811−/sys/vane/clay/hoon:<[4.085 3].[4.314 5]>
812−...
813−/sys/vane/clay/hoon:<[1.365 7].[1.365 51]>
814−[ %clay-bad-foreign-request-care
815− [%sing mood=[care=%d case=[%da p=~2021.5.3..20.04.57..1092] path=/foo/txt]]
816−]
817−/sys/vane/clay/hoon:<[1.365 48].[1.365 50]>
818−```
819−
820−## `%merg` - Remote
821−
822−To merge a foreign `desk` into a local one, you just send Clay a `%merg` `task` (as you would for a local merge) and specify the foreign ship in the `her` field. For an example, see the [%merg](#merg) section.
823−
824−The foreign ship will respond only if correct permissions have been set. See the [%perm](#perm) section for an example.
arvo/clay/scry.mddeleted−425
@@ -1,425 +0,0 @@
1−+++
2−title = "Scry Reference"
3−weight = 5
4−template = "doc.html"
5−+++
6−
7−The various Clay scries are specified by a `care`, which is a single character corresponding with a Clay submodule. Apart from `%s` they just take a `path` to a `desk`, file or directory. All examples are dojo commands, the ='s in the path are automatically populated by the dojo like:
8−
9−```
10−> /===
11−[~.~zod ~.home ~.~2021.4.26..02.29.03..d31b ~]
12−```
13−
14−## Contents
15−
16−- [%a](#a) - Build a `hoon` file.
17−- [%b](#b) - Dynamic `mark`.
18−- [%c](#c) - Dynamic `mark` conversion.
19−- [%d](#d) - List `desk`s.
20−- [%e](#e) - Static `mark`.
21−- [%f](#f) - Static `mark` conversion.
22−- [%p](#p) - File permissions.
23−- [%r](#r) - Vase-wrapped file data.
24−- [%s](#s) - Miscellaneous scries:
25− - [%yaki](#yaki) - `yaki:clay` of the specified commit.
26− - [%blob](#blob) - `blob:clay` of file.
27− - [%hash](#hash) - Content hash of the specified commit.
28− - [%cage](#cage) - `cage` of the data of a file.
29− - [%open](#open) - Compile prelude of file.
30− - [%late](#late) - Most recent `case` of `desk`.
31− - [%base](#base) - Mergebase of two `desk`s.
32−- [%t](#t) - List files in directory.
33−- [%u](#u) - Check for existence of file.
34−- [%v](#v) - Desk state.
35−- [%w](#w) - Revision number of the given `desk` `case`.
36−- [%x](#x) - Raw data of file.
37−- [%y](#y) - `arch` of a file or directory.
38−- [%z](#z) - Content hash of a file or directory.
39−
40−## %a
41−
42−A scry with a `care` of `%a` will build a `hoon` file and return it as a `vase`.
43−
44−Example:
45−
46−```
47−.^(vase %ca /===/lib/strandio/hoon)
48−```
49−
50−## %b
51−
52−A scry with a `care` of `%b` will produce a `dais:clay` processed `mark` core for the specified `mark`. The `path` in the scry is a `mark`.
53−
54−Example:
55−
56−```
57−.^(dais:clay %cb /===/txt)
58−```
59−
60−## %c
61−
62−A scry with a `care` of `%c` will produce a `tube:clay` dynamically typed `mark` conversion gate. The `path` specifies two `mark`s - *from* and *to*, like `/txt/noun`.
63−
64−Example:
65−
66−```
67−> =a .^(tube:clay %cc /===/txt/mime)
68−> !< mime (a !>(~['foo']))
69−[p=/text/plain q=[p=3 q=7.303.014]]
70−```
71−
72−## %d
73−
74−A scry with a `care` of `%d` will return a `(set desk)` of the `desk`s that exist on your ship.
75−
76−Example:
77−
78−```
79−> .^((set desk) %cd /===)
80−{%home %kids}
81−```
82−
83−## %e
84−
85−A scry with a `care` of `%e` will return a statically typed `nave:clay` `mark` core in a `vase`. The `path` in the scry specifies the `mark`.
86−
87−Example:
88−
89−```
90−.^(vase %ce /===/noun)
91−```
92−
93−## %f
94−
95−A scry with a `care` of `%f` will return a static `mark` conversion gate. The `path` specifies two `mark`s - *from* and *to*, like `/txt/mime`.
96−
97−```
98−> =a .^($-(text mime) %cf /===/txt/mime)
99−> (a ~['foo'])
100−[p=/text/plain q=[p=3 q=7.303.014]]
101−```
102−
103−## %p
104−
105−A scry with a `care` of `%p` will return the permissions of the file or directory in question. The type returned is a `[dict:clay dict:clay]` where the head is read permissions and the tail is write permissions.
106−
107−If the specified file or directory has no permissions set, it will default to the permissions of its parent. If nothing above it has permissions set, it will default to empty whitelists. If the specified file or directory doesn't exist, it will also return the default empty whitelist.
108−
109−Example:
110−
111−```
112−> .^([dict:clay dict:clay] %cp /===/gen)
113−[[src=/ rul=[mod=%white who=[p={} q={}]]] src=/ rul=[mod=%white who=[p={} q={}]]]
114−```
115−
116−## %r
117−
118−A scry with a `care` of `%r` will return the data of the given file wrapped in a `vase` or crash if it's a directory. It's basically just a vase-wrapped `%x` scry.
119−
120−Examples:
121−
122−```
123−> .^(vase %cr /===/gen/hood/hi/hoon)
124−[ #t/@
125− q
126− 3.548.750.706.400.251.607.252.023.288.575.526.190.856.734.474.077.821.289.791.377.301.707.878.697.553.411.219.689.905.949.957.893.633.811.025.757.107.990.477.902.858.170.125.439.223.250.551.937.540.468.638.902.955.378.837.954.792.031.592.462.617.422.136.386.332.469.076.584.061.249.923.938.374.214.925.312.954.606.277.212.923.859.309.330.556.730.410.200.952.056.760.727.611.447.500.996.168.035.027.753.417.869.213.425.113.257.514.474.700.810.203.348.784.547.006.707.150.406.298.809.062.567.217.447.347.357.039.994.339.342.906
127−]
128−```
129−
130−```
131−> !< @t .^(vase %cr /===/gen/hood/hi/hoon)
132−':: Helm: send message to an urbit\0a::\0a:::: /hoon/hi/hood/gen\0a ::\0a/? 310\0a:- %say\0a|=([^ [who=ship mez=$@(~ [a=tape ~])] ~] helm-send-hi+[who ?~(mez ~ `a.mez)])\0a'
133−```
134−
135−```
136−> .^(vase %cr /===/gen)
137−Crash!
138−```
139−
140−## %s
141−
142−A scry with a `care` of `%s` is for miscellaneous internal and debug functions and is liable to change in the future.
143−
144−Rather than just a `path` to a file, the head of the `path` is tagged with one of `%yaki %blob %hash %cage %open %late %base` and the tail depends on which tag you use. We'll look at each in turn.
145−
146−### %yaki
147−
148−This will return the [yaki:clay](@/docs/arvo/clay/data-types.md#yaki-clay-commit) of the specified commit. It takes a [tako:clay](@/docs/arvo/clay/data-types.md#tako-clay-commit-reference).
149−
150−Example:
151−
152−Here we scry the [dome:clay](@/docs/arvo/clay/data-types.md#dome-desk-data) for `/===`, get the latest `tako:clay` and the do a `%s` scry for the `yaki:clay` in question.
153−
154−```
155−> =/ =dome:clay .^(dome:clay %cv /===)
156− =/ =tako:clay (~(got by hit.dome) let.dome)
157− .^(yaki:clay %cs /===/yaki/(scot %uv tako))
158−[ p=~[80.174.473.756.485.530.520.259.753.935.584.637.641.665.425.899.348.092.348.244.635.557.986.495.151.006]
159− q
160− { [p=/mar/hark/graph-hook-update/hoon q=0v5.ea0bj.21s5c.mjrop.ishic.fpkvl.e5bbs.91kc9.tdo41.ifi06.60v41]
161− [p=/gen/hood/autocommit/hoon q=0v19.rh7jv.sa67o.t3jrb.4sdvs.7c45f.pv2u0.ragik.psp20.agqd8.8srkj]
162− ...
163− [p=/tests/lib/primitive-rsa/hoon q=0v1g.3qmq3.6i15q.arh6h.lfsqu.gvc9m.ql6m5.e2rdr.vnnt9.tptc6.mv9u7]
164− [p=/tests/sys/vane/gall/hoon q=0va.alspc.qptqn.7tuj0.bgecg.1093t.gtsjs.up03k.d1fmk.4jrh8.2tdfa]
165− }
166− r=88.666.797.531.755.181.802.690.473.856.185.443.710.929.766.582.249.039.904.824.278.074.149.777.897.099
167− t=~2021.4.16..10.41.57..3565
168−]
169−```
170−
171−### %blob
172−
173−This will return the [blob:clay](@/docs/arvo/clay/data-types.md#blob-clay-data) of some file. It takes a [lobe:clay](@/docs/arvo/clay/data-types.md#lobe-clay-data-reference).
174−
175−Example:
176−
177−Here we grab the `lobe:clay` of `/gen/hood/hi/hoon` with a `%y` scry, then use it to do a `%s` scry for the `blob:clay` of the file.
178−
179−```
180−> =/ =arch .^(arch %cy /===/gen/hood/hi/hoon)
181− ?~ fil.arch
182− ~
183− .^(blob:clay %cs /===/blob/(scot %uv u.fil.arch))
184−[ %direct
185− p=0vp.k7nsm.qkdr3.t17rp.33bae.8gajg.v27gi.40itr.2u9qa.nppbt.7k255
186− q
187− [ p=%hoon
188− q
189−3.548.750.706.400.251.607.252.023.288.575.526.190.856.734.474.077.821.289.791.377.301.707.878.697.553.411.219.689.905.949.957.893.633.811.025.757.107.990.477.902.858.170.125.439.223.250.551.937.540.468.638.902.955.378.837.954.792.031.592.462.617.422.136.386.332.469.076.584.061.249.923.938.374.214.925.312.954.606.277.212.923.859.309.330.556.730.410.200.952.056.760.727.611.447.500.996.168.035.027.753.417.869.213.425.113.257.514.474.700.810.203.348.784.547.006.707.150.406.298.809.062.567.217.447.347.357.039.994.339.342.906
190− ]
191−]
192−```
193−
194−### %hash
195−
196−This will return the `@uvI` content hash of the specified commit. It takes a `tako:clay`.
197−
198−Example:
199−
200−Here we grab the `dome:clay` for `/===` with a `%v` scry, get the latest `tako:clay` and then do a `%s` `%hash` scry for it.
201−
202−```
203−> =/ =dome:clay .^(dome:clay %cv /===)
204− =/ =tako:clay (~(got by hit.dome) let.dome)
205− .^(tako:clay %cs /===/hash/(scot %uv tako))
206−0v16.er7uq.oke4u.cru7u.nglu9.q3su7.6ub1o.bh4qk.r5uav.ut12d.5rdl5
207−```
208−
209−### %cage
210−
211−This will return a `cage` of the data of some file. It takes a `lobe:clay`.
212−
213−Example:
214−
215−Here we grab the `lobe:clay` of `/gen/hood/hi/hoon` with a `%y` scry, then use it to do a `%s` scry for the `cage` of the data.
216−
217−```
218−> =/ =arch .^(arch %cy /===/gen/hood/hi/hoon)
219− ?~ fil.arch
220− ~
221− .^(cage %cs /===/cage/(scot %uv u.fil.arch))
222−[ p=%hoon
223− q
224− [ #t/@t
225− q
226−3.548.750.706.400.251.607.252.023.288.575.526.190.856.734.474.077.821.289.791.377.301.707.878.697.553.411.219.689.905.949.957.893.633.811.025.757.107.990.477.902.858.170.125.439.223.250.551.937.540.468.638.902.955.378.837.954.792.031.592.462.617.422.136.386.332.469.076.584.061.249.923.938.374.214.925.312.954.606.277.212.923.859.309.330.556.730.410.200.952.056.760.727.611.447.500.996.168.035.027.753.417.869.213.425.113.257.514.474.700.810.203.348.784.547.006.707.150.406.298.809.062.567.217.447.347.357.039.994.339.342.906
227− ]
228−]
229−```
230−
231−### %open
232−
233−This is like a `%a` scry but it only compiles the prelude to the file, e.g. the Ford rune imports. Proper documentation for this will be done as part of Ford documentaton at a later date.
234−
235−### %late
236−
237−This will return the most recent revision number of a `desk` that has been fully downloaded. The type it returns is a `cass:clay`. The `case` in the `beak` must be a revision number rather than a date. You can just provide a case of `1` since it returns the latest regardless. If we have nothing for the specified `desk`, this will just return the bunt of a `cass:clay` like `cass=[ud=0 da=~2000.1.1]`.
238−
239−Example:
240−
241−```
242−> .^(=cass:clay %cs /(scot %p (sein:title our now our))/kids/1/late)
243−cass=[ud=50 da=~2021.4.22..10.38.50..57a8]
244−```
245−
246−```
247−> .^(=cass:clay %cs /~sampel/kids/1/late)
248−cass=[ud=0 da=~2000.1.1]
249−```
250−
251−### %base
252−
253−This will return the mergebase (i.e. most recent common ancestor) between two `desk`s. The type it returns is a `(list tako:clay)`. The first `desk` will just be the one in the `beak` `path` prefix and the second will be specified like `/ship/desk` at the end of the scry `path`. If there is no common ancestor between the two `desk`s, this will just produce an empty `list`.
254−
255−Examples:
256−
257−```
258−> .^((list tako:clay) %cs /===/base/(scot %p (sein:title our now our))/kids)
259−~[102.787.244.596.033.419.950.995.540.301.493.841.569.518.772.322.508.085.465.561.801.703.148.627.263.473]
260−```
261−
262−```
263−> .^((list tako:clay) %cs /===/base/~sampel/kids)
264−~
265−```
266−
267−## %t
268−
269−A scry with a `care` of `%t` will return a `(list path)` of all files in the given directory, or just a `(list path)` of the single file if it's a file. This is done recursively so will provide files in subdirectories as well. The paths will be fully qualified except for the `ship`, `desk` and `case`. If the directory or file specified does not exist, it will return an empty `list`.
270−
271−Examples:
272−
273−```
274−> .^((list path) %ct /===/app/landscape)
275−~[
276− /app/landscape/css/index/css
277− /app/landscape/img/favicon/png
278− /app/landscape/img/imageupload/png
279− /app/landscape/img/touch_icon/png
280− /app/landscape/index/html
281− /app/landscape/js/channel/js
282−]
283−```
284−
285−```
286−> .^((list path) %ct /===/gen/group-store/add/hoon)
287−~[/gen/group-store/add/hoon]
288−```
289−
290−```
291−> .^((list path) %ct /===/foobar)
292−~
293−```
294−
295−## %u
296−
297−A scry with a `care` of `%u` will return a `?` depending on whether the file exists. It will produce `%.n` if it's a directory or doesn't exist and will produce `%.y` if it's a file and exists.
298−
299−Examples:
300−
301−```
302−> .^(? %cu /===/app)
303−%.n
304−```
305−
306−```
307−> .^(? %cu /===/gen/code/hoon)
308−%.y
309−```
310−
311−```
312−> .^(? %cu /===/foobar)
313−%.n
314−```
315−
316−## %v
317−
318−A scry with a care of `%v` will return the entire state of a `desk` as a `dome:clay`.
319−
320−Example:
321−
322−```
323−> =a .^(dome:clay %cv /===)
324−> let.a
325−1
326−```
327−
328−Note: If you try printing this it will take forever and probably OOM your ship.
329−
330−## %w
331−
332−A scry with a `care` of `%w` will return the revision number and date of a given `case`. The type returned is a `cass:clay` like `[ud=@ud da=@da]` where `ud` is the revision number and `da` is the date.
333−
334−Example:
335−
336−```
337−> .^(cass:clay %cw /===)
338−[ud=2 da=~2021.4.13..19.12.49..3389]
339−```
340−
341−## %x
342−
343−A scry with a `care` of `%x` will return the raw data of a file as an `@` or crash if it's a directory.
344−
345−
346−Examples:
347−
348−```
349−> .^(@ %cx /===/gen/hood/hi/hoon)
350−3.548.750.706.400.251.607.252.023.288.575.526.190.856.734.474.077.821.289.791.377.301.707.878.697.553.411.219.689.905.949.957.893.633.811.025.757.107.990.477.902.858.170.125.439.223.250.551.937.540.468.638.902.955.378.837.954.792.031.592.462.617.422.136.386.332.469.076.584.061.249.923.938.374.214.925.312.954.606.277.212.923.859.309.330.556.730.410.200.952.056.760.727.611.447.500.996.168.035.027.753.417.869.213.425.113.257.514.474.700.810.203.348.784.547.006.707.150.406.298.809.062.567.217.447.347.357.039.994.339.342.906
351−```
352−
353−```
354−> .^(@t %cx /===/gen/hood/hi/hoon)
355−':: Helm: send message to an urbit\0a::\0a:::: /hoon/hi/hood/gen\0a ::\0a/? 310\0a:- %say\0a|=([^ [who=ship mez=$@(~ [a=tape ~])] ~] helm-send-hi+[who ?~(mez ~ `a.mez)])\0a'
356−```
357−
358−```
359−> .^(@ %cx /===/gen/hood)
360−Crash!
361−```
362−
363−## %y
364−
365−A scry with a `care` of `%y` will return the `arch` of a file or directory.
366−
367−An `arch` is a `[fil=(unit lobe:clay) dir=(map @ta ~)]`. The `fil` will contain the `lobe:clay` hash if it's a file, otherwise it will be null. The `dir` will contain a map of the files and directories it contains, otherwise it will be null.
368−
369−It will return the bunt of an `arch` if the file or directory is not found.
370−
371−Examples:
372−
373−```
374−> .^(arch %cy /===/gen/group-store)
375−[ fil=~
376− dir
377− { [p=~.allow-ships q=~]
378− [p=~.add q=~]
379− [p=~.ban-ranks q=~]
380− [p=~.remove q=~]
381− [p=~.create q=~]
382− [p=~.join q=~]
383− [p=~.allow-ranks q=~]
384− [p=~.ban-ships q=~]
385− }
386−]
387−```
388−
389−```
390−> .^(arch %cy /===/gen/group-store/allow-ships)
391−[fil=~ dir={[p=~.hoon q=~]}]
392−```
393−
394−```
395−> .^(arch %cy /===/gen/group-store/allow-ships/hoon)
396−[fil=[~ 0vb.g8sqs.7gjm9.bl3vu.nk677.h5be1.g9eg3.4v1jo.00ivf.g8ndu.48a53] dir={}]
397−```
398−
399−```
400−> .^(arch %cy /===/foobar)
401−[fil=~ dir={}]
402−```
403−
404−## %z
405−
406−A scry with a `care` of `%z` will return the hash of a file or the recursive hash of a directory. If the file or directory doesn't exist it will return a null value.
407−
408−The type returned is a `@uxI`.
409−
410−Examples:
411−
412−```
413−> .^(@uvI %cz /===/gen)
414−0v5.itmhj.lt7ak.lgr1k.dr7vu.u7u9s.ko5rf.idfcr.ukrd2.t088n.3ml1k
415−```
416−
417−```
418−> .^(@uvI %cz /===/gen/code/hoon)
419−0v1t.vi1pf.3ba4n.87g6h.dcc1p.4t4l8.rm6a9.b4de4.v77qc.p9dc0.p8289
420−```
421−
422−```
423−> .^(@uvI %cz /===/foobar)
424−0v0
425−```
arvo/clay/tasks.mddeleted−555
@@ -1,555 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 6
4−template = "doc.html"
5−+++
6−
7−# Contents
8−
9−- [Introduction](#introduction)
10−- [%warp](#warp) - Read and Subscribe.
11− - [%sing](#sing) - Read a file or directory.
12− - [%next](#next) - Subscribe for the next change to a file or directory.
13− - [%mult](#mult) - Subscribe for the next change to a set of files and/or directories.
14− - [%many](#many) - Track changes to a `desk` for the specified range of revisions.
15− - [Cancel Subscription](#cancel-subscription)
16−- [Write and Modify](#write-and-modify)
17− - [%info](#info)
18−- [Manage Mounts](#manage-mounts)
19− - [%boat](#boat) - List mounts.
20− - [%mont](#mont) - Mount something.
21− - [%ogre](#ogre) - Unmount something.
22− - [%dirk](#dirk) - Commit changes.
23−- [Merge Desks](#merge-desks)
24− - [%merg](#merg)
25−- [Permissions](#permissions)
26− - [%perm](#perm) - Set file permissions.
27− - [%cred](#cred) - Add permission group.
28− - [%crew](#crew) - Get permission groups.
29− - [%crow](#crow) - Get group usage.
30−- [Foreign Ships](#foreign-ships)
31− - [%warp](#warp-remote) - Read a file on a foreign ship.
32− - [%merg](#merg-remote) - Merge from a foreign `desk`.
33−
34−# Introduction
35−
36−This document details all the `task`s you're likely to use to interact with Clay, as well as the `gift`s you'll receive in response. Each section has a corresponding practical example in the [Examples](@/docs/arvo/clay/examples.md) document. Many of the types referenced are detailed in the [Data Types](@/docs/arvo/clay/data-types.md) document. It may also be useful to look at the `++ clay` section of `/sys/lull.hoon` in Arvo where these `task`s, `gift`s and data structures are defined.
37−
38−The focus of this document is on interacting with Clay from userspace applications and threads, so it doesn't delve into the internal mechanics of Clay from a kernel development perspective.
39−
40−# `%warp`
41−
42−A `%warp` `task` is for reading a subscribing to files and directories.
43−
44−### Accepts
45−
46−```hoon
47−[wer=ship rif=riff]
48−```
49−
50−The `wer` field is the target ship. The `(unit rave)` of the [riff](@/docs/arvo/clay/data-types.md#riff-clay-request-desist) is null to cancel an existing subscription, otherwise the [rave](@/docs/arvo/clay/data-types.md#rave-clay-general-subscription-request) is tagged with one of:
51−
52−- `%sing` - Read a single file or directory.
53−- `%next` - Subscribe for the next change to a file or directory.
54−- `%mult` - Subscribe for the next change to a set of files and/or directories.
55−- `%many` - Track changes to a desk for the specified range of revisions.
56−
57−We'll look at each of these in more detail below.
58−
59−### Returns
60−
61−Clay responds to a `%mult` request with a `%wris` `gift`, and the rest with a `%writ` `gift`.
62−
63−A `%wris` `gift` looks like:
64−
65−```hoon
66−[%wris p=[%da p=@da] q=(set (pair care path))] :: many changes
67−```
68−
69−...and a `%writ` `gift` looks like:
70−
71−```hoon
72−[%writ p=riot] :: response
73−```
74−
75−The `unit` of the [riot](@/docs/arvo/clay/data-types.md#riot-clay-response) will be null if the target file cannot be found or if a subscription has ended (depending on context). Otherwise it will have a [rant](@/docs/arvo/clay/data-types.md#rant-clay-response-data) with a `cage` containing the data you requested. Its contents will vary depending on the kind of request and `care`.
76−
77−Now we'll look at each of the `rave` request types in turn.
78−
79−## `%sing`
80−
81−```hoon
82−[%sing =mood]
83−```
84−
85−This `rave` is for reading a single file or directory immediately.
86−
87−The `care` of the [mood](@/docs/arvo/clay/data-types.md#mood-clay-single-subscription-request) will determine what you can read and what type of data will be returned. See the [care](@/docs/arvo/clay/data-types.md#care-clay-clay-submode) documentation and [scry](@/docs/arvo/clay/scry.md) documentation for details on the various `care`s.
88−
89−The [case](@/docs/arvo/clay/data-types.md#case-specifying-a-commit) specifies the `desk` revision and you can use whichever kind you prefer. The `path` will usually be a path to a file or directory like `/gen/hood/hi/hoon` but may be something else depending on the `care`.
90−
91−### Example
92−
93−[See here for an example of using %sing.](@/docs/arvo/clay/examples.md#sing)
94−
95−## `%next`
96−
97−```hoon
98−[%next =mood] :: await next version
99−```
100−
101−This subscribes to the next version of the specified file. See [here](@/docs/arvo/clay/data-types.md#mood-clay-single-subscription-request) for details of the `mood` structure.
102−
103−If you subscribe to the current `case` of the `desk`, Clay will not respond until the file changes. If you subscribe to a previous `case` of the `desk` and the file has changed in between then and now, it will immediately return the first change it comes across in that range. For example, if you're currently at `case` `100`, subscribe to case `50` and the file in question has been modified at both `60` and `80`, clay will immediately return the version of the file at `case` `60`.
104−
105−### Example
106−
107−[See here for an example of using %next.](@/docs/arvo/clay/examples.md#next)
108−
109−## `%mult`
110−
111−```hoon
112−[%mult =mool] :: next version of any
113−```
114−
115−This subscribes to the next version of a `set` of files or directories. Clay will only send a single response, and it will send it when *any* of the specified files change. For example, if you subscribe to both `/foo/txt` and `/bar/txt`, and only `/foo/txt` changes, Clay will send a response indicating a change to `/foo/txt`. If `/bar/txt` changes subsequently, it will not tell you. If more than one file changes at once, it will tell you about each of the changes in the one response.
116−
117−The behaviour with respect to requesting old `case`s is the same as explained in the [`%next`](#next) section above.
118−
119−The `mool` specified in the request is this structure:
120−
121−```hoon
122−+$ mool [=case paths=(set (pair care path))] :: requests in desk
123−```
124−
125−You can use a different `care` for each of the files specified by the `path` if you like. Significantly, the `care` will determine whether Clay sends a response for a given change. For example, if you subscribe to an existing `/foo/txt` with a `%u` `care` and `/foo/txt` is modified but isn't deleted, Clay will *not* tell you. However, if you subscribe with an `%x` `care`, it *will* tell you.
126−
127−### Example
128−
129−[See here for an example of using %mult.](@/docs/arvo/clay/examples.md#mult)
130−
131−## `%many`
132−
133−```hoon
134−[%many track=? =moat] :: track range
135−```
136−
137−This subscribes to all changes to a `desk` for the specified range of `case`s. Note that you're unlikely to use this directly, it's mostly used implicitly if you make a `%sing` or `%next` request with a `%v` `care` to a foreign `desk`. Regardless, we'll have a look at it for completeness.
138−
139−If the `track` is `%.y` it will just return a `%writ` like:
140−
141−```hoon
142−[%writ p=[~ [p=[p=%w q=[%ud p=256] r=%home] q=/ r=[p=%null q=[#t/@n q=0]]]]]
143−```
144−
145−...that merely informs you of a change. If you want the actual data you'll have to request it separately.
146−
147−If the `track` is `%.n`, the `cage` of the `%writ` will contain a [nako](@/docs/arvo/clay/data-types.md#nako-subscription-response-data) with the relevant data for all changes to a desk between what you have and the `case` requested. It is very large and fairly complicated. The `nako` structure is defined in the `clay.hoon` source file itself rather than in `lull.hoon` or elsewhere since you're unlikely to work with it yourself.
148−
149−The `from` and `to` fields of the [moat](@/docs/arvo/clay/data-types.md#moat-clay-range-subscription-request) specify the range of `case`s for which to subscribe. The range is *inclusive*. It can be specified by date or by revision number, whichever you prefer.
150−
151−The `path` in the `moat` is a path to a file or directory. If it's `~` it refers to the root of the `desk` in question. This lets you say "only inform me of changes to the `desk` if the specified file or directory exists". If it doesn't exist, Clay will not send you anything.
152−
153−When you reach the end of the subscribed range of `case`s, Clay will send you a `%writ` with a null `riot` to inform you the subscription has ended like:
154−
155−```hoon
156−[%writ p=~]
157−```
158−
159−### Example
160−
161−[See here for an example of using %many.](@/docs/arvo/clay/examples.md#many)
162−
163−## Cancel Subscription
164−
165−To cancel a subscription, you just send a `%warp` with a null `(unit rave)` in the `riff`. Clay will cancel the subscription based on the `wire`. The request is exactly the same regardless of which type of `rave` you subscribed with originally.
166−
167−### Example
168−
169−[See here for an example of cancelling a subscription.](@/docs/arvo/clay/examples.md#cancel-subscription)
170−
171−# Write and Modify
172−
173−## `%info`
174−
175−To write or modify a file, we send Clay a `%info` `task`.
176−
177−### Accepts
178−
179−```hoon
180−[des=desk dit=nori]
181−```
182−
183−The `%|` tag in the [nori](@/docs/arvo/clay/data-types.md#nori-clay-repository-action) is not currently supported and will crash with a `%labelling-not-implemented` if used, so you can focus on the `%&` part. The [soba](@/docs/arvo/clay/data-types.md#soba-clay-delta) in the `nori` is just a list of changes so you can make more than one change in one request. Its `path` is just the path to a file like `/gen/hood/hi/hoon` and the [miso](@/docs/arvo/clay/data-types.md#miso-clay-ankh-delta) is one of these types of requests:
184−
185−- `%del` - Delete a file.
186−- `%ins` - Insert file. This will also replace an existing file.
187−- `%dif` - This has not yet been implemented so will crash with a `%dif-not-implemented` error.
188−- `%mut` - Change a file. At the time of writing this behaves identically to `%ins` so its use merely informs the reader.
189−
190−### Returns
191−
192−Clay does not give any response to an `%info` `task` so don't expect a `sign` back.
193−
194−### Example
195−
196−Here are examples of using each of these as well as making multiple changes in one request:
197−
198−- [%del](@/docs/arvo/clay/examples.md#del)
199−- [%ins](@/docs/arvo/clay/examples.md#ins)
200−- [%mut](@/docs/arvo/clay/examples.md#mut)
201−- [Multiple Changes](@/docs/arvo/clay/examples.md#multiple-changes)
202−
203−
204−# Manage Mounts
205−
206−Here we'll look at managing Clay unix mounts programmatically.
207−
208−There are four Clay `task`s relevant to mounts:
209−
210−- [%boat](#boat) - List mounts.
211−- [%mont](#mont) - Mount something.
212−- [%ogre](#ogre) - Unmount something.
213−- [%dirk](#dirk) - Commit changes.
214−
215−## `%boat`
216−
217−A `%boat` `task` requests the list of existing mounts.
218−
219−### Accepts
220−
221−```hoon
222−~
223−```
224−
225−A `%boat` `task` does not take any arguments.
226−
227−### Returns
228−
229−The type it returns is a `%hill` `gift`, which looks like:
230−
231−```hoon
232−[%hill p=(list @tas)]
233−```
234−
235−...where the `@tas` is the name of the mount point.
236−
237−### Example
238−
239−[See here for an example of using %boat.](@/docs/arvo/clay/examples.md#boat)
240−
241−## `%mont`
242−
243−
244−A `%mont` `task` mounts the specified `beam` to the specified `term` mount point.
245−
246−### Accepts
247−
248−```hoon
249−[pot=term bem=beam]
250−```
251−
252−A `beam:clay` is the following structure:
253−
254−```hoon
255−+$ beam [[p=ship q=desk r=case] s=path] :: global name
256−```
257−
258−You can mount the whole desk with a `path` of `/`, and you can also mount subdirectories or even individual files. If you want to mount an individual file, you must exclude its `mark` from the path. For example, if you want to mount `/gen/hood/hi/hoon`, you'd specify `/gen/hood/hi`. It will automatically be given the correct file extension when mounted. If you include the `hoon` mark it will crash (and currently crash your ship).
259−
260−### Returns
261−
262−Clay does not return a `gift` in response to a `%mont` `%task`.
263−
264−### Example
265−
266−[See here for an example of using %mont.](@/docs/arvo/clay/examples.md#mont)
267−
268−## `%ogre`
269−
270−A `%ogre` `task` unmounts the specified mount.
271−
272−### Accepts
273−
274−```hoon
275−[pot=$@(desk beam)]
276−```
277−
278−It's defined in `lull.hoon` as taking `$@(desk beam)` but in fact it will only unmount the target when specified as a `term` mount name. Passing it a `desk` will incidentally work if the mount is named the same as the `desk` but otherwise it won't work. Passing it a `beam:clay` will simply not work.
279−
280−### Returns
281−
282−Clay does not return a `gift` in response to a `%ogre` `task`.
283−
284−### Example
285−
286−[See here for an example of using %ogre.](@/docs/arvo/clay/examples.md#ogre)
287−
288−## `%dirk`
289−
290−A `%dirk` `task` commits changes in the target mount.
291−
292−### Accepts
293−
294−```hoon
295−des=desk
296−```
297−
298−It's defined in `lull.hoon` as taking a `desk` but like [%ogre](#ogre), it actually takes the name of a mount point rather than a `desk` as is specified.
299−
300−### Returns
301−
302−Clay does not return a `gift` in response to a `%dirk` `task`.
303−
304−### Example
305−
306−[See here for an example of using %dirk.](@/docs/arvo/clay/examples.md#dirk)
307−
308−# Merge Desks
309−
310−## `%merg`
311−
312−A `%merg` `task` will merge the specified source `desk` into the target local `desk`.
313−
314−### Accepts
315−
316−```hoon
317−$: des=desk :: target
318− her=@p dem=desk cas=case :: source
319− how=germ :: method
320−==
321−```
322−The `germ` specifies the merge strategy. You can refer to the [Strategies](@/docs/arvo/clay/using.md#strategies) section of the [Using Clay](@/docs/arvo/clay/using.md) document for details of each `germ`.
323−
324−If you're merging into a new `desk` you must use `%init`, all other strategies will fail. If the desk already exists, you cannot use `%init`. Otherwise, you're free to use whichever you'd like.
325−
326−### Returns
327−
328−Clay will respond to the request with a `%mere` `gift` which looks like:
329−
330−```hoon
331−[%mere p=(each (set path) (pair term tang))] :: merge result
332−```
333−
334−If the merge succeeded, `p` will look like `[%mere p=[%.y p={}]]` where `p.p` is the set of files which had a merge conflict. For example, `[%mere p=[%.y p={/foo/txt}]]` means there was a conflict with `/foo/txt`. An empty set means there were no conflicts.
335−
336−If the merge failed, `p` will have a head of `%.n` and then a `[term tang]` where the `term` is an error message and the `tang` contains additional details, for example:
337−
338−```hoon
339−[ %mere
340− p
341− [ %.n
342− p=[p=%mate-conflict q=~[[%rose p=[p="/" q="/" r=""] q=~[[%leaf p="foo"] [%leaf p="txt"]]]]]
343− ]
344−]
345−```
346−
347−### Example
348−
349−[See here for an example of using %merg.](@/docs/arvo/clay/examples.md#merg)
350−
351−# Permissions
352−
353−For each file or directory, there is both a read permission and a write permission. Each may be set separately and is either a whitelist or a blacklist (but not both). The whitelist/blacklist contains a `set` of ships and/or groups which are allowed or banned respectively. If it's an empty whitelist it means all foreign ships are denied. If it's an empty blacklist it means all foreign ships are allowed.
354−
355−If permissions are not set for a particular file, they will be inherited from the directory in which it resides. If *that* directory has no permissions set, they will be inherited from another level up, and so on to the `desk`'s root directory. If the root directory has no permissions set, it will have the default permissions of an empty whitelist, meaning "deny all".
356−
357−A group is called a `crew` and is just a `set` of ships with a `@ta` name.
358−
359−The permissions for each file or directory are a pair of `dict:clay` where the head is read permissions and the tail is write permissions.
360−
361−A `dict:clay` is this structure:
362−
363−```hoon
364−+$ dict [src=path rul=real] :: effective permission
365−```
366−
367−The `src` path is where the permissions were inherited from and the `real` is this structure:
368−
369−```hoon
370− +$ real :: resolved permissions
371− $: mod=?(%black %white) ::
372− who=(pair (set ship) (map @ta crew)) ::
373− == ::
374−```
375−
376−So if we scry for permissions with a `%p` `care`, it'll look like:
377−
378−```hoon
379−> .^([r=dict:clay w=dict:clay] %cp /===/lib/strandio/hoon)
380−[r=[src=/ rul=[mod=%white who=[p={} q={}]]] w=[src=/ rul=[mod=%white who=[p={} q={}]]]]
381−```
382−
383−There are four permission-related `task`s which you can pass to Clay.
384−
385−A `%perm` `task` is for setting permissions, and the other three are for managing groups:
386−
387−- `%cred` - Add permission group.
388−- `%crew` - Get permission groups.
389−- `%crow` - Get group usage.
390−
391−We'll look at each of these in turn.
392−
393−## `%perm`
394−
395−A `%perm` `task` sets permissions for the target file or directory.
396−
397−Note this will replace existing permissions rather than add to them, so if you want to add a ship to an existing whitelist or whatever you'll have to first read the existing permissions, add the ship, then send the whole lot back.
398−
399−### Accepts
400−
401−```hoon
402−[des=desk pax=path rit=rite]
403−```
404−
405−The `pax` path is the file or directory whose permissions you want to change, and the `rite` is this structure:
406−
407−```hoon
408−+$ rite :: new permissions
409− $% [%r red=(unit rule)] :: for read
410− [%w wit=(unit rule)] :: for write
411− [%rw red=(unit rule) wit=(unit rule)] :: for read and write
412−```
413−
414−Where a `rule` is this structure:
415−
416−```hoon
417−+$ rule [mod=?(%black %white) who=(set whom)] :: node permission
418−```
419−
420−...and finally `whom` is this:
421−
422−```hoon
423−+$ whom (each ship @ta) :: ship or named crew
424−```
425−
426−As the comment suggests, the `@ta` is the name of a `crew` (group).
427−
428−### Returns
429−
430−Clay does not return a `gift` in response to a `%perm` `task`.
431−
432−### Example
433−
434−[See here for an example of using %perm.](@/docs/arvo/clay/examples.md#perm)
435−
436−## `%cred`
437−
438−This simply creates a permission group.
439−
440−### Accepts
441−
442−```hoon
443−[nom=@ta cew=crew]
444−```
445−
446−The `nom` is a name for the group and the `crew` is just a `(set ship)`:
447−
448−```hoon
449−+$ crew (set ship) :: permissions group
450−```
451−
452−### Returns
453−
454−Clay does not return a `gift` in response to a `%cred` `task`.
455−
456−### Example
457−
458−[See here for an example of using %cred.](@/docs/arvo/clay/examples.md#cred)
459−
460−## `%crew`
461−
462−This retrieves all permission groups.
463−
464−### Accepts
465−
466−```hoon
467−~
468−```
469−
470−A `%crew` `task` takes no arguments.
471−
472−### Returns
473−
474−Clay wil return a `%cruz` `gift`. It looks like:
475−
476−```hoon
477−[%cruz cez=(map @ta crew)] :: permission groups
478−```
479−
480−The `cez` is just a map from group name to `crew` which is just a `(set ship)`.
481−
482−### Example
483−
484−[See here for an example of using %crew.](@/docs/arvo/clay/examples.md#crew)
485−
486−## `%crow`
487−
488−A `%crow` `task` retrieves all files and directories in all `desk`s which have permissions set for the group in question. It will not return inherited permissions, only those explicitly set.
489−
490−### Accepts
491−
492−```hoon
493−nom=@ta
494−```
495−
496−The `nom` is the name of a `crew`.
497−
498−### Returns
499−
500−The `gift` you get back is a `%croz` which looks like:
501−
502−```hoon
503−[%croz rus=(map desk [r=regs w=regs])] :: rules for group
504−```
505−
506−...where `regs` is this structure:
507−
508−```hoon
509−+$ regs (map path rule) :: rules for paths
510−```
511−
512−### Example
513−
514−[See here for an example of using %crow.](@/docs/arvo/clay/examples.md#crow)
515−
516−# Foreign Ships
517−
518−Here we'll looking at making Clay requests to a foreign ship.
519−
520−As it currently stands, it's not possible to write to a foreign `desk`. Additionally, remote scries are not implemented. That leaves requests to read files (`%warp`) and merge desks (`%merg`), which we'll look at next.
521−
522−## `%warp` - Remote
523−
524−To read files on a foreign `desk`, you just send Clay a `%warp` `task` (as you would for a local read) and specify the target ship in the `wer` field. For details on making such requests, see the [Read and Subscribe](#warp) section.
525−
526−Clay only allows a subset of `care`s to be used remotely. They are:
527−
528−- `%u` - Check for existence of file.
529−- `%v` - Get entire `dome:clay` state of a desk.
530−- `%w` - Get revision number.
531−- `%x` - Get data of file.
532−- `%y` - Get `arch` of file or directory.
533−- `%z` - Get content hash of file or directory.
534−
535−Any other `care` will crash with a `%clay-bad-foreign-request-care` error.
536−
537−The foreign ship will respond only if correct permissions have been set. See the [Permissions](#permissions) section for details.
538−
539−Note that if you're reading a whole `desk` or directory, all subfolders and files must also permit reading. If even a single file does not permit you reading it, the foreign ship will not respond to the request.
540−
541−### Example
542−
543−[See here for examples of requests to foreign ships.](@/docs/arvo/clay/examples.md#foreign-ships)
544−
545−## `%merg` - Remote
546−
547−To merge a foreign `desk` into a local one, you just send Clay a `%merg` `task` (as you would for a local merge) and specify the foreign ship in the `her` field. For details on making such requests, see the [Merge Desks](#merge-desks) section.
548−
549−The foreign ship will respond only if correct permissions have been set. See the [Permissions](#permissions) section for details. By default, a ship's `%kids` desk is set to be publicly readable, so unless permissions have been manually modified, you should be able to merge from any `%kids` `desk`.
550−
551−Note that all subfolders and individual files within the `desk` must permit your reading in order for the merge to succeed. If even one file does not permit you reading it, the remote ship will not respond to the request at all.
552−
553−### Example
554−
555−[See here for examples of requests to foreign ships.](@/docs/arvo/clay/examples.md#foreign-ships)
arvo/clay/using.mddeleted−217
@@ -1,217 +0,0 @@
1−+++
2−title = "Using Clay"
3−weight = 3
4−template = "doc.html"
5−+++
6−
7−### Reading and Subscribing
8−
9−When reading from Clay, there are three types of requests. A
10−`%sing` request asks for data at single revsion. A `%next`
11−request asks to be notified the next time there's a change to
12−given file. A `%many` request asks to be notified on every
13−change in a `desk` for a range of changes.
14−
15−For `%sing` and `%next`, there are generally three things to be
16−queried. A `%u` request simply checks for the existence of a
17−file at a path. A `%x` request gets the data in the file at a
18−path. A `%y` request gets a hash of the data in the file at the
19−path combined with all its children and their data. Thus, `%y`
20−of a node changes if it or any of its children change.
21−
22−A `%sing` request is fulfilled immediately if possible. If the
23−requested revision is in the future, or is on another ship for
24−which we don't have the result cached, we don't respond
25−immediately. If the requested revision is in the future, we wait
26−until the revision happens before we respond to the request. If
27−the request is for data on another ship, we pass on the request
28−to the other ship. In general, Clay subscriptions, like most
29−things in Urbit, aren't guaranteed to return immediately.
30−They'll return when they can, and they'll do so in a
31−referentially transparent manner.
32−
33−A `%next` request checks the query at the given revision, and it
34−produces the result of the query the next time it changes, along
35−with the revision number when it changes. Thus, a `%next` of a
36−`%u` is triggered when a file is added or deleted, a `%next` of a
37−`%x` is triggered when a file is added, deleted, or changed, and
38−a `%next` of a `%y` is triggered when a file or any of its
39−children is added, deleted, or changed.
40−
41−A `%many` request is triggered every time the given `desk` has a
42−new revision. Unlike a `%next`, a `%many` has both a start and
43−an end revision, after which it stops returning. For `%next`, a
44−single change is reported, and if the caller wishes to hear of
45−the next change, it must resubscribe. For `%many`, every revision
46−from the start to the end triggers a response. Since a `%many`
47−request doesn't ask for any particular data, there aren't `%u`,
48−`%x`, and `%y` versions for it.
49−
50−### Unix sync
51−
52−Usage:
53−```
54−|mount %/path/to/directory %mount-point
55−|commit %mount-point
56−|autocommit %mount-point
57−```
58−
59−One of the primary functions of Clay is as a convenient user
60−interface. While tools exist to use Clay from within Urbit, it's
61−often useful to be able to treat Clay like any other filesystem
62−from the Unix perspective -- to "mount" it, as it were.
63−
64−From the dojo, you can run `|mount %/path/to/directory %mount-point`, and this
65−will mount the given Clay directory to the mount-point directory in Unix, with
66−your pier as the root directory. For example `|mount %/gen %generators` will
67−create a `/generators` directory in your pier, and mount the `/gen` folder at
68−that point. If you'd like to use the directory name as the mount point, you can
69−elide the last argument, e.g. `|mount %/gen` mounts `/gen` to `/gen`.
70−
71−Every file is converted to `%mime` before it's written to Unix, and converted
72−back when read from Unix. The entire directory is watched (a la Dropbox), and
73−every change is committed once you run `|commit %mount-point`. Every change can
74−be automatically committed with `|autocommit %mount-point`.
75−
76−### Merging
77−
78−Usage:
79−```
80−|merge %target-desk ~source-ship %source-desk
81−|merge %target-desk ~source-ship %source-desk, =gem %strategy
82−|merge %target-desk ~source-ship %source-desk, =cas ud+5
83−```
84−
85−Clay supports various merge strategies. A "commit" is a snapshot of
86−the files with a list of parents plus a date. Most commits have
87−one parent; a "merge" commit is a commit with two parents. The
88−%home `desk` starts with an initial commit with no parents; commits
89−with several parents ("octopus merges") are possible but we don't
90−generate them right now.
91−
92−Unless otherwise specified, all of the following create a new commit
93−with the source and destination commits as parents.
94−
95−Several strategies need a "merge-base". They find it by identifying
96−the most recent common ancestor of the two `desk`s. If none, fail
97−with `%merge-no-merge-base`; if there are two or more, pick one.
98−
99−#### Strategies
100−
101−**`%init`**: the only way to create a `desk`. Not a true merge, since it
102−simply assigns the source commit to the destination.
103−
104−**`%fine`**: if source or destination are in the ancestry of each other,
105−use the newer one; else abort. If the destination is ahead of the
106−source, succeed but do nothing. If the source is ahead of the
107−destination, assign the next revision number to the source commit.
108−Some call this "fast-forward".
109−
110−**`%meet`**: combine changes, failing if both sides changed the same file.
111−Specifically, take diff(merge-base,source) and
112−diff(merge-base,destination) and combine them as long as those diffs
113−touch different files.
114−
115−**`%mate`**: combine changes, failing if both sides changed the same part
116−of a file. Identical to `%meet`, except that some marks, like `%hoon`,
117−allow intelligent merge of changes to different parts of a file.
118−
119−**`%meld`**: combine changes; if both sides changed the same part of a
120−file, use the version of the file in the merge-base.
121−
122−**`%only-this`**: create a merge commit with exactly the contents of the
123−destination `desk`.
124−
125−**`%only-that`**: create a merge commit with exactly the contents of the
126−source commit.
127−
128−**`%take-this`**: create a merge commit with exactly the contents of the
129−destination `desk` except take any files from the source commit which
130−are not in the destination `desk`.
131−
132−**`%take-that`**: create a merge commit with exactly the contents of the
133−source commit except preserve any files from the destination `desk`
134−which are not in the source commit.
135−
136−**`%meet-this`**: merge as in `%meet`, except if both sides changed the same
137−file, use the version in the destination `desk`.
138−
139−**`%meet-that`**: merge as in `%meet`, except if both sides changed the same
140−file, use the version in the source commit.
141−
142−#### Examples and notes:
143−
144−The most common merge strategy is `%mate`, which is a normal 3-way
145−merge which aborts on conflict.
146−
147−`%take-that` is useful to "force" an OTA. After running `%take-that`,
148−you're guaranteed to have exactly the files in the source commit plus
149−any files you separately added.
150−
151−We speak of merging into a destination *`desk`* from a source *commit*
152−because while you can only merge on top of a `desk`, you can merge from
153−historical commits. For example,
154−```
155−|merge %old our %home, =cas ud+5, =gem %init
156−```
157−will create a new `desk` called `%old` with the 5th commit in `%home`.
158−You can revert the contents of a `desk` to what they were yesterday
159−with
160−```
161−|merge %home our %home, =cas da+(sub now ~d1), =gem %only-that
162−```
163−
164−Note this is a normal `%only-that merge`, which means you're creating a
165−*new* commit with the old *contents*.
166−
167−`%meld` is rarely used on its own, however if you specify `%auto` or
168−omit the merge strategy, `%kiln` will run a `%meld` merge into a scratch
169−`desk` and then annotate the conflicts there.
170−
171−If you resolve merge conflicts manually, for example by mounting the
172−`desk`s, copying the files in Unix and then running `|commit`, you
173−should usually run an `%only-this merge`. This will not change the
174−newly-fixed contents of your `desk`, but it will record that the merge
175−happened so that those conflicts don't reappear in later merges.
176−
177−If you get a `%merge-no-merge-base` error, this means you're trying to
178−merge two `desk`s which have no common ancestors. You need to give
179−them a common ancestor by choosing a merge strategy which doesn't
180−need a merge-base, like `%only-this`, `%only-that`, `%take-this`, or
181−`%take-that`.
182−
183−`%take-this` could be useful to install 3rd party software, but you
184−couldn't get subsequent updates this way, since the files would
185−already exist in the destination `desk`. Something like "take only
186−the files which aren't in my OTA source or any other 3rd party app"
187−would be basically correct. This would require a parameter listing
188−the `desk`s to not conflict with.
189−
190−`%meet-this` and `%meet-that` imply the existence of `%mate-this` and
191−`%mate-that`, but those don't exist yet.
192−
193−### Autosync
194−
195−Usage:
196−```
197−|sync %target-desk ~source-ship %source-desk
198−```
199−
200−Tracking and staying in sync with another `desk` is another
201−fundamental operation. We call this "autosync". This doesn't mean
202−simply mirroring a `desk`, since that wouldn't allow local changes.
203−We simply want to apply changes as they are made upstream, as
204−long as there are no conflicts with local changes.
205−
206−This is implemented by subscribing to changes to the other `desk`, with a
207−`%many` request and, when it has changes, merging these changes into our `desk`
208−with the usual merge strategies.
209−
210−Note that it's quite reasonable for two `desk`s to be autosynced to
211−each other. This results in any change on one `desk` being mirrored
212−to the other and vice versa.
213−
214−Additionally, it's fine to set up an autosync even if one `desk`,
215−the other `desk`, or both `desk`s do not exist. The sync will be
216−activated when the upstream `desk` comes into existence and will
217−create the downstream `desk` if needed.
arvo/concepts/_index.mddeleted−13
@@ -1,13 +0,0 @@
1−+++
2−title = "Concepts"
3−weight = 100
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
8−
9−Other concepts related to the way Arvo works.
10−
11−## [Subscriptions](@/docs/arvo/concepts/subscriptions.md)
12−
13−Urbit relies heavily on subscriptions throughout the stack. We strongly prefer reactive data flow compared to querying or polling, which is why for example our equivalent to git natively supports subscriptions to its data.
arvo/concepts/subscriptions.mddeleted−162
@@ -1,162 +0,0 @@
1−+++
2−title = "Subscriptions"
3−weight = 50
4−template = "doc.html"
5−+++
6−
7−Urbit relies heavily on subscriptions throughout the stack. We strongly
8−prefer reactive data flow compared to querying or polling, which is why
9−for example our equivalent to git natively supports subscriptions to its
10−data.
11−
12−We have many application-level styles of subscription, but we only have
13−three true subscription types in Arvo, named for the vane they're
14−implemented in: Clay subscriptions (filesystem), Gall subscriptions
15−(applications), and Jael subscriptions (Urbit ID info). They're at
16−three different points in the idea maze of subscriptions, and we'll
17−encounter each of them here.
18−
19−For our purposes, a subscription is a stream of events from a publisher
20−to a subscriber, where (1) the publisher has indicated interest in that
21−stream, (2) any update sent to one subscriber is sent to all subscribers
22−on the same stream, and (3) when the publisher has a new update ready,
23−they send it immediately to their subscribers instead of waiting for a
24−later request.
25−
26−## Basic properties
27−
28−### Exactly-once updates
29−
30−Some subscriptions need the subscriber to receive each update separately
31−instead of collapsing them into a single diff. Sometimes a subscription
32−is really a sequence of commands, in which case there's no meaningful
33−way to collapse them. Similarly, software updates may be expected to be
34−applied in order.
35−
36−### Syncing data
37−
38−Other times, it's more natural to think of a subscription as
39−communicating a data structure, where the only goal is to keep the data
40−structure on the subscriber's side up-to-date with what's on the
41−publisher's side. In this case, it's perfectly fine to collapse several
42−updates into one large update, or even to resend the entire data
43−structure. Partial updates exist only as an optimization.
44−
45−For this sort of subscription, we commonly use terms like "diff" instead
46−of "message" or "update", and we say that we "apply a diff" instead of
47−"process an update". We also often identify the subscription with the
48−data structure itself.
49−
50−## Memory pressure
51−
52−Naively implemented, subscriptions pose a memory leak risk if the
53−subscriber can't receive updates as fast as the publisher wants to send
54−them. This commonly happens when the subscriber goes offline for an
55−extended period of time (possibly forever; especially for comets). It's
56−sufficient to bound the amount of memory dedicated to any particular
57−subscriber.
58−
59−In a synchronous system, you don't have to worry about what happens if
60−one side or the other ceases to be available. All of our subscriptions,
61−though, can happen between ships.
62−
63−### Small data
64−
65−For particularly low-volume subscriptions, it may be acceptable to
66−ignore the problem. Jael uses this approach, since the only time it's
67−used across ships is to update moon keys, which is very low-volume and
68−less than 1KB per update. If these subscriptions are used for more,
69−this strategy will have to be revisited.
70−
71−### Buffers
72−
73−A common solution to this problem is the venerable buffer. If more than
74−N updates need to be sent, start dropping updates. There are several
75−options for what to do when the buffer is full and the publisher wishes
76−to send another message:
77−
78−- Drop the oldest message. Particularly suitable for systems where new
79−messages obsolete old ones. For example, if you just need the latest
80−ticker price for an asset, you could use a buffer size of one and
81−replaced it any time you have a new price.
82−
83−- Don't add the new message to the buffer. Semantically this is usually
84−less helpful, but mechanically it can be simpler and reduce memory
85−churn, since the buffer stops changing and new messages are simply
86−ignored.
87−
88−- Drop the newest message and close the subscription. Unlike the
89−previous two, this is compatible with the principle of exactly-once
90−messaging. Specifically, it preserves the guarantee that you won't
91−receive two non-consecutive subscription updates, at the cost of making
92−you resubscribe if you fall behind.
93−
94−Gall subscriptions use the last of these. The buffer is bounded by a
95−simple heuristic, and when a subscription exceeds that buffer, it is
96−closed and the app is expected to resubscribe when they come back
97−online. Note that even though the subscription is closed, messages in
98−flight cannot be removed until they've been acknowledged since Ames
99−guarantees exactly-once messaging, so those last few messages will be
100−stuck in memory until the subscriber comes back online.
101−
102−Buffers are commonly bounded by size, but this puts constraints on the
103−types of messages may be sent. They may also be bounded in time: if the
104−subscriber stops taking messages for at least X time, the buffer is
105−full. Gall taks a hybrid approach; currently the heuristic is that the
106−buffer counts as full if it has at least five messages and it has been
107−30 seconds since a message was acknowledged.
108−
109−### One at a time
110−
111−Another scheme is to avoid multi-message subscriptions. Instead of
112−allowing the subscriber to subscribe to all future updates on a path,
113−allow them to "subscribe" to the *next* update only. When they get that
114−update, they subscribe to the new next update, so that they ultimately
115−get every message.
116−
117−Commonly this is implemented where each update is given a version
118−number, and every time you hear update N you request update N+1 (even
119−though you won't get an answer for an indeterminate period of time).
120−
121−This is near the theoretical ideal for memory usage, since you'll never
122−queue up several messages to send to the subscriber.
123−
124−It also encourages processing each update in order rather than zooming
125−forward from time to time. It's possible (if a little awkward) to
126−simulate this with buffers though, and it's possible to allow zooming
127−forward in the one-at-a-time scheme by having the requests be "most
128−recent after update N" instead of "next after update N".
129−
130−This scheme is at its strongest, then, when you're already storing
131−intermediate states or updates, or when you don't care about
132−intermediate states and always send the most recent one. Otherwise,
133−buffers are a convenient place to temporarily store updates that you
134−don't want to store internally. Of course, if it's semantically
135−important that you give each update separately, buffers won't save you
136−from having to store the intermediate updates, since they may fill up.
137−
138−Another conceptual advantage is that it has no notion of "connectivity".
139−It operates forever in a single mode. By contrast, buffer-based
140−solutions must keep track of whether the buffer is full and react to
141−that. This increases complexity in the system, and complexity is the
142−great evil.
143−
144−The biggest disadvantage of this system is that it takes much longer to
145−process many small updates. With buffers, the publisher could have a
146−dozen small updates in flight at the same time, while in this scheme
147−they would only send one at a time, waiting for a response between each
148−one. Losing this pipelining can be quite significant for some
149−applications, but for low-volume subscriptions (certainly anything that
150−updates less than once per minute) this will have no noticeable effect.
151−
152−Clay uses this scheme. It's low-volume, it stores all previous states
153−anyway (since it's a revision-control system), and it's sometimes
154−important to get updates one at a time (for example when downloading OTA
155−software updates). Ships that send OTA updates often have many ships
156−subscribed to them, and the updates themselves may be large, so it's
157−important they don't queue up when ships inevitably disappear.
158−
159−I tend to think most Gall subscriptions should follow this pattern as
160−well. Our most latency-sensitive subscriptions are chat messages, and
161−while I haven't tested it, I would guess that even those wouldn't be
162−affected by this scheme.
arvo/dill/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Dill"
3−weight = 40
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/dill/dill-api.mddeleted−366
@@ -1,366 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 10
4−template = "doc.html"
5−+++
6−
7−In this document we describe the public interface for Dill. Namely, we describe
8−each `task` that Dill can be `pass`ed, and which `gift`(s) Dill can `give` in return.
9−
10−Dill is unique among vanes since it is technically the first vane to be booted (though we
11−regard Jael as the "true" first vane). As a result, there are four `task`s in
12−`task:able:dill` for which Dill acts only as a middleman that passes the `task`s
13−directly to the Arvo kernel. Thus we have split this document into a [Dill
14−tasks](#dill-tasks) section and an [Arvo tasks](#arvo-tasks) section.
15−
16−## Dill Tasks
17−
18−
19−### `%belt`
20−
21−Every keystroke entered into the console triggers a `%belt` `task` for Dill which contains information about the keystroke, such as which key was pressed
22−and from which terminal.
23−
24−#### Accepts
25−
26−`%belt` `task`s come in a number of different types, corresponding to different
27−keystrokes. You can find this list in `+dill-belt` in `zuse.hoon`.
28−
29−```hoon
30−++ dill-belt :: new belt
31− $% {$aro p/?($d $l $r $u)} :: arrow key
32− {$bac ~} :: true backspace
33− {$cru p/@tas q/(list tank)} :: echo error
34− {$ctl p/@} :: control-key
35− {$del ~} :: true delete
36− {$hey ~} :: refresh
37− {$met p/@} :: meta-key
38− {$ret ~} :: return
39− {$rez p/@ud q/@ud} :: resize, cols, rows
40− {$txt p/(list @c)} :: utf32 text
41− {$yow p/gill:gall} :: connect to app
42− == ::
43−```
44−
45−#### Returns
46−
47−Dill returns no `gift` in response to a `%belt` `task`.
48−
49−
50−### `%blew`
51−
52−This `task` is called whenever the terminal emulator is resized, so that Dill can adjust
53−the text output to fit the new window size.
54−
55−#### Accepts
56−
57−```hoon
58−[p=@ud q=@ud]
59−```
60−
61−`p` is the number of columns and `q` is the number of rows.
62−
63−#### Returns
64−
65−Dill returns no `gift` in response to a `%blew` `task`.
66−
67−
68−### `%boot`
69−
70−This `task` is used only once, when Arvo first enters the [adult
71−stage](@/docs/arvo/overview.md#structural-interface-core). Dill is
72−technically the first vane to be activated, via the `%boot` `task`, which then
73−send Jael (considered the the "true" first vane) an `%init` `task`, which then goes on to
74−call `%init` `task`s for other vanes (including Dill).
75−
76−#### Accepts
77−
78−`%boot` takes an argument that is either `%dawn` or `%fake`. `%dawn` is the one
79−used in any typical scenario and activates the ordinary vane initialization
80−process outlined above, while `%fake` is a debugging tool.
81−
82−#### Returns
83−
84−`%boot` does not return a `gift`.
85−
86−
87−
88−### `%crud`
89−
90−This `task` is used by Dill to produce error reports. It prints the received
91−error message(s) (a `(list tank)`) to the terminal. The level of detail of the
92−error message is set by `$log-level`, which is either `%hush`, `%soft`, or `%loud`.
93−
94−#### Accepts
95−
96−```hoon
97−[err=@tas tac=(list tank)]
98−```
99−
100−`err` is the type of error and `tac` is the associated error message.
101−
102−#### Returns
103−
104−`%crud` does not return a `gift`.
105−
106−
107−### `%flog`
108−
109−A `%flog` `task` is a wrapper over a `task` sent by another vane. Dill removes the wrapper
110−and sends the bare `task` to itself over the default `duct`.
111−
112−#### Accepts
113−
114−`%flog` `task`s can take any valid Dill `task` as an argument.
115−
116−#### Returns
117−
118−`%flog` never returns a `gift` on its own, but the wrapped `task` might.
119−
120−#### Example
121−
122−`%crud` `task`s from other vanes are typically passed to Dill wrapped in a
123−`%flog` `task` to print errors to the terminal.
124−
125−
126−
127−### `%flow`
128−
129−This `task` is not used.
130−
131−
132−### `%hail`
133−
134−`%hail` refreshes the terminal by sending an empty message to the default duct
135−for Dill,
136−causing the terminal to redraw itself (?)
137−
138−#### Accepts
139−
140−```hoon
141−[ ~ ]
142−```
143−
144−#### Returns
145−
146−`%hail` returns no `gift`s.
147−
148−
149−### `%heft`
150−
151−`%heft` causes Dill to `pass` a `%wegh` `task` to all other vanes (but not to
152−itself), thus obtaining a complete digest of Arvo's memory usage.
153−
154−#### Accepts
155−
156−```hoon
157−[ ~ ]
158−```
159−
160−#### Returns
161−
162−`%heft` does not directly return any `gift`s, but each `%wegh` `task` sent will
163−return a `%mass` `gift`.
164−
165−
166−### `%hook`
167−
168−This task is not used.
169−
170−
171−### `%harm`
172−
173−This `task` is not used.
174−
175−
176−### `%init`
177−
178−This `task` is called only once, when Arvo first enters the [adult
179−stage](@/docs/arvo/overview.md#structural-interface-core). It performs
180−initial setup for Dill, such as setting the width of the console.
181−
182−Note that this is not actually the first `task` passed to Dill - see [%boot](#%boot).
183−
184−#### Accepts
185−
186−`%init` takes no arguments.
187−
188−#### Returns
189−
190−`%init` returns no `gift`s.
191−
192−
193−### `%knob`
194−
195−`%knob` sets the verbosity level for each error tag.
196−
197−#### Accepts
198−
199−```hoon
200−[tag=@tas level=log-level]
201−```
202−
203−`tag` is the error tag. `level` is the verbosity, set to either `%hush`,
204−`%soft`, or `%loud`.
205−
206−#### Returns
207−
208−`%knob` does not return a gift.
209−
210−
211−
212−
213−### `%noop`
214−
215−`%noop` does nothing - it stands for "no operation".
216−
217−#### Accepts
218−
219−```hoon
220−[ ~ ]
221−```
222−
223−#### Returns
224−
225−This `task`, predictably, returns nothing.
226−
227−#### Example
228−
229−This can be useful if a shell command requires a Dill `task` but you don't want
230−Dill to do anything.
231−
232−
233−
234−### `%talk`
235−
236−This `task` is not used.
237−
238−### `%text`
239−
240−This `task` prints a `tape` to the dojo by first converting it from a UTF8
241−`tape` to a `list` of UTF32 codepoints (`@c`'s) and then recursively popping off a character from the
242−`tape` and sending it to to Unix to be printed into the terminal via a `%blit` event.
243−
244−#### Accepts
245−
246−```hoon
247−[p=tape]
248−```
249−
250−#### Returns
251−
252−This `task` returns zero or more `%blit` `gift`s, each containing a .
253−
254−
255−### `%trim`
256−
257−`%trim` is a common vane `task` used to reduce memory usage. However, it does
258−nothing for Dill.
259−
260−#### Accepts
261−
262−```hoon
263−[p=@ud]
264−```
265−
266−This is a common parameter for `%trim` `task`s across all vanes but does nothing
267−for Dill.
268−
269−#### Returns
270−
271−This `task` returns no `gift`s.
272−
273−
274−
275−### `%vega`
276−
277−This is a common vane `task` used to inform the vane that the kernel has been
278−upgraded. Dill does not do anything in response to this.
279−
280−#### Accepts
281−
282−```hoon
283−[ ~ ]
284−```
285−
286−#### Returns
287−
288−This `task` returns no `gift`s.
289−
290−
291−
292−## Arvo tasks
293−
294−These `task`s live in `task:able:dill` but are passed directly to the Arvo
295−kernel for processing.
296−
297−### `%lyra`
298−
299−This `task` updates the kernel.
300−
301−#### Accepts
302−
303−```hoon
304−[p=@t q=@t]
305−```
306−
307−`p` is the contents of the new `hoon.hoon` and `q` is the contents of the new `arvo.hoon`.
308−
309−#### Returns
310−
311−This `task` returns no `gift`s.
312−
313−
314−### `%pack`
315−
316−This `task` defragments and deduplicates Arvo's memory. This is ultimately
317−performed by the interpreter so you won't find the code in `arvo.hoon` but
318−rather under `c3__pack` in `urbit/worker/main.c`.
319−
320−#### Accepts
321−
322−```hoon
323−[ ~ ]
324−```
325−
326−#### Returns
327−
328−This `task` returns no `gift`s.
329−
330−
331−### `%veer`
332−
333−This `task` is used to install `zuse` and vanes. It is handled by `+veer` in
334−`arvo.hoon`.
335−
336−#### Accepts
337−
338−```hoon
339−[p=@ta q=path r=@t]
340−```
341−
342−`p` is the vane letter, `q` is the formal `path` to the
343−vane, and `r` is the source code for the vane. The vane letter is `%` followed
344−by the first letter of the vane in lowercase, such as `%d` for Dill. `p=%$` in
345−the case of `zuse`.
346−
347−#### Returns
348−
349−This `task` returns no `gift`s.
350−
351−
352−### `%verb`
353−
354−This `task` toggles verbose mode for all of Arvo, which is located here since
355−Dill is the vane that prints errors. To be precise, `%verb` toggles the laconic
356−bit `lac` in the [Arvo state](@/docs/arvo/overview.md#the-state).
357−
358−#### Accepts
359−
360−```hoon
361−[ ~ ]
362−```
363−
364−#### Returns
365−
366−This `task` returns no `gift`s.
arvo/dill/dill.mddeleted−24
@@ -1,24 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−aliases = ["/docs/learn/arvo/dill/"]
6−+++
7−Our terminal driver.
8−
9−Unix sends keyboard events to `%dill` from either the console or telnet,
10−and `%dill` produces terminal output. The only app that should directly
11−talk to `%dill` is the terminal app. Command-line apps are run by,
12−receive input from, and produce output to, the `%shell` app, which is
13−controlled by `%terminal`, which talks to `%dill`, which talks to unix.
14−Clay also uses `%dill` directly to print out the filesystem change
15−events, but this is questionable behavior.
16−
17−`%dill` has two main components. First, it controls the terminal on a
18−very basic, event-by-event level. This includes keeping track of things
19−like the dimensions of the terminal, the prompt type (plain text or
20−password), which duct to produce effects on, and so forth. Second, it
21−handles terminal events, keystroke by keystroke. Most characters are
22−simply pushed onto the buffer and blitted to the screen, but some
23−characters, including control-modified keys, arrow keys, etc. require
24−special handling. Most of the readline functionality is in `%dill`.
arvo/eyre/_index.mddeleted−16
@@ -1,16 +0,0 @@
1−+++
2−title = "Eyre"
3−weight = 50
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
8−
9−## [Overview](@/docs/arvo/eyre/eyre.md)
10−
11−A high-level overview of `eyre`, Urbit's HTTP server vane.
12−
13−## [Using Eyre](@/docs/arvo/eyre/using-eyre.md)
14−
15−How to use Urbit's HTTP API.
16−
arvo/eyre/eyre.mddeleted−721
@@ -1,721 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−aliases = ["/docs/learn/arvo/eyre/"]
6−+++
7−
8−*Current docs on Eyre are out of date. Until they are updated this doc remains for historical purposes*
9−
10−
11−Our HTTP server.
12−
13−Unix sends http messages to `%eyre`, and `%eyre` produces http messages
14−in response. In general, apps and vanes do not call `%eyre`; rather,
15−`%eyre` calls apps and vanes. `%eyre` uses `%ford` and `%gall` to
16−functionally publish pages and facilitate communication with apps.
17−
18−`%eyre` primarily parses web requests and handles them in a variety of
19−ways, depending on the control string. Nearly all of these are
20−essentially stateless, like functional publishing with `%ford`.
21−Additionally, there's a fairly significant component that handles
22−`%gall` messaging and subscriptions, which must be stateful.
23−
24−## Reference
25−
26−### State
27−
28−Stored
29−
30−- `++bolo`
31−- `++cyst`
32−- `++stem`
33−
34−Runtime
35−
36−- `perk`
37− + `perk-auth`
38−- `pest`
39−- `even`
40−
41−### Cores
42−
43−- `++handle`
44− + `++parse`
45− - `++as...`
46−- `++ya`
47−- `++ix`
48−
49−## Commentary
50−
51−
52−Let us follow the loading of a simple cli app, as it bounces from
53−browser to server to browser and back.
54−
55−### Initial request
56−
57−An http request for `http://sampel-sipnym.urbit.org/cli` will be [redirected](dns)
58−to the `%eyre` on ~sampel-sipnym, and come in as a `%this` task.
59−
60−From arvo, requests enter `++call`, which after some type reification are passed
61−along to `++apex:ye`. In the case of a `%this` task, its components are
62−parsed(see `++zest:epur`, `++eat-headers`) and handed off to `++handle`, wrapped
63−in `++emule` to produce a `++fail` page in case of error. `++apex:handle` will
64−`++process` the request to a `pest` or a `++done` [core](/docs/glossary/core/), and in the former case
65−`++resolve` the pest into an outgoing card.
66−
67−XX it also seems to affect the current ship, test that serving ship name is consistently correct
68−
69−The pest is produced by `++process`, which will first further `++parse` the
70−request, and if this does not make the response immediately obvious,
71−`++process-parsed` the resulting `perk`.
72−
73−`++parse` produces the `perk`, by attempting to interpret the `pork`(url path)
74−[`++as-magic-filename`](#mage), `++as-beam`, and `++as-aux-request`. In this
75−case, `/cli` is parsed by the second case as a `%beam` query to `/=cli=`: a path
76−which starts with a valid ship name is expected to be a full clay(well, ford)
77−path, and one starting with a term implies the current serving ship and a case
78−of `0`, the current revision.
79−
80−XX spur: when the desks are merged, `/cli` shall point to `/=main=/pub/cli`
81−
82−The parsed `perk` generates a `%f %boil` note, `mark`ed as its extension(here
83−defaulting to `%urb`) and `wire`d with `~` to return unaltered to the client. It
84−goes on to `++resolve` by being passed to `++ford-get-beam`, which translates
85−the perk it into a `%boil` `++ford-req`, adding an `++fcgi` path-segment
86−containing query string and `++fcgi-cred:for-client` auth information.
87−
88−`%ford`s translation of `/=cli=/hymn/hook` to a self-refreshing `%urb` html page
89−[deserves its own commentary](/docs/arvo/ford#commentary), but
90−we resume in `%eyre` when the `%made` sign arrives in `++take`, and soon after
91−`++axon:ye`. There the `wire`, or rather the `whir` it has been verified to be,
92−determines that the response should be served immediately. However, as the mark
93−is not `%mime`, another trip to `%ford` is required to encode it, on the same
94−wire; afterwards, the value of the `%mime` cage is verified to be of the correct type, and finally
95−delivered back up the requesting duct as a successful `%thou` HTTP response.
96−
97−XX `%cast %mime` used to be in ford-get-beam, is there a reason it was removed?
98−
99−## Back into the breach, or: auxilary requests
100−
101−Now, it was mentioned that this result is self-refreshing: the `%urb`
102−translation [door](/docs/glossary/door/) injects a `;script@"/~/on/{deps}.js"` into every page, `deps`
103−is a ford-readable hash of the set of resources that page construction depended
104−on.
105−
106−This triggers another `%this` request. Its handling is identical to that of
107−`/cli` up until `++parse`, where it is seen not `++as-beam` but
108−`++as-aux-request`(auxillary requests starting with `/~/` or `/~~/`).
109−`/on/[hash]` is a long-`%poll`, which `++process-parsed`, for a `.js` mark,
110−answers with a direct `%js`. Its contents are the static `++poll:js`, which
111−initiates the long-polling loop, run against an injected `urb.js` of
112−`{poll:[hash]}`.
113−
114−A `%js` `pest` is `resolve`d as a `text/javascript` success `%this`.
115−
116−When `poll.js` is received by the client, it opens an `XMLHttpRequest` for
117−`/~/on/{window.urb.poll}.json`, bringing us back to `%poll:process`.
118−
119−In the case of a non-`%js` `/~/on/`, `%poll:process-parsed` turns into a
120−`++new-dependency`, which stores the listening duct, and `pass-note`s a `%wasp`
121−with the deps-hash back to `%ford` whence it came. While this occured, the page
122−has loaded.
123−
124−Some indeterminate amount of time afterwards, with dropped `/~/on/{...}.json`s
125−being retried upon expiring and also being stored, a `%news` sign arrives in
126−`++axon`, and the hash in question is retrieved from the wire, and the listening
127−long-polls retrieved by the hash. Each receives a 205 "Reload parent view" HTTP
128−response, which `poll.js` dutifully executes, and a fixed typo of markdown is
129−rendered.
130−
131−## Authentication
132−
133−Now, while this accurately reflects the presentation of e.g. a markdown file,
134−`/cli` is an application front-end, and one that permits only owner access. Its
135−second script is `@"/~~/~/at/main/lib/urb.js"`, semantically equivalent to
136−`/~/as/own/~/at/main/lib/urb.js`, and handled as follows.
137−
138−In `++as-aux-request`, `%as %own` becomes `%auth %get our` perk, which
139−`++process` passes to `++process-parsed` passes to `++process-auth`. There, a
140−`yac` "ya" core is built `++for-client`: a `++cookie-prefix`, which is just the
141−serving ship name, is used to get a `++session-from-cookies`, here nil as the
142−client has no cookie set. In lieu of a cookie, a `++new-ya` is constructed, with
143−a random token `hole` and a `++new-cyst` which fills out `cyst` session state
144−from request data.
145−
146−Returning to `++process-auth`, `%get` checks if the yac is authenticated with
147−the requested credentials(`anon` requests are always granted), which for the
148−fresh new `cyst` is not the case (more on success [later](#auth-ok)). Unless
149−authenticating as a [foreign ship](#xeno), the only thing left is to
150−`++show-login-page`, which detects that the requested resource is not `%html`,
151−and produces a `%red` pest. For `%js`, `%red`irections `++resolve` to
152−`++auth-redir:js`, a line of javascript which prepends `/~~` to the url path.
153−
154−The owner-authenticated main page request similarly ends in `++show-login-page`,
155−which for the empty session is an `[%htme ++login-page:xml]`, `resolve`d to
156−`++give-html` with a 401 "unathorized".
157−
158−The login page shows a simple prompt, and requests `/~/at/auth.js` to handle the
159−submission. And so we are, once again, attempting to divine if what we're doing
160−makes sense `++as-aux-request`.
161−
162−To understand `/~/at`, there will first be a brief diversion to `~/auth.json`.
163−`auth.json`, perk `[%auth %json]`, in `++process-auth` serves `++stat-json:ya`,
164−containing such information as the serving ship, which identities are associated
165−with this session, and `oryx`, a CSRF token. An oryx must be present on all
166−stateful requests, in this case executing a log in. It also saves the new/old
167−session using `abet`.
168−
169−XX explain `ixor` here and not [later](#ixor)?
170−
171−`/~/at` is an alternate interface, which injects `auth.json` data into the
172−requested file. `/~/at/auth.js`, then, is a request for the built-in `auth:js`
173−(parsed to and processed from an `[%auth %js ~]` perk), with session data added
174−as `window.urb`. And indeed, ``[`%js /~/at/auth]`` is parsed to
175−``[%auth at [`%js /auth]``, which in `++process-auth` is re-`process`ed to
176−`[%js ++auth:js]`, which is `++resolve`d after an `++add-json` of
177−the relevant data. The yac cookies are also passed to `resolve`, which
178−`++add-cookies` injects into the `httr`.
179−
180−It is at this point that there is first occasion for user input, namely the password.
181−
182−The `auth:js` script sends a `PUT` request, also to `/~/auth.json`. In `parse`,
183−the first nontrivial `++check-oryx` occurs, `++grab-body` the request oryx and
184−ensuring it is recorded for the session. The request parsed with `++need-body`
185−to a `[%auth %try {password}]` perk. `%get:process-auth` checks it against
186−`++load-secret`, upon success updates the session with `++logon:ya`, and
187−serves a fresh `auth.json` which reflects the changed `user`. Upon receiving
188−this, the page is refreshed to retry the original request.
189−
190−### Post-authentication: app communication.
191−
192−Upon refresh, `/~~/cli` brings us for the third time to `%get:process-auth`, but
193−this time the cookie is set, and the `yac` fetched contains the serving ship as
194−authenticated. The `++handle` sample is updated to reflect the requesting ship,
195−and the `process` continues for the rest of the pork, once again serving the
196−ford page.
197−
198−The `/~/on/[deps].json` poll starts anew, and `/~~/~/at/main/lib/urb.js` we now
199−know to serve the window.urb necessary to make requests, and the `urb.js`
200−standard library which extends it with a number of wrappers to them and other
201−useful functions.
202−
203−One of those functions is `urb.bind`, which is used to subscribe to application
204−data. Userspace javascript sets `urb.appl` to `/tic`, and binds `lines` to a
205−`;pre;` text display, using a callback.
206−
207−This triggers a `PUT` to `/~/is/{ixor}/cli/lines.json`, where `ixor` is a hash
208−of `oryx` that identifies the connection. `++as-aux-request`, an `%is` is a
209−`%subs` subscription update update, which for `%put` forwards to
210−`++add-subs:ix`, the ix core fetched `++for-view` by hashing the request
211−`++oryx-to-ixor`.
212−
213−A view has all the state associated with a client that must be
214−remembered between events. In this case, this is what app/path the request duct
215−is associated with; but mainly, `++add-subs:ix` will `pass-note` to `%gall` so
216−it `%show`s the data on the path, current and future.
217−
218−This will immediately(assuming the ship is local) result in a `%nice` by the
219−`/cli` app, returning `{ok:true}` `++nice-json` to `urb.bind`'s second callback
220−as `{ok:true}`. The initial `%rush` results also arrive, and in `++axon` are
221−converted to json using `++back`(ford `%cast` wrapper), and when `%made` get
222−passed to `++get-rush:ix`. There the source application/path are decoded by
223−duct, and then the full event goes to `++get-even`; `++add-even` inserts it to
224−the queue, and as there is no long poll it simply stays there.
225−
226−Upon receipt, the client realizes the long-poll isn't actually running, so that
227−is started using `urb.poll`. At `/~/of/{ixor}`, perk
228−`[%view ixor ~ {sequence-number}]`, it is `process`ed by `++poll:ix` (the cyst
229−is retrieved by `++ire-ix` form global state, using the perk `ixor`): the
230−sequence number is in the past, so the previously received `%rush` is
231−`++give-even`. After deleting the previous message in the queue and invoking
232−`++pass-took` to signal `%gall` of this occurrence, the data is annotated with
233−the source app+path `++subs-to-json`, and returned to the polling duct.
234−
235−On the client, the user callback receives the `/cli` history, and displays it on
236−the page. The `/~/of` long poll is continued, this time reaching `++poll:ix`
237−with the "pending" sequence number, and being stored in the `cyst` for its troubles.
238−
239−Its next update proceeds idenitcally, but first it must be triggered, which
240−happens when the user enters "(add 2 2)\n", firing an `urb.send` from the event
241−handler. This sends a `POST` request to `/~/to/cli/json.json`, perk `%mess`,
242−`++process`ed to a `%g %mess`. Were the mark not `%json`, a `%ford` conversion
243−would occur first, and `%made:axon` would send the gall message proper. In
244−either case, eventually a `%mean` or `%nice` arrives, is encoded as json, and
245−sent to the client callback.
246−
247−## A path not taken: magic filenames
248−
249−The `/robots.txt` and `/favicon.(ico|png)` files are static, and served
250−immediately when caught by a `++parse`.
251−
252−XX index.html?
253−
254−## A path not taken: foreign auth
255−
256−While this example details a login `/~/as/own`, it is possible to be
257−authenticated as any ship on the network. A request for such seen in
258−`%get:process-auth` is passed to `++foreign-auth:ya`, which sends an
259−`%ames /lon` message to the ship in question. The foreign ship stores the
260−inquiry, calculates(the local) `++our-host` and responds with a `/hat`,
261−containing the redirection host, which is stored by `++foreign-hat`; it is later
262−used to send the client to a `/~/am` url on the foreign client, which acts as a
263−normal login page but later sends the client back. XX expand, basically the
264−status quo is you're logged in and `/~/as/foo` is ignored, just setting your
265−`urb.user` XX
266−
267−
268−### A path not taken: deauthentication
269−
270−`/~/away`, perk `[%away ~]`, produces a static `++logout-page:xml`, which also
271−uses `/~/at/auth.js`, to send a `DELETE /~/auth.json`, perk `[%auth %del]`. This
272−executes `++logoff:ya` for the cookie session, resolving to `++abut` to wipe it
273−from memory.
274−
275−### A path not taken: unsubscription
276−
277−`DELETE /~/is/app/path/within` works much like `PUT /~/is/app/path/within`,
278−`++del-subs:ix` acting as reverse of `++add-subs` by deleting the duct binding
279−and sending `%g %nuke`.
280−
281−
282−XX unmentioned arms: abet, add-poll, adit, ames-gram, anon, ares-to-json, bolo, cyst, doze, even, ford-kill, get-mean, gift, give-json, give-thou, gram, hapt, hasp, host-to-ship, ix, ixor, js, kiss, load, mean-json, move, note, pass-note, perk, perk-auth, pest, poke-test, print-subs, render-tang, resp, root-beak, scry, ses-authed, ses-ya, sign, silk, sine, stay, stem, teba, titl, to-oryx, urb, wait-era, wake, whir, wush, xml, ya, ye
283−
284−### Appendix A: DNS
285−
286−The `*.urbit.org` domain can be used to access destroyers and cruisers. In the
287−common case oh hosted ships, this is done by dynamic DNS directly to the hosting
288−instance. We do not speak of the uncommon case. When ports are blocked and
289−infrastructure crumbles around you, only imported martian networking can be
290−trusted: the `%get` and `%got` grams are used to proxy `%this` requests and
291−`%thou` responses respectively.
292−
293−## Specification
294−
295−The `%eyre` vane serves one purpose: receiving inbound HTTP requests from browsers and clients pretending to be browsers. To facilitate this communication, `%eyre` does two things: 1. provide an API for traditional clients to talk to; and 2. provide a mechanism for saving state that allows the server to keep track of identities/sessions, subscription data, and active connections.
296−
297−This document outlines the following:
298−
299−1. [`perk`](#perk), a `pork` subset that defines what URLs the client can send to `%eyre`.
300−
301−2. [the values stored on the client](#client), both statically in cookies and dynamically as the `window.urb` object, which facilitate this transaction.
302−
303−3. [`task`](#task), the requests `%eyre` will accept.
304−
305−4. [`gift`](#gift), the responses it will give to those requests.
306−
307−5. [`note`](#note), the set of arvo requests that %eyre makes to the other vanes.
308−
309−6. [`whir`](#whir), a `wire` subset, the associated dynamic state
310−
311−7. [`sign`](#sign), the responses `%eyre` accepts
312−
313−8. [`bolo`](#bolo), the state stored between separate events.
314−
315−## 1. URL structure
316−
317−There exist several URL forms accepted by `%eyre`.
318−
319−### 1.1 Functional request
320−
321−The simplest of them is a static `%f` functional publish request:
322−
323−```
324− GET /[ship]/[desk]/[case]/path/to/file.[mark]
325−```
326−e.g.
327−
328−```
329− /~pittyp-pittyp/main/5/lib/urb.js
330−```
331−A `case` of 0 signifies the most recent version.
332−
333−If no file extension is provided, the default `mark` is `%urb`, which consists of `%html` injected with an auto-refresh script.
334−
335−A shorter form:
336−
337−```
338− /path/to.[mark]
339−```
340−is prepended with the [default request path](#prefix). For example, if `%eyre`
341−is configured with a root of `/<our>/main/0/pub`, then `/doc/arvo` is
342−interpreted as a request for `/=main=/pub/doc/arvo.urb`.
343−
344−Auxiliary paths start with `/~/`, and provide other functionality, such as:
345−
346−### 1.2 Auto-reload
347−
348−When a new version of a page becomes available, it is useful to propagate it to the client. The `%f` vane manages the particulars, and provides an update token along with all published pages. The `/~/on` long-polling endpoint makes use of that token, which is a hash of the server-stored dependency set.
349−- `/~/on/[hash].json` retuns `true` when a page may require updating.
350−- `/~/on/[hash].js` is a lightweight script that polls for the above. It is primarily used in error messages.
351−
352−### 1.3 Authentication
353−
354−Authenticated requests are accomplished through sessions, tracked with cookies which are set on the first such request.
355−- `/~/as/[user]/...` is an authenticated request to `...`, where `user` can be a `@p` ship, `'own'`, `'any'`, or `'anon'`.
356− + `'anon'` is a randomly-generated per-session submarine, and requires no further authentication.
357− + `'own'` represents the serving ship. The short form of `/~/as/own/` is `/~~/`
358− + `'any'` requires a network ship, chosen with a prompt if unknown. The short form of `/~/as/any/` is `/_/`
359− + Auth requests are handled in three ways:
360− + I. If the session is associated with the `ship`, serve `...`, storing the ship as the session's default ship. For example, `/~/as/sivtyv-barnel/main/pub/test.html` is an authenticated request of `/main/pub/test.html` with the identity of `~sivtyv-barnel`.
361− + II. If the session is not associated with the `ship` in the path, the client is redirected to a login page, where a password can be entered. Successful authentication results in a page refresh to the requested path.
362− + III. otherwise, [send a message](#foreign) to the claimed ship, and redirect the user to `https://[foreign-host]/~/am/[ses]/...#[current-host]&?code=[code]`
363−- `/~/am/[ses]/...#original-host` similarly serves a login page. Upon success, inform the `ship` of the success and redirect it back to `http://[original-host]/~/as/<this-ship>/...`
364−- `/~/away.html` is a log-out page.
365−- `/~/auth.json` returns `{ship,oryx,user,auth}`: the serving ship, a CSRF token, active user, and all allowed users respectively.
366−- `/~/at/{...}.js` is an alternate form of `/~/auth.json`, which injects a line into the served js file that sets `{ship, oryx, user, auth}` on the `window.urb` object.
367−
368−So far, all the paths specified have been GET requests. Authentication, however, requires sending data. This is also done at the `/~/auth.json` endpoint.
369−- `POST {oryx,ship,code} /~/auth.json?PUT` is used by the login script to authorize a user, and returns the same result as `GET`, additionally containing either`{ok:true}` or `{fail:'type',mess:"Error message"}`
370−- `POST {oryx,ship?} /~/auth.json?DELETE` revokes authorization. Response as above.
371−
372−### 1.4 Messaging
373−
374−- `POST {oryx, wire, xyro} /~/to/[app]/[mark].json`, where `xyro` is data that will be converted to the `mark`. In the simplest case, `/~/to/hello/json.json` will pass `xyro` through verbatim, sending `[%json xyro]` to the `++poke` arm of app `%hello`.
375−- `POST {oryx, wire, xyro} /~/to/<ship>/[app]/[mark].json` is a foreign message send, as above.
376−
377−### 1.5 Subscriptions
378−
379−- `/~/of/[ixor]` is an `EventSource`: a conceptually infinite file containing a stream of events. By default, it sends a newline every 30 seconds serving to signal that the connection is alive to both the server and IP middleware.
380− + `/~/of/[ixor]?poll={n}` is a long-polling fallback interface. Produces event number `{n}`, blocking until it occurs. Its contexts can be affected by `POST` requests with a body of `{oryx, wire}`, and a query string of `PUT` or `DELETE`. They return either `{mark}`(which may be `null`), or [`{fail, mess}`](#mean-json)
381−- `/~/in/[hash].json` is a dual to [`/~/on`](#on-change). It binds `mod` events, which echo the requesting token.
382−- `/~/is/[app]/path/to.[mark]` binds `rush` events, formatted with a first line of `[app] /path/to`, and the rest containing subscription data. Additionally, `mean` events formatted similarly may arrive, also converted to the relevant mark.
383−
384−
385−
386−### 1.6 Ablative
387−
388−These interfaces will temporarily exist to aid development, and are to be considered unstable.
389−- `/~/debug/...` access normally inaccessible pages. For example, `/~/debug/as.html` will present the login page, regardless of current session status.
390−
391−
392−## 2. Client state
393−
394−Some information is stored on, and provided to, browser clients
395−
396−### 2.1 Cookies
397−
398−Authenticated users receive a cookie on the domain of `*.urbit.org`. The cookie contains a client session token, keyed by the serving ship.
399−
400−### 2.2 Authentication
401−
402−It is common(e.g. by the `%urb` mark) to set window.urb to the contents of `/~/auth.json`:
403−- `ship` is the serving ship
404−- `oryx` is a unique CSRF token that identifies this view, bound to the session cookie
405−- `ixor` is a hash of `oryx`, used as an insecure view identifier
406−- `user` is the authenticated/generated ship name
407−- `auth` is a list of identities usable by this session
408−
409−### 2.3 Client library
410−
411−To this object, `/main/lib/urb.js` adds helpers:
412−- `app` is an optional app name to send messages to by default
413−- `send({data,mark?='json',app?=urb.app,ship?}, cb?)` delivers messages
414−- `bind({path,app?=urb.app}, cb)` subscribes by path
415−- `drop({path,app?=urb.app}, cb?)` pulls the subscription
416−- `util` is an object containing methods for converting between JavaScript types and Hoon [atom](/docs/glossary/atom/) auras.
417−
418−## 3. Requests
419−
420−## `[%born port=@ud]`, unix init
421−
422−When the `vere` process is re/started, a TCP port is bound, HTTP requests on which are the scope of this document. The `%born` gift informs eyre of this occurrence, which in turn updates [its state.](#bolo)
423−
424−**Gifts given in response:** none.
425−
426−## `[%hiss p=mark q=cage]`, outbound http
427−
428−Userspace http request, converted by `%ford` into an actual `hiss`.
429−
430−**Gifts given in response:** a `%sigh`
431−
432−### 3.1 `[%this httq]`, inbound http
433−
434−The primary `%eyre` request type comes from the host system, and constitutes an inbound http request. It consists of five parts:
435−
436−I. `p=[? @if]`: a loobean determining whether the request is being made over https, and the client source, an IPv6 address possibly encoding an IPv4 one as `.0.0.0.0.0.ffff.wwxx.yyzz`
437−
438−II. `q=meth`, an http method
439−
440−III. `r=@t`, the unparsed URL
441−
442−IV. `s=mess`, an associative list of header keys/values
443−
444−V. `t=(unit octs)`, the request body, if any.
445−
446−After `r` is parsed to a `purl`, the `pork`(relative path) determines the resource being served. The first step in handling an http request is [classifying its intent](#perk).
447−
448−- A ford request results in a [`%boil` note](#boil).
449−- `/~/[name].js` is generated from [session](#sink) or [view](#stem) state, and [served](#mime) as `%js`.
450−- `/~/am` generates a login page.
451−- `/~/as` is resolved further if authenticated, generates a similar login page if the claimed ship is local, and otherwise is saved to [session state](#sink) and sends a ["login" `%a` message](#lon) to the foreign ship.
452−- `/~/at` and `/~/auth.json` generate a new `oryx` and store it in the [session state](#sink).
453−- `/~/in` and `/~/is` affect [view state](#stem), possibly sending subscriptions or unsubscriptions to `%f` and `%g` respectively, and are generated from view state.
454−- `/~/on` is saved to the `bolo` by `hash`, and translated to a [`%wasp` note](#wasp).
455−- `/~/of` fails if the `ixor` is unknown, and otherwise is stored in the `ixor`, receiving a partial response and all events after its [last-seen header](#). If it has a `poll` parameter, the response is full, and only occurs if the body is non-empty. Otherwise the oryx is saved as a [live](#live) request in case of cancellation.
456−- `/~/to` transforms into a [`%g` message](#mess).
457−
458−**Gifts given in response:** a `%thou`, or a [`%that`](#that) followed by multiple `%thar`s.
459−
460−### 3.2 `[%thud ~]`, inbound close
461−
462−Sent when an unresponded-to request is cancelled. The [live](#live) effect of the request is looked up, and
463−- `%exec` ford boil requests are cancelled with `[%exec ~]`
464−- `%wasp` ford deps requests are cancelled with `[%wasp |]`
465−- `%poll` session polls `%rest` the session heartbeat timeout
466−
467−### 3.3 `[%thin p=@ud]`, delivery failure
468−
469−Sent when a partial [response](#that) or [body](#thar) fails to arrive. Its `duct` is the same as that of the original request. This is handled by [waiting](#wait) for the client to reconnect, and if this not occur, unwinding all subscription state.
470−
471−
472−**Gifts given in response:** None.
473−
474−### 3.4 ``[%wart sock [path *]]``, inbound message
475−
476−Sometimes, messages are received from other ships. They are expected to take the from of a `gram`.
477−
478−**Gifts given in response:** [`%nice` or `%mean`](#ack).
479−
480−#### 3.4.1 `gram`
481−
482−There are three messages of note, all concerning authentication
483−- `[/lon ses]` is a login request, which contains the session wishing to authenticate.
484−- if the session is already authorized, a reply of `[/aut ses]` from (%eyre on) a foreign ship prescribes that the session is henceforth allowed to act on its behalf. All waiting `/~/as` are resolved as successful.
485−- otherwise, `[/hat ses hart]` contains the ship's preferred hostname. This can then be used to redirect the client. All waiting `/~/as` are given `307 Redirect`s to `/~/am` on the provided host.
486−
487−**Gifts given in response:** nice?
488−
489−## 4. Responses
490−
491−### 4.1 `[%nice ~]`, `[%mean ares]`, network acknowledgement
492−
493−A `%nice` is given upon receiving an [ames message](#gram), indicating succesful receipt. `%mean` is currently unused directly, but reserved for error conditions.
494−
495−## `[%sigh p=cage]`, inbound http response
496−
497−An HTTP response gets converted to the requested mark, or `%tang` in case of error.
498−
499−### 4.2 `[%thou httr]`, full HTTP response
500−
501−Most requests are served with one coherent response, consisting of
502−- `p=@ud`, an HTTP status code
503−- `q=mess`, response headers
504−- `r=(unit octs)`, an optional body
505−
506−### 4.3 `[%that httr]`, partial HTTP response
507−
508−[EventStream responses](#of-ixor) consist of multiple sequential chunks. Treated as `%thou`, except the request is kept open.
509−
510−### 4.4 `[%thar (unit octs)]`, partial HTTP body
511−
512−Complementing `%that`, `%thar` is a body chunk, containing an event. An empty `%thar` signals for the connection to be closed.
513−
514−Body chunks, besides `[1 '\0a']`(a heartbeat newline), are encoded from `even` events. The stem becomes the [`event` field](#eventsource), and the content, `data` lines.
515−
516−#### 4.4.1 `even`, event types
517−
518−There are three events that a [client subscription](#subs) will be given.
519−
520−- `[%news hash]` is a `%f` update, and contains the relevant dependency token.
521−- `[%mean [term path] ares]` is a sourced subscription error.
522−
523−## 5. Vane requests
524−
525−### 5.1 ``[%a %wont sock `[path *]`gram]``, outbound message
526−
527−The `%a` interface provides conveyance of [messages](#gram) over UDP.
528−
529−Signs a `%woot` upon message arrival.
530−
531−
532−All open [subscriptions](#of-ixor) require a "heartbeat" newline every `~s30`. When this fails to arrive, a complementary timer is set for `~m1`, after which the client is considered to have departed.
533−The `%b` timer interface is used to schedule the next such event, or cancel past scheduled ones when a connection closes.
534−
535−Signs a `%wake` upon timer activation.
536−
537−### 5.3 `[%f %wasp @uvI]`, dependency listen
538−
539−Knowledge of filesystem changes, requested by `/~/on` and `/~/in`, is requested the `%wasp` note. It contains the hash token which identifies a set of dependencies to query. Saved as a (live[live](#live)] request in case of cancellation when caused by `/~/on`.
540−
541−Signs a `%writ` upon change.
542−
543−### 5.4 `[%f %exec (unit silk)]`, functional transformations
544−
545−The `%f` interface converts [nouns](/docs/glossary/noun/) from one form to another. An empty unit represents cancellation.
546−
547−Signs a `%made` containing the computation result.
548−
549−The `silk`s used are as follows:
550−
551−### `[%cast %mime %boil mark beam [%web span ~]]`, file load
552−
553−The simplest functional request is the construction of a page. Saved as a [live](#live) request in case of cancellation.
554−- The `mark` is the request extension, defaulting to `%html`.
555−- A `beam`(path in `%clay`) is decoded from the request path.
556−- A `/web/<nyp ced quy>` virtual path is appended, span-encoding method, auth, and query string.
557−
558−### `[%cast mark %done ~ cage]`, convert
559−
560−This is used when communicating with apps, in both directions.
561−- Client messages are encoded as JSON objects, but can contain many different marks. Ones sent to non-`json.json` endpoints are `%cast` to he relevant mark, with a `cage` of `[%json p:!>(*json) jon]`, prior to being sent onwards to applications with `[%g %mess]`.
562−- Subscription responses also come in arbitrary marks, but are required to be sent as whichever mark an endpoint is subscribed to. They get `%cast` prior to being sent back as a `%that` EventSource segment.
563−
564−### 5.5 `%g`, app actions
565−
566−The end goal of many a userspace `hymn.hook` is to provide UI for a `%gall` app. To accommodate this, various functionality needs to be interfaced with.
567−
568−### `[%mess hapt ship cage]`, app message
569−
570−After a `/~/to` POST has been received, and possibly converted to the correct mark, it is sent to `%g` for processing. The `hapt` is the destination, the `ship` is the source, the `cage` is the marked message data.
571−
572−Signs a `%nice` or `%mean`, in userspace or upon crashing.
573−
574−### `[%show hapt ship path]`, app subscription
575−
576−An `/~/is` PUT, if not already registered, results in a new subscription. A request for such contains the destination `hapt`, requesting `ship`, and app-internal `path`.
577−
578−Signs a `%nice` on init, `%rush` on data, and a `%mean` in subscription termination.
579−
580−### `[%took hapt ship]`, %rush confirmation
581−
582−A `%took` must be sent to acknowledge the receipt of subscription data, which in this case occurs automatically.
583−
584−Causes no signs.
585−
586−### `[%nuke hapt $|(ship [ship path])]`, subscription cancel
587−
588−An `/~/is` DELETE is used to remove a subscription, and is converted straightforwardly to a `%nuke`. Additionally, when a client disconnects, all of its subscriptions are `%nuke`d to reflect their expiration.
589−
590−Signs an empty `%mean` for each open subscription that is closed.
591−
592−## 6. In-flight metadata
593−
594−Various state can be associated with requests, but not necessarily be returned in responses to them.
595−
596−### 6.1 `~`, dropthrough
597−
598−If the response should be sent statelessly further up the duct, the `wire` is empty. This is used in `%f` pure functional page generation.
599−
600−### 6.2 `[?(%y %n) ...]`, stability
601−
602−The first element of a [`%b` timer](#wait) path distinguishes between live(%y) and dying(%n) channels.
603−
604−### 6.3 `/of/[ixor]`, view
605−
606−Designates which stream to act upon. Present on `%b` timer cards.
607−
608−### 6.4 `/on/<deps>`
609−
610−Present on `%f` dependency news. Looked up in [the state](#bolo) to see if any response is necessary.
611−
612−### 6.5 `/to/<hasp>/<ship>`, app
613−
614−Present on `%f` translations of message marks
615−
616−### 6.6 `/is/[ixor]/{hasp path}`, subscription
617−
618−Subscription requests. Present on `%g` subscription requests, and `%f` translations of [`%rush` subscription data](#show).
619−
620−## 7. Vane responses
621−
622−The goal of requests is to cause some manner of result. Specifically,
623−
624−### 7.1 `[%a %woot ship coop]`, acknowledgement
625−
626−A [message](#mess) which has been acknowledged remotely.
627−
628−### 7.2 `[%b %wake ~]`, timer
629−
630−Timer activate. If this is a `%y` [timer](#wire-live), send a newline to each `/~/of/[oryx]`; if `%n` and the `oryx` still has no listeners, wipe its state/subscriptions.
631−
632−### 7.3 `[%f %news ~]`, dependency update
633−
634−This message signifies a `hash` has changed, and listeners to it should be updated. Results in [`%news` events](#even-news) to concerned streams, and [full responses](#thou) to relevant long-polls.
635−
636−### 7.4 `[%f %made (each bead (list tank))]`, compute result
637−
638−Further action depends on the [`wire`](#whir). It can:
639−- Be empty, designating direct request data, which is [served](#mime) back up the `duct`.
640−- Contain [app and requester identities](#wire-to), which designates an app message has been converted to the correct `mark`, and can now be [sent to the app](#mess) with an empty `wire`.
641−- Contain an `oryx`, app, and `path`, designating subscription data. If the subscription is active in the relevant `stem`, it is acknowledged with a `%took` and given as a [`%rush` event](#even-rush) to all listeners. Otherwise, the subscription is `%nuke`d.
642−
643−### 7.5 `%g`, applications
644−
645−The `%g` interface sends several responses.
646−
647−### `[%nice ~]` and `[%mean ares]`, acknowledgment
648−
649−These are given as a response to `%mess`, with an empty wire, and `%show`s, with a [subscription wire](#wire-is).
650−The former is [served](#mime) back to the requester(i.e. the remaining duct), and the latter returned to the client.
651−
652−#### 7.5 `[%rush cage]`, subscription data
653−
654−A `%rush` arrives on a [subscription wire](#wire-is), and is then sent [for conversion](#done) to the correct mark. An unexpected `%rush` is `%nuke`d.
655−
656−## 8. Server state
657−
658−There is a quantity of data that persists between events.
659−
660−### 8.1 Global
661−
662−- `path` the default path which is prepended to relative plain requests. Initialized to `/<our>`, the serving ship; this interprets the first element of requests as a desk, and injects a `case` of `0`.
663−- `(jar ship hart)` remembered hostnames in order of preference, made accessible through `.^`
664− + The default values(for self) are `http://<ship>.urbit.org:80` if not on a fake network, followed by `https://0.0.0.0:[port]`.
665−- `(jug deps (each duct oryx))`, `/~/on` and `/~/in` endpoints listening to `%c` updates.
666−- `(map duct live)`, inbound request state
667−- `(map ixor oryx)`, open `/~/of` streams.
668−- `(map oryx stem)`, open view state.
669−- `(map hole sink)`, session state.
670−- `(map hole ,[ship ?])`, foreign session names, along with their origin ships and whether they are authorized to act on our behalf.
671−
672−### 8.2 `live`, per-request state
673−
674−To honor request cancellations, each unserved request must track which effect it is causing.
675−+ `[%exec whir]` if it is a ford data request
676−+ `[%wasp (list @uvH)]` if it is a ford dependency poll
677−+ `[%xeno ship]` if this is a proxied request
678−+ `[%poll ixor]` if this is a session long-poll
679−
680−### 8.3 `sink`, per-session state
681−
682−Each `hole` has associated authentication state.
683−- `priv`, a random secret that verifies the session, stored in cookie.
684−- `[ship (set ship)]`, the `ship` a session is acting as and any others it has been authorized with.
685−- `(jug ship ,[path duct])`, authentication `/~/as` requests waiting on foreign ships.
686−- `(set oryx)`, views associated with this session. Dual of `hole` in `stem`.
687−
688−### 8.4 `stem`, per-view state
689−
690−Each `oryx` has active subscription state.
691−- `hole`, session in which this view resides. Dual of `(set oryx)` in `sink`.
692−- `ixor`, a cached hash of the `oryx` that is used as a subscription id, by the `/~/of` EventStream.
693−- `[,@u (map ,@u even)]`, queued [events](#even). Has a maximum size.
694−- `(unit ,[duct @u ?])`, http connection, its last received event, and whether it is a long-poll request.
695−- `(set deps)`, subscribed `/~/in` points. Mirrored in `bolo`.
696−- `(map ,[hasp path] mark)`, subscribed `/~/is` points
697−- `(que duct)`, where any `%nice`/`%mean
698−
699−## Appendix A: Glossary
700−
701−- An `oryx` is a CSRF token used for [authenticated requests](#auth)
702−- `mean.json` is a rendering of hoon `ares`: an error message formatted as `{fail:'type',mess:"Error message"}`
703−- `urb.js` is the standard client-side implementation of the `%eyre` protocols, normally found in `/=main=/lib`
704−- The act of "serving", refers to the wrapping of a `%mime` cage in an HTTP `200 Success` response, and errors or other marks being [sent to ford](#done) for conversion. Inside a `sign`, this conversion occurs along the same [`wire`](#wire); otherwise, the `wire` is [empty](#wire-drop).
705−
706−## Appendix B: EventSource
707−
708−UNIMPLEMENTED
709−
710−For more information, see <http://dev.w3.org/html5/eventsource/>
711−
712−An EventSource is a stream of events, encoded in a conceptually infinite `GET` request. Each event is formatted as
713−```
714− http
715− id: {number}
716− event: {type}
717− data: {contents}
718− data: {more-contents}
719−```
720−
721−Data lines are joined by ASCII `10` newline characters; multiple newlines signify separate events. The `id` is used in a `Last-Event-ID` HTTP request header upon reconnection.
arvo/eyre/using-eyre.mddeleted−230
@@ -1,230 +0,0 @@
1−+++
2−title = "Using Eyre"
3−description = "How to work with eyre from outside Urbit."
4−weight = 20
5−template = "doc.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−## Prerequisites
11−
12−You'll need a working development ship to follow along with this guide. It's
13−recommended that you set up a new "fakezod" on port 8080: Run this code,
14−substituting the appropriate path to your Urbit binary:
15−
16−```bash
17−/path/to/urbit -p 8080 -F zod
18−```
19−
20−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. For more information on this process, see our guide on [Environment Setup](@/docs/development/environment.md).
21−
22−## Authentication
23−
24−We'll authenticate with a code that can be retrieved from the dojo. You can run
25−`+code` in the dojo to obtain it, but a fakezod's code is always
26−`lidlut-tabwed-pillex-ridrup`.
27−
28−Run this code in your bash terminal (requires cURL):
29−
30−```bash
31−curl -i localhost:8080/~/login -X POST -d "password=lidlut-tabwed-pillex-ridrup"
32−```
33−Let's explain what this does:
34−
35− - `-i` displays the headers, so that you can see the cookie that gets sent
36− - `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.
37− - `-X POST` specifies that you are POSTing data, not GETting.
38− - `-d "password=lidlut-tabwed-pillex-ridrup"` specifies the code 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)
39−
40−You should see the following:
41−
42−```bash
43−HTTP/1.1 200 ok
44−Date: Sun, 01 Jan 2020 00:00:00 GMT
45−Connection: keep-alive
46−Server: urbit/vere-0.10.8
47−set-cookie: urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg; Path=/; Max-Age=604800
48−transfer-encoding: chunked
49−```
50−
51−The `Date` and `set-cookie` will be slightly different of course.
52−
53−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:
54−
55− - `urbauth` is a prefix that Eyre uses to check for presence of authentication
56− - `~zod` is the name of the ship you are logging in as
57− - `0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg` is the actual authentication token.
58−
59−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.
60−
61−## Interacting with Eyre
62−
63−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.
64−
65−Interacting with Urbit comprises two parts:
66−
67−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).
68−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/))
69−
70−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.
71−
72−### Creating a Channel
73−
74−For this example, we will use the following channel:
75−
76−```
77−http://localhost:8080/~/channel/1601844290-ae45b
78−```
79−
80−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.
81−
82−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.
83−
84−### Making Requests
85−
86−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.
87−
88−Let's look at the structure of a message by examining the most basic `hi` we will send.
89−
90−```js
91−{
92− 'id': 1, // Required. A sequential ID. Keep track of which messages you have sent.
93− 'action': 'poke', // Required. The action to take. poke is the most basic way of sending data, like HTTP POST
94− '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.
95− 'app': 'hood', // Required by poke. The Urbit app to which to send the data.
96− 'mark': 'helm-hi', // Required by poke. The "mark," or type, of data being sent.
97− 'json': 'Opening airlock' // Required by poke. The actual data being sent.
98−}
99−```
100−
101−Let's open our channel by sending the following request using cURL (**remember to change the cookie**):
102−
103−```bash
104−curl --header "Content-Type: application/json" \
105− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
106− --request PUT \
107− --data '[{"id":1,"action":"poke","ship":"zod","app":"hood","mark":"helm-hi","json":"Opening airlock"}]' \
108− http://localhost:8080/~/channel/1601844290-ae45b
109−```
110−
111−If you switch to your fakezod's dojo, you should see `< ~zod: Opening airlock`.
112−
113−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.
114−
115−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.
116−
117−Let's look at how to receive events from Urbit.
118−
119−### Subscribing to Events
120−
121−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`:
122−
123−```js
124−{
125− 'id': 2, // Required. This is the next message we are sending, so we give it the next ID.
126− 'action': 'subscribe', // Required.
127− 'ship': 'zod', // Required by subscribe.
128− '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.
129− '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.
130−}
131−```
132−
133−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."
134−
135−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:
136−
137−```js
138−const eventSource = new EventSource('http://localhost:8080/~/channel/1601844290-ae45b', {
139− withCredentials: true // Required, sends your cookie
140−});
141−
142−eventSource.addEventListener('message', function (event) {
143− ack(Number(event.lastEventId)); // See section below
144− const payload = JSON.parse(event.data); // Data is sent in JSON format
145− payload.id === event.lastEventId; // The SSE spec includes event IDs. This information is duplicated in the payload.
146− const data = payload.json; // Beyond this, the actual data will vary between apps
147−});
148−
149−eventSource.addEventListener('error', function (event) {
150− handleError(event);
151−});
152−
153−```
154−
155−### Handling Received Events
156−
157−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:
158−
159−```js
160−{
161− 'id': 3, // Required. Picking up where we left off
162− 'action': 'ack', // Required.
163− 'event-id': 15, // Required by ack. Whichever SSE of which you are acknowledging receipt
164−}
165−```
166−
167−### Unsubscribing from Events
168−
169−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:
170−
171−```javascript
172−{
173− 'id': 4, // Required. We always increment the ID as we send messages.
174− 'action': 'unsubscribe', // Required.
175− 'subscription': 2 // Required by unsubscribe. This corresponds to the id of a subscribe message sent earlier.
176−}
177−```
178−
179−### Deleting a Channel
180−
181−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.
182−
183−```javascript
184−{
185− 'id': 5, // Required.
186− 'action': 'delete' // Required.
187−}
188−```
189−
190−## Other Operations
191−
192−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`.
193−
194−### Scrying
195−
196−Scrying lets you see what an app has exposed at a particular path. It does not manipulate state.
197−
198−It takes the form `{url}/~/scry/{app}{path}.{mark}`
199−
200− Let's get the base hash of our fakezod in the same way that Landscape does it.
201−
202−```bash
203−curl --header "Content-Type: application/json" \
204− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
205− --request GET \
206− http://localhost:8080/~/scry/file-server/clay/base/hash.json
207−```
208−
209−Note the use of a `GET` request.
210−
211−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.
212−
213−Scry will fail with a 500 or return a 404 if no data is found.
214−
215−### Running Threads with Spider
216−
217−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.
218−
219−It takes the form `{url}/spider/{inputMark}/{threadname}/{outputmark}.json`
220−
221−This should be considered an advanced technique, but the basic structure of a request can be seen here:
222−
223−```bash
224−curl --header "Content-Type: application/json" \
225− --cookie "urbauth-~zod=0v3.fvaqc.nnjda.vude1.vb5l6.kmjmg" \
226− --request POST \
227− --data '[{"foo": "bar"}]' \
228− http://localhost:8080/spider/graph-view-action/graph-create/json.json
229−
230−```
arvo/ford/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Ford"
3−weight = 60
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/gall/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Gall"
3−weight = 70
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/gall/overview.mddeleted−11
@@ -1,11 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−+++
6−
7−**Gall** is the application-management [vane](../vane). Userspace apps – daemons, really – are started, stopped, and sandboxed by Gall. Gall provides developers with a consistent interface for connecting their app to [Arvo](../arvo). It allows applications and other vanes to send messages to applications and subscribe to data streams. Messages coming into Gall are routed to the intended application, and the response comes back along the same route. If the intended target is on another [ship](../ship), Gall will route it behind the scenes through [Ames](../ames) to the other ship.
8−
9−Gall is located at `/home/sys/vane/gall.hoon` within Arvo.
10−
11−For more details, see the [userspace](@/docs/userspace/gall/gall.md) section.
arvo/iris/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Iris"
3−weight = 80
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/iris/iris-api.mddeleted−191
@@ -1,191 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 10
4−template = "doc.html"
5−+++
6−
7−In this document we describe the public interface for Iris. Namely, we describe
8−each `task` that Iris can be `%pass`ed, and which `gift`(s) Iris can `%give` in
9−return.
10−
11−## Returns to Unix
12−
13−Much of what Iris does is translating `task`s from other vanes into `card`s
14−meant for Unix via the `%request` and `%cancel-request` `task`s. What this means in practice is that Iris may be `%pass`ed a
15−`task` via some `duct`, which in response Iris then `%give`s a `gift` to Unix
16−via another `duct`. This `gift` will actually be a response to the `%born`
17−`task` that Iris was `%pass`ed when the Urbit was resumed, which came along the
18−duct to Unix.
19−
20−
21−## Tasks
22−
23−### `%born`
24−
25−Each time you start your Urbit the Arvo kernel calls the `%born` `task` for
26−Iris. This causes Iris to cancel any outstanding http requests and resets all
27−connection states.
28−
29−#### Accepts
30−
31−```hoon
32−[ ~ ]
33−```
34−
35−#### Returns
36−
37−In response to a `%born` `task` Iris `give`s a `%http-response %cancel` `gift`
38−to each outstanding connection.
39−
40−
41−### `%cancel-request`
42−
43−This `task` cancels a previous fetch. Iris knows which request is meant based on the
44−`duct` that the `task` comes on.
45−
46− We note that `%cancel-request` is also a `gift` that Iris can `%give`.
47−
48−#### Accepts
49−
50−```hoon
51−[ ~ ]
52−```
53−
54−#### Returns
55−
56−```hoon
57−[%cancel-request id=@ud]
58−```
59−Receiving this `task` causes Iris to `%give`s a `%cancel-request` `gift` to Unix,
60−which then cancels the request in the runtime. See [Returns to Unix](#returns-to-unix).
61−
62−`id` is obtained via a `(map duct @ud)`, with the `duct` corresponding to one along
63−which the `%cancel-request` `task` came with.
64−
65−
66−### `%crud`
67−
68−`%crud` is called whenever an error involving Iris occurs. It produces a crash
69−report in response.
70−
71−#### Accepts
72−
73−```hoon
74−[p=@tas q=(list tank)]
75−```
76−
77−`p` is the type of error, `q` is the error message.
78−
79−#### Returns
80−
81−Iris does not `%give` a `gift` in response to a `%crud` `task`, but it does
82−`%slip` Dill a `%flog` `task` instructing it to print the error.
83−
84−
85−### `%receive`
86−
87−The `%receive` `task` is used to receive a response from Unix to an `http-request` that
88−was made.
89−
90−#### Accepts
91−
92−```hoon
93−[id=@ud =http-event:http]
94−```
95−
96−`id` is the identification number assigned by Iris to the http connection under
97−consideration. `http-event` is a packet that contains a header and data.
98−
99−#### Returns
100−
101−The response depends on what kind of packet `http-event` is: `%start`,
102−`%continue`, or `%cancel` and whether the `complete` flag is `%.y` or `%.n`.
103−
104−If the packet says to `%start` or `%continue` and `complete=%.n`, Iris will `%give` a
105−`%http-response %progress` `gift`.
106−
107−If the packet says to `%start` or `%continue` and `complete=%.y`, Iris will
108−`%give` a `%http-response %finished` `gift`.
109−
110−If the packet says to `%cancel`, Iris will `%give` a `%http-response %cancel`
111−`gift` in return. The `complete` flag is unused here.
112−
113−
114−### `%request`
115−
116−`%request` is used to fetch a remote resource. `%request` is also a `gift` Iris
117−can `%give`.
118−
119−#### Accepts
120−
121−```hoon
122−[=request:http =outbound-config]
123−```
124−
125−A `$request` consists of the following:
126− - `=method`, the http method, which is one of `CONNECT`, `DELETE`, `GET`,
127− `HEAD`, `OPTIONS`, `POST`, `PUT`, and `TRACE`.
128− - `url=@t`, the URL being requested
129− - `=header-list`, a list of headers to pass with the request,
130− - `body=(unit octs)`, optional data to include in the request.
131−
132− A `$outbound-config` contains the number of redirects and retries that Iris
133− will attempt. By default this is 5 redirects (the recommended limit for the
134− http standard) and 3 retries.
135−
136−#### Returns
137−
138−```hoon
139−[id=@ud request=request:http]
140−```
141−Iris will `%give` a `%request` `gift` to Unix in response to a `%request`
142−`task`. See [Returns to Unix](#returns-to-unix). This `gift`
143−contains the `request` in the original `task` as well as the ID number assigned
144−by Iris for that particular http connection, which is extracted from the input `task`.
145−
146−
147−### `%trim`
148−
149−This `task` is sent by the interpreter to free up memory. It has no effect on Iris.
150−
151−#### Accepts
152−
153−```hoon
154−[ ~ ]
155−```
156−
157−#### Returns
158−
159−This `task` returns no `gift`s.
160−
161−
162−### `%vega`
163−
164−This `task` informs the vane that the kernel has been upgraded. Iris does not do
165−anything in response to this.
166−
167−#### Accepts
168−
169−```hoon
170−[ ~ ]
171−```
172−
173−#### Returns
174−
175−This `task` returns no `gift`s.
176−
177−
178−### `%wegh`
179−
180−This `task` asks Iris to product a memory usage report.
181−
182−#### Accepts
183−
184−This `task` has no arguments.
185−
186−#### Returns
187−
188−When Iris is `%pass`ed this `task`, it will `%give` a `%mass` `gift` in response
189−containing Iris' current memory usage.
190−
191−
arvo/jael/_index.mddeleted−7
@@ -1,7 +0,0 @@
1−+++
2−title = "Jael"
3−weight = 90
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
arvo/jael/jael-api.mddeleted−393
@@ -1,393 +0,0 @@
1−+++
2−title = "API Reference"
3−weight = 10
4−template = "doc.html"
5−+++
6−
7−In this document we describe the public interface for Jael. Namely, we describe
8−each `task` that Jael can be `%pass`ed, and which `gift`(s) Jael can `%give` in return.
9−
10−
11−## Tasks
12−
13−### `%dawn`
14−
15−This `task` is called once per ship during the vane initialization
16−phase immediately following the beginning of the [adult
17−stage](@/docs/arvo/overview.md#structural-interface-core). This `task` is `%pass`ed to Jael by Dill, as Dill is the first vane to be loaded for
18−technical reasons, though we consider Jael to be the true "first" vane. This
19−`task` is only used for ships that will join the Ames network - fake ships (i.e.
20−made with `./urbit -F zod`) use the `%fake` `task` instead.
21−
22−`%dawn` is used to perform a sequence of initialization tasks related to saving
23−information about Azimuth and the Ames network and booting other vanes for the first time. Upon
24−receipt of a `%dawn` `task`, Jael will:
25− - record the Ethereum block the public key is registered to,
26− - record the URL of the Ethereum node used,
27− - save the signature of the parent planet (if the ship is a moon),
28− - load the initial public and private keys for the ship,
29− - set the DNS suffix(es) used by the network (currently just `arvo.network`),
30− - save the public keys of all galaxies,
31− - set Jael to subscribe to `%azimuth-tracker`,
32− - `%slip` a `%init` `task` to Ames, Clay, Gall, Dill, and Eyre, and `%give` an `%init`
33−`gift` to Arvo, which then informs Unix that the initialization process has concluded.
34−
35−#### Accepts
36−
37−`%dawn` accepts a `dawn-event`:
38−
39−```hoon
40− +$ dawn-event
41− $: =seed
42− spon=(list [=ship point:azimuth-types])
43− czar=(map ship [=rift =life =pass])
44− turf=(list turf)
45− bloq=@ud
46− node=(unit purl:eyre)
47− ==
48−```
49−
50−The `seed` is `[who=ship lyf=life key=ring sig=(unit oath:pki)]`. `who` is the
51−`@p` of the ship running the `task`, `lyf` is the current ship key revision,
52−`key` is the ship's private key, and `sig` is the signature of the ship's parent
53−planet if the ship is moon and `[~]` otherwise.
54−
55−`spon` is a `list` of ships and their `point`s in the ship's sponsorship chain,
56−all the way to the galaxy level. `point:azimuth-types` contains all Azimuth
57−related data and can be found in `zuse.hoon`.
58−
59−`czar` is a map from each galaxy's `@p` to its `rift`, `life`, and public key (`pass`).
60−
61−`turf` is a `list` of DNS suffixes used by the Ames network, which for now is
62−just `arvo.network`.
63−
64−`bloq` is the number of the Ethereum block in which the ship registered its keys
65−with the Azimuth smart contract.
66−
67−`node` is the URL of the Ethereum node used to register the ship's keys with Azimuth.
68−
69−#### Returns
70−
71−Jael `%give`s an `%init` `gift` to Unix. This occurs after the Dill `%slip`
72−init.
73−
74−#### Slips
75−
76−Jael `%slip`s `%init` `task`s to each of Eyre, Dill, Gall, Clay, and Ames, in
77−that order.
78−
79−
80−### `%fake`
81−
82−This `task` is used instead of `%dawn` when creating a fake ship via the `-F`
83−flag when calling the Urbit binary. It performs a subset of the actions that
84−`%dawn` performs, modified to accommodate the fake ship.
85−
86−`%fake` endows the ship with a private key and a public key deterministically derived from the
87−ship's `@p`. It sets `fak.own.pki` to `%.y`, which is the bit that determines
88−whether or not a ship is fake. Other parts of the Jael state, such as the
89−sponsorship chain and galaxy public keys are left at their bunted values.
90−
91−#### Accepts
92−
93−```hoon
94−[=ship]
95−```
96−`ship` is the `@p` of the fake ship being created.
97−
98−#### Returns
99−
100−Jael `%give`s a `%init` `gift` to Unix.
101−
102−#### Slips
103−
104−In response to a `%fake` `task`, Jael `%slip`s a `%init` `task` to each of Eyre, Dill, Gall,
105−Clay, and Ames, in that order.
106−
107−
108−### `%listen`
109−
110−Sets the source that the public keys for a set of `ship`s should be obtained
111−from. This can either be a Gall app that communicates with an Ethereum node such
112−as `%azimuth-tracker`, as in the case for galaxies, stars,
113−and planets, or a ship, as in the case of a moon or comet.
114−
115−After setting the source, Jael will then subscribe to the source for updates on
116−public keys for the given ships.
117−
118−
119−#### Accepts
120−
121−```hoon
122−[whos=(set ship) =source]
123−```
124−
125−`whos` is the set of ships whose key data source is to be altered. `source` is
126−`(each ship term)`, where `term` will ultimately be treated as a handle for a
127−Gall app.
128−
129−A `%listen` `task` with empty `whos` will set the default source to `source`.
130−This is the source used for all ships unless otherwise specified.
131−
132−When the `source` is a `term`, Jael looks into its state to find what source has
133−been previously assigned to that `term` and will henceforth obtain public keys for
134−ships in `(set ship)` from there. In practice, this is always
135−`%azimuth-tracker`, but the ability to use other sources is present.
136−
137−When the `source` is a ship, Jael will obtain public keys for ships in `(set ship)` from
138−the given ship. By default, the `source` for a moon will be the planet that
139−spawned that moon, and the `source` for a comet will be the comet itself.
140−
141−#### Returns
142−
143−This `task` returns no `gift`s.
144−
145−#### Passes
146−
147−If the `source` is a `term`, Jael will `%pass` a `%deal` `task` to Gall asking to
148−`%watch` the app given by `source` at path `/`.
149−
150−If the `source` is a `ship`, Jael will `%pass` a `%plea` `task` to Ames wrapping
151−a `%public-keys` `task` intended for Jael on the `ship` specified by `source`.
152−
153−
154−### `%meet`
155−
156−This `task` is deprecated and does not perform any actions.
157−
158−#### Accepts
159−
160−```hoon
161−[=ship =life =pass]
162−```
163−
164−#### Returns
165−
166−This `task` returns no `gift`s.
167−
168−
169−### `%moon`
170−
171−This `task` sets the public keys of a moon.
172−
173−#### Accepts
174−
175−```hoon
176−[=ship =udiff:point]
177−```
178−
179−The `ship` is the `@p` of the moon. The `task` will be a no-op if the `@p` is not that
180−of a moon, or if the moon does not belong to the ship.
181−
182−`udiff:point` contains the new public keys to be stored for the moon.
183−
184−#### Returns
185−
186−This `task` returns no `gift`s.
187−
188−
189−### `%nuke`
190−
191−This `task` cancels subscriptions to Jael's state from a given set of `ship`s.
192−This `task` works differently depending on whether the `task` originated locally
193−or remotely.
194−
195−#### Accepts
196−
197−```hoon
198−[whos=(set ship)]
199−```
200−`whos` is the `set` of `ship`s from which subscriptions are to be canceled.
201−
202−#### Returns
203−
204−This `task` returns no `gift`s.
205−
206−
207−### `%plea`
208−
209−This `task` is `%pass`ed to Jael from Ames. `%plea`s are wrappers for `task`s
210−that originate from a remote source, as the `%plea` pattern
211−is used to extend the `%pass`/`%give` semantics over the Ames network. Jael
212−attempts to perform the `task` wrapped in the `%plea`.
213−
214−Jael accepts two kinds of `%plea`s: [`%nuke`](#nuke) and
215−[`%public-keys`](#public-keys) and will crash if passed anything else. See the
216−relevant entries to learn how Jael responds to these.
217−
218−#### Accepts
219−
220−```hoon
221−[=ship =plea:ames]
222−```
223−`ship` is the origin of the plea, and `plea:ames` is `[vane=@tas =path
224−payload=*]`. Here, `vane=%j`, `path` is the internal route on the receiving ship, and `payload` is either a `%nuke` or
225−a `%public-keys` `task`.
226−
227−#### Returns
228−
229−Jael `%give`s a `%done` `gift` in response to a `%plea` `task`.
230−
231−#### Passes
232−
233−Jael `%pass`es itself the wrapped `task`.
234−
235−
236−### `%private-keys`
237−
238−This `task` creates a subscription to the private keys kept by Jael.
239−
240−We note that there are two `+private-keys` arms in Jael - one located in the
241−`+feed` core and the other located in the `+feel` core. This `task` calls the
242−arm in the `+feed` core.
243−
244−#### Accepts
245−
246−```hoon
247−[~]
248−```
249−
250−#### Returns
251−
252−```hoon
253−[%private-keys =life vein=(map life ring)]
254−```
255−
256−In response to a `%private-keys` `task`, Jael `%give`s a `%private-keys` `gift`.
257−`life=@ud` is the current `life` of the ship, and `vein` is a `map` from
258−`life`s to `ring`s that keeps track of all `life`-`ring` pairs throughout the
259−history of the ship.
260−
261−
262−### `%public-keys`
263−
264−This `task` creates a subscription for the callee to a selection of the public
265−keys kept by Jael. This `task` can originate locally or remotely.
266−
267−#### Accepts
268−
269−```hoon
270−[ships=(set ship)]
271−```
272−`ships` is the `set` of `ship`s whos' public keys are being subscribed to.
273−
274−#### Returns
275−
276−```hoon
277−[%public-keys =public-keys-result]
278−```
279−If the `task` originated locally, Jael `%give`s a `%public-keys` `gift` in
280−response. If it originated remotely, Jael `%give`s a `%boon` `gift` to back
281−to Ames wrapping a `%public-keys` `gift`.
282−
283−A `$public-keys-result` is the following.
284−```hoon
285− +$ public-keys-result
286− $% [%full points=(map ship point)]
287− [%diff who=ship =diff:point]
288− [%breach who=ship]
289−```
290−The first time Jael receives a `%public-keys` `task` from a ship it will return
291−a `[%public-keys-result %full]` `gift`, which contains all information about ships and
292−their associated points that Jael knows. Subsequent updates will typically be
293−`[%public-keys-result %diff]`, which tells the caller what has changed
294−since last time they sent a `%public-keys` `task`, and `[%public-keys-result
295−%breach]`, which informs the caller of ship breaches.
296−
297−
298−### `%rekey`
299−
300−This `task` updates the ship's private keys.
301−
302−#### Accepts
303−
304−```hoon
305−[=life =ring]
306−```
307−
308−`life` is a `@ud` that is the new ship key revision number. `ring` is a `@` that is the new private key.
309−
310−#### Returns
311−
312−```hoon
313−[%private-keys =life vein=(map life ring)]
314−```
315−
316−In response to a `%rekey` `task`, Jael `%give`s a `%private-keys` `gift`. `life`
317−is the new `life` given in the original `task`, and `vein` is a `map` from
318−`life`s to `ring`s that keeps track of all `life`-`ring` pairs throughout the
319−history of the ship.
320−
321−
322−### `%trim`
323−
324−This `task` is sent by the interpreter in order to free up memory.
325− This `task` is empty for Jael, since it is not a good idea to forget your
326− private keys and other cryptographic data.
327−
328−#### Accepts
329−
330−```hoon
331−[p=@ud]
332−```
333−This argument is unused by Jael.
334−
335−#### Returns
336−
337−This task returns nothing.
338−
339−
340−
341−### `%turf`
342−
343−This `task` is a request for Jael to provide its list of `turf`s, e.g. DNS
344−suffixes for the Ames network. Currently `arvo.network` is the only `turf` in use.
345−
346−#### Accepts
347−
348−```hoon
349−[~]
350−```
351−
352−#### Returns
353−
354−```hoon
355−[%turn tuf.own.pki]
356−```
357−
358−Jael `%give`s a `%turf` `gift` in response to a `%turf` `task`. `tuf.own.pki` is
359−a `(list turf)`, which is Jael's list of `turf`s.
360−
361−
362−### `%vega`
363−
364−`%vega` is called whenever the kernel is updated. Jael currently does not do
365−anything in response to this.
366−
367−#### Accepts
368−
369−`%vega` takes no arguments.
370−
371−#### Returns
372−
373−This `task` returns no `gift`s.
374−
375−
376−
377−### `%wegh`
378−
379−This `task` is a request to Jael to produce a memory usage report.
380−
381−#### Accepts
382−
383−This `task` has no arguments.
384−
385−#### Returns
386−
387−In response to this `task,` Jael `%give`s a `%mass` `gift` containing Ames'
388−current memory usage.
389−
390−
391−
392−
393−
arvo/overview.mddeleted−577
@@ -1,577 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 1
4−aliases = ["/docs/learn/arvo/arvo/"]
5−template = "doc.html"
6−+++
7−
8−Arvo, also called Urbit OS, is our operating system.
9−
10−# Introduction
11−
12−This article is intended to provide a thorough summary of all of the most
13−important aspects of the Arvo kernel and how this functionality gives life to
14−the ambitions of the Urbit platform. We work on two levels: a conceptual level
15−that should be useful to anybody interested in how Arvo works, and a more
16−technical level intended for those that intend to write software for Urbit.
17−
18−The [Urbit white paper](https://media.urbit.org/whitepaper.pdf) is a good
19−companion to this document, and some segments are direct quotes or paraphrases, but it should be noted that some parts of it are now either out of date or not yet implemented.
20−
21−## Prerequisites
22−
23−The conceptual section titled [What is Arvo?](#what-is-arvo-) can be understood
24−without knowing Hoon, the Urbit programming language. The technical section
25−titled [The kernel](#the-kernel) will require Chapter One of the [Hoon
26−tutorial](@/docs/hoon/hoon-school/_index.md) for full understanding, and some
27−material from Chapter Two will be helpful as well. At the bare minimum, we
28−presume that the reader has read through the [Technical
29−Overview](@/docs/system-overview/_index.md).
30−
31−We also suggest to the reader to peruse the [glossary](@/docs/glossary/_index.md) before diving into this article. It will provide the initial scaffolding that you will be able to gradually fill in as you read this article and go deeper into the alternate universe of computing that is Urbit.
32−
33−
34−# Table of Contents
35−
36−- [What is Arvo?](#what-is-arvo)
37− * [An operating function](#an-operating-function)
38− + [Determinism](#determinism)
39− + [Event log](#event-log)
40− * [Solid state interpreter](#solid-state-interpreter)
41− + [Over-the-air updates](#over-the-air-updates)
42− + [ACID Database](#acid-database)
43− + [Single-level store](#single-level-store)
44− + [Non-preemptive](#non-preemptive)
45−- [The kernel](#the-kernel)
46− * [Overall structure](#overall-structure)
47− + [Formal interface](#formal-interface)
48− + [Types](#types)
49− + [Arvo cores](#arvo-cores)
50− * [The state](#the-state)
51− * [Vanes](#vanes)
52−
53−# What is Arvo?
54−
55−Arvo is a [non-preemptive](#non-preemptive)
56−operating system purposefully built to create a new, peer-to-peer internet
57−whereby users own and manage their own data. Despite being an operating system,
58−Arvo does not replace Windows, Mac OS, or Linux. It is better to think of the
59−user experience of Arvo as being closer to that of a web browser despite being a
60−fully fledged OS. As such, Arvo is generally run inside a virtual machine, though in theory it could be run on bare metal.
61−
62−Urbit is a “browser for the server side”; it replaces multiple developer-hosted web services on multiple foreign servers, with multiple self-hosted applications on one personal server. Every architectural decision for Arvo (and indeed, the entire Urbit stack) was made with this singular goal in mind. Throughout this document, we connect the various concepts underlying Arvo with this overarching goal.
63−
64−Arvo is designed to avoid the usual state of complex event networks: event spaghetti. We keep track of every event's cause so that we have a clear causal chain for every computation. At the bottom of every chain is a Unix I/O event, such as a network request, terminal input, file sync, or timer event. We push every step in the path the request takes onto the chain until we get to the terminal cause of the computation. Then we use this causal stack to route results back to the caller.
65−
66−Unlike any other popular operating system, it is possible for a single human to understand every aspect of Arvo due to its compact size. The entire Urbit stack is around 30,000 lines of code, while the Arvo kernel is only about 1,000 lines of code. We strive for a small codebase because the difficulty in administering a system is roughly proportional to the size of its code base.
67−
68−## An operating function
69−
70−Arvo is the world's first _purely functional_ operating system, and as such it may reasonably be called an _operating function_. The importance of understanding this design choice and its relevance to the overarching goal cannot be understated. If you knew only a single thing about Arvo, let it be this.
71−
72−This means two things: one is that the there is a notion of _state_ for the operating system, and that the current state is a pure function of the [event log](#event-log), which is a chronological record of every action the operating system has ever performed. A _pure function_ is a function that always produces the same output given the same input. Another way to put this is to say that Arvo is _deterministic_. Other operating systems are not deterministic for a number of reasons, but one simple reasons is because they allow programs to alter global variables that then affect the operation of other programs.
73−
74−In mathematical terms, one may think of Arvo as being given by a transition function _T_:
75−
76−```
77−T: (State, Input) -> (State, Output).
78−```
79−
80−In practice, _T_ is implemented by the `+poke` [arm](/docs/glossary/arm/) of the Arvo kernel, which is described in more detail in the [kernel section](#the-kernel). In theoretical terms, it may be more practical to think of Arvo as being defined by a _lifecycle function_ we denote here by _L_:
81−
82−```
83−L: History -> State.
84−```
85−
86−Which perspective is more fruitful depends on the problem being considered.
87−
88−### Determinism
89−
90−We consider Arvo to be deterministic at a high level. By that we mean that it is
91−stacked on top of a frozen instruction set known as Nock. Frozen instruction
92−sets are a new idea for an operating system, but not for computing in general.
93−For instance, the CPU instruction sets such as
94−[x86-64](https://en.wikipedia.org/wiki/X86-64v) are frozen at the level of the
95−chip. A given operating system may be adapted to run on more than one CPU
96−instruction set, we merely freeze the instruction set at a higher level in order
97−to enable deterministic computation.
98−
99−Arvo handles nondeterminism in an interesting way. Deciding whether or not to
100−halt a computation that could potentially last forever becomes a heuristic
101−decision that is akin to dropping a packet. Thus it behooves one to think of
102−Arvo as being a stateful packet transceiver rather than an ordinary computer - events
103−are never guaranteed to complete, even if one can prove that the computation
104−would eventually terminate. We elaborate on this in the [solid state
105−interpreter](#solid-state-intrepeter) section.
106−
107−Because Arvo is run on a VM, nondeterministic information such as the stack
108−trace of an infinite loop that was entered into may be obtained. This is
109−possible because while Arvo may be unable to obtain that information, the
110−interpreter beneath does and can inject that information back into the event log.
111−
112−Being deterministic at a high level enables many
113−things that are out of reach of any other operating system. For
114−instance, we are able to do [over-the-air](#over-the-air-updates) (OTA) updates,
115−which allows software updates to be implemented across the network without
116−needing to worry whether it won't work on someone's ship, since Arvo is an
117−[interpreter](#solid-state-intrepeter) that can accept source code to
118−update itself instead of requiring a pre-compiled binary. This essential
119−property is why Urbit is able to act as a personal server while having
120−a user experience as accessible as a browser.
121−
122−### Event log
123−
124−The formal state of an Arvo instance is an event history, as a linked list of [nouns](/docs/glossary/noun/) from first to last. The history starts with a bootstrap sequence that delivers Arvo itself, first as an inscrutable kernel, then as the self-compiling source for that kernel. After booting, we break symmetry by delivering identity and entropy. The rest of the log is actual input.
125−
126−The Arvo event log is a list of every action ever performed on your ship that
127−lead up to the current state. In principle, this event log is maintained by the
128−[Nock runtime environment](@/docs/vere/_index.md), but in practice
129−event logs become too long over time to keep, as the event log has a size of
130−O(n) where n is the number of events. Thus it is our intention to
131−implement a feature whereby periodic snapshots of the state of Arvo are taken
132−and the log up to that state is pruned. This is currently unnecessary and thus
133−this feature has not been prioritized.
134−
135−The beginning of the event log starting from the very first time a ship is
136−booted up until the kernel is compiled and identity and entropy are created is a
137−special portion of the Arvo lifecycle known as the _larval stage_. We describe
138−the larval stage in more detail in the [larval stage](#larval-stage-core) section.
139−
140−More information on the structure of the Arvo event log and the Arvo state is given in the section on [the kernel](#the-kernel).
141−
142−
143−
144−## Solid state interpreter
145−
146−Arvo is a _solid state interpreter_. In this section we describe what is meant
147−by this new term, and how this behavior derives from the fact that Arvo is an [ACID database](#acid-database) and a [single-level store](#single-level-store).
148−
149−In computer science, an _interpreter_ is a program that directly executes
150−instructions written in some human-understandable programming or scripting
151−language, rather than requiring the code to first be compiled into a machine
152−language. Arvo is an interpreter, which is important for us since it allows us
153−to perform deterministic [over-the-air updates](#over-the-air-updates) by the
154−direct transfer of raw source code.
155−
156−To understand what we mean by _solid state_ interpreter, consider the operation of a solid state hard drive when a computer shuts down or loses power. Data written to an SSD is permanent unless otherwise deleted - loss of power may leave some partially written data, but nothing is ever lost. Thus, the state of an SDD can be considered to be equivalent to the data that it contains. That is to say, you do not need to know anything about the system which is utilizing the SSD to know everything there is to know about the SSD. There is no notion of "rebooting" a SSD - it simply stores data, and when power is restored to it, it is in exactly the same state as it was when power was lost.
157−
158−Contrast this with other popular operating systems, such as Windows, Mac, or Linux. The state of the operating system is something that crucially depends on having a constant power supply because much of the state of the operating system is stored in RAM, which is volatile. When you reboot your computer or suddenly lose power, any information stored in RAM is lost. Modern operating systems do mitigate this loss of information to some extent. For instance, it may remember what applications you were running at the time power was lost and try to restore them. Particularly durable programs may go as far as writing their state to disk every few seconds so that only very minimal information can be lost in a power outage. However, this is not the default behavior, and indeed if it were then they would be so slow as to be unusable, as you would effectively be using your hard disk as the RAM.
159−
160−How Arvo handles loss of power is closer to that of an SSD. Since it is an [ACID database](#acid-database) and a [single-level store](#single-level-store), a sudden loss of power have no effect on the state of the operating system. When you boot your ship back up it will be exactly as it was before the failure. Your information can never be lost, and because it was designed from the ground up to behave in this fashion, it does not suffer significant slowdown by persisting all data in this manner as would be the case if your typical operating system utilized its hard disk as RAM.
161−
162−Another way to describe a solid state interpreter is to think of it as a
163−stateful packet transceiver. Imagine
164−it as a chip. Plug this chip into power and network; packets go in and
165−out, sometimes changing its state. The chip never loses data and has
166−no concept of a reboot; every packet is an [ACID transaction](#acid-database).
167−
168−
169−### Over-the-air updates
170−
171−Arvo can hotpatch any other semantics at any layer in the system (apps, vanes, Arvo or Hoon itself) with automatic over-the-air updates.
172−
173−Typically, updates to an operating system are given via a pre-compiled binary,
174−which is why some updates will work on some systems but not on others where the
175−hardware and environment may differ. This is not so on Arvo - because it is an
176−[interpreter](#solid-state-interpreter), Arvo may update itself by receiving
177−source code from your sponsor over [Ames](@/docs/arvo/ames/ames.md), our
178−network. As Hoon compiles down to Nock, which is an axiomatic representation of
179−a deterministic computer, this code is guaranteed to run identically on your machine as it
180−would on anybody else's.
181−
182−Some subtleties regarding types arise when handling OTA updates, since they can
183−potentially alter the type system. Put more concretely, the type of `type` may
184−be updated. In that case, the update is an untyped Nock formula from the
185−perspective of the old kernel, but ordinary typed Hoon code from the perspective of
186−the new kernel. Besides this one detail, the only functionality of the Arvo
187−kernel proper that is untyped are its interactions with the Unix runtime.
188−
189−### ACID Database
190−
191−In the client-server model, data is stored on the server and thus reliable and efficient databases are an integral part of server architecture. This is not quite so true for the client - a user may be expected to reboot their machine in the middle of a computation, alter or destroy their data, never make backups or perform version control, etc. In other words, client systems like your personal computer or smart phone are not well suited to act as databases.
192−
193−In order to dismantle the client-server model and build a peer-to-peer internet, we need the robustness of modern database servers in the hands of the users. Thus the Arvo operating system itself must have all of the properties of a reliable database.
194−
195−Database theory studies in precise terms the possible properties of anything that could be considered to be a database. In this context, Arvo has the properties of an [ACID database](https://en.wikipedia.org/wiki/ACID), and the Ames network could be thought of as network of such databases. ACID stands for _atomicity_, _consistency_, _isolation_, and _durability_. We review here how Arvo satisfies these properties.
196−
197− - Atomicity: Events in Arvo are _atomic_, meaning that they either succeed completely or fail completely. In other words, there are no transient periods in which something like a power failure will leave the operating system in an invalid state. When an event occurs in Arvo, e.g. [the kernel](#the-kernel) is `poke`d, the effects of an event are computed, the event is [persisted](https://en.wikipedia.org/wiki/Persistence_(computer_science)) by writing it to the event log, and only then are the actual effects applied.
198−
199− - Consistency: Every possible update to the database puts it into another valid state. Given that Arvo is purely functional, this is easier to accomplish than it would be in an imperative setting.
200−
201− - Isolation: Transactions in databases often happen concurrently, and isolation
202− ensures that the transactions occur as if they were performed sequentially,
203− making it so that their effects are isolated from one another. Arvo ensures
204− this simply by the fact that it only ever performs events sequentially. While
205− Arvo
206− transactions are sequential and performed by the daemon, persistence and effect application are performed
207− in parallel by the worker; see [worker and
208− daemon](@/docs/vere/_index.md) for more detail.
209−
210− - Durability: Completed transactions will survive permanently. In other words,
211− since the event log is stored on disk, if power is lost you are guaranteed
212− that no transactions will be reversed.
213−
214−It is easy to think that "completed transaction will survive permanently"
215−along with "the state of Arvo is pure function of its event log" implies that
216−nothing can ever be deleted. This is not quite true.
217−[Clay](@/docs/arvo/clay/clay.md) is our [referentially
218−transparency](https://en.wikipedia.org/wiki/Referential_transparency)
219−file system, which could naively be thought to mean that since data must be
220−immutable, files cannot be deleted. However, Clay can replace a file with a
221−"tombstone" that causes Clay to crash whenever it is accessed. Referential
222−transparency only guarantees that there won't be new data at a previously
223−accessed location - not that it will still be available.
224−
225−### Single-level store
226−
227−A kernel which presents the abstraction of a single layer of permanent state is also called a _single-level store_. One way to describe a single-level store is that it never reboots; a formal model of the system does not contain an operation which unpredictably erases half its brain.
228−
229−Today's operating systems utilize at least two types of memory: the hard disk and the RAM, and this split is responsible for the fact that data is lost whenever power is lost. Not every operating system in history was designed this way - in particular, [Multics](https://en.wikipedia.org/wiki/Multics) utilized only one store of memory. Arvo takes after Multics - all data is stored in one permanent location, and as a result no data is ever lost when power is lost.
230−
231−### Non-preemptive
232−
233−Most operating systems are preemptive, meaning that they regularly interrupt
234−tasks being performed with the intention of resuming that task at a later time,
235−without the task explicitly yielding control.
236−Arvo does not do this - tasks run until they are complete or are cancelled due
237−to some heuristic, such as taking too long or because the user pressed Ctrl-C.
238−This is known as
239−[non-preemptive](https://en.wikipedia.org/wiki/Cooperative_multitasking) or
240−cooperative multitasking.
241−
242−
243−> Parts of the remainder of this document are out of date as of 2020.07.20, please use information here with
244−> caution. This message will be removed once it is up to date.
245−
246−
247−# The kernel
248−
249−The Arvo kernel, stored in `sys/arvo.hoon`, is about 1k lines of Hoon whose primary purpose is to implement the transition function, `+poke`. In this section we point out the most important parts of `arvo.hoon` and describe their role in the greater system. We also give brief descriptions of Arvo's kernel modules, known as vanes, and how Arvo interfaces with them.
250−
251−This section requires an understanding of Hoon of at least the level of Chapter One of the [Hoon tutorial](@/docs/hoon/hoon-school/_index.md).
252−
253−After concluding this section, the reader is encouraged to follow along with the
254−[move trace tutorial](@/docs/arvo/tutorials/move-trace.md),
255−which applies many of the concepts covered below.
256−
257−## Overall structure
258−
259−`arvo.hoon` contains five top level cores as well as a "formal interface" consisting of a single [gate](/docs/glossary/gate/) that implements the transition function. They are nested with the `=<` and `=>` runes like so, where items lower on the list are contained within items higher on the list:
260− + Types
261− + Section 3bE Arvo Core
262− + Implementation core
263− + Structural interface core, or adult core
264− + Larval stage core
265− + Formal interface
266−
267−See [Section 1.7](@/docs/hoon/hoon-school/arms-and-cores.md) of the Hoon tutorial for further explanation of what is meant here by "nesting". We now describe the functionality of each of these components.
268−
269−### Formal interface
270−
271−The formal interface is a single gate that takes in the current time and a noun that encodes the input. This input, referred to as an _event_, is then put into action by the `+poke` arm, and a new noun denoting the current [state of Arvo](#the-state) is returned. In reality, you cannot feed the gate just any noun - it will end up being an `ovum` described below - but as this is the outermost interface of the kernel the types defined in the type core are not visible to the formal interface.
272−
273−```hoon
274− :: Arvo formal interface
275− ::
276− :: this lifecycle wrapper makes the arvo door (multi-armed core)
277− :: look like a gate (function or single-armed core), to fit
278− :: urbit's formal lifecycle function. a practical interpreter
279− :: can ignore it.
280− ::
281− |= [now=@da ovo=*]
282− ^- *
283− ~> %slog.[0 leaf+"arvo-event"]
284− .(+> +:(poke now ovo))
285−```
286−
287−### Types
288−
289−This core contains the most basic types utilized in Arvo. We discuss a number of them here.
290−
291−#### `+duct`
292−
293−```hoon
294−++ duct (list wire) :: causal history
295−```
296−
297−Arvo is designed to avoid the usual state of complex event networks: event
298−spaghetti. We keep track of every event's cause so that we have a clear causal
299−chain for every computation. At the bottom of every chain is a Unix I/O event,
300−such as a network request, terminal input, file sync, or timer event. We push
301−every step in the path the request takes onto the chain until we get to the
302−terminal cause of the computation. Then we use this causal stack to route
303−results back to the caller.
304−
305−The Arvo causal stack is called a `duct`. This is represented simply as a list of paths, where each path represents a step in the causal chain. The first element in the path is the first letter of whichever vane handled that step in the computation, or the empty span for Unix.
306−
307−Here's a `duct` that was recently observed in the wild upon entering `-time ~s1`
308−into the dojo and pressing Enter, which sets a timer for one second that will
309−then produce a `@d` with the current time after the timer has elapsed:
310−
311−```
312−~[
313− /g/a/~zod/4_shell_terminal/u/time
314− /g/a/~zod/shell_terminal/u/child/4/main
315− /g/a/~zod/terminal/u/txt
316− /d/term-mess
317− //term/1
318−]
319−```
320−
321−This is the `duct` that the timer vane, Behn, receives when the `time` sample app asks the Behn to set a timer. This is also the `duct` over which the response is produced at the specified time. Unix sent a terminal keystroke event (enter), and Arvo routed it to Dill (our terminal), which passed it on to the Gall app terminal, which sent it to shell, its child, which created a new child (with process id 4), which on startup asked Behn to set a timer.
322−
323−Behn saves this `duct`, so that when the specified time arrives and Unix sends a
324−wakeup event to the timer vane, it can produce the response on the same `duct`.
325−This response is routed to the place we popped off the top of the `duct`, i.e. the
326−time app. This app returns a `@d` which denotes the current time, which falls down to the shell,
327−which drops it through to the terminal. Terminal drops this down to Dill, which
328−converts it into an effect that Unix will recognize as a request to print the
329−current time to the screen. When Dill produces this, the last path in the `duct` has an
330−initial element of the empty span, so this is routed to Unix, which applies the effects.
331−
332−This is a call stack, with a crucial feature: the stack is a first-class citizen. You can respond over a `duct` zero, one, or many times. You can save `duct`s for later use. There are definitely parallels to Scheme-style continuations, but simpler and with more structure.
333−
334−
335−#### `wire`
336−
337−```hoon
338−++ wire path :: event pretext
339−```
340−
341−Synonym for `path`, used in `duct`s. These should be thought of as a list of symbols
342−representing a cause.
343−
344−#### `move`
345−
346−```hoon
347−++ move [p=duct q=arvo] :: arvo move
348−```
349−
350−If `duct`s are a call stack, then how do we make calls and produce results? Arvo
351−processes `move`s which are a combination of message data and metadata. There
352−are four types of `move`s: `%pass`, `%give`, `%slip`, and `%unix`.
353−
354−A `%pass` `move` is analogous to a call:
355−
356−```
357−[duct %pass return-path=path vane-name=@tD data=card]
358−```
359−
360−Arvo pushes the return path (preceded by the first letter of the vane name) onto
361−the `duct` and sends the given data, a `card`, to the vane we specified. Any response will come along the same `duct` with the `wire` `return-path`.
362−
363−A `%give` `move` is analogous to a return:
364−
365−```
366−[duct %give data=card]
367−```
368−
369−Arvo pops the top `wire` off the `duct` and sends the given `card` back to the caller.
370−
371−A `%slip` `move` is a cousin of `%pass`. Any `card` that can be `%pass`ed can also be
372−`%slip`ed, but while a `%pass` says to "push this `wire` onto the `duct` and
373−transfer control to the receiving vane", a `%slip` transfers control to the
374−receiving vane without altering the `duct`. Therefore, a `%give` in response to
375−a `%slip` will go to the caller of the vane that sent the `%slip` rather than
376−the vane that actually sent the `%slip`. `%slip`s are much more rare than
377−`%pass`es and `%give`s. In general, `%slip` and `%pass` `move`s are
378−both referred to as "passes" and it should be clear from the context if one
379−means to refer only to `%pass`es and not `%slip`s or vice versa. Lastly, we note
380−that `%slip` is a code smell and should nearly always be avoided. It can result
381−in unexpected behavior like receiving a gift from a vane you never passed a note to.
382−
383−Lastly, a `%unix` `move` is how Arvo represents communication from Unix, such as a
384−network request or terminal input.
385−
386−#### `card`s and `curd`s
387−
388−`card`s are the vane-specific portion of a `move`, while `curd`s are typeless
389−`card`s utilized at the level of the kernel. `card`s are not actually defined in
390−`arvo.hoon`, rather they are given by `+note-arvo` and `+sign-arvo` in the
391−standard library `zuse`
392−(which then refer to `+task` and `+gift` in each of the vane cores), but they are closely
393−connected to `curd`s so we speak of them in the same breath.
394−
395−Each vane defines a protocol for interacting with other vanes (via Arvo) by defining four types of `card`s: `task`s, `gift`s, `note`s, and `sign`s.
396−
397−When one vane is `%pass`ed a `card` in its `task` (defined in `zuse`), Arvo activates the `+call` gate with the `card` as its argument. To produce a result, the vane `%give`s one of the `card`s defined in its `gift`. If the vane needs to request something of another vane, it `%pass`es it a `note` `card`. When that other vane returns a result, Arvo activates the `+take` gate of the initial vane with one of the `card`s defined in its `sign`.
398−
399−In other words, there are only four ways of seeing a `move`: (1) as a request seen by the caller, which is a `note`. (2) that same request as seen by the callee, a `task`. (3) the response to that first request as seen by the callee, a `gift`. (4) the response to the first request as seen by the caller, a `sign`.
400−
401−When a `task` `card` is `%pass`ed to a vane, Arvo calls its `+call` gate,
402−passing it both the `card` and its `duct`. This gate must be defined in every vane.
403−It produces two things in the following order: a list of `move`s and a possibly
404−modified copy of its context. The `move`s are used to interact with other vanes,
405−while the new context allows the vane to save its state. The next time Arvo
406−activates the vane it will have this context as its subject.
407−
408−This cycle of `%pass`ing a `note` to `%pass`ing a `task` to `%give`ing a `gift`
409−to `%give`ing a `%sign` is summarized in the following diagram:
410−
411−<div style="text-align:center">
412−<img class="mv5 w-150" src="https://media.urbit.org/docs/arvo/cycle.png">
413−</div>
414−
415−Note that `%pass`ing a `note` doesn't _always_ result in a return - this diagram
416−just
417−shows the complete cycle. However, `%give`ing a `gift` is always in response to being
418−`%pass`ed some `task`. Since the Arvo kernel acts as a middleman between all `move`s in Arvo, in diagrams we will
419−generally represent the intermediate steps of a vane `%pass`ing a `note` to the kernel addressed to
420−another vane followed by the kernel `%pass`ing a `task` to the
421−addressed vane as a single arrow from one vane to the other to make the diagrams
422−less cluttered.
423−
424−This overview has detailed how to pass a `card` to a particular vane. To see the `card`s each vane can be `%pass`ed as a `task` or return as a `gift` (as well as the semantics tied to them), each vane's public interface is explained in detail in its respective overview.
425−
426−#### `ovum`
427−
428−This mold is used to represent both steps and actions.
429−
430−A pair of a `wire` and a `curd`, with a `curd` being like a typeless `card`. The
431−reason for a typeless `card` is that this is the data structure which Arvo uses
432−to communicate with the runtime, and Unix events have no type. Additionally,
433−upgrading the kernel may alter the type system and thus may not be able to be
434−described within the current type system. Then the `wire` here is the default Unix `wire`, namely `//`. In particular, it is not a `duct` because `ovum`s come from the runtime rather than from within Arvo.
435−
436−### Arvo cores
437−
438−`arvo.hoon` has four additional cores that encode the functionality of Arvo. The [larval core](#larval-stage-core), [structural interface core](#structural-interface-core), and [implementation core](#implementation-core) each have five arms, called `+come`, `+load`, `+peek`, `+poke`, and `+wish`. Of these five arms, only `+poke` affects the [Arvo state](#the-state), while the rest leave the state invariant. Thus `+poke` is the aforementioned transition function that sends Arvo from one state to the next.
439−
440−A short summary of the purpose of each these arms are as follows:
441−
442− - `+poke` is the transition function that `move`s Arvo from one state to the
443− next. It is the most fundamental arm in the entire system. It is a typed
444− transactional message that is processed at most once. If the `+poke` causes
445− Arvo to send an message over [Ames](@/docs/arvo/ames/ames.md) Ames
446− guarantees that the message will be delivered exactly once. This is sometimes said
447− to be impossible, and it is for standard operating systems, but that is not the case for single-level stores engaged in
448− a permanent session, as is the case among Arvo ships.
449− - `+peek` is an arm used for inspecting things outside of the kernel. It grants
450− read-only access to `scry` Arvo's global referentially transparent namespace.
451− It takes in a `path` and returns a `unit (unit)`. If the product is `~`, the
452− path is unknown and its value cannot be produced synchronously. If its
453− product is `[~ ~]` the `path` is known to be unbound and can never become
454− bound. Otherwise the product is a `mark` and a noun.
455− - `+wish` is a function that takes in a core and then parses and compiles it
456− with the standard library, `zuse`. It is useful from the outside if you ever
457− want to run code within. One particular way in which it is used is by the
458− runtime to read out the version of `zuse` so that it knows if it is
459− compatible with this particular version of the kernel.
460− - `+load` is used when upgrading the kernel. It is only ever called by Arvo
461− itself, never by the runtime. If upgrading to a kernel where types are
462− compatible, `+load` is used, otherwise `+come` is used.
463− - `+come` is used when the new kernel has incompatible types, but ultimately
464− reduces to a series of `+load` calls.
465−
466− The [Section 3bE core](#section-3be-core) does not follow this pattern.
467−
468−#### Section 3bE core
469−
470−This core defines helper functions that are called in the larval and adult cores. These helper functions are placed here for safety so that they do not have access to the entire [state of Arvo](#the-state), which is contained in the structural interface core. One reason this core is required is that the Arvo interface has only five arms and additional arms are required to perform everything the kernel needs to do in a clean manner, so they must be segregated from the other three cores that stick to the five-arm paradigm.
471−
472−#### Implementation core
473−
474−This core is where the real legwork of the Arvo kernel is performed during the adult stage. It does not communicate with Unix directly, rather it is called by the structural interface core.
475−
476−#### Structural interface core
477−
478−This core could be thought of as the primary "adult core" - the one that is in operation for the majority of its lifecycle and the one that contains the [Arvo state](#the-state). This core should be thought of as an interface - that is, the amount of work the code does here is minimal as its main purpose is to be the core that communicates with Unix, and Unix should not be able to access deeper functions stored in the implementation core and 3bE core on its own. Thus, arms in this core are there primarily to call arms in the implementation core and 3bE core.
479−
480−#### Larval stage core
481−
482−This core is in use only during the larval stage of Arvo, which is after the Arvo kernel has compiled itself but before it has "broken symmetry" by acquiring identity and entropy, the point at which the larval stage has concluded. We call this breaking symmetry because prior to this point, every Urbit is completely identical. The larval stage performs the following steps in order:
483−
484− + The standard library, `zuse`, is installed.
485− + Entropy is added
486− + Identity is added
487− + Metamorph into the next stage of Arvo
488−
489−Once the larval stage has passed its functionality will never be used again.
490−
491−## The state
492−
493−As we follow functional programming paradigms, the state of Arvo is considered
494−to be the entire Arvo kernel core currently in operation (whether it be the larval
495−stage or adult stage). Thus when `+poke` is performed, a new core with the
496−updated state is produced, rather than modifying the existing core as would be
497−expected to happen in an imperative setting.
498−
499−Thus besides the battery of the Arvo core, we have the [payload](/docs/glossary/payload/) which is as
500−follows.
501−
502−```hoon
503−:: persistent arvo state
504−::
505−=/ pit=vase !>(..is) ::
506−=/ vil=vile (viol p.pit) :: cached reflexives
507−=| $: lac=_& :: laconic bit
508− eny=@ :: entropy
509− our=ship :: identity
510− bud=vase :: %zuse
511− vanes=(list [label=@tas =vane]) :: modules
512− == ::
513−```
514−
515−Let's investigate the state piece by piece.
516−
517−```hoon
518−=/ pit=vase !>(..is) ::
519−```
520−This `vase` is part of the state but does not get directly migrated when `+poke`
521−is called. `!>(..is)` consists of the code in `arvo.hoon` written above this core contained in
522−a `vase`. Thus this part of the state changes only when that code changes in an
523−update.
524−
525−```hoon
526−=/ vil=vile (viol p.pit) :: cached reflexives
527−
528−```
529−This is a cache of specific types that are of fundamental importance to Arvo -
530−namely `type`s, `duct`s, `path`s, and `vase`s. This is kept because it is
531−unnecessarily wasteful to recompile these fundamental types on a regular basis.
532−Again, this part of the state is never updated directly by `+poke`.
533−
534−```hoon
535−=| $: lac=_& :: laconic bit
536− eny=@ :: entropy
537− our=ship :: identity
538− bud=vase :: %zuse
539− vanes=(list [label=@tas =vane]) :: modules
540− ==
541−```
542−This is where the real state of the Arvo kernel is kept. `lac` detemines whether
543−Arvo's output is verbose, which can be set using the `|verb` command in the
544−dojo. `eny` is the current entropy. `our` is the ship, which is permanently
545−frozen during the larval stage. `bud` is the standard library. Lastly, `vanes`
546−is of course the list of vanes, which have their own internal states.
547−
548−As you can see, the state of Arvo itself is quite simple. Its primary role is that of
549−a traffic cop, and most of the interesting part of the state lies in `vanes`.
550−
551−
552−## Vanes
553−
554−The Arvo kernel can do very little on its own. Its functionality is extended in a careful and controlled way with vanes, also known as kernel modules.
555−
556−As described above, we use Arvo proper to route and control the flow of `move`s.
557−However, Arvo proper is rarely directly responsible for processing the event
558−data that directly causes the desired outcome of a `move`. This event data is contained within a `card`. Instead, Arvo proper passes the `card` off to one of its vanes, which each present an interface to clients for a particular well-defined, stable, and general-purpose piece of functionality.
559−
560−As of this writing, we have nine vanes, which each provide the following services:
561−
562−- [Ames](@/docs/arvo/ames/ames.md): the name of both our network and the vane that communicates over it.
563−- [Behn](@/docs/arvo/behn/behn.md): a simple timer.
564−- [Clay](@/docs/arvo/clay/clay.md): our version-controlled, referentially- transparent, and global filesystem.
565−- [Dill](@/docs/arvo/dill/dill.md): a terminal driver. Unix sends keyboard events to `%dill` from the console, and `%dill` produces terminal output.
566−- [Eyre](@/docs/arvo/eyre/eyre.md): an http server. Unix sends http messages to `%eyre`, and `%eyre` produces http messages in response.
567−- [Ford](@/docs/arvo/ford/ford.md): a build system also utilized for marks
568− (file types) and debugging.
569−- [Gall](@/docs/userspace/gall/gall.md): manages our userspace applications. `%gall` keeps state and manages subscribers.
570−- `Iris`: an http client.
571−- `Jael`: storage for Azimuth information.
572−
573−#### Applying your knowledge
574−
575−Now that you've learned about the nuts and bolts of the Arvo kernel, why not
576−check it out in action? An in-depth "move trace" tutorial for running a timer app
577−is available [here](@/docs/arvo/tutorials/move-trace.md).
arvo/tutorials/_index.mddeleted−9
@@ -1,9 +0,0 @@
1−+++
2−title = "Tutorials"
3−weight = 200
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
8−
9−Tutorials aimed at broadening understanding of Arvo.
arvo/tutorials/move-trace.mddeleted−378
@@ -1,378 +0,0 @@
1−+++
2−title = "Move Trace"
3−weight = 12
4−template = "doc.html"
5−+++
6−
7−In this tutorial we will run a simple "move trace" and use the output to get a
8−picture of what the Arvo kernel proper does during the routine task of setting a
9−timer. Some level of familiarity with the kernel is required for this section,
10−which can be obtained in our [Arvo kernel tutorial](@/docs/arvo/overview.md#the-kernel).
11−
12−## Running a move trace
13−
14−Ultimately, everything that happens in Arvo is reduced to Unix events, and the
15−Arvo kernel acts as a sort of traffic cop for vanes and apps to talk to one
16−another. Here we look at how a simple command, `-time ~s1`, goes from pressing
17−Enter on your keyboard in Dojo towards returning a notification that one second
18−has elapsed.
19−
20−To follow along yourself, boot up a fake `~zod` and enter `|verb` into the dojo
21−and press Enter to enable verbose mode (this is tracked by the laconic bit
22−introduced in the section on [the
23−state](@/docs/arvo/overview.md#the-state)) in the kernel documentation, followed by `-time ~s1`
24−followed by Enter. Your terminal should pretty print a series of `move`s that looks something like this:
25−
26−```
27−["" %unix p=%belt //term/1 ~2020.1.14..19.01.25..7556]
28−["|" %pass [%d %g] [[%deal [~zod ~zod] %hood %poke] /] [i=//term/1 t=~]]
29−["||" %pass [%g %g] [[%deal [~zod ~zod] %dojo %poke] /use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo] [i=/d t=~[//term/1]]]
30−["|||" %give %g [%unto %fact] [i=/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo t=~[/d //term/1]]]
31−["||||" %give %g [%unto %fact] [i=/d t=~[//term/1]]]
32−["|||||" %give %d %blit [i=//term/1 t=~]]
33−["|||" %pass [%g %f] [%build /use/dojo/~zod/drum/hand] [i=/d t=~[//term/1]]]
34−["||||" %give %f %made [i=/g/use/dojo/~zod/drum/hand t=~[/d //term/1]]]
35−["|||||" %pass [%g %g] [[%deal [~zod ~zod] %spider %watch] /use/dojo/~zod/out/~zod/spider/drum/wool] [i=/d t=~[//term/1]]]
36−["||||||" %give %g [%unto %watch-ack] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
37−["|||||" %pass [%g %g] [[%deal [~zod ~zod] %spider %poke] /use/dojo/~zod/out/~zod/spider/drum/wool] [i=/d t=~[//term/1]]]
38−//term/1]]]
39−["||||||" %pass [%g %f] [%build /use/spider/~zod/find/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u] [i=/d t=~[//term/1]]]
40−["|||||||" %give %f %made [i=/g/use/spider/~zod/find/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u t=~[/d //term/1]]]
41−["||||||||" %pass [%g %f] [%build /use/spider/~zod/build/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u] [i=/d t=~[//term/1]]]
42−["|||||||||" %give %f %made [i=/g/use/spider/~zod/build/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u t=~[/d //term/1]]]
43−["||||||||||" %pass [%g %b] [%wait /use/spider/~zod/thread/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u/wait/~2020.1.14..19.01.26..7556] [i=/d t=~[//term/1]]]
44−["|||||||||||" %give %b %doze [i=//behn/0v1p.sn2s7 t=~]]
45−> -time ~s1
46−```
47−followed by a pause of one second, then
48−```
49−["" %unix p=%wake //behn ~2020.1.14..19.01.26..755d]
50−["|" %give %b %doze [i=//behn/0v1p.sn2s7 t=~]]
51−["|" %give %b %wake [i=/g/use/spider/~zod/thread/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u/wait/~2020.1.14..19.01.26..7556 t=~[/d //term/1]]]
52−["||" %give %g [%unto %fact] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
53−["|||" %give %g [%unto %fact] [i=/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo t=~[/d //term/1]]]
54−["||||" %give %g [%unto %fact] [i=/d t=~[//term/1]]]
55−["|||||" %give %d %blit [i=//term/1 t=~]]
56−["||" %give %g [%unto %kick] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
57−~s1..0007
58−```
59−This gives us a move trace that is a list of `move`s and some
60−associated metadata. Some of the `move`s are a bit of a distraction from what's
61−going on overall such as acknowledgements that a `poke` was received
62−(`%poke-ack`s), so we've omitted them for clarity. Furthermore, two `move`s (the
63−`%blit` `card`s) is not printed even in verbose mode because it occurs so
64−frequently, but there are only two of them here and so we have added it in.
65−
66−The main process that is occurring here is a sequence of `%pass` `move`s initiated
67−by pressing Enter in the terminal that goes on to be handled by Dill, then Gall,
68−and finally Behn. After the timer has elapsed, a sequence of `%give` `move`s is
69−begun by Behn, which then passes through Gall and ultimately ends up back at the
70−terminal. Any `move`s besides `%pass` in the first segment of the move trace is a
71−secondary process utilized for book-keeping, spawning processes, interpreting
72−commands, etc. All of this will be explained in detail below.
73−
74−
75−It is important to note that this move trace should be thought of
76−as being from the "point of view" of the kernel - each line represents the
77−kernel taking in a message from one source and passing it along to its
78−destination. It is then processed at that destination (which could be a vane or
79−an app), and the return of that process is sent back to Arvo in the form of
80−another `move` to perform and the loop begins again. Thus this move trace does
81−not display information about what is going on inside of the vane or app such as
82−private function calls, only what the kernel itself sees.
83−
84−## Interpreting the move trace
85−
86−In this section we will go over the move trace line-by-line, explaining how the
87−move trace is printed, what each line means (including some things not found in
88−the move trace), and a particular focus on what code is being activated in the
89−first few lines that should equip you well enough to unravel the rest of the
90−move trace in as much detail as you desire.
91−
92−
93−### The call
94−
95−Let's put the first part of the move trace into a diagram to make following
96−along a little easier.
97−
98−<div style="text-align:center">
99−<img src="https://media.urbit.org/docs/arvo/move-trace-with-key.png">
100−</div>
101−
102−Here, each arrow represents the passing of some information, with most of it
103−being from vane to vane. Here, when Vane A has an arrow to a card and then an
104−arrow to Vane B, this represents either a `%pass` `note/task` sequence or a
105−`%give` `gift/sign` sequence that actually has the Arvo kernel in the middle.
106−That is to say, Vane A `%pass`es a `note` to the Arvo kernel addressed to Vane
107−B, and the Arvo kernel then `%pass`es a `task` to Vane B. For more information,
108−see the [Arvo kernel tutorial](@/docs/arvo/overview.md#the-kernel).
109−
110−This simple action ends up involving four vanes - Dill, Gall, Behn, and Ford -
111−as well as four applications - hood, spider, dojo, and time.
112−
113−Now let's go through each line one by one.
114−```
115−["" %unix p=%belt //term/1 ~2020.1.14..19.01.25..7556]
116−```
117−This tells us that Unix has sent a `%belt` `card`, which corresponds to
118−terminal input (the Enter keystroke) at time `~2020.1.14..19.01.25..7556`
119−
120−Here is the line of code in `arvo.hoon`, found in the [section
121−3bE core](@/docs/arvo/overview.md#section-3be-core), that generated the output:
122−
123−```hoon
124− ~? !lac ["" %unix -.q.ovo p.ovo now]
125−```
126−First we note that this line is executed only if the laconic bit is set to true,
127−as we did when we input `|verb`. Here, `ovo` is the input `ovum`. Knowing that an `ovum` is a `[p=wire q=curd]`,
128−we can then say that this is a `%unix` `move` tagged with `%belt` whose cause is a `wire` given by `//term/1`,
129−where the empty span `//` represents Unix and `term/1` represents the terminal
130−in Unix. Here we have a `wire` instead of a `duct` (i.e. a list of `wire`s)
131−since Unix I/O events are always the beginning and end of the Arvo event loop,
132−thus only a single `wire` is ever required at this initial stage.
133−
134−The `""` here is a metadatum that keeps track of how many steps deep in the
135−causal chain the event is. An event
136−with `n` `|`'s was caused by the most recent previous event with `n-1` `|`'s. In
137−this case, Unix events are an "original cause" and thus represented by an empty
138−string.
139−
140−At this point in time, Dill has received the `move` and then processes it. The
141−`%belt` `task` in `dill.hoon` is `+call`ed, which is processed using the `+send`
142−arm:
143−
144−```hoon
145− ++ send :: send action
146− |= bet/dill-belt
147− ^+ +>
148− ?^ tem
149− +>(tem `[bet u.tem])
150− (deal / [%poke [%dill-belt -:!>(bet) bet]])
151−```
152−
153−Dill has taken in the command and in response it `%pass`es a `task` `card` with
154−instructions to `%poke` hood, which is a Gall app
155−primarily used for interfacing with Dill. Here, `+deal` is an arm for
156−`%pass`ing a `card` to Gall to ask it to create a `%deal` `task`:
157−
158−
159−```hoon
160− ++ deal :: pass to %gall
161− |= [=wire =deal:gall]
162− (pass wire [%g %deal [our our] ram deal])
163−```
164−
165−Next in our move trace we have this:
166−```
167−["|" %pass [%d %g] [[%deal [~zod ~zod] %hood %poke] /] [i=//term/1 t=~]]
168−```
169−Here, Dill `%pass`es a `task` `card` saying to `%poke` Gall's hood app (with the
170−Enter keystroke).
171−
172−Let's glance at part of the `+jack` arm in `arvo.hoon`, located in the [section 3bE
173−core](@/docs/arvo/overview.md#section-3be-core). This arm is what the Arvo kernel uses to send `card`s,
174−and here we look at the segment that includes `%pass` `move`s.
175−
176−```hoon
177− ++ jack :: dispatch card
178− |= [lac=? gum=muse]
179− ^- [[p=(list ovum) q=(list muse)] _vanes]
180− ~| %failed-jack
181− :: =. lac |(lac ?=(?(%g %f) p.gum))
182− :: =. lac &(lac !?=($b p.gum))
183− %^ fire
184− p.gum
185− s.gum
186− ?- -.r.gum
187− $pass
188− ~? &(!lac !=(%$ p.gum))
189− :- (runt [s.gum '|'] "")
190− :^ %pass [p.gum p.q.r.gum]
191− ?: ?=(?(%deal %deal-gall) +>-.q.q.r.gum)
192− :- :- +>-.q.q.r.gum
193− (,[[ship ship] term term] [+>+< +>+>- +>+>+<]:q.q.r.gum)
194− p.r.gum
195− [(symp +>-.q.q.r.gum) p.r.gum]
196− q.gum
197− [p.q.r.gum ~ [[p.gum p.r.gum] q.gum] q.q.r.gum]
198−```
199−
200−Code for writing traces can be a bit tricky, but let's try not to get too
201−distracted by the lark expressions and such. By paying attention to the lines
202−concerning the laconic bit (following `!lac`) we can mostly determine what is being told to us.
203−
204−From the initial input event, Arvo has generated a `card` that it is now
205−`%pass`ing from Dill (represented by `%d`) to Gall (represented by `%g`). The
206−`card` is a `%deal` `task`, asking Gall to `%poke` hood using data that has
207−originated from the terminal `//term/1`, namely that the Enter key was pressed. The line `:- (runt [s.gum '|'] "")`
208−displays the causal chain length metadatum mentioned above. Lastly, `[~zod ~zod]` tells us that
209−`~zod` is both the sending and receiving ship.
210−
211−From here on our explanations will be more brief. We include some information
212−that cannot be directly read from the move trace in [brackets]. Onto the next line:
213−
214−```
215−["||" %pass [%g %g] [[%deal [~zod ~zod] %dojo %poke] /use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo] [i=/d t=~[//term/1]]]
216−```
217−
218−Here is another `%pass` `move`, this time from Gall to iself as denoted by `[%g
219−%g]`. Gall's hood has received the `%deal` `card` from Dill, and in response it is
220−`%poke`ing dojo with the information [that Enter was pressed].
221−
222−```
223−["|||" %give %g [%unto %fact] [i=/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo t=~[/d //term/1]]]
224−```
225−
226−Gall's dojo `%give`s a `gift` with a `%fact` (subscription update) to Gall's hood, [saying to clear
227−the terminal prompt].
228−
229−```
230−["||||" %give %g [%unto %fact] [i=/d t=~[//term/1]]]
231−```
232−Gall's hood `%give`s a `gift` with a `%fact` to Dill [saying to replace the current terminal line with `~zod:dojo>`]
233−
234−Next is the `move` that is not actually printed in the move trace mentioned
235−above:
236−
237−```
238−["|||||" %give %d %blit [i=//term/1 t=~]]
239−```
240−
241−Dill `%give`s a `%blit` (terminal output) event to Unix [saying to replace the current terminal line with `~zod:dojo>`].
242−
243−```
244−["|||" %pass [%g %f] [%build /use/dojo/~zod/drum/hand] [i=/d t=~[//term/1]]]
245−```
246−
247−Gall's dojo also `%pass`es a `%build` request to Ford [asking to run "~s1" against the subject we use in the dojo].
248−
249−```
250−["||||" %give %f %made [i=/g/use/dojo/~zod/drum/hand t=~[/d //term/1]]]
251−```
252−
253−Ford `%give`s a result back to dojo [with the value `~s1`]
254−
255−```
256−["|||||" %pass [%g %g] [[%deal [~zod ~zod] %spider %watch] /use/dojo/~zod/out/~zod/spider/drum/wool] [i=/d t=~[//term/1]]]
257−```
258−
259−Gall's dojo `%pass`es a `%watch` to Gall's spider app [to start listening for the result of the thread it's about to start].
260−
261−```
262−["||||||" %give %g [%unto %watch-ack] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
263−```
264−
265−Gall's spider acknowledges the subscription from dojo.
266−
267−```
268−["|||||" %pass [%g %g] [[%deal [~zod ~zod] %spider %poke] /use/dojo/~zod/out/~zod/spider/drum/wool] [i=/d t=~[//term/1]]]
269−```
270−
271−Gall's dojo also `%pass`es a `%poke` to Gall's spider [asking it start the thread "-time" with argument `~s1`].
272−
273−```
274−["||||||" %pass [%g %f] [%build /use/spider/~zod/find/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u] [i=/d t=~[//term/1]]]
275−```
276−
277−Gall's spider `%pass`es a `%build` request to Ford [asking it to find the path in `/ted` where the "time" thread is].
278−
279−```
280−["|||||||" %give %f %made [i=/g/use/spider/~zod/find/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u t=~[/d //term/1]]]
281−```
282−
283−Ford `%give`s a result back to Gall's spider [saying it's in `/ted/time.hoon`].
284−
285−```
286−["||||||||" %pass [%g %f] [%build /use/spider/~zod/build/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u] [i=/d t=~[//term/1]]]
287−```
288−
289−Gall's spider `%pass`es a `%build` request to Ford [asking it to compile the file `/ted/time.hoon`].
290−
291−```
292−["|||||||||" %give %f %made [i=/g/use/spider/~zod/build/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u t=~[/d //term/1]]]
293−```
294−
295−Ford `%give`s a result back to Gall's spider [with the compiled thread].
296−
297−```
298−["||||||||||" %pass [%g %b] [%wait /use/spider/~zod/thread/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u/wait/~2020.1.14..19.01.26..7556] [i=/d t=~[//term/1]]]
299−```
300−
301−Gall's spider's thread with id `~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u` asks Behn to set a timer [for one second].
302−
303−```
304−["|||||||||||" %give %b %doze [i=//behn/0v1p.sn2s7 t=~]]
305−```
306−
307−Behn `%give`s a `%doze` `card` to Unix, asking it to set a timer [for one second from
308−now]. At this point Arvo may rest.
309−
310−### The return
311−
312−Now Unix sets a timer for one second, waits one second, and then informs Behn that a second has
313−passed, leading to a chain of `%give` `move`s that ultimately prints
314−`~s1..0007`.
315−
316−Let's throw the move trace into a table:
317−
318−| length | move | vane(s) | card | duct |
319−|--------|---------|---------|-----------------|------------------------------------------------------------------------------------------------------------------|
320−| 0 | `%unix` | | `%wake` | `//behn` |
321−| 1 | `%give` | `%b` | `%doze` | `//behn/0v1p.sn2s7` |
322−| 1 | `%give` | `%b` | `%wake` | `/g/use/spider/~zod/thread/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u/wait/~2020.1.14..19.01.26..7556 /d //term/1` |
323−| 2 | `%give` | `%g` | `[%unto %fact]` | `/g/use/dojo/~zod/out/~zod/spider/drum/wool /d //term/1` |
324−| 3 | `%give` | `%g` | `[%unto %fact]` | `/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo /d //term/1` |
325−| 4 | `%give` | `%g` | `[%unto %fact]` | `/d //term/1` |
326−| 5 | `%give` | `%d` | `%blit` | `//term/1` |
327−| 2 | `%give` | `%g` | `[%unto %kick]` | `/g/use/dojo/~zod/out/~zod/spider/drum/wool /d //term/1` |
328−
329−Now we follow it line-by-line:
330−
331−```
332−["" %unix p=%wake //behn ~2020.1.14..19.01.26..755d]
333−```
334−
335−Unix sends a `%wake` (timer fire) `card` at time `~2020.1.14..19.01.26..755d`.
336−
337−```
338−["|" %give %b %doze [i=//behn/0v1p.sn2s7 t=~]]
339−```
340−
341−Behn `%give`s a `%doze` `card` to Unix, asking it to set a timer [for whatever next timer it has in its queue].
342−
343−```
344−["|" %give %b %wake [i=/g/use/spider/~zod/thread/~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u/wait/~2020.1.14..19.01.26..7556 t=~[/d //term/1]]]
345−```
346−
347−Behn `%give`s a `%wake` to Gall's spider's thread with id `~.dojo_0v6.210tt.1sme1.ev3qm.qgv2e.a754u`.
348−
349−```
350−["||" %give %g [%unto %fact] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
351−```
352−
353−Gall's spider `%give`s a `%fact` (subscription update) to dojo [saying that the thread completed successfully and produced value `~s1.0007`].
354−
355−```
356−["|||" %give %g [%unto %fact] [i=/g/use/hood/~zod/out/~zod/dojo/drum/phat/~zod/dojo t=~[/d //term/1]]]
357−```
358−
359−Gall's dojo `%give`s a `%fact` to hood [saying to output `~s1..0007`].
360−
361−```
362−["||||" %give %g [%unto %fact] [i=/d t=~[//term/1]]]
363−```
364−
365−Gall's hood `%give`s a `%fact` to Dill [saying to output `~s1..0007`].
366−
367−```
368−["|||||" %give %d %blit [i=//term/1 t=~]]
369−```
370−
371−Dill `%give`s a `%blit` (terminal output) event to Unix [saying to print a new line with output `~s1..0007`].
372−
373−```
374−["||" %give %g [%unto %kick] [i=/g/use/dojo/~zod/out/~zod/spider/drum/wool t=~[/d //term/1]]]
375−```
376−
377−Gall's spider also closes the subscription from dojo [since the thread has completed].
378−
azimuth/_index.mddeleted−22
@@ -1,22 +0,0 @@
1−+++
2−title = "Azimuth"
3−weight = 700
4−sort_by = "weight"
5−template = "sections/docs/chapters.html"
6−insert_anchor_links = "right"
7−+++
8−
9−
10−## [Azimuth](@/docs/azimuth/azimuth.md)
11−
12−An overview of the Ethereum-based public key infrastructure utilized by Urbit.
13−
14−## [Life and Rift](@/docs/azimuth/azimuth.md)
15−
16−An explanation of how Azimuth keeps track of the most recent set of networking
17−keys necessary to communicate with a ship.
18−
19−## [Advanced Azimuth Tools](@/docs/azimuth/advanced-azimuth-tools.md)
20−
21−Expert-level tooling for generating, signing, and sending Azimuth-related
22−transactions from within Urbit itself.
azimuth/advanced-azimuth-tools.mddeleted−68
@@ -1,68 +0,0 @@
1−+++
2−title = "Advanced Azimuth Tools"
3−weight = 4
4−template = "doc.html"
5−+++
6−
7−This document outlines some advanced techniques for generating, signing, and sending Azimuth-related transactions from within Urbit itself. It's strongly discouraged to do this unless you're very confident as Azimuth transactions are permanent and will cost ETH to complete. However, until you upload a signed transaction to the blockchain no transaction will take place so it's safe to explore these tools. It will also be very helpful to have at least a rudimentary understanding of Hoon in order to read and modify parts of the code.
8−
9−First you will want to [boot a fakezod](https://urbit.org/using/develop/#creating-a-development-ship). You can do this with your live running ship but at this time this will need you to modify the code so it's best to do this on a ship you can make mistakes on.
10−
11−Be sure to have mounted your home desk so you can easily edit files on it.
12−The first edit that will probably need to be made is in [`app/claz.hoon`](https://github.com/urbit/urbit/blob/85435e9a81e105809d5d381b5d34fae1d4daa3b8/pkg/arvo/app/claz.hoon#L14). The listed url will need to be changed to a valid Ethereum endpoint. infura.io provides an Ethereum API that you can use.
13−
14−The second change that may potentially be needed is to modify the [gas limit](https://github.com/urbit/urbit/blob/85435e9a81e105809d5d381b5d34fae1d4daa3b8/pkg/arvo/app/claz.hoon#L179). This number here is the maximum number of gas units that will be used. In future this will be configurable but for now you may need to change this manually. For a guide to what to set it to you can use the [constants in bridge](https://github.com/urbit/bridge/blob/29f4a14869489481a950a1af53f583d751897444/src/lib/constants.js#L23) as a guide based on what action you are going to be performing. The maximum cost of your transaction will be the maximum gas units multiplied by the gwei you're going to set later. You'll need at least this much in your account.
15−
16−Once you have made these changes be sure to run `|commit %home` to get them into your ship.
17−
18−Next run `|start %claz` after which you'll be able to generate transactions.
19−
20−```
21−:claz [%generate %/spawn/eth-txs %mainnet author %single %spawn ~ship to]
22−```
23−
24−Here we have an example of generating a transaction to spawn a ship. Something to note is that for this to be successful you'll need to actually have the right to spawn the ship in question. Let's break down the command.
25−
26−
27−`%generate` is how all commands to `claz` are going to start.
28−
29−`%/spawn/eth-txs` is simply the path for the output file
30−
31−`%mainnet` specifies which network this is going to sent out on. Other options are possible including the test-net `%ropsten`.
32−
33−`author` here is an Ethereum address that is issuing the transaction. It will need to be written in `@ux` notation, e.g. `0x3b17.d097.d9dd.711e.4ef8.517a.bbf1.8b2b.a643.81fe`.
34−
35−`%single` specifies what kind of batch that will be created. If you are going to do multiple transactions you will need to either set this to `%more` followed by a _list_ of batches, or generate the next transaction after having submitted the previous one to the blockchain.
36−
37−`[%spawn ~ship to]` is the transaction we want to issue. The arguments are will vary based on the transaction. `~ship` will be the ship to be spawned. `to` is the Ethereum address to spawn the ship to.
38−
39−You will want to read [`/sur/claz.hoon`](https://github.com/urbit/urbit/blob/85435e9a81e105809d5d381b5d34fae1d4daa3b8/pkg/arvo/sur/claz.hoon).
40−This will contain more details about the various kinds of transactions you can perform particularly `++call`
41−
42−After running this command you should find a csv file at the output path you specified. You can examine this file to learn how they are constructed. You are able to modify the nonces, gas limit and price without changing the functionality of the transaction but it's not important for this guide.
43−
44−This file can now be signed and uploaded. At this point, you can transfer this file to an airgapped machine which has your keys, if you want. If you choose to do that you will need to download the `urbit` binary as well as the most recent pill file or a copy of the fakezod pier you have already booted.
45−
46−For this guide, we'll continue on the same ship.
47−
48−Run `|start %eth-sender` and then you can use it to sign the transaction file.
49−
50−```
51−:eth-sender [%sign %/spawn-signed/txt %/spawn/eth-txs %/mykey/txt ~[40 80]]
52−```
53−
54−Let's break this down again.
55−
56−`%sign` is the action we are going to perform here. `eth-sender` can also be used to submit batches of transactions to the network in various ways, but details on that are outside of the scope of this guide.
57−
58−`%/spawn-signed/txt` is the path to the output file.
59−
60−`%/spawn/eth-txs` is the path to the transaction file we generated earlier. It will need to be accessible so don't forget to `|commit %home` if you moved it to a different pier.
61−
62−`%/mykey/txt` is the path to your private key file. It should contain your private key beginning with 0x and followed by a hex string with no dots, and where capital letters are fine. This file is most likely the reason you will want to use an airgapped machine so that your private key never touches a networked computer. Opsec is left to the reader.
63−
64−`~[40 80]` is a list of gas prices, in gwei; a signed transaction file will be created for each one listed. Here we just specify 40 and 80 gwei. You may want to adjust this list based on current Ethereum network traffic and your time preference for the transactions.
65−
66−Now you should have one file in your pier for each gwei costs.
67−
68−To actually transmit the transaction, paste the contents of one of these files into https://etherscan.io/pushTx or whatever other transmission system you would like to use. **This is the action that will actually cost you ETH and perform the transaction on the network. Only do this step if you want to actually perform the action.**
azimuth/azimuth.mddeleted−150
@@ -1,150 +0,0 @@
1−+++
2−title = "Overview"
3−weight = 2
4−template = "doc.html"
5−aliases = ["/docs/learn/azimuth"]
6−+++
7−Azimuth is a general-purpose public-key infrastructure (PKI) on the Ethereum blockchain, used as a platform for _Urbit identities_. You need such an identity to use the Arvo network.
8−
9−The primary way to interact with Azimuth is through our [Bridge](https://github.com/urbit/bridge) application and the node libraries that it depends on, [azimuth-js](https://github.com/urbit/azimuth-js) and [urbit-key-generation](https://github.com/urbit/urbit-key-generation). Take a look at the source and play around, or see [Getting Started](@/getting-started/_index.md).
10−
11−## Arvo vs. Azimuth
12−
13−Urbit is a project, not a single computer system. It has multiple components: Arvo, the operating system; and Azimuth, the identity system. Let's compare them.
14−
15−**Arvo** is an operating system that provides the software for a personal server. These personal servers together constitute the peer-to-peer Arvo network. To make this network work on the social level, Arvo is built to work with a system of scarce and immutable identities.
16−
17−**Azimuth** is the public-key infrastructure built to be such a system. A suite of smart-contracts on the Ethereum blockchain, Azimuth determines which Ethereum addresses own which Azimuth identities, called _Urbit identities_, or just _identities_. All identity-related operations, such as transfers, are governed at this layer. But Azimuth isn't built strictly for Arvo -- it could be used as a generalized identity system for other projects.
18−
19−These otherwise-parallel systems meet when you want to connect to the Arvo network. Your Arvo personal server, called your _ship_, needs to be able to prove cryptographically that it is who it says it is. This proof comes in the form of a keyfile, derived from your identity, that you use to start your ship.
20−
21−A metaphor might help illustrate the relationship between these two systems: the Arvo network is the neighborhood that you live in; Azimuth is the bank vault that stores the deed to your house.
22−
23−## The Urbit HD Wallet
24−
25−Owners of Urbit identities need safeguards that allow for the use of Urbit without jeopardizing cryptographic ownership of their assets. Toward this end, we created the **Urbit Hierarchical Deterministic (HD) Wallet** for the storage of identities. The Urbit HD Wallet is not one key-pair, but a system of related key-pairs that each have distinct powers, from setting networking keys for communicating in the Arvo network to transferring ownership of identities.
26−
27−The Urbit HD Wallet's derivation paths have a hierarchical structure, so that
28−keys with different powers can be physically separated. A "master ticket" can
29−[re-derive the entire wallet](#hd-wallet-generation) in case of loss. The
30−encryption and authentication keys that identities ships use to sign messages
31−within the network are also derived from the wallet.
32−
33−Another HD wallet option you may wish to utilize to store your Urbit are hardware
34−wallets such as Trezor or Ledger. We compare this method to the Urbit HD wallet
35−[below](#hardware-hd-wallet).
36−
37−Urbit HD wallets are composed of the following items, which are each assigned to their own individual Ethereum key-pairs.
38−
39−### Master Ticket
40−
41−Think of your master ticket like a very high-value password. The master ticket is the secret code from which all of your other keys are derived. Technically, your master ticket is seed entropy. You should never share it with anyone, and store it very securely. This ticket can derive all of your other keys: your ownership key and all of the related proxies.
42−
43−### Ownership Address
44−
45−An ownership address has all rights over the assets deeded to it. These rights are on-chain actions described and implemented in the Ecliptic, Azimuth's suite of governing smart-contracts.
46−
47−### Proxies
48−
49−Proxy addresses allow you to execute non-ownership related actions like spawning child identities, voting, and setting networking keys without jeopardizing the keys you've designated with ownership rights. Setting proxy rights is optional, but it is recommended for on-chain actions you will execute more frequently.
50−
51−- **Management Proxy**
52−
53− Can configure or set Arvo networking keys and conduct sponsorship related
54− operations.
55−
56−- **Voting Proxy**
57−
58− Galaxies only. Galaxies are the part of the galactic senate, and this means
59− they can cast votes on new proposals including changes to the Ecliptic.
60−
61−- **Spawn Proxy**
62−
63− For stars and galaxies only. Can create new child identities.
64−
65−### HD wallet generation
66−
67−Your Urbit HD wallet is generated from a `@q` seed called `T`, which looks
68−something like `~sampel-ticket-bucbel-sipnem`. This is the string known as your
69−"Master Ticket" that you input into Bridge to sign in. This is put through a
70−series of algorithms that ultimately generate your keys and the Ethereum addresses at which they are stored.
71−
72−
73−
74−First, your `@q` is converted into a numeric value `E` as an intermediary step
75−by adding [salt](https://en.wikipedia.org/wiki/Salt_(cryptography)). Then by
76−adding additional salts, `E` is converted into a set of BIP39 seed phrases -
77−these are 24 word mnemonic sequences used to generate Ethereum wallets. You end up
78−with one seed phrase for each proxy associated with your ship, and these seed
79−phrases are then used to generate Ethereum wallets.
80−
81−One of the wallets will store your Azimuth point, an [ERC-721](#erc-721) token,
82−which will be known as your ownership address. Bridge then automatically uses
83−your ownership address to assign the other proxies to the other wallets
84−generated.
85−
86−### ERC-721
87−
88−Most Ethereum tokens use the ERC-20 standard for smart contracts. Urbit identities
89−are, however, essentially different from most Ethereum tokens, due to identities not
90−being fungible. Since any two stars will handle social-networking realities in a
91−different way, they will carry a different reputation. identities are to houses as
92−tokens are to gold.
93−
94−The ERC-721 standard, having been made specifically to provide a smart-contract
95−interface for non-fungible assets, serves our needs well. This is the standard
96−that we use for deeding Urbit identities.
97−
98−Identities, and all of their blockchain operations, are governed by the Ecliptic.
99−The Ecliptic is an Ethereum smart-contract that governs identity state and the
100−ownership, spawn, management, and voting rights affiliated with your identities.
101−
102−For the technical implementation details, take a look at Azimuth's
103−[Github repository](https://github.com/urbit/azimuth).
104−
105−## Hardware HD wallet
106−
107−You may also store your Urbit using a hardware HD wallet such as a Trezor or
108−Ledger. This option is used instead of a master ticket - it is a totally
109−separate process from that outlined above. How hardware wallets work are
110−outside of the scope of this document, but here we explain how you may utilize
111−your hardware wallet in a similar fashion to the Urbit HD wallet.
112−
113−A hardware HD wallet is generated from a seed phrase that should be thought of
114−as analogous to the `@q` `T` used to generate the Urbit HD wallet in the above
115−diagram. This seed phrase is a human readable sequence of words that may be used
116−to generate private keys to a near-limitless number of wallets created by adding
117−salt. Some hardware
118−wallets also allow an additional passphrase to go into the generation of these
119−wallets. The seed phrase and passphrase should be considered equal in
120−value to the master ticket `T`- never share these with anyone!
121−
122−In order to use your hardware wallet as your Urbit wallet, you first need to
123−generate a set of addresses on which you would like to store your Azimuth point
124−and proxies. Consult your wallet vendor on how to do this. Then login to Bridge
125−using your current method (likely a master ticket) and transfer ownership to the
126−wallet address you generated on your hardware wallet for ownership.
127−
128−Next, login to Bridge using your hardware wallet. While Bridge supports Trezor
129−and Ledger natively, this may require using Metamask as an intermediary anyways,
130−depending on which firmware you are running. Then [accept the
131−transfer](@/using/id/using-bridge.md#accept-your-transfer). Your Azimuth
132−point is now stored on your hardware wallet.
133−
134−To finish the process, use Bridge to set your management, voting, and spawn
135−proxies to the other addresses you generated as applicable. You are now using
136−your hardware HD wallet in an analogous fashion to the Urbit HD wallet.
137−
138−## Heightened security practices
139−
140−A common security pattern is to have "hot" and "cold" wallets. For higher value
141−points such as stars and galaxies, you may consider having your ownership
142−address live on a "cold" wallet that never touches an
143−internet-connected computer, and the various proxies on a "hot" wallet that is
144−permitted to connect to internet-connected devices. This could be accomplished
145−with multiple hardware wallets, a combination of paper and hardware wallet, a
146−hardware cold wallet and Metamask hot wallet, etc.
147−
148−One tool useful for this setup is `claz`, located at `app/claz.hoon`. `claz` is
149−used for making and signing Bridge transactions from an offline computer. A
150−guide to using `claz` is forthcoming.
azimuth/life-and-rift.mddeleted−58
@@ -1,58 +0,0 @@
1−+++
2−title = "Life and Rift"
3−weight = 3
4−template = "doc.html"
5−+++
6−
7−Associated to every Azimuth point are two non-negative integers known as _life_
8−and _rift_. This numbering system partition messages according to the quantity
9−of networking key changes and quantity of
10−[breaches](@/using/id/guide-to-breaches.md), respectively. This is explained in
11−more detail below. These values are utilized by [Ames](@/docs/arvo/ames/ames.md)
12−and [Jael](@/docs/arvo/jael/jael-api.md) to ensure that communication between
13−ships is always done with the most recent set of networking keys, and that
14−networking state is appropriately reset when a breach has occurred.
15−
16−Every ship begins with a `life` and `rift` of 0. For
17−galaxies, stars, and planets, these values are stored in the Azimuth PKI, while
18−for moons, these values are stored by their parent. Comets cannot change their
19−networking keys, nor can they breach, and so their `life` and `rift` are always 0.
20−
21−You can check your current `life` and `rift` number by running the `+keys our`
22−generator in dojo. You can inspect another ship's `life` and `rift` by running
23−`+keys ~sampel-palnet`.
24−
25−## Life
26−
27−A ship's `life`, or _key revision number_, is a count of the number of times which
28−a ship's networking keys have been altered. The initial value of each key is
29−always zero, and the initial `life` is always 0.
30−
31−Thus, setting the keys of a ship to a nonzero value for the first time will
32−increment the `life` from 0 to 1. Rotating to a new set of keys will then
33−increment the `life` to 2. Setting the keys back to zero would increment the
34−`life` once more, to 3.
35−
36−## Rift
37−
38−A ship's `rift`, or _continuity number_, is a count of the number of times that
39−a ship has breached, also known as broken continuity.
40−
41−In other words, a ship's `rift` will remain at 0 until the first time it is
42−breached.
43−
44−Network-wide breaches do not affect the `rift` of any ship. They are only used to
45−count the number of personal breaches.
46−
47−## Edge cases
48−
49−Configuring the keys to the same value they already were (i.e. a no-op) is
50−possible, but has no effect on the `life`. Thus `life` is actually a measure of
51−networking key _revisions_, and not the number of times they've been set.
52−
53−Thus under ordinary circumstances, a breach will increment both `life` and
54−`rift` since a breach typically also involves changing the networking keys.
55−However, it is possible to breach without changing the networking keys.
56−If the new keys specified
57−as part of a breach are the same as the old, `rift` will increment while
58−`life` will not.
components/BackgroundImage.jsnew file+9
@@ -0,0 +1,9 @@
1+// Easily crops images
2+export default function BackgroundImage(props) {
3+ return (
4+ <div
5+ className={`bg-img bg-cover ${props.className || ""}`}
6+ style={{ backgroundImage: `url(${props.src})`, ...props.style }}
7+ />
8+ );
9+}
components/BasicPage.jsnew file+46
@@ -0,0 +1,46 @@
1+import { useRouter } from "next/router";
2+import Head from "next/head";
3+import Meta from "../components/Meta";
4+import ErrorPage from "../pages/404";
5+import {
6+ Container,
7+ SingleColumn,
8+ Section,
9+ Markdown,
10+ IntraNav,
11+ TableOfContents,
12+} from "@urbit/foundation-design-system";
13+import Header from "./Header";
14+import Footer from "./Footer";
15+import classNames from "classnames";
16+
17+export default function BasicPage({ post, markdown, search, index = false }) {
18+ const router = useRouter();
19+ if (!router.isFallback && !post?.slug) {
20+ return <ErrorPage />;
21+ }
22+ return (
23+ <Container>
24+ <Head>
25+ <title>{post.title}</title>
26+ {Meta(post)}
27+ </Head>
28+ <IntraNav ourSite="https://urbit.org" search={search} />
29+ <SingleColumn>
30+ <Header search={search} />
31+ <Section>
32+ <h1>{post.title}</h1>
33+ </Section>
34+ <Section>
35+ <div className={classNames("flex", { sidebar: index })}>
36+ <div className={classNames("markdown", { "max-w-prose": index })}>
37+ <Markdown.render content={JSON.parse(markdown)} />
38+ </div>
39+ {index && <TableOfContents />}
40+ </div>
41+ </Section>
42+ </SingleColumn>
43+ <Footer />
44+ </Container>
45+ );
46+}
components/Contact.jsnew file+16
@@ -0,0 +1,16 @@
1+import NewsletterSignup from "./NewsletterSignup";
2+
3+export default function Contact({
4+ emphasize,
5+ ecosystem = false,
6+ className = "",
7+}) {
8+ const linkText = emphasize ? "text-green-400" : "text-wall-600";
9+ const border = emphasize ? "border-green-400" : "border-wall-600";
10+
11+ return (
12+ <div className={className}>
13+ <NewsletterSignup color={border} />
14+ </div>
15+ );
16+}
components/ContentArea.jsnew file+86
@@ -0,0 +1,86 @@
1+import { useState, useEffect, useRef } from "react";
2+import { useRouter } from "next/router";
3+import { TableOfContents } from "@urbit/foundation-design-system";
4+
5+export default function ContentArea(props) {
6+ const [shortcut, setShortcut] = useState("");
7+
8+ const detectOS = () => {
9+ const agent = window.navigator.appVersion;
10+ if (agent.includes("Win")) {
11+ return "Ctrl+K";
12+ } else if (agent.includes("Mac")) {
13+ return "⌘K";
14+ } else if (agent.includes("Linux")) {
15+ return "Ctrl+K";
16+ }
17+ };
18+
19+ useEffect(() => {
20+ setShortcut(detectOS());
21+ }, []);
22+
23+ const scrollBox = useRef();
24+
25+ const router = useRouter();
26+
27+ useEffect(() => {
28+ const handleRouteChange = () => {
29+ if (scrollBox.current === null) return;
30+ scrollBox.current.scrollTop = 0;
31+ };
32+
33+ router.events.on("routeChangeComplete", handleRouteChange);
34+
35+ // If the component is unmounted, unsubscribe
36+ // from the event with the `off` method:
37+ return () => {
38+ router.events.off("routeChangeStart", handleRouteChange);
39+ };
40+ }, []);
41+
42+ return (
43+ <div className="w-full min-w-0 flex flex-col items-center bg-white">
44+ <div
45+ ref={scrollBox}
46+ className="px-4 md:px-12 lg:px-24 pt-8 md:pt-10 lg:pt-16 flex flex-col w-full max-w-screen-xl max-h-screen h-screen overflow-y-scroll"
47+ >
48+ <div className="flex justify-between w-full items-center shrink-0">
49+ <div className="font-semibold antialiased text-lg text-black">
50+ {props.breadcrumbs}
51+ </div>
52+ <div className="hidden md:block">
53+ <button
54+ onClick={(e) => {
55+ e.stopPropagation();
56+ props.search.toggleSearch();
57+ }}
58+ className="bg-wall-100 text-wall-500 flex px-4 py-1 rounded-lg type-ui"
59+ >
60+ Search<div className="ml-4 text-wall-400">{shortcut}</div>
61+ </button>
62+ </div>
63+ </div>
64+ <div className="flex justify-between">
65+ <div className="min-w-0 max-w-screen-md">
66+ <div className="mb-16">
67+ <h2 className="mt-24">{props.title}</h2>
68+ {props?.description && (
69+ <p className="text-wall-400 font-regular mt-2 text-xl">
70+ {props.description}
71+ </p>
72+ )}
73+ </div>
74+ {props.children}
75+ <div className="pb-24" />
76+ </div>
77+ {!props?.disableToC && (
78+ <TableOfContents
79+ key={props.params.slug?.join("/") || Math.random()}
80+ />
81+ )}
82+ </div>
83+ </div>
84+ </div>
85+ );
86+}
components/CopyLink.jsnew file+61
@@ -0,0 +1,61 @@
1+import { useCopyToClipboard } from "../lib/hooks";
2+
3+export default function CopyLink({ content, className }) {
4+ const [copyStatus, copy] = useCopyToClipboard(content);
5+
6+ const buttonIcon =
7+ copyStatus === "inactive" ? (
8+ <svg
9+ width="16"
10+ height="16"
11+ viewBox="0 0 16 16"
12+ className="fill-white"
13+ xmlns="http://www.w3.org/2000/svg"
14+ >
15+ <path
16+ fillRule="evenodd"
17+ clipRule="evenodd"
18+ d="M3.2 1.6C3.2 0.716344 3.91634 0 4.8 0H11.3615L14.9333 2.38124V12.2667C14.9333 13.1503 14.217 13.8667 13.3333 13.8667H12.8V14.4C12.8 15.2837 12.0837 16 11.2 16H2.66667C1.78301 16 1.06667 15.2837 1.06667 14.4V3.73333C1.06667 2.84968 1.78301 2.13333 2.66667 2.13333H3.2V1.6ZM3.2 3.2H2.66667C2.37211 3.2 2.13333 3.43878 2.13333 3.73333V14.4C2.13333 14.6946 2.37211 14.9333 2.66667 14.9333H11.2C11.4946 14.9333 11.7333 14.6946 11.7333 14.4V13.8667H4.8C3.91634 13.8667 3.2 13.1503 3.2 12.2667V3.2Z"
19+ />
20+ </svg>
21+ ) : copyStatus === "copied" ? (
22+ <svg
23+ width="16"
24+ height="16"
25+ viewBox="0 0 16 16"
26+ xmlns="http://www.w3.org/2000/svg"
27+ >
28+ <path
29+ fillRule="evenodd"
30+ clipRule="evenodd"
31+ d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM7.54325 11.4247L12.1498 5.66647L11.3169 5.00013L7.39013 9.90859L4.60812 7.59025L3.92526 8.40969L7.54325 11.4247Z"
32+ />
33+ </svg>
34+ ) : (
35+ <svg
36+ width="16"
37+ height="16"
38+ viewBox="0 0 16 16"
39+ className="fill-white"
40+ xmlns="http://www.w3.org/2000/svg"
41+ >
42+ <path
43+ fillRule="evenodd"
44+ clipRule="evenodd"
45+ d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM10.8229 11.5772L8.00004 8.75429L5.17716 11.5772L4.42292 10.8229L7.24579 8.00004L4.42292 5.17716L5.17716 4.42292L8.00004 7.24579L10.8229 4.42292L11.5772 5.17716L8.75429 8.00004L11.5772 10.8229L10.8229 11.5772Z"
46+ />
47+ </svg>
48+ );
49+
50+ return (
51+ <button
52+ className={`bg-wall-600 p-4 rounded-xl button-sm text-white flex items-center justify-center space-x-2 ${className}`}
53+ onClick={() => copy()}
54+ >
55+ <p className="leading-5">
56+ {copyStatus === "copied" ? "Copied" : "Shortcode"}
57+ </p>
58+ {buttonIcon}
59+ </button>
60+ );
61+}
components/DocsSidebar.jsnew file+32
@@ -0,0 +1,32 @@
1+import Link from "next/link";
2+import { useState } from "react";
3+import { MenuTray } from '@urbit/foundation-design-system'
4+
5+export default function Sidebar(props) {
6+ const [isOpen, setTray] = useState(false);
7+ return (
8+ <>
9+ <div className="hidden md:flex flex-col w-96 bg-wall-100 max-h-screen h-screen">
10+ <header className="flex shrink-0 justify-between items-center pl-6 pt-12 mt-5 pb-8">
11+ <Link href="/" passHref>
12+ <a className="font-semibold antialiased text-lg text-wall-500">Urbit</a>
13+ </Link>
14+ </header>
15+ <div className="overflow-y-auto p-6 pt-16">
16+ {props.children}
17+ <div className="pb-32" />
18+ </div>
19+ </div>
20+
21+ <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>
22+ <header className="flex shrink-0 justify-between items-center pb-8">
23+ <Link href="/" passHref>
24+ <a className="type-ui text-wall-500">Urbit</a>
25+ </Link>
26+ </header>
27+ {props.children}
28+ <div className="pt-64" />
29+ </MenuTray>
30+ </>
31+ );
32+}
components/EventPreview.jsnew file+92
@@ -0,0 +1,92 @@
1+import Link from "next/link";
2+import { DateTime } from "luxon";
3+import { DateRange } from "../components/Snippets";
4+import {
5+ generateDisplayDate,
6+ generateRealtimeDate,
7+} from "@urbit/foundation-design-system";
8+import classNames from "classnames";
9+
10+export default function EventPreview({ event, className, big }) {
11+ // Event tiles have a 'dark mode' used when their background images are dark and white text is needed for legibility.
12+ const grayText = event?.dark ? "text-white dark:text-black" : "text-wall-400";
13+ const blackText = event?.dark
14+ ? "text-white dark:text-black"
15+ : "text-wall-600";
16+
17+ const starts = generateDisplayDate(event.starts, event.timezone);
18+ const ends = generateDisplayDate(event.ends, event.timezone);
19+
20+ const inFuture = generateRealtimeDate(starts) > DateTime.now();
21+
22+ const happeningNow =
23+ generateRealtimeDate(event.starts) > DateTime.now() && !inFuture;
24+
25+ return (
26+ <div className={`cursor-pointer h-full ${className}`}>
27+ <div
28+ key={event.slug}
29+ className={`bg-wall-100 min-h-[320px] h-full flex flex-col rounded-xl bg-cover bg-center bg-no-repeat `}
30+ style={{ backgroundImage: `url(${event.image})` || "" }}
31+ >
32+ <Link href={`/events/${event.slug}`}>
33+ <div
34+ className={classNames(
35+ "flex flex-col p-6 min-h-[320px] justify-between items-between h-full relative",
36+ {
37+ "backdrop-brightness-50 rounded-xl": Boolean(
38+ event?.darken_image
39+ ),
40+ }
41+ )}
42+ >
43+ <div
44+ className={`grow-1 flex ${big ? "justify-center" : ""
45+ } flex-col h-full`}
46+ >
47+ <h3 className={`${blackText} mb-2`} id={event.title}>{event.title}</h3>
48+ <p className={blackText + " truncate text-sm"}>
49+ {event.description}
50+ </p>
51+ </div>
52+
53+ <div className="flex justify-between items-end">
54+ <div className="">
55+ <p className={`${blackText} type-sub mb-1`}>{event.location}</p>
56+ <DateRange
57+ starts={starts}
58+ ends={ends}
59+ className={`${grayText} type-sub`}
60+ />
61+ </div>
62+
63+ {inFuture && event.registration_url ? (
64+ <div>
65+ <a
66+ className="button-sm bg-green-400 text-white"
67+ href={event.registration_url}
68+ onClick={(e) => e.stopPropagation()}
69+ target="_blank"
70+ >
71+ RSVP
72+ </a>
73+ </div>
74+ ) : event.youtube ? (
75+ <div className="shrink-0">
76+ <a
77+ className="button-sm bg-wall-600 text-white shrink-0"
78+ href={`https://www.youtube.com/watch?v=${event.youtube}`}
79+ onClick={(e) => e.stopPropagation()}
80+ target="_blank"
81+ >
82+ ▶ Watch
83+ </a>
84+ </div>
85+ ) : null}
86+ </div>
87+ </div>
88+ </Link>
89+ </div>
90+ </div>
91+ );
92+}
components/Footer.jsnew file+6
@@ -0,0 +1,6 @@
1+import { Footer as FooterComponent } from "@urbit/foundation-design-system";
2+import { footerData } from "../lib/constants";
3+
4+export default function Footer() {
5+ return <FooterComponent data={footerData} />;
6+}
components/GrantPreview.jsnew file+63
@@ -0,0 +1,63 @@
1+import classnames from "classnames";
2+import Link from "next/link";
3+
4+export default function GrantPreview({ grant }) {
5+ const isCompleted = grant.extra.completed;
6+ const isOpen = !isCompleted && grant.extra.assignee?.[0] === "";
7+ const type = grant.taxonomies.grant_type;
8+
9+ const className = classnames({
10+ "bg-lightBlue": type.includes("Proposal") && isOpen,
11+ "bg-purple-200": type.includes("RFP") && isOpen,
12+ "bg-yellow-100": type.includes("Bounty") && isOpen,
13+ });
14+
15+ return (
16+ <div
17+ key={grant.slug}
18+ className={`mb-4 cursor-pointer bg-wall-100 rounded-lg ${className}`}
19+ >
20+ <Link href={`/grants/${grant.slug}`} passHref>
21+ <a>
22+ <div className="p-8">
23+ <div className="flex items-center mb-4">
24+ <h3 className="type-ui" id={grant.slug}>
25+ {grant.title}
26+ </h3>
27+ <div className={`bg-wall-500 text-wall-100 badge-sm ml-2`}>
28+ {!isCompleted ? (isOpen ? "Open" : "In Progress") : "Completed"}
29+ </div>
30+ </div>
31+ <p className="mb-4">{grant.extra.description}</p>
32+ <div className="flex w-full flex-col md:flex-row md:items-center justify-between">
33+ <p className="text-wall-500">
34+ <strong>Reward: </strong>
35+ {grant.extra.reward}
36+ </p>
37+ <div className="flex items-center flex-wrap md:mt-0 mt-4">
38+ {grant.taxonomies.grant_type.map((category) => {
39+ const className = classnames({
40+ "bg-blue-400 text-white": category === "Proposal",
41+ "bg-purple text-white": category === "RFP",
42+ "bg-green-400 text-white": category === "Apprenticeship",
43+ "bg-yellow-300": category === "Bounty",
44+ });
45+ return (
46+ <div className={`${className} badge-sm mr-1 my-1`}>
47+ {category}
48+ </div>
49+ );
50+ })}
51+ {grant.taxonomies.grant_category.map((category) => (
52+ <div className="bg-wall-500 text-wall-100 badge-sm mr-1 my-1">
53+ {category}
54+ </div>
55+ ))}
56+ </div>
57+ </div>
58+ </div>
59+ </a>
60+ </Link>
61+ </div>
62+ );
63+}
components/GrantProgramOverview.jsnew file+59
@@ -0,0 +1,59 @@
1+import { useRouter } from "next/router";
2+import Link from "next/link";
3+import Head from "next/head";
4+import Meta from "../components/Meta";
5+import ErrorPage from "../pages/404";
6+import {
7+ Container,
8+ Section,
9+ SingleColumn,
10+ Markdown,
11+ IntraNav,
12+ formatDate,
13+} from "@urbit/foundation-design-system";
14+import Header from "./Header";
15+import Footer from "./Footer";
16+import { DateTime } from "luxon";
17+
18+export default function GrantProgramOverview({
19+ post,
20+ markdown,
21+ search,
22+ program,
23+ actionLink,
24+ actionText,
25+}) {
26+ const router = useRouter();
27+ if (!router.isFallback && !post?.slug) {
28+ return <ErrorPage />;
29+ }
30+
31+ const title = program.charAt(0).toUpperCase() + program.slice(1);
32+ return (
33+ <Container>
34+ <Head>
35+ <title>{title} • Grants</title>
36+ {Meta(post)}
37+ </Head>
38+ <IntraNav ourSite="https://urbit.org" search={search} />
39+ <SingleColumn>
40+ <Header search={search} />
41+ <Section narrow short>
42+ <h1>{post.title}</h1>
43+ <div className="type-ui text-wall-500 mt-4 md:mt-8 lg:mt-10">
44+ Last Revision: {formatDate(DateTime.fromISO(post.date))}
45+ </div>
46+ <Link href={actionLink} passHref>
47+ <a className="button-sm bg-green-400 text-white mt-8 max-w-fit">
48+ {actionText}
49+ </a>
50+ </Link>
51+ </Section>
52+ <Section narrow short className="markdown">
53+ <Markdown.render content={JSON.parse(markdown)} />
54+ </Section>
55+ </SingleColumn>
56+ <Footer />
57+ </Container>
58+ );
59+}
components/Header.jsnew file+169
@@ -0,0 +1,169 @@
1+import Link from "next/link";
2+import { useRouter } from "next/router";
3+import { useState } from "react";
4+import classnames from "classnames";
5+import { capitalize, MenuTray } from "@urbit/foundation-design-system";
6+
7+function ActiveLink({ children, href, className, currentPath }) {
8+ const firstCrumb = currentPath.split("/")[1];
9+
10+ const activeClassName = classnames({
11+ "text-wall-900": "/" + firstCrumb === href,
12+ "text-wall-500": "/" + firstCrumb !== href,
13+ });
14+
15+ return (
16+ <Link href={href} passHref>
17+ <a className={`${className} ${activeClassName}`}>{children}</a>
18+ </Link>
19+ );
20+}
21+
22+export default function Header(props) {
23+ const [isOpen, setTray] = useState(false);
24+
25+ const currentPath = useRouter().asPath;
26+
27+ const routeDepth = currentPath.split("/").length;
28+
29+ const firstCrumb = currentPath.split("/")[1];
30+
31+ return (
32+ <header className="layout px-4 md:px-8 flex justify-between items-center pt-8 md:pt-10 lg:pt-12 pb-10 md:pb-12 lg:pb-24">
33+ <div>
34+ <Link href="/" passHref>
35+ <a className="font-semibold text-lg">Urbit</a>
36+ </Link>
37+ {routeDepth > 2 ? (
38+ <Link href={`/${firstCrumb}`} passHref>
39+ <a className="inline md:hidden type-ui text-wall-500 ml-2">
40+ {capitalize(firstCrumb)}
41+ </a>
42+ </Link>
43+ ) : null}
44+ </div>
45+ {
46+ // Large screen header
47+ }
48+ <nav className="items-center hidden md:flex">
49+ <ActiveLink
50+ currentPath={currentPath}
51+ className="mr-5 type-ui"
52+ href="/getting-started"
53+ >
54+ Get Started
55+ </ActiveLink>
56+
57+ <ActiveLink
58+ currentPath={currentPath}
59+ className="mr-5 type-ui"
60+ href="/overview"
61+ >
62+ Overview
63+ </ActiveLink>
64+
65+ <ActiveLink
66+ currentPath={currentPath}
67+ className="mr-5 type-ui"
68+ href="/ecosystem"
69+ >
70+ Ecosystem
71+ </ActiveLink>
72+
73+ <ActiveLink
74+ currentPath={currentPath}
75+ className="mr-5 type-ui"
76+ href="/grants"
77+ >
78+ Grants
79+ </ActiveLink>
80+
81+ <ActiveLink
82+ currentPath={currentPath}
83+ className="mr-5 type-ui"
84+ href="/events"
85+ >
86+ Events
87+ </ActiveLink>
88+
89+ <ActiveLink
90+ currentPath={currentPath}
91+ className="mr-5 type-ui"
92+ href="/blog"
93+ >
94+ Blog
95+ </ActiveLink>
96+ </nav>
97+
98+ {
99+ // Small screen header
100+ }
101+ <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>
102+ <Link href="/" passHref>
103+ <a className="font-semibold mb-4">Urbit</a>
104+ </Link>
105+ <Link href="https://urbit.org" passHref>
106+ <a className="font-semibold mt-2">Urbit.org</a>
107+ </Link>
108+ <Link href="https://operators.urbit.org" passHref>
109+ <a className="mt-2">Operators</a>
110+ </Link>
111+ <Link href="https://developers.urbit.org" passHref>
112+ <a className="mt-2">Developers</a>
113+ </Link>
114+ <Link href="https://roadmap.urbit.org" passHref>
115+ <a className="mt-2 mb-4">Roadmap</a>
116+ </Link>
117+ <hr className="border-wall-200" />
118+
119+ <ActiveLink
120+ currentPath={currentPath}
121+ className="mr-5 mt-4 mb-4 text-green-400"
122+ href="/getting-started"
123+ >
124+ Get Started
125+ </ActiveLink>
126+
127+ <ActiveLink
128+ currentPath={currentPath}
129+ className="mr-5 mb-4"
130+ href="/overview"
131+ >
132+ Overview
133+ </ActiveLink>
134+
135+ <ActiveLink
136+ currentPath={currentPath}
137+ className="mr-5 mb-4"
138+ href="/ecosystem"
139+ >
140+ Ecosystem
141+ </ActiveLink>
142+
143+ <ActiveLink
144+ currentPath={currentPath}
145+ className="mr-5 mb-4"
146+ href="/grants"
147+ >
148+ Grants
149+ </ActiveLink>
150+
151+ <ActiveLink
152+ currentPath={currentPath}
153+ className="mr-5 mb-4"
154+ href="/events"
155+ >
156+ Events
157+ </ActiveLink>
158+
159+ <ActiveLink
160+ currentPath={currentPath}
161+ className="mr-5 mb-4"
162+ href="/blog"
163+ >
164+ Blog
165+ </ActiveLink>
166+ </MenuTray>
167+ </header>
168+ );
169+}
components/HighlightCard.jsnew file+22
@@ -0,0 +1,22 @@
1+import Link from "next/link";
2+export default function HighlightCard({ slug, highlight }) {
3+ return (
4+ <Link href={highlight.url}>
5+ <div className="cursor-pointer bg-wall-100 rounded-xl min-h-0 flex-1">
6+ <div className="flex flex-col p-4 h-full relative">
7+ {highlight.image ? (
8+ <div className="w-64 md:w-full rounded-xl object-cover overflow-hidden basis-3/5">
9+ <img className="h-full w-64 md:w-full object-cover" src={highlight.image} />
10+ </div>
11+ ) : (
12+ <div className="rounded-xl w-full"/>
13+ )}
14+ <div className="pt-4">
15+ <p className="mb-2 font-semibold leading-5">{highlight.title}</p>
16+ <p className="text-sm leading-5">{highlight?.description}</p>
17+ </div>
18+ </div>
19+ </div>
20+ </Link>
21+ );
22+}
components/JoinGroup.jsnew file+79
@@ -0,0 +1,79 @@
1+import { useCopyToClipboard } from "../lib/hooks";
2+
3+export default function Contact({ emphasize, groupName, label, className }) {
4+ const [copyStatus, copy] = useCopyToClipboard(groupName);
5+
6+ const linkText = emphasize ? "text-green-400" : "text-wall-600";
7+ const border = emphasize ? "border-green-400" : "border-wall-600";
8+ const washedBg = emphasize ? "bg-green-100" : "bg-wall-100";
9+ const iconColor = emphasize ? "#00B171" : "#24221E";
10+
11+ const buttonIcon =
12+ copyStatus === "inactive" ? (
13+ <svg
14+ width="16"
15+ height="16"
16+ viewBox="0 0 16 16"
17+ fill="none"
18+ xmlns="http://www.w3.org/2000/svg"
19+ >
20+ <path
21+ fillRule="evenodd"
22+ clipRule="evenodd"
23+ d="M3.2 1.6C3.2 0.716344 3.91634 0 4.8 0H11.3615L14.9333 2.38124V12.2667C14.9333 13.1503 14.217 13.8667 13.3333 13.8667H12.8V14.4C12.8 15.2837 12.0837 16 11.2 16H2.66667C1.78301 16 1.06667 15.2837 1.06667 14.4V3.73333C1.06667 2.84968 1.78301 2.13333 2.66667 2.13333H3.2V1.6ZM3.2 3.2H2.66667C2.37211 3.2 2.13333 3.43878 2.13333 3.73333V14.4C2.13333 14.6946 2.37211 14.9333 2.66667 14.9333H11.2C11.4946 14.9333 11.7333 14.6946 11.7333 14.4V13.8667H4.8C3.91634 13.8667 3.2 13.1503 3.2 12.2667V3.2Z"
24+ fill={iconColor}
25+ />
26+ </svg>
27+ ) : copyStatus === "copied" ? (
28+ <svg
29+ width="16"
30+ height="16"
31+ viewBox="0 0 16 16"
32+ fill="none"
33+ xmlns="http://www.w3.org/2000/svg"
34+ >
35+ <path
36+ fillRule="evenodd"
37+ clipRule="evenodd"
38+ d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM7.54325 11.4247L12.1498 5.66647L11.3169 5.00013L7.39013 9.90859L4.60812 7.59025L3.92526 8.40969L7.54325 11.4247Z"
39+ fill={iconColor}
40+ />
41+ </svg>
42+ ) : (
43+ <svg
44+ width="16"
45+ height="16"
46+ viewBox="0 0 16 16"
47+ fill="none"
48+ xmlns="http://www.w3.org/2000/svg"
49+ >
50+ <path
51+ fillRule="evenodd"
52+ clipRule="evenodd"
53+ d="M0 8C0 3.58172 3.58172 0 8 0C12.4183 0 16 3.58172 16 8C16 12.4183 12.4183 16 8 16C3.58172 16 0 12.4183 0 8ZM10.8229 11.5772L8.00004 8.75429L5.17716 11.5772L4.42292 10.8229L7.24579 8.00004L4.42292 5.17716L5.17716 4.42292L8.00004 7.24579L10.8229 4.42292L11.5772 5.17716L8.75429 8.00004L11.5772 10.8229L10.8229 11.5772Z"
54+ fill={iconColor}
55+ />
56+ </svg>
57+ );
58+
59+ return (
60+ <div className={className}>
61+ <h4 className="text-wall-500 flex items-baseline flex-wrap">
62+ {label ? label + " " : ""}
63+ <div className="rounded-lg flex items-stretch">
64+ <code
65+ className={`rounded-l-lg px-2 md:px-4 py-2 ${washedBg} flex items-center h-full ${linkText}`}
66+ >
67+ {groupName}
68+ </code>
69+ <button
70+ className={`rounded-r-lg px-4 ml-0.5 flex-1 flex justify-center items-center ${washedBg}`}
71+ onClick={() => copy()}
72+ >
73+ {buttonIcon}
74+ </button>
75+ </div>
76+ </h4>
77+ </div>
78+ );
79+}
components/Meta.jsnew file+54
@@ -0,0 +1,54 @@
1+export default function Meta(post, disableImage, large = false) {
2+ const author = post?.extra?.author || "urbit.org";
3+ const title = post?.title ? post.title : "";
4+ const description =
5+ post?.description || "Urbit is a new kind of computer that you can own completely in ways that matter: networking, identity, & data.";
6+ const image =
7+ post?.extra?.image ||
8+ post?.image ||
9+ "https://storage.googleapis.com/media.urbit.org/site/opengraph/sig-white.png";
10+ return (
11+ <>
12+ <link rel="icon" type="image/png" href="/images/favicon.ico" />
13+ <link
14+ rel="apple-touch-icon"
15+ sizes="180x180"
16+ href="/images/apple-touch-icon.png"
17+ />
18+ <link
19+ rel="icon"
20+ type="image/png"
21+ sizes="32x32"
22+ href="/images/favicon-32x32.png"
23+ />
24+ <link
25+ rel="icon"
26+ type="image/png"
27+ sizes="16x16"
28+ href="/images/favicon-16x16.png"
29+ />
30+ <link rel="manifest" href="/images/site.webmanifest" />
31+
32+ <meta
33+ name="twitter:card"
34+ content={large ? "summary_large_image" : "summary"}
35+ key="twitter-card"
36+ />
37+ <meta name="twitter:site" content="@urbit" key="twitter-site" />
38+ <meta name="twitter:creator" content="@urbit" key="twitter-creator" />
39+ <meta name="og:title" content={title} key="title" />
40+ <meta name="og:description" content={description} key="description" />
41+ <meta name="description" content={description} />
42+ <meta name="author" content={author} key="author" />
43+ {!disableImage && (
44+ <meta name="twitter:image" content={image} key="image" />
45+ )}
46+ <link
47+ rel="alternative"
48+ type="application/rss+xml"
49+ title="RSS"
50+ href="/rss.xml"
51+ />
52+ </>
53+ );
54+}
components/NewsletterSignup.jsnew file+38
@@ -0,0 +1,38 @@
1+export default function NewsletterSignup(props) {
2+ return (
3+ <form
4+ action="https://urbit.us11.list-manage.com/subscribe/post?u=972a03db9e0c6c25bb58de8c8&amp;id=be143888d2"
5+ method="post"
6+ id="mc-embedded-subscribe-form"
7+ name="mc-embedded-subscribe-form"
8+ className="validate form max-w-screen-sm"
9+ target="_blank"
10+ noValidate
11+ >
12+ <div className="input-group" id="mc_embed_signup_scroll">
13+ <div className="mc-field-group w-full relative">
14+ <input
15+ className={`appearance-none outline-none text-wall-500 type-ui bg-white black ${
16+ props.color || "border-wall-600"
17+ } border-4 px-3 w-full mb-2 h-16 rounded-xl`}
18+ type="email"
19+ name="EMAIL"
20+ id="mce-EMAIL"
21+ placeholder="your@email.com"
22+ />
23+ <div className="flex h-16 items-center justify-center absolute top-0 right-6">
24+ <button
25+ id="mc-embedded-subscribe"
26+ className="type-ui dark:text-green-400 text-wall-500 bg-transparent"
27+ type="submit"
28+ name="subscribe"
29+ >
30+ {/* onClick={() => _paq.push(['trackEvent', 'Mailing List', 'Subscribe'])}> */}
31+ Sign Up
32+ </button>
33+ </div>
34+ </div>
35+ </div>
36+ </form>
37+ );
38+}
components/Pagination.jsnew file+22
@@ -0,0 +1,22 @@
1+import Link from "next/link";
2+export default function Pagination(props) {
3+ return (
4+ <Link
5+ href={`/${props.section}/${props.post.slug}`}
6+ key={`post-${props.post.slug}`}
7+ >
8+ <div
9+ className="bg-wall-100 cursor-pointer font-semibold p-2 px-4 rounded-xl flex"
10+ style={{ maxWidth: "45%" }}
11+ >
12+ <p className="shrink-0 pr-1">{props.previous ? "<- " : ""}</p>
13+ <p className="text-wall-600 truncate">{props.post.title}</p>
14+ <p className="shrink-0 pl-1">{props.next ? " ->" : ""}</p>
15+ </div>
16+ </Link>
17+ );
18+}
19+
20+Pagination.defaultProps = {
21+ className: "",
22+};
components/PostPreview.jsnew file+27
@@ -0,0 +1,27 @@
1+import {
2+ Card,
3+ formatDate,
4+ generateDisplayDate,
5+} from "@urbit/foundation-design-system";
6+
7+export default function PostPreview(props) {
8+ const section = props?.section ? props.section : "blog";
9+
10+ const date = generateDisplayDate(props.post.date);
11+ return (
12+ <Card
13+ slug={`/${section}/${props.post.slug}`}
14+ image={props.post.extra.image}
15+ title={props?.title || props.post?.title || ""}
16+ author={props.post?.extra?.author || ""}
17+ ship={props.post?.extra?.ship || ""}
18+ content={
19+ <div className="text-wall-500 type-sub mt-1">{formatDate(date)}</div>
20+ }
21+ />
22+ );
23+}
24+
25+PostPreview.defaultProps = {
26+ className: "",
27+};
components/Sidebar.jsnew file+21
@@ -0,0 +1,21 @@
1+import { useState } from "react";
2+import { MenuTray } from '@urbit/foundation-design-system';
3+
4+export default function Sidebar(props) {
5+ const [isOpen, setTray] = useState(false);
6+ return (
7+ <>
8+ <div className="hidden md:flex flex-col h-full sticky top-8">
9+ <div className="overflow-y-auto">
10+ {props.children}
11+ <div className="pb-32" />
12+ </div>
13+ </div>
14+
15+ <MenuTray isOpen={isOpen} setTray={setTray} search={props.search}>
16+ {props.children}
17+ <div className="pt-64" />
18+ </MenuTray>
19+ </>
20+ );
21+}
components/Snippets.jsnew file+111
@@ -0,0 +1,111 @@
1+import Link from "next/link";
2+import {
3+ formatDate,
4+ formatTime,
5+ formatTimeZone,
6+} from "@urbit/foundation-design-system";
7+
8+export function Name({ children, className }) {
9+ return <b className={`font-normal ${className || ""}`}>{children}</b>;
10+}
11+
12+export function Patp({ children, className }) {
13+ return (
14+ <Link href={`/ids/${children}`} passHref>
15+ <a>
16+ <code className={`font-mono ${className || ""}`}>{children}</code>
17+ </a>
18+ </Link>
19+ );
20+}
21+
22+// Used to render a human name alongside their @p
23+export function Person({
24+ name,
25+ patp,
26+ nameClassNames,
27+ patpClassNames,
28+ className,
29+}) {
30+ return (
31+ <>
32+ {patp && name ? (
33+ <>
34+ <Name className={nameClassNames}>{name}</Name>{" "}
35+ <Patp className={patpClassNames + " opacity-60"}>{patp}</Patp>
36+ </>
37+ ) : patp ? (
38+ <Patp className={patpClassNames}>{patp}</Patp>
39+ ) : name ? (
40+ <Name className={nameClassNames}>{name}</Name>
41+ ) : null}
42+ </>
43+ );
44+}
45+
46+// This goes inside a <p/> tag
47+export function ReadableList({ children, serial = ",", conjunction = "and" }) {
48+ return (
49+ <>
50+ {children.map((Child, index) => {
51+ if (index < children.length - 2) {
52+ return (
53+ <>
54+ {Child}
55+ {serial}
56+ </>
57+ );
58+ } else if (index < children.length - 1) {
59+ return (
60+ <>
61+ {Child} {conjunction}{" "}
62+ </>
63+ );
64+ }
65+ return <>{Child}</>;
66+ })}
67+ </>
68+ );
69+}
70+
71+export function ShowOrHide({ children, condition }) {
72+ if (condition) {
73+ return children;
74+ }
75+ return null;
76+}
77+
78+export function DateRange({ starts, ends, className, short }) {
79+ // For events which have no end datetime
80+ if (!ends.isValid) {
81+ return (
82+ <div>
83+ <p className={className}>
84+ {`${formatDate(starts)} • ${formatTime(starts)} ${formatTimeZone(
85+ starts
86+ )}`}
87+ </p>
88+ </div>
89+ );
90+ }
91+ // For events which start and end on the same day
92+ if (starts.hasSame(ends, "day")) {
93+ return (
94+ <div>
95+ <p className={className}>
96+ {`${formatDate(starts)} • ${formatTime(starts)} to ${formatTime(
97+ ends
98+ )} ${formatTimeZone(starts)}`}
99+ </p>
100+ </div>
101+ );
102+ }
103+ // For multi-day events
104+ return (
105+ <div>
106+ <p className={className}>{`${starts.toFormat(
107+ "cccc, LLLL d"
108+ )} to ${formatDate(ends)}`}</p>
109+ </div>
110+ );
111+}
components/TabCarousel.jsnew file+9
@@ -0,0 +1,9 @@
1+// Given multiple children, returns only 1 to be rendered based on props.index
2+export default function TabCarousel(props) {
3+ if (props.children) {
4+ if (props.children[props.index]) {
5+ return props.children[props.index]
6+ }
7+ }
8+ return null
9+}
components/ecosystem/Badge.jsnew file+20
@@ -0,0 +1,20 @@
1+import classnames from "classnames";
2+export default function EcosystemBadge({ type }) {
3+ return (
4+ <div
5+ className={classnames(
6+ "uppercase font-bold text-white text-xs w-fit rounded-lg mb-2 px-2 py-1",
7+ {
8+ "bg-[#B37ED7]": type === "Organization",
9+ "bg-[#83b2d4]": type === "Application",
10+ "bg-wall-600": type === "Podcast",
11+ "bg-[#8dd5b1]": type === "Marketplace",
12+ "bg-[#B5966D]": type === "Article",
13+ "bg-[#219DFF]": type === "Group",
14+ }
15+ )}
16+ >
17+ {type}
18+ </div>
19+ );
20+}
components/ecosystem/BasicPage.jsnew file+146
@@ -0,0 +1,146 @@
1+import { useRouter } from "next/router";
2+import Head from "next/head";
3+import Link from "next/link";
4+import Meta from "../Meta";
5+import ErrorPage from "../../pages/404";
6+import classnames from "classnames";
7+import {
8+ Container,
9+ SingleColumn,
10+ Section,
11+ Markdown,
12+ IntraNav,
13+} from "@urbit/foundation-design-system";
14+import Header from "../Header";
15+import Footer from "../Footer";
16+import MetadataBlock from "./MetadataBlock";
17+
18+export default function BasicPage({
19+ section,
20+ post,
21+ markdown,
22+ search,
23+ children,
24+}) {
25+ const router = useRouter();
26+ if (!router.isFallback && !post?.slug) {
27+ return <ErrorPage />;
28+ }
29+ const metaPost = Object.assign({}, post);
30+ metaPost.title = `${post.title} - ${section}`;
31+ metaPost.description =
32+ section === "Podcast" ? `${post.podcast} - ${post.date}` : post.description;
33+ section === "Article" ? `${post.publication} - ${post.date}` : post.description;
34+ return (
35+ <Container>
36+ <Head>
37+ <title>
38+ {post.title} • {section}
39+ </title>
40+ {Meta(metaPost)}
41+ </Head>
42+ <IntraNav ourSite="https://urbit.org" search={search} />
43+ <SingleColumn>
44+ <Header search={search} />
45+ <Section narrow className="space-y-12">
46+ <div className="flex items-center space-x-4">
47+ <img src={post.image} className="w-36" />
48+ <div className="flex flex-col pl-2">
49+ <h1 className="text-3xl">
50+ {post.title}
51+ </h1>
52+ <p>{section}</p>
53+ </div>
54+ </div>
55+ {/* General purpose metadata bar -- podcast listen button is special-cased URL, flexed at the end of the row */}
56+ <div className="flex justify-between">
57+ <div className="flex space-x-12">
58+ {post?.podcast && (
59+ <MetadataBlock
60+ title="Podcast"
61+ content={post.podcast}
62+ />
63+ )}
64+ {post?.publication && (
65+ <MetadataBlock
66+ title="Publication"
67+ content={post.publication}
68+ />
69+ )}
70+ {post?.author && (
71+ <MetadataBlock
72+ title="Author"
73+ content={post.author}
74+ />
75+ )}
76+ {post?.date && (
77+ <MetadataBlock
78+ title="Date"
79+ content={post.date}
80+ />
81+ )}
82+
83+ {post?.twitter && (
84+ <div className="flex flex-col">
85+ <p className="font-bold text-wall-400">Twitter</p>
86+ <Link href={"http://twitter.com/" + post.twitter}>
87+ <a className="text-green-400 text-sm font-semibold font-mono">@{post.twitter}</a>
88+ </Link>
89+ </div>
90+ )}
91+
92+
93+ {post?.URL && section !== "Podcast" && section !== "Article" && (
94+ <div className="flex flex-col">
95+ <p className="font-bold text-wall-400">Website</p>
96+ <a
97+ className="text-green-400 text-sm font-semibold font-mono"
98+ href={post.URL}
99+ >
100+ {post.URL.slice(post.URL.indexOf("://") + 3)}
101+ </a>
102+ </div>
103+ )}
104+
105+ {post?.URL && section === "Urbit Marketplace" && (
106+ <div className="flex flex-col">
107+ <p className="font-bold text-wall-400">Accepts</p>
108+ <p className="text-sm font-semibold font-mono">
109+ {post.payment.join(", ")}
110+ </p>
111+ </div>
112+ )}
113+ </div>
114+
115+
116+
117+ {post?.URL && section === "Podcast" && (
118+ <a
119+ href={post.URL}
120+ className="button-lg bg-green-400 text-white cursor-pointer flex space-x-2"
121+ >
122+ <img src="/images/sound.svg" />
123+ Listen
124+ </a>
125+ )}
126+ {post?.URL && section === "Article" && (
127+ <a
128+ href={post.URL}
129+ className="button-lg bg-green-400 text-white cursor-pointer flex space-x-2"
130+ >
131+ Read
132+ </a>
133+ )}
134+ </div>
135+ <div className="flex">
136+ <div className="markdown w-full">
137+ <Markdown.render content={JSON.parse(markdown)} />
138+ {children}
139+ </div>
140+ </div>
141+ </Section>
142+ </SingleColumn>
143+ <Footer />
144+ </Container>
145+ );
146+}
components/ecosystem/EcosystemSidebar.jsnew file+86
@@ -0,0 +1,86 @@
1+import { useRouter } from "next/router";
2+import Link from "next/link";
3+import classnames from "classnames";
4+function ActiveLink({ children, href, className, currentPath }) {
5+ // special casing this behaviour which overloads one nav
6+ const archive = Boolean(
7+ currentPath === "/ecosystem?type=archive" && href === "/ecosystem"
8+ );
9+ const activeClassName = classnames({
10+ "text-wall-800": currentPath === href || archive,
11+ "text-wall-400": currentPath !== href && !archive,
12+ });
13+
14+ return (
15+ <Link href={href} passHref>
16+ <a className={`${className} ${activeClassName}`}>{children}</a>
17+ </Link>
18+ );
19+}
20+
21+export default function EcosystemSidebar() {
22+ const router = useRouter();
23+ let currentPath = router.asPath;
24+ return (
25+ <div className="flex flex-col space-y-4 pr-24">
26+ <ActiveLink
27+ currentPath={currentPath}
28+ className="type-ui"
29+ href="/ecosystem"
30+ >
31+ Spotlight
32+ </ActiveLink>
33+ <ActiveLink
34+ currentPath={currentPath}
35+ className="type-ui"
36+ href="/ecosystem?type=communities"
37+ >
38+ Communities
39+ </ActiveLink>
40+ <ActiveLink
41+ currentPath={currentPath}
42+ className="type-ui"
43+ href="/ecosystem?type=organizations"
44+ >
45+ Organizations
46+ </ActiveLink>
47+
48+ <ActiveLink
49+ currentPath={currentPath}
50+ className="type-ui"
51+ href="/ecosystem?type=applications"
52+ >
53+ Applications
54+ </ActiveLink>
55+ <ActiveLink
56+ currentPath={currentPath}
57+ className="type-ui"
58+ href="/ecosystem?type=groups"
59+ >
60+ Groups
61+ </ActiveLink>
62+ <ActiveLink
63+ currentPath={currentPath}
64+ className="type-ui"
65+ href="/ecosystem?type=marketplaces"
66+ >
67+ Marketplaces
68+ </ActiveLink>
69+ <ActiveLink
70+ currentPath={currentPath}
71+ className="mr-5 type-ui"
72+ href="/ecosystem?type=podcasts"
73+ >
74+ Podcasts
75+ </ActiveLink>
76+
77+ <ActiveLink
78+ currentPath={currentPath}
79+ className="mr-5 type-ui"
80+ href="/ecosystem?type=articles"
81+ >
82+ Articles
83+ </ActiveLink>
84+ </div>
85+ );
86+}
components/ecosystem/IndexCard.jsnew file+34
@@ -0,0 +1,34 @@
1+import Link from "next/link";
2+import EcosystemBadge from "./Badge";
3+export default function IndexCard({ slug, feat }) {
4+ return (
5+ <Link href={slug}>
6+ <div className="cursor-pointer bg-wall-100 rounded-xl min-h-0 flex-1">
7+ <div className="flex flex-col p-4 h-full relative">
8+ {feat.image ? (
9+ <div
10+ className="w-64 md:w-full rounded-xl object-cover overflow-hidden basis-1/2"
11+ style={{
12+ backgroundColor: feat?.matchedPost?.bgColor || "rgba(0,0,0,0)",
13+ }}
14+ >
15+ <img className="h-full w-64 md:w-full object-cover" src={feat.image} />
16+ </div>
17+ ) : (
18+ <div
19+ className="rounded-xl w-full"
20+ style={{
21+ backgroundColor: feat?.matchedPost?.bgColor || "rgba(0,0,0,0)",
22+ }}
23+ />
24+ )}
25+ <div className="pt-4">
26+ <p className="mb-2 font-semibold leading-5">{feat.title}</p>
27+ <EcosystemBadge type={feat.type} />
28+ <p className="text-sm leading-5">{feat?.description}</p>
29+ </div>
30+ </div>
31+ </div>
32+ </Link>
33+ );
34+}
components/ecosystem/MetadataBlock.jsnew file+7
@@ -0,0 +1,7 @@
1+export default function MetadataBlock({ title, content }) {
2+ return <div className="flex flex-col py-2 basis-1/2">
3+ <p className="font-bold text-wall-400">{title}</p>
4+ <p>{content}</p>
5+ </div>
6+
7+}
components/ecosystem/Post.jsnew file+107
@@ -0,0 +1,107 @@
1+import { Markdown } from "@urbit/foundation-design-system";
2+import EcosystemBadge from "./Badge";
3+
4+import Link from "next/link";
5+export default function Post({ post }) {
6+ return ["featured-1", "featured-2", "featured-3"].map((feat) => {
7+ const childPath =
8+ post[feat] && (post[feat]?.matchedPost?.type === "Application" || post[feat]?.matchedPost?.type === "Group")
9+ ? `${post[feat]?.matchedPost.ship}/${post[feat].matchedPost.slug}`
10+ : `${post[feat].matchedPost?.slug}`;
11+ const href = post[feat]?.matchedPost
12+ ? `/${post[feat].matchedPost.type.toLowerCase()}s/${childPath}`
13+ : null;
14+ return post?.[feat] ? (
15+ <div
16+ className="mt-8 mb-24"
17+ id={post?.[feat].title.toLowerCase().replace(/ /, "-")}
18+ >
19+ <div className="flex space-x-4 items-center">
20+ <div
21+ className="h-24 w-24 rounded-xl items-center justify-center shrink-0 overflow-hidden"
22+ style={{
23+ backgroundColor:
24+ post[feat]?.matchedPost?.bgColor || "rgba(0,0,0,0)",
25+ }}
26+ >
27+ {(post[feat]?.matchedPost?.image || post[feat]?.matchedPost?.tile) && (
28+ <img
29+ className="rounded-xl w-24 object-cover"
30+ src={post[feat]?.matchedPost?.image || post[feat]?.matchedPost?.tile}
31+ />
32+ )}
33+ </div>
34+ <div className="flex flex-col">
35+ <h4 className="text-xl pb-2 leading-6 font-bold">
36+ {post?.[feat].title}
37+ </h4>
38+ <EcosystemBadge type={post[feat].type} />
39+ </div>
40+ </div>
41+ <div className="markdown mt-8 mb-8">
42+ <Markdown.render content={JSON.parse(post[feat].content)} />
43+ </div>
44+
45+ {post[feat].type === "Podcast" && (
46+ <Link href={href || "#"} passHref>
47+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
48+ Listen to {post[feat].type}
49+ </a>
50+ </Link>
51+ )}
52+
53+ {post[feat].type === "Article" && (
54+ <Link href={href || "#"} passHref>
55+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
56+ Read {post[feat].type}
57+ </a>
58+ </Link>
59+ )}
60+
61+ {post[feat].type === "Application" && (
62+ <Link href={href || "#"} passHref>
63+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
64+ View {post[feat].type}
65+ </a>
66+ </Link>
67+ )}
68+
69+ {post[feat].type === "Organization" && (
70+ <Link href={href || "#"} passHref>
71+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
72+ More about {post[feat].title}
73+ </a>
74+ </Link>
75+ )}
76+
77+ {post[feat].type === "Community" && (
78+ <Link href={href || "#"} passHref>
79+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
80+ More about {post[feat].title}
81+ </a>
82+ </Link>
83+ )}
84+
85+
86+ {post[feat].type === "Marketplace" && (
87+ <Link href={href || "#"} passHref>
88+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
89+ More about {post[feat].title}
90+ </a>
91+ </Link>
92+ )}
93+
94+ {post[feat].type === "Group" && (
95+ <Link href={href || "#"} passHref>
96+ <a class="button-sm text-white flex-col bg-green-400 cursor-pointer pr-4 w-fit">
97+ More about {post[feat].title}
98+ </a>
99+ </Link>
100+ )}
101+
102+ </div>
103+ ) : null;
104+ });
105+}
106+
107+
components/ecosystem/SpotlightArchive.jsnew file+66
@@ -0,0 +1,66 @@
1+import { Container, IntraNav, SingleColumn, Section } from "@urbit/foundation-design-system";
2+import Header from "../Header";
3+import Footer from "../Footer";
4+import Meta from "../Meta";
5+import Head from "next/head";
6+import Link from "next/link";
7+import EcosystemSidebar from "./EcosystemSidebar";
8+import Sidebar from "../Sidebar";
9+
10+export default function SpotlightArchive({ posts, search }) {
11+ const post = {
12+ title: "Spotlight Archive",
13+ description: "The archive of ecosystem spotlights.",
14+ };
15+ return (
16+ <Container>
17+ <Head>
18+ <title>Archive • Spotlight • Urbit</title>
19+ {Meta(post)}
20+ </Head>
21+ <IntraNav ourSite="https://urbit.org" search={search} />
22+ <SingleColumn>
23+ <Header search={search} />
24+ <Section>
25+ <div className="measure">
26+ <h1>Ecosystem</h1>
27+ </div>
28+ </Section>
29+ <Section className="flex">
30+ <Sidebar>
31+ <EcosystemSidebar />
32+ </Sidebar>
33+ <div>
34+ <h3 className="mb-12">Spotlight Archive</h3>
35+ {posts.map((post) => {
36+ return (
37+ <div key={post.slug} className="mb-24 cursor-pointer">
38+ <Link href={`/ecosystem/spotlight/${post.slug}`}>
39+ <div>
40+ <h3 className="text-green-400">{post.title}</h3>
41+ <div className="type-ui mt-2">
42+ {["featured-1", "featured-2", "featured-3"].map(
43+ (feat, i) => {
44+ if (post?.[feat]) {
45+ return (
46+ <>
47+ {i ? ", " : ""}
48+ <span>{post[feat].title}</span>
49+ </>
50+ );
51+ }
52+ }
53+ )}
54+ </div>
55+ </div>
56+ </Link>
57+ </div>
58+ );
59+ })}
60+ </div>
61+ </Section>
62+ </SingleColumn>
63+ <Footer />
64+ </Container>
65+ );
66+}
components/gateway/Description.jsnew file+19
@@ -0,0 +1,19 @@
1+import { Markdown } from "@urbit/foundation-design-system";
2+
3+const Description = ({ description, fallback, markdown }) => {
4+ return (
5+ (description !== fallback || markdown) && (
6+ <div className="flex flex-col space-y-4">
7+ {markdown ? (
8+ <div className="markdown">
9+ <Markdown.render content={JSON.parse(markdown)} />
10+ </div>
11+ ) : (
12+ <p>{description}</p>
13+ )}
14+ </div>
15+ )
16+ );
17+};
18+
19+export default Description;
components/gateway/Gateway404.jsnew file+29
@@ -0,0 +1,29 @@
1+import GatewayHeader from "./GatewayHeader";
2+import {
3+ Container,
4+ SingleColumn,
5+ Section,
6+} from "@urbit/foundation-design-system";
7+import Link from "next/link";
8+
9+const Gateway404 = ({ type }) => {
10+ return (
11+ <Container>
12+ <SingleColumn>
13+ <Section narrow className="space-y-12">
14+ <GatewayHeader
15+ title="Error 404"
16+ error
17+ item={`No ${type} at this address`}
18+ />
19+ <hr className="text-wall-200" />
20+ <Link href="/" passHref>
21+ <a className="text-xl block font-semibold">Urbit.org</a>
22+ </Link>
23+ </Section>
24+ </SingleColumn>
25+ </Container>
26+ );
27+};
28+
29+export default Gateway404;
components/gateway/GatewayHeader.jsnew file+29
@@ -0,0 +1,29 @@
1+import GatewayImage from "./Image";
2+
3+const GatewayHeader = ({
4+ image,
5+ patp,
6+ color,
7+ subtitle,
8+ subtitleMono,
9+ error,
10+ title,
11+ item,
12+}) => {
13+ return (
14+ <div className="flex items-center space-x-4">
15+ <GatewayImage patp={patp} color={color} image={image} error={error} />
16+ <div className="flex flex-col">
17+ <h2>{title}</h2>
18+ {subtitle && (
19+ <p className={(subtitleMono ? "font-mono" : "font-sans") }>
20+ {subtitle}
21+ </p>
22+ )}
23+ <p className="mt-1">{item}</p>
24+ </div>
25+ </div>
26+ );
27+};
28+
29+export default GatewayHeader;
components/gateway/Image.jsnew file+62
@@ -0,0 +1,62 @@
1+import { Sigil } from "@urbit/foundation-design-system";
2+const GatewayImage = ({
3+ error = false,
4+ patp = false,
5+ color = "transparent",
6+ image = "",
7+ size = 100,
8+}) => {
9+ if (error) {
10+ return (
11+ <div className="overflow-hidden rounded-xl shrink-0">
12+ <svg
13+ width={size}
14+ height={size}
15+ viewBox="0 0 100 100"
16+ fill="none"
17+ xmlns="http://www.w3.org/2000/svg"
18+ >
19+ <rect width="100" height="100" rx="10" className="fill-wall-600" />
20+ <path
21+ d="M28.8906 27.9844C28.5019 28.0215 28.1699 28.2833 28.043 28.6524C27.914 29.0235 28.0137 29.4336 28.2969 29.7032L70.2969 71.7032C70.4844 71.8965 70.7402 72.0059 71.0098 72.0059C71.2773 72.0079 71.5352 71.9004 71.7246 71.709C71.9141 71.5176 72.0176 71.2598 72.0137 70.9903C72.0098 70.7227 71.8984 70.4668 71.7031 70.2813L66.2501 64.8283C69.8204 60.9181 72.0001 55.7073 72.0001 50.0003C72.0001 37.8618 62.1386 28.0003 50.0001 28.0003C44.2931 28.0003 39.0976 30.1956 35.1876 33.7658L29.7031 28.2813C29.4922 28.0645 29.1934 27.9551 28.8906 27.9844L28.8906 27.9844ZM50.0001 30C61.0566 30 70.0001 38.9435 70.0001 50C70.0001 55.17 68.0411 59.8575 64.8281 63.406L36.5936 35.1715C40.1405 31.9606 44.8336 29.9995 49.9996 29.9995L50.0001 30ZM32.1721 37.8125C31.842 37.8321 31.5452 38.0137 31.3752 38.2969C29.2424 41.6856 28.0002 45.7029 28.0002 49.9999C28.0002 62.1384 37.8617 71.9999 50.0002 71.9999C54.2951 71.9999 58.3147 70.7558 61.7032 68.6249C62.1739 68.3319 62.3165 67.7128 62.0235 67.2421C61.7305 66.7714 61.1114 66.6288 60.6407 66.9218C57.5587 68.8593 53.9122 69.9999 50.0002 69.9999C38.9437 69.9999 30.0002 61.0564 30.0002 49.9999C30.0002 46.0878 31.1233 42.4414 33.0627 39.3594C33.2697 39.043 33.2815 38.6387 33.092 38.3125C32.9045 37.9844 32.5491 37.7929 32.1721 37.8125L32.1721 37.8125Z"
22+ className="fill-white"
23+ />
24+ </svg>
25+ </div>
26+ );
27+ }
28+
29+ if (patp) {
30+ return (
31+ <div className="rounded-xl overflow-hidden shrink-0">
32+ <Sigil patp={patp} size={size} color={color} />
33+ </div>
34+ );
35+ }
36+
37+ if (image?.startsWith("#")) {
38+ return (
39+ <div
40+ style={{ height: size, width: size, backgroundColor: image }}
41+ className="rounded-xl shrink-0"
42+ />
43+ );
44+ }
45+
46+ return image ? (
47+ <div
48+ className="rounded-xl overflow-hidden shrink-0"
49+ style={{ backgroundColor: color }}
50+ >
51+ <img src={image} style={{ height: size, width: size }} />
52+ </div>
53+ ) : (
54+ <img
55+ className="object-contain shadow-sm rounded-xl"
56+ style={{ height: size, width: size }}
57+ src="https://media.urbit.org/public-links/placeholder-image.png"
58+ />
59+ );
60+};
61+
62+export default GatewayImage;
components/gateway/MetadataBlock.jsnew file+8
@@ -0,0 +1,8 @@
1+const MetadataBlock = ({ title, content }) => (
2+ <div className="flex flex-col basis-1/2 pr-2 sm:basis-1/4 mb-4 md:mb-0 flex-1">
3+ <p className="font-bold text-wall-400">{title}</p>
4+ <p className="font-mono">{content}</p>
5+ </div>
6+);
7+
8+export default MetadataBlock;
components/gateway/MetadataLink.jsnew file+14
@@ -0,0 +1,14 @@
1+import Link from "next/link";
2+
3+const MetadataLink = ({ title, href, content }) => (
4+ <div className="flex flex-col basis-1/2 sm:basis-1/4 pr-2 mb-4 min-w-0 flex-1">
5+ <p className="font-bold text-wall-400">{title}</p>
6+ <Link href={href}>
7+ <div className="flex truncate">
8+ <a className="truncate font-mono text-green-400">{content}</a>
9+ </div>
10+ </Link>
11+ </div>
12+);
13+
14+export default MetadataLink;
components/gateway/ResourceCard.jsnew file+24
@@ -0,0 +1,24 @@
1+import Link from "next/link";
2+import GatewayImage from "./Image";
3+import classNames from "classnames";
4+import { capitalize } from "@urbit/foundation-design-system";
5+
6+const ResourceCard = ({ type, shortcode, title, description = "", color, image, full }) => (
7+ <Link href={`/${type}s/${shortcode}`}>
8+ <div className={classNames("cursor-pointer rounded-xl bg-wall-100 p-4 flex items-center space-x-4 mr-2 my-1", {
9+ "basis-full": full
10+ })}>
11+ <GatewayImage color={color} image={image || color} size={50} />
12+ {full
13+ ? <><div className="flex flex-col w-full">
14+ <a className="font-semibold">{title}</a>
15+ <p className="hidden lg:block">{description}</p>
16+ </div>
17+ <a className="button-lg bg-green-400 text-white shrink-0">View {capitalize(type)}</a>
18+ </>
19+ : <a className="font-semibold">{title}</a>}
20+ </div>
21+ </Link>
22+);
23+
24+export default ResourceCard;
components/icons/Cross.jsnew file+11
@@ -0,0 +1,11 @@
1+export default function Cross(props) {
2+ return (
3+ <svg {...props} viewBox="0 0 12 12">
4+ <path
5+ fillRule="evenodd"
6+ clipRule="evenodd"
7+ d="M0.292893 10.2942C-0.0976311 10.6847 -0.0976311 11.3179 0.292893 11.7084C0.683417 12.0989 1.31658 12.0989 1.70711 11.7084L6.00063 7.41487L10.2948 11.7091C10.6853 12.0996 11.3185 12.0996 11.709 11.7091C12.0996 11.3185 12.0996 10.6854 11.709 10.2949L7.41484 6.00066L11.7084 1.70711C12.0989 1.31658 12.0989 0.683417 11.7084 0.292894C11.3179 -0.0976312 10.6847 -0.0976312 10.2942 0.292894L6.00063 4.58645L1.70775 0.293571C1.31723 -0.0969534 0.684061 -0.0969534 0.293536 0.293571C-0.0969879 0.684095 -0.0969879 1.31726 0.293536 1.70778L4.58641 6.00066L0.292893 10.2942Z"
8+ />
9+ </svg>
10+ );
11+}
components/index/BubbleLink.jsnew file+25
@@ -0,0 +1,25 @@
1+export default function BubbleLink(props) {
2+ return (
3+ <li className={"list-none " + props.className}>
4+ <a className={"flex"} href={props.href} target={props.target}>
5+ <div>{props.children}</div>
6+ <div className="flex flex-col ml-4">
7+ <p className="font-bold">{props.title}</p>
8+ <p className="text-wall-400 dark:text-antiwall-400 font-bold leading-snug">
9+ {props.caption}
10+ </p>
11+ </div>
12+ </a>
13+ </li>
14+ );
15+}
16+
17+BubbleLink.defaultProps = {
18+ className: "",
19+ title: "",
20+ caption: "",
21+ children: (
22+ <div className="w-12 h-12 bg-wall-500 dark:bg-antiwall-500 rounded-full" />
23+ ),
24+ target: "_blank",
25+};
content/applications/_index.mdnew file+3
@@ -0,0 +1,3 @@
1++++
2+title = "Application Directory"
3++++
content/applications/~bacwyl-samweg/templeochess.mdnew file+22
@@ -0,0 +1,22 @@
1++++
2+title = "Temple O Chess"
3+shortcode = "~bacwyl-samweg/templeochess"
4+license = "MIT"
5+image = "https://0x0.st/oFuT.png"
6+bgColor = "#FFFF55"
7+developer = "~bacwyl-samweg"
8+website = "https://youtu.be/Raej8C2yIEc"
9+description = "chess game from Temple OS"
10++++
11+
12+### Chess from Temple OS
13+
14+
15+Temple O Chess is a pixel-for-pixel reproduction of the chess game from Temple OS.
16+
17+It was created using [this youtube video](https://youtu.be/Raej8C2yIEc) as a reference.
18+
19+It's a fully playable online chess game. Instead of a challenge system, games are formed using a naive public queue.
20+
21+Just queue up, and you will be automatically matched with the next (or previous) player.
22+
content/applications/~datder-sonnet/hodl.mdnew file+16
@@ -0,0 +1,16 @@
1++++
2+title = "hodl"
3+description = "Track your digital hodlings"
4+shortcode = "~hodler-datder-sonnet/hodl"
5+license = "MIT"
6+image = "https://user-images.githubusercontent.com/16504501/194947852-8802fd63-5954-4ce8-b147-2072bd929242.png"
7+bgColor = "#b8a3d1"
8+developer = "~datder-sonnet"
9+website = "https://github.com/tomholford/hodl"
10++++
11+
12+A portfolio app for tracking your digital assets.
13+
14+Add transactions to get a summary of your crypto net worth.
15+
16+Supports over 13K coins via the Coingecko API.
content/applications/~disreb-winner-mittec/urbit-go.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Go"
3+shortcode = "~disreb-winner-mittec/urbit-go"
4+license = "GPLv3"
5+image = "https://winnermittec.space/icon.svg"
6+bgColor = "#D37504"
7+developer = "~winner-mittec"
8+website = "https://winnermittec.space/"
9+description = "Go on Urbit"
10++++
11+
12+The classic board-game Go, now on Urbit!
content/applications/~dister-dister-datryn-ribdun/campfire.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Campfire"
3+shortcode = "~dister-dister-datryn-ribdun/campfire"
4+description = "Voice and video chat"
5+license = "MIT"
6+image = "https://raw.githubusercontent.com/datryn-ribdun/urbit-webrtc/master/campfire/logo.svg"
7+bgColor = "#FFC179"
8+developer = "~datryn-ribdun"
9+website = "https://github.com/datryn-ribdun/urbit-webrtc"
10++++
11+
12+Hang out with your friends. Voice and video chat by Holium.
content/applications/~dister-dister-sidnym-ladrut/quorum.mdnew file+17
@@ -0,0 +1,17 @@
1++++
2+title = "Quorum"
3+shortcode = "~dister-dister-sidnym-ladrut/quorum"
4+developer = "Quorum Team"
5+description = "A choral explanations app for Urbit"
6+license = "MIT"
7+website = ""
8+bgColor = ""
9+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/quorum-logo.png"
10++++
11+
12+Quorum is a Stack Overflow/Quora style application that allows individuals to submit and vote on questions and answers in threads.
13+
14+To join the Urbit Foundation's [battery payload] board, when prompted to add a board, enter `~dister-dozzod-lapdeg` as the provider, and `battery-payload` as the board.
15+
16+
17+
content/applications/~dister-dozzod-bacdun/uqbar-suite.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "Uqbar Development Suite"
3+shortcode = "~dister-dozzod-bacdun/zig"
4+developer = "Uqbar"
5+description = "The contract & app development, wallet, and block explorer suite from Uqbar."
6+license = "MIT"
7+website = "https://uqbar.network"
8+bgColor = ""
9+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/uqbarsuite.png"
10++++
11+
12+The Uqbar Development Suite, also known as Ziggurat, is an all-in-one developer suite designed to give programmers a seamless coding experience as they create and deploy smart contracts and blockchain-integrated Urbit apps to our testnet. The Ziggurat suite consists of:
13+
14+
15+
16+
17+
18+
19+
20+For more information, read our [Developer Docs](https://uqbar-network.gitbook.io/uqbar-developer-documentation/developer-documentation/developer-documentation).
content/applications/~dister-dozzod-dalten/books.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "Books"
3+developer = "Quartus Co."
4+shortcode = "~dister-dozzod-dalten/books"
5+description = "It just makes cents"
6+license = "MIT"
7+website = "https://dalten.org"
8+bgColor = "#E44D11"
9++++
10+
11+Books is an application for managing your crypto wallets, transactions, and counterparties. It allows you to add your wallet and other people’s, track balances and transactions, and add private annotations to all of the above.
12+
13+
14+
15+## Books in a Nutshell
16+If you spend much time interacting with crypto, you probably have a few wallets: a few hot wallets in metamask, a ledger or two, perhaps an Urbit ID on a master ticket, and that’s just Ethereum.
17+
18+To get a good picture of your aggregate activity you can use a variety of chain analytics tools, but there’s always a sizable catch: there’s nowhere to record the identities of the counter parties you transact with, or the purpose of the transactions. To do this now, your options are to either keep your own records (offline), use a local-storage based address book like Metamask’s, or put your data on someone else’s servers.
19+
20+Books provides an ideal solution: annotate on-chain, public information with private data stored on your urbit, your personal server. This lets you account for your spending, keep records of the people you transact with, and organize your wallets without compromising on privacy or mobility.
content/applications/~dister-dozzod-dalten/gora.mdnew file+24
@@ -0,0 +1,24 @@
1++++
2+title = "Gora - ピタゴラ装置"
3+developer = "~dalten"
4+shortcode = "~mister-dozzod-dalten/gora"
5+description = "A Proof of Attendance Protocol for Urbit"
6+license = "MIT"
7+website = "https://dalten.org"
8+bgColor = "#FCD977"
9++++
10+
11+### A Proof of Attendance Protocol for Urbit
12+
13+Gora is a proof of presence protocol (POPP) that is
14+intended to be extensible, flexible and educational
15+(at least for new hooners).
16+
17+
18+
19+
20+Gora has two distros in
21+circulation - these can be found at:
22+~laddys-dozzod-dalten (Vue.js frontend)
23+~mister-dozzod-dalten (sail frontend)
24+The canonical distro for all Quartus and Dalten Collective apps can always be found at ~dister-dozzod-dalten
content/applications/~dister-dozzod-dalten/keep.mdnew file+13
@@ -0,0 +1,13 @@
1++++
2+title = "Keep"
3+developer = "Quartus Co."
4+shortcode = "~dister-dozzod-dalten/keep"
5+description = "State backup for your agents"
6+license = "MIT"
7+website = "https://dalten.org"
8+bgColor = "#E44D11"
9++++
10+
11+Keep is backup utility for preserving the state of your applications across breaches. Unlike [peat](https://urbit.org/ecosystem/applications/~dister-dozzod-dalten/peat), Keep can backup the state of any arbitrary agent, but does not offer granular control of specific graphs or other targeted contexts.
12+
13+For support with any of Quartus' applications, please visit the [Quartus public group](https://urbit.org/ecosystem/groups/~mister-hilper-dozzod-dalten/quartus)
content/applications/~dister-dozzod-dalten/orca.mdnew file+17
@@ -0,0 +1,17 @@
1++++
2+title = "Orca"
3+developer = "Quartus Co."
4+shortcode = "~dister-dozzod-dalten/orca"
5+description = "Now THIS is podchatting"
6+license = "MIT"
7+website = "https://dalten.org"
8+bgColor = "#13181C"
9++++
10+
11+** ocra has been deprecated and will soon be replaced with updated tooling supporting chat federation for the new Groups backend **
12+
13+Now THIS is podchatting
14+
15+
16+
17+
content/applications/~dister-dozzod-dalten/peat.mdnew file+36
@@ -0,0 +1,36 @@
1++++
2+title = "peat"
3+developer = "Quartus Co."
4+shortcode = "~dister-dozzod-dalten/peat"
5+description = "Graph Backup and Restoration Utility"
6+license = "REKT"
7+website = "https://dalten.org"
8+bgColor = "#574D5A"
9++++
10+
11+Peat is Urbit's first backup utility and works with the %graph-store backend. Quartus is also working to support backup and recovery for arbitrary agent state via %keep, as well as updated utility tooling that supports the new Groups backend.
12+
13+
14+
15+## Peat in a Nutshell
16+- Import
17+ - Recover a Social `graph` from a saved file - transferrable between ships
18+- Export
19+ - Export a Social `graph` to a file on underlying file system (e.g. Unix)
20+- Backup/Restore
21+ - Local recreation of a `graph` that exists, 're-basing' the `graph` to be hosted by the local ship
22+## Import from Disk - Details
23+- User has a `/path/to/pier/<project-desk>/hav` directory for importing (though they could import from anywhere, really).
24+- User also has a form interface, through Peat's webapp allowing them to import without tracking the files in their loom.
25+### From Clay
26+- User gets instructions from the frontend as to how to add files to this directory and commit the desk so the files are available in the OS
27+ - NOTE: This should be converted to using `drum`'s `get` functionality at some point, but this hasn't been wired up yet in `drum`.
28+- User can see all files available for restoration in the default `hav` directory, delineated by whether they represent Agent `state` or `graph`s
29+- User can select a file for restoration
30+- User can apply the file for restoration
31+ - Potentially needing to specify additional details, for a `graph` (e.g. what `group` to associate it with, and what to call the new `resource`)
32+User is informed that the restoration is underway/has completed
33+### From Web
34+- User gets instructions from the frontend as to how to upload files through the frontend, resulting in their unpacking and importing to graph store
35+- User can select from local files on the computer through which they're accessing the frontend.
36+- Note: This method avoids polluting loom with transient files - it is to be the preferred method
content/applications/~dister-dozzod-dalten/wrdu.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "wrdu"
3+developer = "Quartus Co."
4+shortcode = "~dister-dozzod-dalten/wrdu"
5+description = "Word game by ~dalten for our mothers"
6+license = "MIT"
7+website = "https://dalten.org"
8+bgColor = "#79A86B"
9++++
10+
11+word game by ~dalten for our mothers
12+
13+
14+
15+
content/applications/~donpub-datdux/forms.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Forms"
3+shortcode = "~donpub-datdux/forms"
4+developer = "~nallux-dozryl"
5+description = "Publish and Respond to Forms."
6+license = "MIT"
7+website = "https://github.com/nallux-dozryl/urbit-forms"
8+bgColor = "#AFC4E0"
9+image = ""
10++++
11+
12+Create and fill out forms and surveys on Urbit.
13+
14+
content/applications/~fabnev-hinmur/escape.mdnew file+16
@@ -0,0 +1,16 @@
1++++
2+title = "EScape"
3+shortcode = "~dister-fabnev-hinmur/escape"
4+developer = "Uqbar"
5+description = "EScape from Eternal September. The UI from Uqbar."
6+license = "MIT"
7+website = "https://uqbar.network"
8+bgColor = "#f2f3ef"
9+image = "https://escape-app-dist.s3.us-east-2.amazonaws.com/escape-logo.png"
10++++
11+
12+EScape is a fully-integrated social management and DAO Tooling system. EScape provides a simple, intuitive, and unified interface for managing groups, messaging ships, receiving notifications, and interacting with other Urbit apps.
13+
14+
15+
16+Get EScape on [iOS](https://apps.apple.com/my/app/escape-by-uqbar/id1610194217) and [Android](https://play.google.com/store/apps/details?id=network.uqbar.escape).
content/applications/~fabnev-hinmur/handshake.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Handshake"
3+developer = "Uqbar"
4+shortcode = "~dister-fabnev-hinmur/handshake"
5+description = "Confirm Urbit IDs via QR code."
6+license = "MIT"
7+website = "https://uqbar.network"
8+bgColor = "#df828b"
9+image = "https://static.thenounproject.com/png/2002633-200.png"
10++++
11+
12+Handshake generates and verifies QR codes for admission into IRL events.
13+
14+
content/applications/~finmep-lanteb/chess.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Chess"
3+shortcode = "~finmep-lanteb/chess"
4+developer = "~bonbud-macryg, ~finmep-lanteb, ~nordus-mocwyl, ~rovmug-ticfyn, ~sigryn-habrex"
5+description = "Fully peer-to-peer chess over Urbit"
6+license = "GPL3"
7+website = "https://github.com/thecommons-urbit/chess"
8+bgColor = "#ffffff"
9+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/finmep-chess.svg"
10++++
11+
12+Fully decentralized, peer-to-peer Chess app for Urbit
13+
14+
content/applications/~haddef-sigwen/transit.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Transit"
3+shortcode = "~haddef-sigwen/transit"
4+license = "MIT"
5+image = "https://haddefsigwen1.s3.us-east-1.amazonaws.com/haddef-sigwen/2022.5.07..20.27.02-image.png"
6+bgColor = "#38285c"
7+developer = "~haddef-sigwen"
8+description = "Planetary transit occurs once per day."
9+website = ""
10++++
11+
12+Planetary transit occurs once per day.
13+
14+
content/applications/~hanfel-dovned/board.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Board"
3+shortcode = "~dister-hanfel-dovned/board"
4+license = "MIT"
5+image = ""
6+bgColor = "#9E34EB"
7+developer = "~hanfel-dovned"
8+website = "https://github.com/hanfel-dovned/Board"
9+description = "A digital bulletin-board"
10++++
11+
12+An implementation of [Robin Sloan’s Spring ‘83](https://www.robinsloan.com/lab/specifying-spring-83/) concept as an Urbit app called %board. Imagine a digital bulletin-board where each item is a person’s miniature homepage, and the pages you see are based on who you know.
13+
14+
content/applications/~hanfel-dovned/pony.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Pony"
3+shortcode = "~dister-hanfel-dovned/pony"
4+license = "MIT"
5+image = ""
6+bgColor = "#232323"
7+developer = "~hanfel-dovned"
8+website = "https://github.com/hanfel-dovned/Pony"
9+description = "Pony is an app for longform threaded conversations"
10++++
11+
12+Pony is an app for longform threaded conversations, like a blend of email and message boards. Create private threads with arbitrary sets of ships, fork threads to new sets of participants, schedule messages to be sent later, and much more.
content/applications/~hanfel-dovned/slam.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Slam"
3+shortcode = "~dister-hanfel-dovned/slam"
4+license = "MIT"
5+image = "https://hanfel-dovned.sfo3.digitaloceanspaces.com/slam-tile.png"
6+bgColor = "#100032"
7+developer = "~hanfel-dovned"
8+website = "https://github.com/hanfel-dovned/Slam"
9+description = "A social arcade game"
10++++
11+
12+Slam is a social arcade game where you battle waves of enemies that are generated from your pals' gorae.
13+
14+Requires [gora](https://urbit.org/applications/~dalten/gora) and [pals](https://urbit.org/applications/~paldev/pals).
content/applications/~hanrut-sillet-dachus-tiprel/blog.mdnew file+16
@@ -0,0 +1,16 @@
1++++
2+title = "%blog"
3+shortcode = "~hanrut-sillet-dachus-tiprel/blog"
4+license = "MIT"
5+image = ""
6+bgColor = "#533E78"
7+developer = "~dachus-tiprel"
8+website = "https://dachus-tiprel.tlon.network/blog/introducing-blog"
9+description = "The easiest and most versatile publishing app on Urbit"
10++++
11+
12+A publishing tool for creating a basic blog with markdown and css.
13+
14+Blog is just what it sounds like. A new tool from Uqbar, the app lets anyone on Urbit spin up and customize a blog that displays to the net at an auto-generated URL. Nothing could be breezier. Plus it’s got payments through Uqbar and group-blogging settings on the roadmap. Find out more about it on it's [creator's blog](https://dachus-tiprel.tlon.network/blog/introducing-blog).
15+
16+
content/applications/~larryx-woldyr/osmosis.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Osmosis"
3+shortcode = "~larryx-woldyr/osmosis"
4+license = "MIT"
5+image = "https://holium-app-globs.nyc3.cdn.digitaloceanspaces.com/osmosis/osmosis-logo-wc.png"
6+bgColor = "#180D39"
7+developer = "~larryx-woldyr"
8+website = "https://https://osmosis.zone/"
9+description = "Interchain liquidity lab."
10++++
11+
12+A fully self-hosted Osmosis frontend, deployed via Urbit.
content/applications/~larryx-woldyr/safe.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Safe"
3+shortcode = "~larryx-woldyr/safe"
4+license = "MIT"
5+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/safe.jpeg"
6+bgColor = "#180D39"
7+developer = "~larryx-woldyr"
8+website = "https://safe.global/"
9+description = "Safe front-end"
10++++
11+
12+A fully self-hosted Safe frontend, deployed via Urbit.
content/applications/~larryx-woldyr/uniswap.mdnew file+12
@@ -0,0 +1,12 @@
1++++
2+title = "Uniswap"
3+shortcode = "~larryx-woldyr/uniswap-v3"
4+license = "MIT"
5+image = "https://cryptologos.cc/logos/uniswap-uni-logo.png"
6+bgColor = "0xffffff"
7+developer = "~larryx-woldyr"
8+website = "http://uniswap.org"
9+description = "Self-hosted Uniswap interface"
10++++
11+
12+A self-hosted Uniswap interface for swapping assets on Ethereum.
content/applications/~larryx-woldyr/urbhue.mdnew file+18
@@ -0,0 +1,18 @@
1++++
2+title = "Hue"
3+shortcode = "~larryx-woldyr/urbhue"
4+license = "MIT"
5+image = "https://i.imgur.com/czmkmoK.png"
6+bgColor = "#F0B43D"
7+developer = "~larryx-woldyr"
8+website = "https://ajlamarc.com"
9+description = "Controlling Philips Hue"
10++++
11+
12+In this prototype, Philips Hue Lightbulbs and groups can be controlled from a standard Urbit application by using the Hue Remote API.
13+
14+History and logging of the bulb are collected to provoke consideration of what should be controlled and tracked by the people living in a smart home.
15+
16+This app will hopefully inspire people to think of the potential utility of Urbit in the smart home, inspire non-Urbit users to think of Urbit in non-community driven scenarios, and be a small step forward in understanding the affordances for Urbit in the home.
17+
18+For more information on `%urbhue`, check out our Urbit group: `~pilwyc-fastec/communal-computing-for-urbit`
content/applications/~lomder-librun/ballot.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Ballot"
3+shortcode = "~livdel-binmun-lomder-librun/ballot"
4+license = "MIT"
5+image = "https://lomder-librun.sfo3.digitaloceanspaces.com/tiles/ballot-app-tile.svg"
6+bgColor = "#cebef0"
7+developer = "~lomder-librun"
8+website = "https://www.holium.com"
9+description = "An app that allows you to vote with other ships."
10++++
11+
12+Ballot allows you to create and vote on proposals, delegate votes to other urbit ships, and trigger actions based on results.
13+
14+
content/applications/~lomder-librun/realm.mdnew file+18
@@ -0,0 +1,18 @@
1++++
2+title = "Realm"
3+shortcode = "~lomdyr-librun/realm"
4+license = ""
5+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/realm-icon.png"
6+bgColor = ""
7+developer = "Holium"
8+website = "https://www.holium.com/"
9+description = "A desktop interface for Urbit"
10++++
11+
12+Realm is a desktop app for Urbit communities (currently in private alpha).
13+
14+[Sign up for the alpha.](https://www.holium.com/)
15+
16+<iframe width="560" height="315" src="https://www.youtube.com/embed/gdu4QtFR-Bs" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
17+
18+Note that the shortcode will not install this application.
content/applications/~midlev-mindyr/astrolabe.mdnew file+30
@@ -0,0 +1,30 @@
1++++
2+title = "Astrolabe"
3+shortcode = "~dister-midlev-mindyr/astrolabe"
4+license = ""
5+image = "https://raw.githubusercontent.com/johnhyde/astrolabe/main/ui/src/assets/astrolabe-tile.svg"
6+bgColor = ""
7+developer = "~midlev-mindyr"
8+website = "https://github.com/johnhyde/astrolabe"
9+description = "Astrolabe is a one-stop shop app for exploring Urbit address space."
10++++
11+
12+### Astrolabe is a one-stop shop app for exploring Urbit address space.
13+
14+Features:
15+
16+- **ID Search**:
17+When you search a partial @p (or use wildcards), it will show you the spawned/owned ships which match your search.
18+
19+- **Sigil Search**:
20+You can use a visual interface to enter sigils, either just general shapes, or specific shape/pattern combos
21+
22+- **Sky Chart**:
23+ Astrolabe integrates with %pals to highlight your pals on the sky chart. Clicking/tapping on a point opens a small modal with basic info and a button to take you to a Ship View of the point.
24+
25+- **Ship View**:
26+Summary view for any ship. As on urbit.live or urbit.me, it shows the @p, owner, parent, etc. Allows PNG or SVG download of sigils. Displays tags from %pals, and potentially allows you to add pals and/or edit tags from that screen.
27+
28+
29+
30+Astrolabe integrates with pals wherever possible, and contains documentation to explain the many quirks of Urbit address space to a new user.
content/applications/~midsum-salrux/faux.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Faux"
3+developer = "~midsum-salrux"
4+shortcode = "~tindys-botter-dozzod-tomdys/faux"
5+description = "An Urbit-native Discord bridge"
6+license = "MIT"
7+website = "https://github.com/midsum-salrux/faux"
8+bgColor = "#000000"
9++++
10+
11+Faux, a bridge between discord and urbit groups. When a member posts a new message in your discord group, a bot reposts it in your urbit group, and vice versa. This is implemented as a native gall agent and includes a frontend app to configure the connections between your discord and urbit servers.
content/applications/~migmeg-fidlen-sillus-mallus/kenning.mdnew file+17
@@ -0,0 +1,17 @@
1++++
2+title = "kenning"
3+shortcode = "~migmeg-fidlen-sillus-mallus/kenning"
4+license = "MIT"
5+image = "https://upload.wikimedia.org/wikipedia/commons/thumb/a/a0/Voiced_dental_fricative_%28vector%29.svg/1920px-Voiced_dental_fricative_%28vector%29.svg.png"
6+bgColor = "#a59a2d"
7+developer = "~sillus-mallus"
8+website = "https://lovecrypt.net"
9+description = "Memorization tool for text passages."
10++++
11+
12+Memorize passages of text. Every passage is called a “kenning”.
13+
14+1. Every kenning is assigned a kelvin version based on word count.
15+1. You may test your knowledge by filling in the blanks.
16+1. As kelvin decreases, the number of blanks increases.
17+1. For large passages, split the text into several kens for best results.
content/applications/~mister-dister-dozzod-dozzod/terminal.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Terminal"
3+developer = "Tlon"
4+shortcode = "~mister-dister-dozzod-dozzod/webterm"
5+description = "A web interface to your Urbit's command line."
6+license = "MIT"
7+website = "https://tlon.io"
8+bgColor = "#324246"
9++++
10+
11+
12+Terminal is a command line interface for your urbit. You can run commands, script, and program your Urbit directly, even if your urbit is located on a remote server. Discover the gratification of programming a computer that is truly yours.
13+
14+
content/applications/~niblyx-malnus/gol-cli.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "Goals"
3+shortcode = "~dister-dozzod-niblyx-malnus/gol-cli"
4+license = "MIT"
5+image = ""
6+bgColor = "#362711"
7+developer = "~niblyx-malnus"
8+website = ""
9+description = "Hierarchically nested goals and projects"
10++++
11+
12+### Goals helps you track and share interrelated tasks
13+
14+
15+Goals is primarily dealing with four kinds of relationships: containment/ownership, virtual nesting, precedence, and priority. These fundamental relationships between goals and that any other important information about a goal does not require any complex sort of topological representation, but can simply be a piece of data associated with the goal.
content/applications/~nocsyx-lassul/silo.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "silo"
3+shortcode = "~dister-nocsyx-lassul/silo"
4+license = "MIT"
5+image = ""
6+bgColor = "#4f46e5"
7+developer = "~nocsyx-lassul"
8+description = "An S3 storage manager"
9+website = "https://github.com/arthyn/silo"
10++++
11+
12+### An S3 storage manager
13+
14+Silo is an application for viewing and managing your urbit's file storage. Currently that means the files in an S3-compatible storage system, but hopefully soon we'll also be able to provide an interface for your local urbit's filesystem too.
15+
16+
17+
18+Currently silo allows you to upload, delete, add folders, and otherwise manage your files like you expect. It also offers easy access to downloading files and copying their URLs.
19+
20+In the future we hope to add the ability to easily share files with others, offer storage to friends or groups, a fully urbit-side S3 and virtual filesystem API, and a drop-in file-picker component that devs can use to easily add image uploads to their apps.
content/applications/~nocsyx-lassul/sphinx.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "sphinx"
3+shortcode = "~dister-nocsyx-lassul/sphinx"
4+license = "MIT"
5+image = "https://nyc3.digitaloceanspaces.com/hmillerdev/nocsyx-lassul/2022.7.16..04.35.22-sphinx-web-shifted.svg"
6+bgColor = "#b25068"
7+developer = "~nocsyx-lassul"
8+website = "https://github.com/arthyn/sphinx"
9+description = "Community powered search"
10++++
11+
12+### Community powered search
13+
14+Sphinx is a search engine powered by you and your pals. Using the gossip mechanism developed by ~paldev for [%rumors](https://urbit.org/applications/~paldev/rumors), anytime you post a listing it gets indexed on your urbit and then shared with your friends and friends of friends.
15+
16+
17+
18+Currently sphinx is probably best as a tool for finding groups and apps, but will likely index content soon too. It uses exact, phonetic, and unordered trigram matching to index the keywords in your listings. This allows you to type a query inconsistently and still get similar results as if it was spelled right.
19+
20+Future features include tag aggregation for more "classifieds"-type browsing, browsing by who shared something, ability to specify who a listing gets shared with (private/pals/pals+sponsor), and the ability to add search providers who might host non-gossiped indexes.
content/applications/~nodmyn-dosrux/basket.mdnew file+34
@@ -0,0 +1,34 @@
1++++
2+title = "basket"
3+shortcode = "~nodmyn-dosrux/basket"
4+license = "MIT"
5+image = "https://0x0.st/oFHB.png"
6+bgColor = "#F2F2F2"
7+developer = "Assembly Capital"
8+website = "https://github.com/bacwyls/basket"
9+description = "show off your meme collection"
10++++
11+
12+
13+### Basket is a simple db of tagged images
14+
15+The frontend displays the most recent image in the full window,
16+so it can be used to add some personal style to an urbit desktop environment.
17+
18+In addition to being a personal db, basket is an experimental app on top of the 'rooms' primitive in [Realm](https://twitter.com/HoliumCorp).
19+
20+Members of a room have temporary write-access to each others basket db.
21+The frontend makes it ergonomic and fun to share / collaboritively create this data.
22+
23+In theory (at scale), this creates a kind of decentralized giphy.
24+
25+The images you know about are the images your friends have shared with you.
26+It gamifies the creation of rich, human curated image metadata.
27+One obvious use case for this is keeping track of memes.
28+
29+To export the full dataset you can GET `http://yoururbitship.com/~/scry/basket/images.json`
30+Then you might want to use a python script to actually download the images to local storage.
31+
32+Eventually, it would be nice to have a simple way to export and share the dataset.
33+
34+Read full documentation on the [Github repository](https://github.com/bacwyls/basket).
content/applications/~nodmyn-dosrux/houston.mdnew file+17
@@ -0,0 +1,17 @@
1++++
2+title = "houston"
3+shortcode = "~nodmyn-dosrux/houston"
4+license = "MIT"
5+image = "https://0x0.st/ojrj.png"
6+bgColor = "#FFFFFF"
7+developer = "Assembly Capital"
8+website = "https://github.com/assemblycapital/houston"
9+description = "Moon Management Dashboard"
10++++
11+
12+### Moon Management Dashboard
13+
14+
15+
16+Keeps track of the moons you've spawned and exposes a poke API for the standard moon utilities: `|moon`, `|moon-breach` and `|moon-cycle`
17+
content/applications/~nodmyn-dosrux/radio.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "radio"
3+shortcode = "~nodmyn-dosrux/radio"
4+license = "MIT"
5+image = "https://0x0.st/o4--.png"
6+bgColor = "#f2f2f2"
7+developer = "Assembly Capital"
8+website = "https://github.com/bacwyls/radio"
9+description = "an app for urbit disc jockeys"
10++++
11+
12+Create and tune into virtual radio stations where you can chat and play Youtube videos with your friends.
13+
14+
15+
content/applications/~nodmyn-dosrux/vita.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "vita"
3+shortcode = "~nodmyn-dosrux/vita"
4+license = "MIT"
5+image = "https://bwyl.nyc3.digitaloceanspaces.com/vita%2Fvita.png"
6+bgColor = "#F2F2F2"
7+developer = "Assembly Capital"
8+website = "https://github.com/assemblycapital/vita"
9+description = "monitor your app distributions"
10++++
11+
12+### Keep track of your app distributions
13+
14+To get downloads, `:vita` periodically scrys %cs /subs for each desk and caches the results.
15+
16+`:vita` accepts foreign pokes attesting to activity on a desk.
17+`/lib/vita-client.hoon` helps any agent send vita activity pokes.
18+It sends a maximum of one poke per day, and allows users to opt-in / opt-out depending on developer preference.
19+
20+Read full documentation on the [Github repository](https://github.com/assemblycapital/vita).
content/applications/~norsyr-torryn/canvas.mdnew file+29
@@ -0,0 +1,29 @@
1++++
2+title = "canvas"
3+shortcode = "~dister-norsyr-torryn/canvas"
4+license = "MIT"
5+image = "https://yosoyubik.fra1.digitaloceanspaces.com/canvas/tile.svg"
6+bgColor = "#3787B9"
7+developer = "~norsyr-torryn"
8+website = "https://github.com/yosoyubik/canvas"
9+description = "Collaborative Pixel Art"
10++++
11+
12+### Collaborative Pixel Art
13+
14+
15+
16+#### Features
17+- Each stroke is stored automatically on your Urbit.
18+- Export Canvas Images as SVG.
19+- Image files are stored on S3 Storage, if configured.
20+- Allows creation of public or private canvases.
21+- Others can join a public canvas and work collaboratively in a cool art project.
22+
23+#### Access
24+Search for ~dister-norsyr-torryn in Grid to find the Canvas app, and install it from there
25+
26+A public canvas is hosted at: ~picsel-norsyr-torryn/public
27+
28+
29+Come and join the group to share your creations and see what others are doing: ~norsyr-torryn/canvas
content/applications/~paldev/face.mdnew file+13
@@ -0,0 +1,13 @@
1++++
2+title = "face"
3+developer = "~paldev"
4+shortcode = "~paldev/face"
5+description = "see your friends"
6+license = "MIT"
7+website = "https://pal.dev/suite/face"
8+bgColor = "#3b5998"
9++++
10+
11+Face is an image rolodex of your urbit friends. Compatible with [pals](/applications/~paldev/pals), face lets you share a photo of yourself with mutuals and also see a gallery of their faces. To share, enter an image link in the url field.
12+
13+
content/applications/~paldev/fafa.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "fafa"
3+developer = "~paldev"
4+shortcode = "~paldev/fafa"
5+description = "2fa otp authenticator app"
6+license = "MIT"
7+website = "https://pal.dev/suite/fafa"
8+bgColor = "#1a1a2a"
9++++
10+
11+
12+Fafa is a two-factor authentication app. Log in to your saved accounts with a one-time passcode generated on your urbit. (Only access this app over a secure connection and remember to also save your backup codes somewhere secure.)
13+
14+
content/applications/~paldev/pals.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "pals"
3+shortcode = "~paldev/pals"
4+developer = "~paldev"
5+description = "friendlist for peer discovery"
6+license = "MIT"
7+website = "https://pal.dev/suite/pals"
8+bgColor = "#99D3BD"
9++++
10+
11+Pals is a contact list for your urbit friends. Send and receive friend requests with intuitive ease. Once you're pals, a smiley face icon indicates mutual status.
12+
13+
14+
15+Keep track of who your pals are or how you know them with tags, which exist mostly for your own book-keeping, but could be used in the future by other applications to group content. Similarly, some apps work better with pals, like [rumors](/applications/~paldev/rumors), an anonymous gossip app, and [sphinx](/applications/~nocsyx-lassul/sphinx), an Urbit search engine.
content/applications/~paldev/picture.mdnew file+13
@@ -0,0 +1,13 @@
1++++
2+title = "picture"
3+developer = "~paldev"
4+shortcode = "~paldev/picture"
5+description = "a picture frame for the garden"
6+license = "MIT"
7+website = "https://pal.dev/suite/picture"
8+bgColor = "#DDDDDD"
9++++
10+
11+Picture is a digital frame for your urbit. Simply upload an image to see it every time you open up Landscape. (Refrain from uploading huge images to avoid memory pressure.)
12+
13+
content/applications/~paldev/rumors.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "rumors"
3+shortcode = "~paldev/rumors"
4+developer = "~paldev"
5+description = "anonymous gossip from friends of friends"
6+license = "MIT"
7+website = "https://pal.dev/suite/rumors"
8+bgColor = "#bb77dd"
9++++
10+
11+Rumors is an anonymous gossip feed powered by [pals](/applications/~paldev/pals). The more mutuals you have, the more rumors you'll see: messages posted by your pals, and their pals, populate the feed.
12+
13+
14+
15+Built using a p2p gossip protocol, rumors anonymizes posts and orders them chronologically. Drop links, ask questions, lurk, or whisper secrets into the void …
content/applications/~paldev/scooore.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "sc'o're"
3+developer = "~paldev"
4+shortcode = "~paldev/scooore"
5+description = "leaderboard for groups' ['o']s, as seen on tv!"
6+license = "MIT"
7+image ="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/scooore.svg"
8+website = "https://pal.dev/suite/scooore"
9+bgColor = "#FDFF54"
10++++
11+
12+A leaderboard of your peers' emoji reactions in Groups.
13+
14+
content/applications/~paldev/verse.mdnew file+13
@@ -0,0 +1,13 @@
1++++
2+title = "verse"
3+developer = "~paldev"
4+shortcode = "~paldev/verse"
5+description = "a random Bible verse, every day"
6+license = "MIT"
7+website = "https://pal.dev/suite/verse"
8+bgColor = "#EEEEDD"
9++++
10+
11+Verse displays a random Bible verse. Whenever you open Landscape, a new daily passage awaits.
12+
13+
content/applications/~pocwet/docs.mdnew file+17
@@ -0,0 +1,17 @@
1++++
2+title = "Docs"
3+developer = "~pocwet"
4+shortcode = "~pocwet/docs"
5+description = "User and developer documentation for Urbit apps"
6+license = "MIT"
7+website = "https://github.com/tinnus-napbus/docs-app"
8+bgColor = "#FBCF44"
9+image = "https://m.tinnus-napbus.xyz/pub/books.svg"
10++++
11+
12+
13+Docs is an Urbit app for documenting other Urbit apps - it finds docs in other desks and displays them for users and deveopers to browse.
14+
15+
16+
17+The docs folder contains the source of the app, and the docs-dev folder contains the files necessary for including docs in your app. Note that the files in docs-dev are symlinked, so the'll need to be copied with cp -rL or equivalent.
content/applications/~pocwet/straw.mdnew file+13
@@ -0,0 +1,13 @@
1++++
2+title = "Straw"
3+developer = "~pocwet"
4+shortcode = "~pocwet/straw"
5+description = "Vote on what to publish."
6+license = "MIT"
7+website = "https://urbit.org"
8+bgColor = "#6C6973"
9+image = ""
10++++
11+
12+
13+This app lets group members vote on whether a post is published to a notebook. It is intended for use with Studio, which you can install from ~tirrel/studio.
content/applications/~ribben-donnyl/funes-notes.mdnew file+15
@@ -0,0 +1,15 @@
1++++
2+title = "Funes Notes"
3+shortcode = "~ribben-donnyl/funes-notes"
4+license = "MIT"
5+image = "https://is4-ssl.mzstatic.com/image/thumb/Purple112/v4/64/64/8b/64648bfc-02b2-b955-6230-b86af334b6b1/AppIcon-0-1x_U007emarketing-0-10-0-85-220.png/230x0w.webp"
6+bgColor = ""
7+developer = "~ribben-donnyl"
8+website = "https://funes.app"
9+description = "Mobile notetaking application using urbit as a back-end."
10++++
11+
12+Funes Notes is a mobile notetaking application [available for iOS](https://apps.apple.com/us/app/funes-notes/id1627315560), using urbit's `%graph-store` as a backend.
13+
14+
15+Initial development funded by the Urbit Foundation via [Urbit Notes](https://urbit.org/grants/urbit-notes) proposal grant.
content/applications/~sitden-sonnet/channel.mdnew file+20
@@ -0,0 +1,20 @@
1++++
2+title = "Channel"
3+shortcode = "~sitden-sonnet/channel"
4+license = "REKT"
5+image = "https://s3.us-east-1.amazonaws.com/haddefsigwen1/reciprocal/2022.7.09..22.54.53-channel.png"
6+bgColor = "#000000"
7+developer = "Quartus Co., Reciprocal Ltd."
8+website = "https://reciprocal.ltd"
9+description = "A distributed imageboard platform, with love"
10++++
11+
12+### An imageboard platform, with love
13+
14+Developed as a collaboration between the Quartus Corporation and [Reciprocal Ltd.](https://reciprocal.ltd), Channel is an imageboard platform that leverages graph-store to allow any ship on the Urbit network to create and manage their own imageboard.
15+
16+
17+
18+Incoming posts have their authors scrambled with a per-ship, per-installation SHA-256 salt and thus get rotated into a "tripcode comet" visible when viewing the graph outside the interface. The interface by default hides all authors.
19+
20+Board owners can ban ships (using their rotated names), delete threads, and ban words and URLs, as well as assign janitors. You can even connect two boards using Quartus' Orca tool to syndicate posts across boards.
content/applications/~sogryp-dister-dozzod-dozzod/groups.mdnew file+40
@@ -0,0 +1,40 @@
1++++
2+title = "Groups"
3+shortcode = "~sogryp-dister-dozzod-dozzod/groups"
4+license = "MIT"
5+image = "https://bootstrap.urbit.org/icon-groups.svg"
6+bgColor = "#EFF0F4"
7+developer = "Tlon"
8+website = "https://github.com/tloncorp/landscape-apps"
9+description = "Groups is a decentralized platform that integrates with Talk, Notebook, and Gallery for a full, communal suite of tools."
10++++
11+
12+Start, host, and cultivate communities. Own your communications, organize your resources, and share documents. Groups is a decentralized platform that integrates with Talk, Notebook, and Gallery for a full, communal suite of tools.
13+
14+ <video autoPlay muted loop playsInline>
15+ <source
16+ src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/groups-create-a-group.webm"
17+ type="video/webm"
18+ />
19+ </video>
20+
21+Teams, clubs, DAOs, and secret societies use Groups to digitally congregate, using channel integrations to extend their capabilities.
22+
23+ <video autoPlay muted loop playsInline>
24+ <source
25+ src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/groups-create-a-channel.webm"
26+ type="video/webm"
27+ />
28+ </video>
29+
30+Write, edit, and publish longform or shorter documents with Notebook, a basic text editor for announcements, internal meeting minutes, blogs, and everything in between.
31+
32+ <video autoPlay muted loop playsInline>
33+ <source
34+ src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/notebooks.webm"
35+ type="video/webm"
36+ />
37+ </video>
38+
39+
40+Gather links to images, articles, and web pages to maintain a collection of references with Gallery, a versatile and interoperable repository for day-to-day digital trawling.
content/applications/~sogryp-dister-dozzod-dozzod/talk.mdnew file+21
@@ -0,0 +1,21 @@
1++++
2+title = "Talk"
3+shortcode = "~sogryp-dister-dozzod-dozzod/talk"
4+license = "MIT"
5+image = "https://bootstrap.urbit.org/icon-talk.svg"
6+bgColor = "#2B5DC0"
7+developer = "Tlon"
8+website = "https://github.com/tloncorp/landscape-apps"
9+description = "Talk is a decentralized chat app that integrates with Groups, Notebook, and Gallery for a full, communal suite of tools."
10++++
11+
12+Send peer-to-peer direct messages to one or many friends. Talk is a simple chat tool for catching up, getting work done, and everything in between.
13+
14+ <video autoPlay muted loop playsInline>
15+ <source
16+ src="https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/talk.webm"
17+ type="video/webm"
18+ />
19+ </video>
20+
21+Start threads. React with emojis. Respond to your Groups chat channels from Talk. When integrated with Groups, both direct messages and team chats appear in Talk. Two apps in one place.
content/applications/~sortug/gate.mdnew file+27
@@ -0,0 +1,27 @@
1++++
2+title = "Gate"
3+shortcode = "~dister-dozzod-sortug/gate"
4+license = "MIT"
5+image = "https://s3.sortug.com/img/fav.png"
6+bgColor = "#000000"
7+developer = "Sortug Development"
8+website = "https://sortug.com"
9+description = "Seamless QR login"
10++++
11+
12+# Secure, seamless login for Urbit
13+
14+Let's make joining Urbit easier!
15+
16+Why do this?
17+
18+When you can do this?
19+
20+
21+Logging in to any Urbit app requires you to input your ship's URL and the `+code` generated on dojo. This requires people to login to their ship's terminal, output the code on dojo, then copy and paste it in their browser or app. This is bad enough if you have a ship running locally, but if you have it running remotely (as is common) the process becomes seriously annoying.
22+
23+Mainstream mobile apps such as Signal handle first login much more seamlessly; after registration is done, further logins are done via QR code. The app produces a QR code, you scan it, and that's it. That's the state-of-the-art, battle-tested user experience for modern applications. Now available on Urbit.
24+
25+Gate makes it easier for newcomers to use Urbit, and greatly enhances the user experience of native applications, desktop and mobile, that Urbit deserves.
26+
27+Users can login to Urbit just by scanning a QR code, receive a URL link and login to an Urbit ship instantly by clicking on it. That simple. Most importantly, hosting providers can use Gate to send a QR code or a URL link to a user, and have the user access his Urbit apps with a simple camera scan or click of a link, making the onboarding process much easier for non-technical users.
content/applications/~sortug/trill.mdnew file+27
@@ -0,0 +1,27 @@
1++++
2+title = "Trill"
3+shortcode = "~dister-dozzod-sortug/trill"
4+license = "MIT"
5+image = "https://s3.urbit.cloud/img/trill-logo.png"
6+bgColor = "#000000"
7+developer = "Sortug Development"
8+website = "https://sortug.com"
9+description = "Urbit Native Microblog"
10++++
11+
12+### Your own social feed, forever.
13+
14+Urbit is a networked personal server. It is the ideal stack to host a microblog service.
15+
16+For years Urbit users have been busy chatting to each other, coordinating to build the network. But it is time that we lay back a little and just post at our leisure.
17+
18+Trill is an Urbit native microblog. You can post text or media links into your feed, make threads, and share it with your friends and followers. You can also build a timeline of your favorite Urbit users, and keep lists of users, categorized as you want.
19+
20+Unlike other microblogs, however, users of Trill truly own their feed. Users host their own content. They can even program it; tinker with the source as much as you want.
21+
22+There are no ads in Trill, no "trends", no analytics. We don't even know how many people are using Trill. And we don't care. We just want to trill. Please join the party.
23+
24+### More information
25+You can install the app by searching for ~dister-dozzod-sortug on your Grid interface, or by running `|install ~dister-dozzod-sortug %trill` in Dojo.
26+
27+The official group of the app is at ~hoster-dozzod-sortug/trill on the Groups app.
content/applications/~sortug/ufa.mdnew file+27
@@ -0,0 +1,27 @@
1++++
2+title = "Urbit Feed Aggregator"
3+shortcode = "~dister-dozzod-sortug/ufa"
4+license = "MIT"
5+image = "https://s3.urbit.cloud/img/lan.png"
6+bgColor = "#000000"
7+developer = "Sortug Development"
8+website = "https://sortug.com"
9+description = "Bring all the web into Urbit"
10++++
11+
12+### Own your content, share it with your friends
13+
14+Urbit is your personal server. Why do you want a personal server? Many things. But one of them, part of the initial vision of Urbit's development, was to use to interact programatically with the Web. To interact with Web services, but in your own terms. Using your chosen frontend, blocking all tracking, telemetry, analytics and other malicious code. Urbit as an API aggregator.
15+
16+The Urbit Feed Aggregator (aka UFA) makes that vision true. Now you will be able to browse the best content on the internet, but really own it, like people used to own books, magazines and newspapers. Control, curate, save and share your the content you like, with complete freedom.
17+
18+UFA is not just an app, it's a platform to which a myriad apps will be added in the future. As of present (August 2022) UFA includes support for Trill (our sister app, the Urbit native microblog) and Twitter. You can read and keep lists of Twitter content without having to login to Twitter.com, and you can save and share that content inside Urbit, via the Trill or Groups apps.
19+
20+### More information
21+You can install the app by searching for ~dister-dozzod-sortug on your Grid interface, or by running `|install ~dister-dozzod-sortug %ufa` in Dojo.
22+
23+The official group of the app is at ~hoster-dozzod-sortug/ufa on the Groups app.
24+
25+You can also follow ~sortug on Trill for announcements.
26+
27+Within 2022 RSS, Instagram and Email support will be added. For the future, the sky is the limit. If you want to help create a new plugin for UFA, please contact us at the official group.
content/applications/~tiller-tolbus/membrane.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Membrane"
3+shortcode = "~mister-master-tiller-tolbus/membrane"
4+license = "MIT"
5+image = "https://tiller-tolbus.nyc3.digitaloceanspaces.com/membrane.png"
6+bgColor = ""
7+developer = "~tiller-tolbus"
8+website = ""
9+description = "Spreadsheets and databases"
10++++
11+
12+### Membrane is a spreadsheet tool for Urbit
13+
14+Spreadsheets were the original tool for the productivity power user, so it is only fitting that we bring them to Urbit. Keep a budget, run a formula, and share your sheets with friends using Membrane.
content/applications/~tirrel/scene.mdnew file+14
@@ -0,0 +1,14 @@
1++++
2+title = "Scene"
3+shortcode = ""
4+license = ""
5+image = "https://tirrel.io/assets/scene-logo-stroke.svg"
6+bgColor = "rgb(0, 0, 0)"
7+developer = "Tirrel Corp."
8+website = "https://tirrel.io"
9+description = "The new Urbit desktop, by ~tirrel corp."
10++++
11+
12+
13+
14+[Download scene here](https://tirrel.io/scene/index.html).
content/applications/~tirrel/studio.mdnew file+21
@@ -0,0 +1,21 @@
1++++
2+title = "Studio"
3+shortcode = "~tirrel/studio"
4+license = ""
5+image = "https://tirrel.io/assets/stool.svg"
6+bgColor = "rgb(160, 226, 167)"
7+developer = "Tirrel Corp."
8+website = "https://tirrel.io"
9+description = "Tools for making money."
10++++
11+
12+### Studio is a publishing tool for Urbit
13+
14+
15+
16+Need a personal website, fast? Studio can set one up in under a minute. For writers, Studio connects you with your legacy-web audience, even if they’re not on Urbit yet. With a click, you can share your newsletter or blog via auto-generated blog or email distribution list
17+
18+Studio pulls content from your Groups notebooks. Notebooks from any group you own will appear.
19+
20+If you need any help, we’re always available in our group: ~tirrel/tirrel-support
21+
content/applications/~worpet-bildet/portal.mdnew file+16
@@ -0,0 +1,16 @@
1++++
2+title = "Portal"
3+shortcode = "~worpet-bildet/portal"
4+license = ""
5+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/applications/portal.svg"
6+bgColor = "rgb(0,0,0)"
7+developer = ""
8+website = ""
9+description = "Portal is the front page"
10++++
11+
12+### Portal is the front page for urbit
13+
14+Portal made its debut as the solution to decentralized discovery on Urbit. Portal enables anyone on Urbit to curate content, apps, and groups for other ships to discover
15+
16+
content/apprenticeships.mdnew file+38
@@ -0,0 +1,38 @@
1++++
2+title = "Become an Apprentice"
3+date = "2023-01-04"
4+weight = 1
5+description = "Everything you need to know about applying for an apprenticeship"
6++++
7+
8+Apprenticeships are practical learning opportunities for new Urbit developers provided by experienced members of the Urbit development community. As an apprentice, you'll have the opportunity to:
9+
10+- Learn from an experienced Urbit contributor
11+- Make helpful contributions to an active project, and
12+- Earn address space for learning
13+
14+Becoming an apprentice is easily one of the best ways to level up your skills, and perhaps even land a job.
15+
16+## Get started
17+
18+Apprenticeships are for those that are new to Urbit development (or an area of it), and would like to find their grounding by working on a pre-existing codebase and problem set. Nearly all apprenticeships involve some degree of Hoon work, so you should make sure that you've completed [Hoon School](https://developers.urbit.org/guides/core/hoon-school) and [App School](https://developers.urbit.org/guides/core/app-school/intro) in either their asychronous or [cohort formats](https://developers.urbit.org/courses) prior to signing up.
19+
20+To become an apprentice, [apply for an open apprenticeship](/grants?program=apprenticeship&open=true&wip=false&completed=false#view-grants)
21+
22+Although some apprenticeships are posted on this site to be claimed, more often than not they emerge out of a conversation between a mentor and an enthusiastic potential apprentice. This is because mentors are generally busy engineering, and while they know many things that need to be done, getting those ideas into writing is difficult.
23+
24+## How it works
25+
26+Once a mentor has written up an apprenticeship, and approved an apprentice, The Urbit Foundation will perform a quick KYC step and send contracts to all parties for signing. Once those contracts are executed, work can proceed.
27+
28+Mentors and apprentices work together by having weekly pairing sessions and maintaining an open line of communication over Urbit. It's expected that mentors put at least two hours per week into supporting their apprentice.
29+
30+## Funding
31+
32+Apprenticeships pay 1 star upon the sucessful completion of the apprenticeship, for an apprenticeship of a duration of up to three months.
33+
34+## Getting Paid
35+
36+When you have completed the scope of your grant, you will create a detailed writeup of the work completed and your learnings, share the writeup with your mentor, and get your approval of completion. After recieving this approval from your mentor, please [submit an invoice here](https://airtable.com/shrXXCs1uaxtNSBcg). Your mentor must also contact `~marfun-pacpet` to confirm completion of the apprenticeship and approve the payment. Once the Urbit Foundation receives approval from your champion and an invoice for the amount agreed upon in your grant or milestone, the Foundation will pay your star allocation to the Ethereum address you have provided.
37+
38+We approve and issue payments within 30 days of invoice receipt and approval, although often payment is made more quickly. If you have any questions regarding getting paid or submitting an invoice, please contact `~marfun-pacpet` for assistance.
content/articles/2022-09-24_urbit-courts-daos-crypto.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Urbit Courts DAOs, Crypto Teams in Quest to Make Internet P2P Again"
3+publication = "Coindesk"
4+author = "March Hochstein and Daniel Kuhn"
5+date = "2022-09-24"
6+URL = "https://www.coindesk.com/layer2/2022/09/24/urbit-courts-daos-crypto-teams-in-push-to-make-internet-p2p-again/"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"
8++++
9+
10+A wildly ambitious project to reinvent the entire internet computing stack is finally shipping usable apps after a decade-plus of laying groundwork. Can it overcome a “janky” UX?
content/articles/2022-09-24_urbit-is-web3-weird-and-wonderful.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Urbit Is Web3, Weird and Wonderful and I Don’t Care Who Made It"
3+publication = "Coindesk"
4+author = "March Hochstein"
5+date = "2022-09-24"
6+URL = "https://www.coindesk.com/layer2/2022/09/24/urbit-is-web3-weird-and-wonderful-and-i-dont-care-who-made-it/"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"
8++++
9+
10+Software can have bugs, but it doesn’t have cooties.
content/articles/2022-09-28_college-course-on-urbit.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Why Would Anyone Take a College Course on Urbit?"
3+publication = "Coindesk"
4+author = "Daniel Kuhn"
5+date = "2022-09-28"
6+URL = "https://www.coindesk.com/layer2/2022/09/28/why-would-anyone-take-a-college-course-on-urbit/"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"
8++++
9+
10+Neal Davis taught the first graduate-level seminar on the controversial computing platform Urbit. Here’s why.
content/articles/2022-09-29_assembly-miami-dispatch.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "Urbit Assembly: If We’re All Here, Who’s Watching The Internet?"
3+publication = "Zora Zine"
4+author = "Madeline Cash"
5+date = "2022-09-29"
6+URL = "https://zine.zora.co/urbit-assembly-miami-dispatch"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/zorazine.png"
8++++
9+
10+Forever Magazine founder and Zora Zine contributor Madeline Cash reports on secret societies, subjective idealism, and digital intimacy in her dispatch from Urbit Assembly in Miami
11+
content/articles/2022-09-29_the-dream-of-digital-homesteading.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "The Dream of Digital Homesteading"
3+publication = "Compact"
4+author = "Geoff Schullenberger"
5+date = "2022-09-29"
6+URL = "https://compactmag.com/article/the-dream-of-digital-homesteading"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/compactmag.png"
8++++
9+
10+Geoff Schullenberger attends Assembly 2022 and chronicles his impressions and thoughts.
content/articles/2022-10-04_a-more-beautiful-computer.mdnew file+11
@@ -0,0 +1,11 @@
1++++
2+title = "User Error: A More Beautiful Computer"
3+publication = "Spike Art Magazine"
4+author = "Adina Glickstein"
5+date = "2022-10-04"
6+URL = "https://www.spikeartmagazine.com/?q=articles/user-error-more-beautiful-computer"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/spike-logo-text.jpg"
8++++
9+
10+From Dimes Square to the Network State, new frontiers are in the making. Adina Glickstein attends Urbit Assembly and considers the politics of tech-augmented exit.
11+
content/articles/2022-10-13_my-weekend-with-the-martians.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "My Weekend With the Martians"
3+publication = "Astra"
4+author = "Ruby Sutton"
5+date = "2022-10-13"
6+URL = "https://astra-mag.com/articles/my-weekend-with-the-martians/"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/astra.png"
8++++
9+
10+At the Assembly, a conference of Urbit denizens, Ruby Sutton discovers a community of eccentrics who dare to dream of a different internet.
content/articles/2022-10-23_three-things.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Three Things #40: October 23, 2022"
3+publication = "Three Things"
4+author = "Lane Rettig"
5+date = "2022-10-23"
6+URL = "https://rettig.substack.com/p/three-things-40-october-23-2022"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/3things40.jpg"
8++++
9+
10+Lane Rettig outlines three unique aspects of Urbit in an attempt to answer the eternal question "What is Urbit?"
content/articles/2023-02-20_trailblazing-urbit-startup-makes-earth-shaking-acquisition.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Trailblazing Urbit Startup Makes Earth Shaking Acquisition"
3+publication = "Globe Newswire"
4+author = "Globe Newswire"
5+date = "2023-02-20"
6+URL = "https://www.globenewswire.com/en/news-release/2023/02/20/2611391/0/en/Trailblazing-Urbit-Startup-Makes-Earth-Shaking-Acquisition.html"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/globe-newswire.jpeg"
8++++
9+
10+Holium Corp closes $2.9 million in seed funding and acquires Third Earth in record pace.
content/articles/2023-05-10_urbit-a-network-older-and-weirder-than-bitcoin.mdnew file+10
@@ -0,0 +1,10 @@
1++++
2+title = "Urbit, a Network Older and Weirder Than Bitcoin, Finally Turns Toward Growth"
3+publication = "Coindesk"
4+author = "Bradley Keoun"
5+date = "2023-05-10"
6+URL = "https://www.coindesk.com/tech/2023/05/10/urbit-a-network-older-and-weirder-than-bitcoin-finally-turns-toward-growth/"
7+image = "https://storage.googleapis.com/media.urbit.org/site/ecosystem/articles/coindesk.jpg"
8++++
9+
10+The peer-to-peer network started in 2002 says it's taking on "MEGACORP," much in the same vein as many blockchain networks. A bit more fun are the "secret code names" that users are assigned.
content/audits.mdnew file+22
@@ -0,0 +1,22 @@
1++++
2+title = "Audits"
3+date = "2021-10-10"
4+weight = 1
5+description = "Urbit Security Audits"
6++++
7+
8+Confidence and trust are fundamental to Urbit's ethos. The strength of our smart contract protocols are regularly scrutinized for potential vulnerabilities and enhanced when weaknesses are identified.
9+
10+To that end, we continue to maintain a robust security protocol. Our smart contracts are generally healthy and secure, but the process of auditing is never fully complete. As our ecosystem evolves, our security protocols evolve with it.
11+
12+Since transparency is an integral feature of trust, we've made our security audits publicly available. Please refer to the below documents for a more thorough analysis.
13+
14+### Security Audits
15+
16+- [Ames Networking Protocol Review](<https://storage.googleapis.com/media.urbit.org/site/audits/Tlon.io%20-%20Urbit%20AMES%20Networking%20Protocol%20Review%20Final%20Report%20(1).pdf>), Leviathan, November 2020
17+- [Urbit Constitution Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20Audit%20-%20OpenZeppelin.pdf), OpenZepplin, September 2021
18+- [Urbit Constitution JS Library Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20JS%20Audit.pdf), bloctrax, July 2018
19+- [Urbit Constitution JS Library Code Review](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Constitution%20JS%20Library%20Report%20-%20December%202018%20Review.pdf), bloctrax, December 2018
20+- [Urbit Keygen JS Library Report](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Keygen%20JS%20Library%20Report.pdf), bloctrax, September 2018
21+- [Urbit Keygen JS Library Report, 2nd Review](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Keygen%20JS%20Library%20Report%20-%20Second%20Review%20with%20Resolutions.pdf), bloctrax, November 2018
22+- [Urbit Security Audit](https://storage.googleapis.com/media.urbit.org/site/audits/Urbit%20Security%20Audit.pdf), bloctrax, June 2018
content/bitcoin-wallet.mdnew file+60
@@ -0,0 +1,60 @@
1++++
2+title = "Bitcoin Wallet"
3++++
4+
5+The latest Urbit release includes a native Bitcoin wallet. Please read the following security recommendations and disclaimers carefully. Urbit.org cannot recover any lost keys.
6+
7+### Instructions
8+
9+Run `|start %btc-wallet` in the dojo. After refreshing Landscape you should see an orange bitcoin tile in the first row. Clicking on it will prompt a two-step process:
10+
11+1. Enter a provider who is connected to a full-node (such as `~zod`). The provider will maintain a synced Bitcoin ledger, index your public addresses to determine your balance, and process your transactions.
12+
13+2. The next step is to provide an extended public key (or xpub). Providing your xpub allows the Bitcoin Wallet to automatically generate new public addresses (called _child public keys_—you can learn more about this [here](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)) when bitcoin is sent to your ship. To provide an xpub you can either enter your master ticket (which can be downloaded from [Bridge](https://bridge.urbit.org)), or directly import your xpub (such as from a hardware wallet like [Ledger](https://support.ledger.com/hc/en-us/articles/360011069619-Extended-public-key) or [Trezor](<https://wiki.trezor.io/User_manual:Displaying_account_public_key_(XPUB)>)).
14+
15+Clicking on the Landscape tile will take you to the Bitcoin Wallet application, where you can view your balance and send bitcoin. All that you'll need to do is enter the recipient's Urbit ID (if they have configured the wallet using the above steps) or a Bitcoin address.
16+
17+If you are interested in [being a provider](https://subject.network/posts/btc-wallet-config/#connecting-a-provider-to-a-full-node) or [running a bitcoin full node](https://subject.network/posts/pi-fullnode-urbit/#bitcoind) on the Urbit network please check out `~sitful-hatred`’s excellent tutorials.
18+
19+### Verify
20+
21+You should verify your version of this Bitcoin wallet. To do so, follow the instructions in the README in our [Github](https://github.com/urbit/urbit/blob/master/pkg/btc-wallet/README) repo.
22+
23+Instructions reproduced here:
24+
25+To verify your version of the bitcoin wallet, run the following command in the dojo:
26+`> +btc-wallet-check`
27+It should return with the following hash:
28+`0v9t022.n8kv1.5emkt.s2p9i.hvsa9`
29+
30+### Disclaimer Statement
31+
32+The Urbit Bitcoin Wallet and its related components are experimental pieces of software. You are free to review the open-source code before using:
33+
34+- [Wallet](https://github.com/urbit/urbit/tree/master/pkg/btc-wallet)
35+- [Full Node Provider Agents](https://github.com/timlucmiptev/btc-agents)
36+
37+No guarantees are made about the security of this software. It may contain vulnerabilities that could lead to loss of funds. This wallet software has not had a formal security audit.
38+
39+You can read about the security audit for Urbit's networking protocol in this [post](https://urbit.org/blog/security-audit/). This audit does not encompass the wallet, except to the extent that the wallet operates on Urbit's networking architecture.
40+
41+If you decide to use this wallet, please store responsible amounts of Bitcoin, and use best security practices. The developers of this software cannot help you recover your keys / funds, if lost.
42+
43+### License
44+
45+With the exception of its external dependencies, this software is a component of Urbit, and is released under Urbit's MIT License, reproduced below. [View Original](https://raw.githubusercontent.com/urbit/urbit/master/LICENSE.txt)
46+
47+The MIT License (MIT)
48+
49+Copyright (c) 2015 Urbit
50+
51+Permission is hereby granted, free of charge, to any person obtaining a copy
52+of this software and associated documentation files (the "Software"), to deal
53+in the Software without restriction, including without limitation the rights
54+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
55+copies of the Software, and to permit persons to whom the Software is
56+furnished to do so, subject to the following conditions:
57+
58+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
59+
60+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
content/bitcoin.mdnew file+125
@@ -0,0 +1,125 @@
1++++
2+title = "Bitcoin Development on Urbit"
3++++
4+
5+### Overview
6+
7+Urbit OS currently ships with our Bitcoin wallet, %btc-wallet, released in 2021,
8+and our Lightning implementation, %volt, is almost ready for live use on the network. Several integrations with the app ecosystem are planned immediately following its release, including subscription publishing, social payments, and more.
9+
10+**The Urbit Advantage**
11+
12+- Composability: Modular userspace applications expose a consistent API format to each other locally and over the network, making seamless integration of Lightning payments, Taro assets, and other protocols easy
13+- Networking and identity: Exactly-once message delivery, NAT traversal, and E2E encryption come built into Urbit's P2P protocol, and Urbit identities are sybil-resistant, human-readable network addresses bound to BIP32 extended public keys
14+- Efficient, secure development: Urbit OS is strictly typed and purely functional, and apps have reproducible builds on all client machines, removing much of the complexity, risk, and pain points from development
15+
16+**Getting Involved**
17+
18+Interested in contributing to or supporting Bitcoin development on Urbit? GitHub repos for individual projects and information on the Urbit Foundation grant program are linked below, and dedicated Urbit groups and Bitcoin node operators on Urbit are listed in the Community section. You can also reach out to current contributors ~tondes-sitrym and ~pindet-timmut on Urbit or at urbitcoin@protonmail.com.
19+
20+### Wallet
21+
22+Urbit's Bitcoin wallet consists of two agents: %btc-provider, which communicates with an external full node; and %btc-wallet, which handles transaction generation and signing, and uses a %btc-provider instance (on the same ship or elsewhere on the Urbit network) to broadcast transactions and receive data from the Bitcoin network.
23+
24+Wallet users can receive payments using the xpub associated with their Urbit ID, allowing Bitcoin payments to be sent between ships with a persistent, human-readable network address without compromising on-chain privacy.
25+
26+**Resources**
27+
28+GitHub
29+
30+- Agents: [https://github.com/urbit/urbit/tree/master/pkg/bitcoin](https://github.com/urbit/urbit/tree/master/pkg/bitcoin)
31+- UI: [https://github.com/urbit/urbit/tree/master/pkg/btc-wallet](https://github.com/urbit/urbit/tree/master/pkg/btc-wallet)
32+- Provider utilities: [https://github.com/urbit/urbit-bitcoin-rpc](https://github.com/urbit/urbit-bitcoin-rpc)
33+
34+Writeups
35+
36+- Grant proposal: [https://urbit.org/grants/bitcoin-full-node-provider-and-wallet](https://urbit.org/grants/bitcoin-full-node-provider-and-wallet)
37+- Architecture document: [https://gist.github.com/jalehman/e0c91071427ca4c349c0673f376945cb](https://gist.github.com/jalehman/e0c91071427ca4c349c0673f376945cb)
38+- Provider setup guide: [https://subject.network/posts/pi-fullnode-urbit/#bitcoind](https://subject.network/posts/pi-fullnode-urbit/#bitcoind)
39+
40+
41+**Continuing Work**
42+
43+The current %btc-wallet implementation is not a modern BIP-157/158 light client. While users who depend on another ship's %btc-provider/full node for communication with the Bitcoin network do not risk loss of on-chain funds, their lack of visibility on the network will be more problematic for those also using it with Lightning. Funding is available for developers interested in contributing: reach out to the Urbit Foundation, ~tondes-sitrym on Urbit, or urbitcoin@protonmail.com.
44+
45+### Lightning
46+
47+Volt, Urbit's Lightning implementation, like our Bitcoin wallet consists of two agents: %volt, the primary agent that manages channels, payments, invoices, and chain monitoring; and %volt-provider, which connects to an external LND node for handling payments with endpoints outside the Urbit network.
48+
49+All Volt nodes will run %volt, and be able to operate channels with Urbit peers without maintaining an LND instance or depending on another ship that does. To transact with non-Urbit Lightning peers, and in the short term (see below) to perform multi-hop payments inside Urbit, they will need to open a channel with a node that uses %volt-provider to connect with LND. Chain monitoring likewise requires connecting to a local or remote %btc-provider agent (see Wallet above). For more details on the network architecture, see the grant proposal linked below.
50+
51+Volt implements BOLTs 2, 3, 5, and 11, and in the near future will add onion routing (variants on BOLTs 4 and 7). Because %ames, Urbit's networking module, already handles transport, guarantees required message delivery properties, and furnishes persistent, unique 'domain names', implementation of BOLTs 1, 8, and 9 is unnecessary for Volt nodes.
52+
53+Beta release of Volt is planned for the end of 2022, and additional features including multi-hop/onion routing implementation are proposed for completion by mid-2023.
54+
55+**Resources**
56+
57+GitHub: [https://github.com/dasrun-fadben/volt/tree/on-chain](https://github.com/dasrun-fadben/volt/tree/on-chain)
58+
59+Initial grant proposal and spec: [https://urbit.org/grants/volt-lightning-on-urbit](https://urbit.org/grants/volt-lightning-on-urbit)
60+
61+Proposal for further work: [https://urbit.org/grants/lightning-development](https://urbit.org/grants/lightning-development)
62+
63+**Continuing Work**
64+
65+The primary element currently missing from Volt is onion routing of multi-hop payments for full privacy and efficiency of payments to and from nodes that don't also operate LND. This has been partially specified in the second proposal linked above: funding and collaborators are available for this as well as work described there on application integrations, submarine swaps, and more, so interested developers should take a look and get in touch.
66+
67+### Roadmap
68+
69+**2022**
70+
71+- *Volt Beta Release*
72+Final work on channel sweeps, remaining safety checks, and UI development is currently ongoing and expected to be complete by EOY 2022.
73+
74+**2023**
75+
76+- *Initial Ecosystem Integrations*
77+ - Submarine swaps: Implementation of the PeerSwap protocol, fallback use of the Loop API, and UI targeted at merchant use-cases. Funded, expected completion in spring 2023.
78+ - Apps: Integration of Lightning subscription and one-time paygates into Groups, social payments and %volt-provider discovery with %pals, and app tipjar module. Specified and proposed for grant funding.
79+- *Lightning Routing*
80+Payments with multiple intra-Urbit hops and via multiple %volt-provider channels are the last remaining component for full-featured and private payments with Volt. Specified and proposed for grant funding.
81+- *Wallet Improvements*
82+Work on feature, security, and UI upgrades for the Bitcoin wallet and node provider, aimed at making the application a full-featured and BIP157/158-compliant light client, should begin before EOY 2023.
83+
84+**Future**
85+
86+- *Taro Implementation*
87+Implementation of Taproot Asset Representation Overlay, with an initial focus on using nonfungible Taro assets to represent credentials, permissions, and reputation of Urbit identities.
88+- *Atomic Streaming Payments*
89+ - Integration of Volt payments with streaming apps like %radio and the Holium WebRTC client via HTLC-DASH or similar implementation.
90+ - Generic protocol for non-media pay-to-stream data
91+
92+### Grants
93+
94+The Urbit Foundation operates a grant program aimed at new Urbit developers, network public goods, and community development. Work on the Bitcoin wallet, Lightning implementation, and submarine swaps for Volt (Urbit Lightning) users all has received funding from UF, and interesting non-technical proposals with social value to the network are also considered.
95+
96+Grants homepage: [https://urbit.org/grants](https://urbit.org/grants)
97+
98+Past Bitcoin-related grants
99+
100+- [https://urbit.org/grants/bitcoin-full-node-provider-and-wallet](https://urbit.org/grants/bitcoin-full-node-provider-and-wallet)
101+- [https://urbit.org/grants/volt-lightning-on-urbit](https://urbit.org/grants/volt-lightning-on-urbit)
102+- [https://urbit.org/grants/lightning-development](https://urbit.org/grants/lightning-development)
103+
104+## Bitcoiners on Urbit
105+
106+### Groups
107+
108+Urbitcoiners: ~pindet-timmut/urbitcoiners
109+
110+### Providers
111+
112+**Bitcoin Full Nodes**
113+
114+~tirrel
115+~zod
116+
117+**Lightning Nodes**
118+
119+~tondes-sitrym
120+~bosdys
121+
122+### Guides
123+
124+Running %btc-provider with a full node on Raspberry Pi: [https://subject.network/posts/pi-fullnode-urbit/](https://subject.network/posts/pi-fullnode-urbit/)
125+
content/blog/2019-10-3-roadmap.mdnew file+112
@@ -0,0 +1,112 @@
1++++
2+title = "~2019.10 Roadmap"
3+date = "2019-10-02"
4+description = "Galen Wolfe-Pauly on the road ahead for the identity/OS/interface/community stack."
5+aliases = [
6+ "/posts/essays/2019-10-3-roadmap",
7+ "/posts/2019-10-3-roadmap"
8+]
9+
10+[extra]
11+author = "Galen Wolfe-Pauly"
12+ship = "~ravmel-ropdyl"
13+image = "https://media.urbit.org/site/posts/essays/2019-10-3-roadmap.jpg"
14++++
15+
16+
17+
18+The daily work of building a new OS from scratch is so engaging and exciting that we habitually forget to even take stock of what we’ve accomplished. We’re fixated on the prospect of moving the world on to Urbit, starting with ourselves.
19+
20+It’s a good thing I have a recurring reminder to write these updates. While our focus is on the future, it’s good to get a sense of the rate that we’re moving forward, and to let everyone know what’s been going on. We’ve made great progress over the past few months.
21+
22+We’ve got a new interface, Urbit 0.8.0, Hoon School, and a grants program among lots of other updates. We’ll go into detail about all of these, and talk a bit about where we’re headed next. The system is improving at a really good pace. We intend to keep it up.
23+
24+## Identity (Azimuth)
25+
26+The other day I got an email, clicked a link, and got a planet. A real, live, piece of cryptographic property with paper wallets and everything. It took about two minutes. And at the end, I could have easily sent invites to my friends.
27+
28+This experience is part of a completely new Bridge, the interface for interacting with your Urbit identity. The beta experience we’re testing today is quite stripped down, but it’s a huge improvement over the last Bridge release. Clicking a link is a lot easier than downloading source code, running it from the command-line, and probably running into a python-related error.
29+
30+Getting to this point involved rewriting Bridge from scratch, figuring out how to host it securely, building infrastructure to fund the requisite transactions involved in registering a new identity, and setting up a service to send emails (and dispose of them afterward). We've also redesigned our paper wallets to make them simpler and clearer.
31+
32+We still want to get this new version of Bridge a bit further along before releasing it to everyone — but we’re excited about it. We didn’t quite get to the point of building an affordance for payments, which we had hoped to do, but that’s coming later.
33+
34+We want everyone to have an Urbit identity. And we want it to be incredibly easy to get one, so we’ll get Bridge out this month with a new urbit.org (more on that below).
35+
36+The other area of identity-related work was Sigils — the algorithmically generated images that go with every Urbit identity. (We’ve got a blog post in the works that covers how we created these, which is a good story that needs to be told.) The original version of Sigils didn’t look very good at small sizes and a few collisions were found (thanks to [urbit.live](https://urbit.live) for helping to discover the collisions). The [new, improved sigils](https://github.com/urbit/sigil-js) have no collisions and look great at small sizes.
37+
38+**Q4 2019**
39+
40+- Release Bridge to the public
41+- Get Bridge working well on mobile
42+- Add payments support, hopefully including BTC
43+- Add a network explorer
44+
45+**Q1 2020**
46+
47+- Integrate Bridge with a native app for Arvo
48+
49+## OS (Arvo)
50+
51+As a team, we want Urbit to be our primary computer, our last computer, our permanent computer. And we want this now — or at least as soon as we possibly can. We’re both ambitious and impatient.
52+
53+The frustration that we can’t move onto Urbit today propels us forward. The system saw major updates over the past few months all the way through the stack. On the Arvo side, we divide our work into Infrastructure (everything in the kernel and interpreter) and Interface (everything in userspace and the front-end). We’ll start with Infrastructure progress first.
54+
55+We’re very nearly to the point that all the kernel-level code in the system has been written by our current team. The one remaining vane that deserves a rewrite (Gall) has had a major cleanup by Jared just recently. The [Ship of Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus) approach does appear to be working. The infrastructure team is doing fantastic work and has really deepened their ownership of the system. The Urbit of today is on the road to becoming a great piece of system software.
56+
57+The biggest infrastructure-level milestone was the release of [Urbit 0.8.0](https://github.com/urbit/urbit/releases/tag/v0.8.0). We introduced a new process-separation architecture, implemented the correct bootstrap sequence, moved to LMDB for persistence, replaced our http vane (%eyre) and moved to Nix for our build system.
58+
59+To put it simply, Arvo is now much more stable and durable. During the beginning of the year we were seeing bugs and instability that were frustrating and unacceptable. While there are still issues on the live network, none of them terrify us much. We also implemented the ability for users to ‘individually breach’, which means that you can now reset your Urbit without waiting for us to reset the network.
60+
61+### Landscape (Arvo UI)
62+
63+We don’t just build infrastructure for others to develop on top of. We build interfaces too. At the top of the stack, we released a completely new Landscape, the interface for Arvo. This new interface makes it possible to build other ‘modules’ for Arvo that go beyond chat and publishing.
64+
65+This new Landscape is a complete departure from the last direction. Your Urbit now has a simple home screen that launches individual modules and it’s [relatively easy](https://github.com/urbit/create-landscape-app) to create new ones. We’re all enjoying using Landscape around the office. It’s still a bit of a prototype — but it’s quite a good one, I think.
66+
67+In moving to this new model we decided to narrow our focus to desktop only for now. We’ll return to mobile again next year — but first we want to get the desktop experience right. We’ve pulled the iOS app from the app store for the time being. I’m personally sad to see it go, since I enjoyed using it. But our prior iteration of Landscape just wasn’t quite right.
68+
69+This version of Landscape is, I think, the last one that we’ll call a prototype. Over the past few weeks, since shipping this, some amazing work has been happening on the interface front. We have a systematic approach to building interfaces on top of Urbit that’s very promising, albeit just getting started. We’ve already put out [one post](https://urbit.org/posts/landscape-a-portrait/) about Landscape's future, with more posts to come.
70+
71+**Q4 2019**
72+
73+- Improved Arvo-level error handling
74+- Implementation plan for ‘telescoping kelvins’ — or [how we plan to future proof Arvo](https://groups.google.com/a/urbit.org/forum/#!topic/dev/6Mwn6TQFVwc)
75+- Versioning scheme between Arvo and Vere
76+- A new Haskell implementation of the daemon
77+- A native client (instead of just a browser tab)
78+- A [new user-space architecture](https://docs.google.com/document/d/1hS_UuResG1S4j49_H-aSshoTOROKBnGoJAaRgOipf54/edit)
79+- Hoon.hoon that’s OTA upgradeable
80+- Working Jacque prototype, a graal-truffle-based implementation of vere
81+
82+**Q1 2020**
83+
84+- Integrated client with Bridge and Arvo
85+- New interface framework, codenamed ‘Widescreen’
86+
87+## Docs + Community
88+
89+We had quite a bit of interest in our second session of Hoon School. We ended up with 150 people enrolled in Hoon 101, and 42 in 201. The 101 session just ended, with a lot of positive responses and feedback from the participants. We learned a lot doing it and got quite a bit of interesting new example code.
90+
91+Hoon 101 started with students with little to no programming experience. Hoon 201, which is just getting underway, covers more advanced topics. We’re quite curious to see what comes out of it.
92+
93+We’re also adding features to Landscape to make it more amenable to use by Hoon Schoolers. Good examples include code evaluation within Chat (for office hours), and the ability to pin posts in Publish. The next crop of Hoon learners will be able to use Urbit to learn about Urbit.
94+
95+Aside from Hoon School we’re always updating our documentation. Most notably, we added search to the docs (finally). This was a much needed feature that makes the docs much more usable.
96+
97+We also launched our [grants program](https://grants.urbit.org/) quietly, but all of our available bounties were quickly claimed nonetheless. We’re ready to give away more address space to contributors and are excited by how quickly people got involved.
98+
99+We also did some experimentation with holding events on Arvo. We held weekly AMAs for while, and hosted a few meetings with the community. With the new UI out, our public channels have been a lot more active. We’ll surely be holding more on-urbit events in the future — but for the time being the conversation in urbit-help is a lot of fun.
100+
101+**Q4 2019**
102+
103+- Vane level documentation
104+- An active grant program
105+
106+## urbit.org
107+
108+Urbit.org is about ready for a refresh — so we’re in the process of rebuilding it. We have, for a long time, told the story of Urbit by describing the system technically. We think Urbit can be explained much more simply and much more concisely. We’re working to put together a new set of materials in this direction.
109+
110+We’d also like to populate urbit.org with a lot more content about what we’re working on and thinking about. We do a reasonable job of writing updates, but many of our projects get released without any background info. Tlon and the Urbit community are full of smart, thoughtful people — and we’d like to do a lot more to surface their work. We plan to close out the year with both a new website and a lot of writing about what we’ve been building. Not everyone wants to read the source code!
111+
112+That covers it for now. If you have questions or want to chat — find us in `~dopzod/urbit-help`. See you online!
content/blog/2019-5-roadmap.mdnew file+103
@@ -0,0 +1,103 @@
1++++
2+title = "~2019.5 Roadmap"
3+date = "2019-05-15"
4+description = "Where we are and where we're going as of mid-2019."
5+aliases = [ "/posts/essays/2019-5-roadmap", "/posts/2019-5-roadmap" ]
6+
7+[extra]
8+author = "Galen Wolfe-Pauly"
9+ship = "~ravmel-ropdyl"
10+image = "https://media.urbit.org/site/posts/essays/2019-5-roadmap-1.png"
11++++
12+
13+
14+
15+We often get so busy that we forget to tell you what we’ve been up to. Here’s an update on what we’re doing and where we’re headed with each layer of the stack.
16+
17+At a very high level we have two goals for 2019: make Azimuth easier to use, and get Arvo to a 1.0.
18+
19+Next year we’ll begin to move away from some of the MEGACORP software we use in the office, and replace it with our own tooling. There’s some exciting work happening in that department, but we’ll cover that in a future post.
20+
21+For some related recent thinking on all of this, see [The 100 Year Computer](/posts/essays/the-100-year-computer/), [The State of Landscape](/posts/essays/the-state-of-landscape/) and [Azimuth as MultiPass](/posts/essays/azimuth-as-multipass/).
22+
23+For now, let’s just look at what’s on the immediate horizon:
24+
25+## Azimuth
26+
27+At lunch the other day someone on our team said something like, ‘We built a complete and working public key infrastructure, but we haven’t told anyone.’
28+
29+It’s true. Azimuth is operational, secure, and well tested. It’s a pretty cool piece of technology and it’s out there in the world for anyone to use. It also doesn’t require that you use Arvo — Arvo happens to make use of Azimuth, but Azimuth itself is a completely separate system.
30+
31+So the question is why haven’t we told the world about it?
32+
33+I tend to think that in order for a technology to succeed it has to not only be an important technical innovation, it also has to be easy to understand as a product. And that’s our answer: we’ve undersold Azimuth because we want it to be easier to understand by _using_, not just by reading the code. Azimuth is quite an elegant piece of technology — but that doesn’t matter until it has a great user experience to match.
34+
35+That’s why, in the near term, we’re focused on building on top of Azimuth ourselves. We can’t ask others to go down roads if we haven’t already been down them.
36+
37+Here’s what we’re building first:
38+
39+### Q2 2019
40+
41+- A simplified onboarding flow for getting an Azimuth point that’s simple to share with friends over email, text or as a URL.
42+- A redesigned and improved Bridge for managing your points.
43+- An interface that allows you to easily send money between Azimuth points without running Arvo.
44+
45+### Q3 2019
46+
47+- Expanded Azimuth-centric example modules, documentation and developer tooling.
48+
49+Still under consideration:
50+
51+- An OAuth server or JWT flow for logging into any service with an Azimuth point.
52+- A mobile app for point to point payments using Azimuth.
53+
54+### 2020
55+
56+Azimuth is beginning to feel like [multipass](/posts/essays/azimuth-as-multipass/), with a variety of ways to use Azimuth points without ever booting Arvo
57+
58+## Arvo
59+
60+The Arvo interface has always been held back by Arvo’s technical immaturity. This is still true to some degree. The system has not stabilized completely.
61+
62+But! We’ve been using Landscape quite a lot lately. I use it daily, in fact — even [on my phone](https://itunes.apple.com/us/app/landscape-urbit/id1393148862). An encrypted (although not audited — so let’s not call it ‘secure’), authenticated chat where I own the keys and can read the source code feels really nice to use. The interface isn’t as good as we’d like, but it’s not bad. Landscape is a great preview of where we’re going: a simple, permanent, self-sovereign computer.
63+
64+There are still rough edges, and Landscape is not nearly general purpose enough, but we have plans:
65+
66+### Q2 2019
67+
68+- A new update to the Arvo interface that we’re calling Modulo. Modulo expands beyond chat and longform discussion to make your Arvo interface feel much more like the computer it actually is.
69+- Upgrades to our event persistence, networking, and DNS integration aimed at much better stability. Arvo instances don’t crash that often, but with these changes it should be very rare.
70+- Significant improvements to testing with a new simulation testing framework and integration testing pipelines.
71+
72+### Q3 2019
73+
74+- A significant overhaul to Gall, our application model, making it much simpler for users to write apps or ‘agents’ in Arvo.
75+- A new version of the compiler that makes us less reliant on jets. This will eliminate a major obstacle to achieving network continuity, or the ability for ships to upgrade themselves totally over-the-air, forever.
76+- A significant overhaul and stability update to Clay, our filesystem, making it possible for us to trust it for self-hosting, search it easily, and depend on it for long-term data storage.
77+- Tooling for hosting and hopefully a beta program for hosted Arvo instances run by Tlon.
78+
79+### 2020
80+
81+- A completely overhauled Arvo interface, Daigo, with a complete but simple set of messaging and collaboration tools. Modulo is meant to be fun to experiment with, but we aim to make Daigo part of our daily workflow.
82+- We come to work every day, use Arvo, go home.
83+
84+## Community
85+
86+We’ve often felt like it was far too early to invite others in to the system.
87+
88+As long as we’re up front about the state of this 100 year computer -- that it’s live, but incomplete — I think it’s a good thing to welcome people on board. There’s plenty to play with, experiment with and explore.
89+
90+Hoon school was the first effort in this direction. We intend to do a lot more:
91+
92+### Q2 2019
93+
94+- Scaling Hoon school up to include both a track for experts and for beginners, and allowing many more participants.
95+- Holding more meetings and events on Landscape, experimenting with Arvo-native discussion.
96+- A clear program for address space grants for developers + contributors.
97+- New documentation site with searchable library docs.
98+
99+### Q3 2019
100+
101+- Hoon School participants understand clearly how to build a Modulo agent, and invite others into it.
102+- The road toward building an Azimuth module is well understood, paved, and clear.
103+- We have clear instructions and tutorials for building Azimuth modules and using Azimuth as a login or reputation primitive.
content/blog/2020-to-2021.mdnew file+45
@@ -0,0 +1,45 @@
1++++
2+title = "2020 -> 2021"
3+description = "Reflecting and looking forward."
4+date = "2021-01-20"
5+
6+[extra]
7+author = "Josh Lehman"
8+ship = "~wolref-podlex"
9+image = "https://media.urbit.org/site/posts/essays/arch-sunrise-2.jpeg"
10++++
11+
12+
13+
14+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.
15+
16+## 2020
17+
18+In spite of the many challenges presented over the last year, it was a resoundingly good one for Urbit.
19+
20+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.
21+
22+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.
23+
24+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.
25+
26+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.
27+
28+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.
29+
30+## 2021
31+
32+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.
33+
34+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:
35+
36+- Rework urbit.org to better help developers learn how to contribute to Urbit
37+- Since Urbit is ready to build on top of, provide practical guides that demonstrate how to do so
38+- Guide developers to make high-value contributions to Urbit and its ecosystem
39+- Build community amongst contributors
40+
41+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.
42+
43+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.
44+
45+See you on the network!
content/blog/20200929-state-of-urbit.mdnew file+72
@@ -0,0 +1,72 @@
1++++
2+title = "Late 2020 Progress Update: OS 1 -> OS 1.N"
3+date = "2020-09-28"
4+description = "When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before."
5+
6+[extra]
7+author = "Galen Wolfe-Pauly"
8+ship = "~ravmel-ropdyl"
9+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/state-of-urbit-1.jpg"
10++++
11+
12+
13+
14+When we announced OS 1, in April, we started to disappear into Urbit. Since then, we’ve been living on Urbit like we never have before. This has been our goal for years: to mature the system we’re building by becoming its first committed users. We knew that critical step toward Urbit’s maturity was being able to depend on it ourselves, but the system itself had to mature to the point that we could do that practically.
15+
16+We’ve done this in fits and starts. We’ve _tried_ and failed a few times over the years. We’ve always _used_ Urbit to some extent, but we’ve never _relied_ on it. These past six months have been different. I can’t tell whether it was out of sheer determination and commitment, or that the system was just genuinely ‘there’. Either way, both Tlon and the Urbit Community genuinely live on Urbit now.
17+
18+In a way, our ability to use Urbit day to day doesn’t make sense. When we shipped OS 1, it was full of holes. There were serious performance, stability, and reliability issues. Plenty of people showed up and thought, ‘I don’t understand why you think this is useful.’ But, it was good enough that we wanted to use it. And since we wanted to use it, we put our energy into making it better like we hadn’t ever before. Being able to use a system that you can really trust is a wonderful feeling. It’s Computing Without Compromises.
19+
20+All of the sudden, it’s Fall. We never found the time to name any of our releases or write announcements. We’ve just been making the system better in every way we can find. We’ve got a lot of exciting things planned for the last few months of the year — but I wanted to recap the progress we’ve made for those following along from the outside. If you haven’t been on the network, it’d be impossible to see.
21+
22+The tl;dr is that Urbit is much faster, more reliable, and nicer to use than it was six months ago. Things have gotten much better, across the board. We threw ourselves into OS 1 admittedly underprepared, but we’ve learned a lot and matured the system a lot along the way.
23+
24+Anyway, let’s walk through the details. We’ll talk about our infrastructure and interface work independently, since that’s how we organize things internally. Then we’ll talk a bit about what’s going on on the network.
25+
26+### Infrastructure
27+
28+
29+
30+In April, Urbit was slow, fragile, and didn’t always update itself properly. We made enormous progress on all of these.
31+
32+First off, Urbit is about 10x faster for most users. With some careful debugging, we were able to locate a few really [high](https://github.com/urbit/urbit/pull/3029) [impact](https://github.com/urbit/urbit/pull/3054) [improvements](https://twitter.com/pcmonk/status/1276327036722704385). There’s still performance work to do, but the effects of this work are widespread. Boot times are faster, local compute is faster, the network is faster. It’s a huge improvement.
33+
34+Second, we got our memory usage under control. Urbit still uses a 2GB memory arena. If the state of your Urbit grows to over 2GB things, uh, fall apart. This used to happen regularly, and now it’s pretty much unheard of. We implemented [tooling](https://github.com/urbit/urbit/pull/3235) to compact and deduplicate the memory image when it’s growing too large. We brought the memory usage of the compiler [down ~90%](https://github.com/urbit/urbit/pull/3041). There are areas where we can be more disciplined about how we use memory, but this is more or less a solved problem for the near term.
35+
36+Third, we implemented a completely new build system. Well, we actually [got rid of the build system](https://urbit.org/blog/ford-fusion/) altogether and [made it a part of the filesystem](https://github.com/urbit/urbit/pull/3060). This made it possible for us to fix our over the air (OTA) updates and make them both fast and reliable. In April, an OTA could bring down your node and would take hours or even days to apply. Today, we regularly deploy OTAs with no fear of them breaking any nodes — they often go from galaxy → planet in a minute or less.
37+
38+We also rewrote a large part of our runtime in Haskell and made overall progress on [network scaling](https://github.com/urbit/urbit/pull/3174). And: we implemented a [principled approach](https://github.com/urbit/urbit/pull/2366) to [error handling](https://github.com/urbit/urbit/pull/3064), making nodes much less likely to become unrecoverable.
39+
40+The network is stable, fast, and safe from day to day. We’re pretty confident it can grow quite a bit without serious issues. When we shipped OS 1 we really weren’t sure what we could handle. Now we’re standing on much more solid ground.
41+
42+### Interface
43+
44+
45+
46+When we shipped OS 1 it was a bunch of separate pages (that were slow to load), all with separate ways of storing and processing data. Our interface work over the past six months is all about unification and simplification.
47+
48+First, we pulled OS 1 together as a [single page app](https://github.com/urbit/urbit/pull/3025). Using OS 1 involves a good amount of moving around and refreshing the page each time was pretty painful. Now it’s snappy to move between pages and keep up with what’s going on. In tandem, we started using our own component library, [Indigo](https://github.com/urbit/indigo-react). This makes frontend development much cleaner and more efficient.
49+
50+Next, we unified the way we store data and compute. It used to be that each individual module (chat, publish, and links) used their own ‘agents’ to store and process data on the Urbit side. (An agent is the Urbit equivalent of a datastore + business logic.) With a lot of moving parts, this approach caused all kinds of synchronization challenges. Rather than a module-per-agent model we’ve started to move toward a type-of-data-per-agent model. The first of these is [graph store](https://github.com/urbit/urbit/pull/3110). We’re presently in the process of migrating all our modules to graph store.
51+
52+Those two are by far the most significant, but there’s so much more. We [rewrote](https://github.com/urbit/urbit/pull/2937) the `group-store`, allowing for different roles (admin, moderators, and so on) in a group. We shipped better debugging tools, automatic reconnection, a settings panel, and overall visual polish and refinement.
53+
54+
55+
56+And I almost forgot [Leap](https://github.com/urbit/urbit/pull/3231): an omnibox for navigating around OS 1 with the keyboard. We have plans to make Leap much more powerful — but it’s a great first start toward making OS 1 keyboard accessible. I almost exclusively use [Leap](https://upload.wikimedia.org/wikipedia/commons/0/06/Canon_Cat_keyboard.jpg) to get around OS 1 these days.
57+
58+### Community + network
59+
60+
61+
62+Our primary goal with OS 1 was to get both Tlon and the Urbit Community living entirely on Urbit. We did that, and in doing so we’ve seen how nice it is to grow a community in a calm, non-invasive environment. We started doing regular [Urbit](https://twitter.com/urbit/status/1308875082312364048) [Dialogues](https://twitter.com/urbit/status/1304139629948329985) with friends and peers in the absence of physical meetups, which have been fun.
63+
64+Getting onto Urbit is still relatively challenging. By the standards of software you run yourself, it’s not so bad at all. But by comparison to ordinary consumer software, it’s way too hard. Tlon is [working on that](https://tlon.io) — but these last six months have been only for the brave. That is, those that want to host their own nodes.
65+
66+Turns out, there are plenty of people who are up for running Urbit themselves and quite a few small communities have sprouted around the network. Overall the network has a fun, cozy feeling. It’s nice.
67+
68+### What’s next
69+
70+We’re still more or less flat-out, full speed ahead into an even better Urbit-world. The seeds of change were planted when we made Josh the [interim technical director of urbit.org](https://urbit.org/blog/first-steps-towards-urbit-org/). Urbit itself is getting close to the point where the separation between Urbit and Tlon has to become more real. Urbit is aimed at being an ubiquitous platform, Tlon is aimed at making it as usable and useful as possible.
71+
72+We’ll talk about some of this on [October 9th](https://www.meetup.com/urbit-sf/events/273439025/), and you can see a bit of what’s coming on [tlon.io](https://tlon.io) today. If you tried booting Urbit in April and it was tough, try again. We’re easy to find on the network, and we’d love to get reacquainted.
content/blog/20201119-models-of-society.mdnew file+65
@@ -0,0 +1,65 @@
1++++
2+title = "Models of Society"
3+description = "Conversations compose society. What composes conversation — how do we digitize it in a way that enhances society without imposing upon it? How do we form this new medium, both to facilitate natural human behavior and to inspire the best of it?"
4+date = "2020-11-18"
5+
6+[extra]
7+author = "Tyler Shuster"
8+ship = "~radbur-sivmus"
9+image = "https://media.urbit.org/site/posts/essays/cochno-stone.png"
10++++
11+
12+_I had used Facebook and Google for my entire adult life. I knew they were toxic but I didn't know why. For a few weeks I tried to create a website that would scrape data from Facebook’s API and push data back, puppetting it from my own server. But as I stared headlong into the ever-shifting darkness of the modern web, I despaired and abandoned my attempt. Less than a year later I heard about Urbit. Technically, it went way over my head—but socially I knew exactly what it was, what it always had to be, why it was a discovery and not an invention, a place and not a product. I've watched the settlers there for four years, only just now using the opportunity of the pandemic to swim to this new landscape and gaze upon this young nation, this digital city, this urbis ec bit. I do not work for Tlon. I just live here._
13+
14+<hr>
15+
16+All people like to talk. Society is built by talking. In this—the year of our Lord two thousand and twenty—for many (maybe most) talking means typing on computers: handheld, laptop, or desktop. Computers can do all sorts of interesting things, like aid in designing buildings or simulate protein folding—fundamentally, a computer is a machine for doing math really fast. But computers can be networked, which turns them into tools for communication. Because society runs on talking and because computers enable us to do that, the most common thing that computers end up doing is to transmit human thoughts in text. Normal people call this writing, which is a kind of talking. Let’s call it messaging. When we think about building a good computer—and computer network—one that serves society in the best ways needs to do messaging well. Only a small percentage of people will regularly do anything else. (Urbit does serve those needs but I will leave that explanation to more capable minds.)
17+
18+## Modes of Messaging
19+
20+
21+
22+In general, technology serves humanity as a kind of appendage—instead of thinking new thoughts or acting on its own, it does what we command. Technology never creates new social structures—it merely makes existing ones easier, or it facilitates the creation of new ones. We use our tools to expand our capacities, and once we are capable of doing more, we can imagine new things to do. Inventing the wheel did not invent motorized transportation—but it did facilitate it and it was a necessary step, even an inspirational one. Similarly, the invention of writing made new forms of human interaction and new tools for organization possible.
23+
24+Consider the following conversational conventions, or modes of messaging: a letter; a dialogue; a book; a meeting; minutes of that meeting. These are each pieces of technology: finely constrained solutions to human problems. Now, we have digital forms of each of these which diverge variously from the original. A letter becomes an email. A dialogue becomes a chat room, or a series of blog posts, or a twitter spat. A book becomes a website or an ebook. Meetings in 2020 have virtually been replaced by their virtual counterparts. Minutes become recordings or transcripts.
25+
26+Although we do not have a clear picture of how humanity developed the technology of writing out of the basic capacity for speech, we can imagine that the computerization of writing has many parallels. It does not make the old tools obsolete, nor does it immediately introduce new social structures. It does create the potential, however. On the timeline of human existence, we have only had digitized text for a relatively short time. Because we want to understand how to best use these new forms, we should look at their underlying structure.
27+
28+In order to digitize messages well, computers need to reconcile two facts about all modes of messaging. They have:
29+
30+1. One basic shape, and
31+2. An infinite variety of forms.
32+
33+1 — The basic shape: all these modes have one common substance: human language. Any conversation is made of words. At first we only had spoken language. Then we discovered writing. Writing allows us to encode our words as glyphs to transmit them over time or distance. The internet extends this capacity. We called this "hypertext"—like good old fashioned text, but one level up. A staggering amount of messaging now takes place over this hypertext transfer protocol (http). In the process of digitizing language, we have learned the basic shape of a message. We can see this in how every social network shares messages in basically the same shape: an author, some content, references, an audience. We can confirm this basic shape by comparing it against our experience of the real world, and the previous comparison between speech and writing. Speech and writing both use the same substance, and take the same basic shape. They all have an author, content, references, and an audience.
34+
35+2 — Our experience of this one basic shape takes an infinite number of forms. The examples above (letter, meeting, &c) are just a few. These forms depend on the content of the message, the people involved, and the place they occur. All three aspects contribute significantly to its form, but the one that computerized messaging has not adequately compensated for is the place. Content depends only on the author and their intent. Getting certain people to view that content might be more difficult but most know how to use a computer. The place however, has not yet been adequately compensated for, and I think that has contributed seriously to our lack of civil and serious discourse over the internet. A president would not give an address in a bar, and a prospective lover would not utter his advances on stage. In writing, we can use the different physical forms to distinguish place. You shouldn’t read a book by the pool. You might not read a letter in public. You wouldn’t put a billboard in your bedroom.
36+
37+Furthermore, it seems possible that in our eagerness to "connect the world," we focused injudiciously on creating communities around "interests." Evidence suggests that unless the interest has a highly refined focus, these communities devolve into pandering, self-reference, and exploitation. In this way, the internet is something like a convention of conventions, where you wander in a sea of foreigners loosely affiliated by interest and surrounded by advertising booths. In physical space, people do gather by interest but they also gather by physical proximity—they are grounded and bound in place.
38+
39+Having an indistinct sense of place makes the form of conversation ambiguous and the participants of the conversation disconnected. Consequently, people are unsure how to interact. One need only know the term "comments section" to understand that.
40+
41+## People in Places
42+
43+
44+
45+As the internet grew to accommodate new conversation forms using the basic substrate of hypertext, web developers began to conceive of "digital spaces" through analogy—chat "rooms" and "forums,” or the "silo" and the "walled garden." Today, most of our conversation takes place in these walled gardens—privately-owned places which may be beautiful on the inside, but inaccessible from elsewhere. While some of these walled gardens are very large, our conversation is essentially confined to them. There is no roaming from one space to another while keeping one’s identity. We create new identities for new spaces both because we must and because we are afraid of repercussions on one platform for what we say on another. This is because we do not own our identity; we merely have a key—our password. The owners of the walled garden still own the artifacts of our tenure there, and can revoke our access to them at any time.
46+
47+The concept of identity and the concept of place are fundamentally linked. We imagine the prince who travels overseas where no one knows his name, or we imagine the old prospect of traveling to a new world to make a fortune. While those both exemplify a dramatic change in identity and place, we usually want to keep our identity consistent. We want to be recognized by friends whichever place we go, and we all strive toward having a good reputation, which is a consistent identity across places. This consistent identity also allows control of that reputation per place. A man is not judged in public by the words he says among friends. And there is no way to search what someone has said except by asking him. With our current system of identity providers (an absurd term, but a real one), we surrender our rights to selectively expose our thoughts, regardless of the place they have been uttered. A data breach or a weak password might lay bare our most private thoughts. We run the real risk of being confronted by an old conversation presented out of context or after we have learned better.
48+
49+People need distinct spaces to form conversations in distinct modes, and they need to have a consistent identity that controls how public their words are.
50+
51+In theory, we would have a digital city with unique regions, public fora, and sovereign parcels, into which one person might travel at will. In practice, we see this pattern: an app emerges to facilitate a mode of conversation. It gains popularity. Facebook (or Google, or Microsoft) buys and absorbs it. As monolithic empires, they can use the same format for all their messages. This gives them a great amount of power. They use this power to create things like "Sign in with Facebook" (or Google, or Microsoft) that benefit the user by consolidating their identity, but fail to solve the underlying problem. Their problem is that in order to allow people to communicate using the current technology stack, they need to be in control of everything.
52+
53+## Urbis ec Bit
54+
55+
56+
57+Urbit does solve this underlying problem. At this point the explanation goes so far down the stack that you could spend years tracing it all, but the relevant part is this: Urbit is not an empire; it’s a territory. An empire is an entangling of land and rule: within the bounds of said empire, you agree to be bound by its laws and the penalties for transgression. The laws exist at the whim of a despot or cabal. Your standing as a Roman citizen buys you no favors in Persia. In contrast, a territory imposes only physical laws. For example, in the desert, you will die faster. The only way to change that is to alter the desert. Urbit imposes nothing but the digital equivalent of physical laws. You have an identity which can be said to be truly yours, and you have a piece of software that runs on whatever computer you choose and can do anything you want with the messages sent to your identity. There are no social protocols enforced, because no one can control what software you run on your computer. As long as you agree to communicate using the same basic substrate, you can communicate with anyone using Urbit. This is the digital equivalent of speaking the same language. Whether or not others will accept you into their coalitions is not the technology's concern.
58+
59+In the same way that the land provides clay and timber, Urbit also provides the tools and material for building places both public and private. These include the aforementioned consistent message substrate (content), as well as tools for organizing people/audiences, structure for referencing other content, and an identity system that is owned only by you while being verified by all. The places are being built—private rooms with just a few people, meeting halls, club houses, huge public spaces, and countless personal encounters, the contents of which are known to none but the participants.
60+
61+The default tools work with messages in a few of the ways with which we've grown familiar: chat, direct messaging, publishing, link-sharing. They map onto existing forms of messaging because as I said earlier, the technology does not create new social structures; it just facilitates them. We have only seen the beginning of what the internet is capable of doing. Within a few decades it replaced the majority of letters, phone calls, and text dissemination—that was just the first phase of getting up to parity with what written text and speech could already do. In order to get to the next phase of creating new social processes, we need our technology to be organic and democratic, in the sense that everyone can participate and shape it. It needs to have a consensual foundation—a common substrate—and infinite possibility for expression. Urbit provides both of those.
62+
63+Similar to working undeveloped land, it takes a lot of hard work, which is why Urbit is not ready for mainstream adoption yet, and why I alluded to the idea of settlers in my opening paragraph. Traveling to the new world is not for everyone, but everyone is welcome.
64+
65+_How could one do other than submit to Tlön, to the minute and vast evidence of an orderly plant? It is useless to answer that reality is also orderly. Perhaps it is, but in accordance with divine laws—I translate: inhuman laws—which we never quite grasp. Tlön is surely a labyrinth, but it is a labyrinth devised by men, a labyrinth destined to be deciphered by men._
content/blog/2021-11-18-report-from-the-field.mdnew file+94
@@ -0,0 +1,94 @@
1++++
2+title = "Report from the field: Assembly 2021"
3+date = "2021-11-18"
4+description = "The system builds the community and the community builds the system."
5+[extra]
6+author = "Galen Wolfe-Pauly"
7+ship = "~ravmel-ropdyl"
8+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/galen-at-assembly.JPG"
9++++
10+
11+
12+
13+Before Assembly I committed to write a ‘recap’ post for everyone who couldn’t make it. Originally I figured this post would be an opportunity to walk through the list of things that we shipped and showed off in Austin. But it turns out that the most important thing about Assembly was simply the way it felt to be there.
14+
15+I’m not sure it’s possible to really do the feeling in the room justice, but I’m going to try. Then I’ll get into the announcements and happenings for those of you who couldn’t make it.
16+
17+But first, a quick note:
18+
19+We ran Assembly under the [Chatham House rule](https://en.wikipedia.org/wiki/Chatham_House_Rule). Basically, you can talk about what happens at Assembly—but you can’t name anyone.
20+
21+I’ve run many of our Urbit events this way because I think it puts people at ease. Everyone in the room can just relax, connect with one another, and hang out without worrying about being named on the internet.
22+
23+I’ll try to abide by the Chatham rule in this post which is why no one is named specifically.
24+
25+
26+
27+New world energy -
28+
29+In the months leading up to Assembly we were totally focussed on using the event as a release date for a bunch of different lines of work. Coming out of that sprint, we didn’t really know what to expect. We wanted to make sure Urbit was ready for people to build on and that everything we were going to ship worked well. What we didn’t realize was just how emphatically people are *ready to build*.
30+
31+When I got up on stage on Friday night to welcome everyone I was really impressed by the room itself. It was packed with people who looked excited and motivated. The room just looked amazing. There were so many different kinds of people staring back at me. Some who I recognized from the earliest days of the project, and lots I had never seen before. I’ve been at my share of Urbit events, but this was something totally different.
32+
33+We didn’t have much scheduled during Assembly. Most of the time was unstructured to allow for freeform discussion, sunbathing on the lawn, and gathering at picnic tables. The panels that we did schedule will go down in history. Panelists discussed questions about creators, escaping reward systems, and the role of DAOs from governance to governments. There was hard money with a computer on it, Moloch shoes, community members grabbing the mic, and a talk written two hours before it was delivered about the relationship between centralization and decentralization when it comes to UX that blew our minds.
34+
35+I spent the weekend of Assembly in almost constant conversation with people building Urbit hardware, experimenting with different kinds of Urbit software, and thinking about incredible things like a Nock chip. I talked to the lead architect of a CPU from the 90s, a former senior US government official, an editor of a well-known literary magazine, the inventor of a new display technology, musicians whose work I already admired, a fragrance designer, writers, and, of course, lots of engineers and designers from many different backgrounds. Data scientists, systems hackers, language nerds, someone running a successful currency. I watched these people get projects off the ground, start raising money, plan the future of Urbit hosting companies, and plan new features for Landscape. I saw a last-minute warehouse party come together that kept people talking well into the early hours of the morning.
36+
37+Where did these people come from? All over the place. They have this incredible *new world energy*. They understand immediately, intuitively that Urbit has the potential to be a foundation for the society they want to live in. I’ve never seen anything like it.
38+
39+This energy seems to have come from the very practical work we do day-to-day: building Urbit, refining it, making it easier to use. The crowd at Assembly was somehow brought together by Urbit itself. It’s insanely exciting. It makes working on Urbit feel even more like a form of definite optimism. The system builds the community and the community builds the system.
40+
41+
42+
43+Urbit is ready to be built upon -
44+
45+Sometime in early 2021 we realized that there were many lines of work converging on a single theme: ‘Urbit is ready to be built upon’. This is the spirit we wanted to bring to Assembly, and it was very much in the room in Austin. Some of that feeling is still lingering on the network. I think it comes from some very concrete improvements that have been made to the system.
46+
47+We’ve always wanted Urbit to be maintained by a self-sustaining ecosystem and, early this year, we could see what needed to be done to really let others begin doing so. There were four parallel projects that came together to hit this milestone: Software distribution, star.market, developer and operator guides, and the Foundation roadmap. We talked about all of these things in the Assembly keynote (which you can watch [here](https://www.youtube.com/watch?v=ywj36TUtbS4)), but let’s touch on them one by one.
48+
49+Software distribution
50+
51+The most important thing that we shipped just before Assembly is the ability to actually package and distribute software over Urbit itself. It’s now possible for someone to build an app, package it up, and share it with a friend directly over the network.
52+
53+For their friend, the experience is incredibly nice. You can simply send someone a link and they can install the app and run it themselves, on their own urbit, right away. The whole thing is peer-to-peer, of course. There’s no app store, no vetting process. It’s networked software like it’s supposed to be: people computing together freely.
54+
55+We’ve been saying for years that we want people to build on top of Urbit and we always meant it. Now it’s possible in a way it never has been before. To check it out, watch [this segment](https://www.youtube.com/watch?v=MA8sqFi8Bd8) from Assembly.
56+
57+Software distribution can get better in _a lot_ of ways, and we’re continuing to work on it. But it’s live, and people are experimenting with it already. There’s Chess, there’s Pokur, there are video calls (although they’re still a little buggy). Everyone seems to love ‘pals’ and ‘zone’—but you’ll have to get on the network to check those out.
58+
59+star.market
60+
61+We’ve always used the address space to fund our work as one of the primary Urbit developers. As Urbit has become more useful, and address space has become more expensive, it’s more and more difficult for others to do this. The community saw the need for developers to easily use their granted address space to fund their work and a higher resolution for the Foundation to fund contributions to Urbit.
62+
63+This is what [star.market](https://star.market/) and the WSTR project are for. WSTR is an ERC-20 token that is backed 1:1 by ERC-721 Urbit stars. Unlike a star, a WSTR token can be fractionally divided, allowing for a broader distribution of ownership of Urbit. WSTR was built by the community over the past couple of months with no involvement from Tlon. Tlon did, eventually, help to put together star.market—the interface for interacting with the WSTR contracts safely and securely.
64+
65+I’ve come to think that WSTR can be a powerful tool for funding new Urbit projects. I’m excited to see what both our early community of developers and operators can do with it, as well as the nascent Urbit Foundation.
66+
67+Guides
68+
69+As we make it easier for developers to build software, operators to participate in the economy, and communities to make Urbit their home, we need to improve our documentation. We always like to do things bottom-up: the product work comes first. Well, the product is now live.
70+To this end we recently launched:
71+
72+[operators.urbit.org](https://operators.urbit.org/) collects all of the information about participating in the Urbit economy, running infrastructure nodes, and participating in governance in one place.
73+
74+[developers.urbit.org](https://developers.urbit.org/) has an overhauled program for learning about Urbit as a system and beginning to develop on top of it.
75+
76+[network.urbit.org](https://network.urbit.org/) allows anyone to explore the network. View galaxy transfers or how many planets a star has spawned.
77+
78+We’ve got a lot more planned in this area of work in the coming months, and these three sites are a great start.
79+
80+Urbit Foundation
81+
82+Over these past few years we’ve operated the Urbit Foundation as a ‘protocol’ inside of Tlon. Our goal has been to develop that protocol to the point that it’s refined, working, and can run on its own outside of Tlon.
83+
84+Josh has done an exceptional job running the foundation protocol at Tlon over the last year or so. He and I have been working closely together on everything that Tlon builds, while also coordinating our community of contributors. I’m very excited that the Foundation, with Josh as its Director, is now separating from Tlon as a fully independent entity focussed on supporting the ecosystem.
85+
86+Assembly was the perfect moment to begin formally separating out the Foundation and, as of a week ago, it is an independent entity. We’ve thought long and hard about how to make the Foundation an enduring, stable organization. Josh will be the first Executive Director but, ultimately, the Senate of Galaxies will elect the Board. This will keep the Foundation accountable to the network as a whole and I’m optimistic it can work well.
87+
88+If you’re on the network, you can read more about the Foundation in ~wolref-podlex/foundation.
89+
90+Assembly 2022 -
91+
92+I had more than a few enthusiastic people come up to me at Assembly and ask what we were planning for Assembly 2022. I have absolutely no idea, of course. We poured all our energy into making Assembly 2021 a success.
93+
94+Given what I saw in Austin, I’m pretty confident that next year we’ll be in completely new territory. The goal of this project has always been to build a completely new digital world. And now, it seems to be building itself.
content/blog/2021-11-18-the-promise-and-paradox-of-decentralization.mdnew file+55
@@ -0,0 +1,55 @@
1++++
2+title = "The Promise and Paradox of Decentralization"
3+date = "2021-11-17"
4+description = "Is centralization just a natural tendency of all networks? Are we destined to have a 'decentralization sandwich?'"
5+[extra]
6+author = ""
7+ship = "~lableg-tadrex"
8+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/ux-centralization.JPG"
9++++
10+
11+
12+
13+Every so often, a platform will do something outrageous—changing its terms of use, kicking off API partners, restricting [the content category it was built on](https://www.theverge.com/2018/12/3/18123752/tumblr-adult-content-porn-ban-date-explicit-changes-why-safe-mode), banning Donald Trump, failing to ban Donald Trump, etc.—and we'll all realize we're utterly dependent on centralized entities that can make arbitrary and unaccountable decisions. Sure, you can build your own minimal Facebook or Twitter clone, if you really want, but can you build your own Cloudflare? How about your own payment network? If your company does something legal in your country but banned in America, and the US decides to sanction you, which leads to local banks cutting you off because they can't survive without access to the dollar, are you going to build your own reserve currency? Your own Taiwan Semiconductor Manufacturing Co. or ASML?
14+
15+There are, to varying extents, efforts to do all of the above. But what's worth considering is that *all of these bans happen through centralized actors running on decentralized systems*. The Internet was supposed to be a totally open set of protocols that anyone could interact with, and for a long time it was, and yet getting kicked off Facebook and Twitter means being exiled from public discourse. Banks are regulated, but every country can set up their own banking regulations, and different countries see the social role of banks very differently; for some countries they're a tool of economic planning, for others a way to help connect local companies to global markets, for others a source of money that can be channeled to politically favored groups. The chip industry was historically very open to new entrants; the transistor was developed at Bell Labs, and for political reasons AT&T licensed it to all comers at a low price.
16+
17+And yet all of these originally decentralized systems end up facing some degree of centralization.
18+
19+The promise of a decentralized system is that anyone can build anything they want, because no one owns it. There are three important features of this; two downsides and a caveat:
20+
21+- The first downside to "Anyone can build anything" is that "anyone" means *anyone*, and the people to whom decentralized systems are the most attractive are the ones who are banned from other systems, often for good reasons. Free speech absolutists want to be defending Aleksandr Solzhenitsyn or Eugene V. Debs or even Lenny Bruce, but if you want to get a sense for the typical piece of content enabled by a totally uncensored communications system, check your spam folder.
22+
23+- The second downside is that a lack of ownership means that no one is responsible when things go wrong. Bitcoin doesn't have a way to censor your decision to move money from one address to another or even a protocol-level sense of whether you're buying Alpaca socks or a rocket launcher. (nb: You are almost certainly not buying a rocket launcher with Bitcoin; you are at best getting scammed, and at worst [getting in trouble](https://www.justice.gov/usao-cdca/pr/los-angeles-county-man-pleads-guilty-federal-charge-attempting-obtain-biological-toxin)). But this also means that the protocol can't tell when you meant to send your life savings to your cold wallet and sent it to the wrong address instead.
24+
25+- The caveat is that, to quote a [*Diff* piece from last year](https://www.thediff.co/p/amazon-a-new-kind-of-antitrust-risk#:~:text=does%20it%2C%20too.-,Technology-Governance%20Fit,-Pondering%20Durian%20has) ($), "[A]ny decentralized order requires a centralized substrate, and the more decentralized the approach is the more important it is that you can count on the underlying system." This applies to cryptocurrencies (you can trust the protocols) and to the Internet (ditto). It also applies, in an interesting way, to the increasingly decentralized world of free trade and free-flowing capital: money can only flow and deals can only be made if everyone has a consistent sense of property rights and contracts, and the definition of those concepts will typically be determined by whichever participant in a transaction has the more sophisticated financial and legal system. Globalization ends up being a bit like Henry Ford's pitch: you can use any economic paradigm you want, as long as it's the American one.1
26+
27+An open, decentralized system is *sparse*: there's room for anything, which means that most of the possibility space consists of nothing at all. This creates a natural demand for onramps—Coinbase for figuring out Bitcoin, portals for figuring out the Internet, TSM for turning chip designs into functioning products, and the like. These create a complicated dynamic: these onramps are built on an open system, but part of their function is to close off some of it. And the better they do that, the more value they can capture. Meanwhile, because they have a monopoly on what they've fenced off, their economics support providing a better user experience. Make a really helpful update to the Bitcoin wiki, and you can feel good about yourself and perhaps contribute to the price of Bitcoin in a highly indirect way; design and launch an improved onboarding process at Coinbase and your contribution is quantifiable, and affects your next cycle's equity grants.
28+
29+This privatization proceeds in three different ways:
30+
31+- Some companies start building on an open protocol and then slowly make it their own. Chrome's decision to make the search bar synonymous with the address bar was a slight improvement in the interface, but also a very strong statement that Google had replaced manually typing in URLs as the default way to navigate. (The strongest evidence for this is the frequency of navigational searches; [the most commonly-searched term on Google](https://www.mondovo.com/keywords/) is "Facebook" and [the most frequently searched term on Bing is "Google"](https://www.bloomberg.com/news/articles/2021-09-28/google-tells-judges-it-s-so-popular-it-s-bing-s-top-search-term).) Typing in URLs is a sometimes-decent way to find what you're looking for, though [the half-life of links is about two years](https://blog.zomdir.com/2017/10/the-half-life-of-link-is-two-year.html). But guessing at URLs can be [perilous](https://en.wikipedia.org/wiki/Whitehouse.com). No one is responsible for fixing this, but Google is the closest approximation, because what they are responsible for is solving the "look for something on the Internet and get the wrong result" problem, a different but related one from the broader task of allowing arbitrary site owners to host arbitrary content. Privatizing is effective, and solves problems for users rather than protocol designers. But it does go against the spirit of the original network.
32+
33+- Twitter is another example, except that they basically created their own open mostly-open protocol and then slowly took control of it. Tweets were originally a simple format, with 140 characters of text and a bit more metadata (this made it compatible with SMS, which had a 160-character limit). For a while, Twitter looked like it would operate a novel protocol and let third parties decide what to put on it and what to read off it. And then the company started to realize that an open system was also one where it was trivial to filter out ads and recommendations. So the outside partners gradually got cut off.
34+
35+- Facebook—the product, not the company—is a third example. It essentially implemented a missing element to the protocol: *identity matters*. When the original protocols were being hammered out, identity was a problem taken care of by the fact that getting online required steep hurdles; if everyone involved is affiliated with a university that trusts them to use a PDP-10 responsibly, spam or abuse were not big concerns. (Not that early usage was [strictly professional](https://www.theguardian.com/science/2013/apr/19/online-high-net-drugs-deal).) With billions of people online, accessing relevant information can mean traversing a graph of people rather than links, so the identities of those people becomes important. To the user, if not to the network itself, a name and relationship is a far more important unique identifier than an IP address.
36+
37+This pattern raises a question: is centralization just a natural tendency of all networks? Are we destined to have a "decentralization sandwich," where there's a hard-to-change set of protocols, something open built on top of *that*, and a series of closed systems built on top of that, which are the only ones the average person interacts with?
38+
39+One of the interesting alternatives to this is [Urbit](https://urbit.org), which is trying to build a network in which identity exists from the start, and is neither free nor monopolized. One of Urbit's principles is that users own their data, and while they can use third-party services, they're sharing their data with services, not using a login to access information that lives on someone else's servers.
40+
41+This is a nice theoretical solution to the "build your own" problem above: if someone tries to start Twitter-but-without-banning-X, they begin with "Twitter-but-it's-100%-X," which seems bad until they reach the next stage where trolls arrive and they start to learn that Online Censorship is mostly about spam and gore and only occasionally about politics. But if they're moving their data around, and their friends graph with it, then spinning up a separate instance of the same service, pulling in the same content from their friends, and whitelisting someone who's blacklisted elsewhere is a lot more feasible.
42+
43+At least at first. One of the problems with owning your own data is that it ignores the question of what format that data is in. Data formats are sometimes considered carefully, but they can also be hammered out fast to get a minimum viable product out the door. Then they evolve over time, accumulating cruft and complexity, until they might as well be encrypted.
44+
45+And indeed, what's to stop someone from having a proprietary format that's literally encrypted? Or one that gets changed to an encrypted version later on? This is not a trivial point; if you're ever in a position where you absolutely have to share some information that you want to keep secret, the smartest thing to do is share a huge amount of confusing and poorly-explained information, or use an [annoying but technically accurate format](https://www.vice.com/en/article/gv5vxb/crypto-keys-printout-of-edward-snowdens-email-service-lavabit-ladar-levison). Strict and unalterable rules are no match for determined adversaries, whether they're trying to play a prank, make a point, or maximize shareholder value.
46+
47+But the data format questions are not rhetorical: there is actually an answer of sorts, though it's a frustrating one. Software systems are not just lines of code, but the entire extended system of people who maintain, host, and build on platforms. And the norms of those communities can push back against market pressures. I've been spending an increasing amount of time around Urbit users and devs, and they really do view the current centralized model of the Internet as anathema. They are aware that the fun apps we use are all either designed to be addictive from the start or subject to relentless evolutionary pressure to get more addictive. There's a history of [norms evolving in response to new addictive behavior](https://gist.github.com/jm3/6724931). And Urbit's architecture is a lot closer to norms than to the clumsy mechanism of laws; instead of centralized services that own data, there's a set of 256 Urbit identities that can route messages between users. Instead of single points of failure, there are a few hundred fallback options; instead of the binary of on-Facebook-or-anathematized, there's a 2^8 bit gradient.
48+
49+One possibility for the successor to the current Internet is that it will end up being a system designed to support communities that achieve cohesion based on which forms of addictive or socially corrosive technology they reject. Sort of a digital version of the Amish, [not rejecting technology wholesale but carefully considering every new technology before adopting it](https://kk.org/thetechnium/amish-hackers-a/). If you assume that the pace of change in consumer-facing Internet stays high, and that it gets more compelling over time, then in the long run the only options are a) be careful what you use, or b) accept that you're outsourcing a growing share of your decisions to product managers and growth hackers who do not necessarily have your interests at heart.
50+
51+Norms are not a perfect solution to these problems (if they were, we'd only know about issues like novel addictive behaviors, monopolies, and the homogenization of entertainment from history books). And technology can't fully solve social problems. But it can certainly have an effect on them—"you can't solve a social problem with technology" is a good guideline, but technologies mitigate them all the time. What's a streetlight if not a technological solution to the social problem that there are places where it's dangerous to be out when it's dark? What's asymmetric-key cryptography if not a technological solution to the social problem that it's hard to keep secrets? There's still a fundamental tension with open systems, where they get mature enough to be useful at which point the median user's priority is getting things done rather than adhering to the network's original design principles. But a design that recognizes this from the beginning, and a community that wants to make it happen, can stave off decline for a long time. And that's the positive story of technology: we're all fighting against entropy, which is a hard fight to win, but there are long and fascinating stalemates ahead.
52+
53+(Disclosure: I'm long decentralization by way of Bitcoin and Urbit. If you're on Urbit and would like to discuss *The Diff*, go to ~lableg-tadrex/the-diff.)
54+
55+1. There is naturally some resistance to this, both because of conflicts with different countries' norms and with other countries' natural desire to determine their own destiny. So it's a leaky abstraction, but it gets less leaky over time as economies get more integrated and thus more of the world has to standardize. The most direct example of this is the fact that [the dollar's share of global invoices is 4.7x the US's share of global imports](https://www.economist.com/schools-brief/2020/08/27/global-trades-dependence-on-dollars-lessens-its-benefits) ($, *Economist*). In the same way that English is most likely to be the shared second language of any two randomly-selected people who don't speak it as a first language, the dollar is most likely to be the second most useful currency to anyone in a country that doesn't use dollars.
content/blog/a-founders-farewell.mdnew file+619
@@ -0,0 +1,619 @@
1++++
2+title = "A Founder's Farewell"
3+date = "2019-01-13"
4+description = "My goal was always to fire myself at the first possible opportunity. I'm super happy to reach it."
5+aliases = [
6+ "/posts/essays/a-founders-farewell",
7+ "/posts/a-founders-farewell"
8+]
9+
10+[extra]
11+author = "Curtis Yarvin"
12+ship = "~sorreg-namtyv"
13+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/farewell.png"
14++++
15+
16+
17+
18+After 17 years, I've left the Urbit project.
19+
20+I've resigned as CTO, board member, and voting shareholder of
21+Tlon (Urbit's corporate sponsor). I've also reassigned my
22+personal galaxies to urbit.org (Urbit's embryonic foundation,
23+still in Tlon's custody).
24+
25+My family still has a few thousand Urbit stars (in long timelock
26+contracts), plus a nonvoting minority in Tlon. This isn't
27+authority, just compensation: I have zero central power over
28+either Urbit or Tlon. Nor will I contribute code to Urbit, nor
29+write nor speak publicly about it. I am actually done here.
30+
31+From the very start, I knew Urbit could not succeed until it
32+ceased to be mine and became the world's. Urbit works; its PKI
33+is on the Ethereum mainnet; it's open source; in every way,
34+technical, legal, and mathematical, it is the world's.
35+
36+(What _is_ Urbit? Please read the [primer](/primer).)
37+
38+Let's talk about: why I've left; the state of Tlon; and the state
39+of Urbit. If there's any time left, we'll read some poetry.
40+
41+## Why I left
42+
43+No one had the power to fire me. (If anyone wanted to, they kept
44+it to themselves.) I wanted to quit; I could; I should have; I did.
45+
46+I'm a thinker, not a doer; an explorer, not a leader; an author,
47+not a maintainer. My goal was always to fire myself at the
48+first possible opportunity. I'm super happy to reach it.
49+
50+Any creator is a sort of parent – where control is dependence,
51+powerlessness is independence, and independence is victory.
52+There are a lot of ways to light a fire. The last step is just
53+getting out of the way – which must be done not too late, not
54+too soon, and just right. No one can beat Satoshi in this act;
55+anyone should be delighted to follow him.
56+
57+I worked full-time on Urbit, alone and self-funded, for eleven
58+years. From 2002 to 2013, I wrote an end-to-end clean-slate
59+system-software stack: an axiomatic interpreter that fits on a
60+T-shirt, a typed functional language that doesn't use abstract
61+math, and a purely functional operating system. I didn't patent
62+any of this; I put it all in the public domain. (Not a valid
63+open-source license; Urbit is now MIT licensed.)
64+
65+By 2013 I had a stack that worked well enough to make [a
66+video](https://vimeo.com/75312418), then raise a 1.5M seed round. Urbit in 2013 was a
67+working product – in fact, Urbit has had a live global network
68+since November 2013. But in a new platform, the distance between
69+_working_ and _compelling_ is nontrivial. Especially for a seed
70+company with just a few young engineers, building something like
71+nothing ever built before.
72+
73+Urbit in 2013 had roughly the same feature set as Slack in 2013,
74+but less polished, and decentralized. It was pretty buggy and
75+slow. But had we put all our resources into debugging and
76+optimization, it would not have taken five years.
77+
78+My instinct was always that Urbit's delivery schedule should be
79+as long as possible. For me, there are always two Urbits: the
80+Urbit that exists, and the Urbit that should exist. To invent
81+the latter I have to inhabit it. When I look at the present,
82+I try as hard as possible to look at it from the perspective of
83+the future – that's where my head should be.
84+
85+This always makes me think Urbit sucks. And the last thing you
86+want to do is evangelize anything that sucks. This is a bias,
87+but that doesn't make it wrong. For instance: the 2013 Urbit had
88+a shell and a persistent distributed chat – but the shell was
89+mixed in with the kernel, and the chat with the network protocol.
90+As seen from the 2019 Urbit, this is very lame indeed.
91+
92+The conventional wisdom is to ship your embarrassing "MVP." For
93+several reasons, Urbit occupies a unique strategic position.
94+Urbit just isn't relevant until Urbit is, if not perfect,
95+uniformly excellent. It can't just work. It has to work right.
96+Urbit has to be amazing – which is hardly a useless discipline.
97+
98+I still did not think it would take five years to make Urbit
99+work right – or to get the resources to make it work right
100+(which only happened in 2018). But founders always delude
101+themselves, or no one would do it.
102+
103+Urbit is not uniformly excellent quite yet. There are a few
104+medium-sized cleanups in the near-term pipeline. But this is a
105+matter of months, not years. I don't see any unknown unknowns.
106+The adventure isn't over – but the exploration is over.
107+
108+A clean-slate system software stack, from fundamental interpreter
109+to social network, through typed functional language and
110+deterministic OS, is an enormous architectural journey – so
111+long and winding that it's easy for anyone to get lost in any
112+detail. Isn't that any explorer's first job: not getting lost?
113+
114+But once the route is marked, there is a second duty: getting out
115+of the way. It's time for surveyors, not explorers, to map,
116+measure and smooth every wrinkle on the map. That's how system
117+software matures. Lines first ripped in one long slash are
118+polished, straightened and refined across years and decades.
119+
120+And Urbit is too deep and interesting for one technical leader.
121+Every part of it needs its own owner. But others can't build a
122+real sense of ownership while the founder is still around. I'm
123+not even the best engineer on the project; I just got here first.
124+
125+This codebase is very young and very general; there is a lot of
126+fun left to be had with it; others deserve to have that fun.
127+
128+I have no successor as "BDFL." Technical leadership passes to
129+Tlon as a company. Urbit is open source and anyone may play, but
130+anyone who wants to catch up to Tlon still has a lot to learn.
131+Not that that should stop them!
132+
133+I can't make Urbit technically transparent in one speech. But
134+maybe I can shed a little light on the strategy, organization,
135+history and future of the company and the project. It's easier
136+to be frank on the way out.
137+
138+## Tlon, boiling oceans since 2013
139+
140+First of all: why did we do what we did?
141+
142+An ambitious system software project can inhabit one of four
143+institutional forms: bigco, startup, academia, or community.
144+
145+None of these is a fit for a clean-slate system software stack.
146+The startup is the least worst. I'd do it again.
147+
148+A normal startup lifecycle (Tlon actually got into YC, but
149+declined – this was either cool or lame) looks nothing like a
150+normal system-software lifecycle. Nor is Urbit normal. But
151+while Silicon Valley is absurd, it still fits Marianne Moore's
152+line: "with a perfect contempt for it, one discovers that there
153+is in it after all a place for the genuine."
154+
155+The less said about big companies and big science, the better.
156+But the choice between startup and community is interesting.
157+Let's talk a little about why Tlon, this corporation, exists,
158+then a little more about what it actually is.
159+
160+### Tlon, from cathedral to bazaar
161+
162+I used to think I could give Urbit directly to the world – that
163+I could just post the code and an open-source community could
164+take it from there. That'd probably work now, but it's not yet
165+the right thing – and not because nobody wants a revolution.
166+
167+I've never been an open-source person myself. But the model has
168+fascinated me since I encountered Nethack in the '80s. Now that
169+open-source software is a mature field, we can see what kinds
170+of problems the open-source "bazaar" mode is and isn't good at,
171+versus the corporate "cathedral" mode.
172+
173+One problem open source isn't good at is creative collaboration
174+on large and novel systems. For example, if we consider the set
175+of people creating Google's new Fuchsia OS, and the set of people
176+contributing npm modules, we see that it's almost impossible to
177+imagine something like Fuchsia as a community effort – but this
178+is not for lack of talent-hours. Imagine a bazaar creating a
179+feature film, and you'll get the picture. (And Fuchsia seems
180+like a fairly traditional OS.)
181+
182+Why is creative work so hard for bazaars? We could take this as
183+an axiom – but it's worth understanding.
184+
185+The path from concept to product is an annealing process. Your
186+code starts as a gas and ends as a metal. It must cool gradually
187+under precise control. When parts cool too fast, flaws appear.
188+Where flaws appear, the code must be reheated: ie, rewritten.
189+
190+Except for ASCII and a few algorithms, Nock, Hoon and Arvo didn't
191+really rely on anything from 20th-century CS. We didn't drop any
192+off-the-shelf parts into the oven; the whole stack is made from
193+gas. So the code in Urbit has been rewritten at least once; the
194+best code has been rewritten four or five times; perhaps some has
195+been rewritten ten, fifteen, even twenty times.
196+
197+In 2002, I started out with no idea what I was doing. Urbit was
198+interstellar vapor. I did have a decent grounding in 20th
199+century CS, academic and practical. In the '90s I was a grad
200+student in OS at Berkeley, then spent eight years on system
201+software projects (a language, an OS and a browser) in industry.
202+What I wanted, I did not know; what I knew, I did not want.
203+
204+In a long annealing process, it's important to triage the order
205+in which you solve problems. There are three kinds of problems:
206+problems you can't solve now, problems you don't have to solve
207+now, and hard problems. Unless you postpone anything that isn't
208+a hard but solvable problem, your gas will never turn into steel.
209+There are lots and lots and lots of ways to go nowhere fast.
210+
211+Somehow it's 2019. Urbit is hot iron under the hammer. It is
212+solid, but not yet hard. It has shape, but can yet be shaped.
213+It is done, but ought to be finished. It is a sword; you don't
214+want to get stabbed with it; it is not Excalibur, the blade to
215+end all blades.
216+
217+The bazaar is great. But cathedrals still exist for a reason.
218+The challenge for an ambitious system-software project is not
219+whether to choose the cathedral or bazaar model, but when and
220+how to transition from cathedral to bazaar.
221+
222+A cathedral – the same classic pyramid org-chart no doubt used
223+by the builders of the actual pyramids, or the actual cathedrals
224+– is economically less efficient than a bazaar. Why?
225+
226+Even on the world's most fun project, working for some dumb boss
227+is no fun. The bazaar succeeds because the project extracts free
228+labor from contributors – not by cheating them, but in exchange
229+for fun, status, experience, etc. But mainly fun, honestly.
230+
231+Whereas a cathedral costs a giant ton of money. But in exchange,
232+the cathedral gets _cohesion_ – the capacity for intelligent
233+coordinated action. Bazaars can coordinate, but not easily.
234+
235+Because a cathedral can coordinate, a cathedral can _create_ –
236+acting at a scale above individual action. A bazaar is very
237+useful, but a bazaar does not create. It can grow; it can heal,
238+harden, extend, and expand; but creation requires an individual
239+or a coordinated group.
240+
241+But a bazaar can get a lot more done, a lot faster and a lot
242+cheaper. So the right starting point for a bazaar is an existing
243+system which is very clear, very final, and very simple. So any
244+new system should be created by a cathedral and perfected by a
245+bazaar. Since these institutions share little or no structure,
246+the transition is by no means straightforward.
247+
248+### Tlon, just a little startup
249+
250+Tlon is Urbit's little corporate cathedral. It's about 20
251+people, about 15 of them engineers. Everyone is working on
252+Urbit, but not everyone is writing Hoon; there is client-side
253+work, Ethereum work, etc.
254+
255+The team is comfortably funded and more than competent. One Tlon
256+engineer is a 10-year, level 6 Google veteran; another is a YC
257+alum; these people are great, but not really outliers. And not
258+to be credentialist – there are plenty of dropouts, too.)
259+
260+Today, there's almost no part of the Urbit codebase that I still
261+know better than anyone else. There are even design areas that
262+others know better. When we transitioned from Nock 5 to Nock 4,
263+all I contributed was a suggestion. The same for our Ethereum
264+address collection, which our customers absolutely loved.
265+
266+Who's responsible for growing and maintaining this team? Who's
267+the stone at at the top of the pyramid? Not me: if you gave me a
268+goat to feed, the goat would die. The stone that holds the arch
269+together is Tlon's CEO and my cofounder, Galen Wolfe-Pauly.
270+
271+Tlon was founded in 2013; Galen led it through its long seed
272+stage, with only a few engineers, to 2018, when he finally
273+secured the resources to do the project justice. (Although way
274+too much of Tlon's energy in 2018 had to go into Ethereum.)
275+
276+Galen's previous project was the social meta-network Ost. He has
277+an architecture degree from Cooper Union; he is a great designer,
278+a good front-end engineer, and a pretty good surfer. (He also
279+runs the @urbit Twitter.)
280+
281+Galen sets Tlon's product vision and is responsible for both
282+visual appearance and human experience. Basically, Galen is the
283+Steve Jobs of Urbit, with only two differences: Galen's not an
284+asshole, and Steve wasn't short.
285+
286+Galen is joined in the new leadership team by Erik Newton
287+(operations, legal) and Anthony Arroyo (product, engineering).
288+Erik used to run a divorce-law firm and still is a relationship
289+coach. Anthony was a grad student in comparative literature and
290+managed engineering prototypes at Applied Minds.
291+
292+With my departure, Galen is in exclusive control of Tlon and
293+holds the only board seat. Tlon did take seed funding from VCs.
294+But outside investors have never held any management role.
295+
296+## Urbit, in the rear-view mirror
297+
298+Since I'm not going to talk about Urbit again, let me say a few
299+words that might otherwise go unsaid.
300+
301+### Urbit, a level and neutral platform
302+
303+Urbit's distribution and sponsorship hierarchy of galaxies,
304+stars and planets is _not_ designed as a political structure,
305+or even a social structure. The actual social layer is in
306+userspace -- one layer up.
307+
308+Socially and politically, Urbit is a flat network of planets.
309+Galaxies and stars are plumbing. No one cares which star is your
310+sponsor, any more than your Facebook friends care who your ISP
311+is, or you care what data center Facebook is in.
312+
313+The sponsorship hierarchy and the senate of galaxies (which can
314+amend Urbit's Ethereum constitution) are _technical_ governance
315+mechanisms. They exist to react to unanticipated technical
316+issues or conflicts (like denial-of-service attacks). Because
317+sponsorship has an escape mechanism, it is not a _feudal_ bond
318+(like your relationship to Facebook).
319+
320+Urbit is a decentralized network of social networks. No one can
321+regulate it. Urbit is made to blossom into an endless garden
322+of human cultures, each of which must regulate itself, none of
323+which can bother the others. The soil in which these flowers
324+grow must be level and neutral.
325+
326+### Urbit, anything but a fair distribution
327+
328+Who got those galaxies, anyway?
329+
330+Urbit has no mining mechanism and needs none. My model was: I
331+own the whole space, since I made it; on the other hand, it's
332+worthless until I find a way to give it away.
333+
334+In the end, I am probably the only individual with a fair amount
335+of Urbit address space (no galaxies, a few percent of all stars).
336+Tlon plus urbit.org also have about the right amount (slightly
337+less than half). The rest are held by third parties – all of
338+whom have either much more, or much less, than they deserve.
339+
340+But although the distribution of Urbit space was thoroughly
341+unfair, it was always _honest_ and never _corrupt_. Everyone
342+who has galaxies or stars did _something_ for Urbit. Some gave a
343+lot of money, some gave a little; some contributed a lot of code,
344+some just showed up. We paid a lawyer by bartering a pair. A
345+bunch went to contest winners who solved a trivial Nock problem
346+in 2010.
347+
348+What's unfair: the standards changed wildly across time. What's
349+honest: they were always the same across _people_. Granted, you
350+often had to be in the right place at the right time. This is
351+another problem with life that we can't fix.
352+
353+Every real system of property is unfair. Who deserves to own
354+Manhattan? Who does own it? If property be not unfair – if it
355+is not the result of respecting past accidents – it is not
356+property at all, but something else. I certainly would not do it
357+this haphazardly again, but the outcome is no tragedy.
358+
359+When you live in Manhattan, you simply don't worry about who
360+owns it or why; and nor does it matter. Are they Jews? Muslims?
361+Christians? Communists? Italians? You don't care and you don't
362+have to. You know it's basically random and probably unfair.
363+Randomness, even blatant unfairness, creates a kind of neutral,
364+peaceful, even promising urban anonymity.
365+
366+Property is always and everywhere a kind of amnesty. It says:
367+whatever happened in the past, this is now what is. When we all
368+agree that everyone has what they now have, however they got it,
369+we have a formula for peace. When we say that everyone should
370+have what they deserve, we can never expect everyone to agree –
371+which means we have planted permanent seeds of discord.
372+
373+And randomness is a virtue – it disrupts hidden patterns. The
374+galaxy owners include famous VCs and total nobodies; a Zen monk
375+and a former Orthodox nun; a blockchain industry leader and a
376+permaculture farmer. If they do have to all agree on something,
377+they should have little to agree on but the truth.
378+
379+## Urbit, a technical report card (January 2019)
380+
381+As a system-software stack, the fundamental thesis of Urbit is
382+that technical simplicity can flow all the way up to the top of
383+the stack, where it becomes human usability. If we can build a
384+purely functional OS, we can build a zero-maintenance server,
385+which is easy to understand because how it works is simple.
386+With this problem solved – nothing else matters.
387+
388+Unfortunately, I still have to give Urbit an "incomplete" here.
389+No grade is available, because usability depends on a lot of
390+fit-and-finish issues that are naturally back-loaded. I would
391+still much rather run an Urbit ship than a Mastodon instance.
392+But still, Urbit today can't quite promise zero maintenance.
393+
394+So we have to look at smaller indicators. One way to get anyone
395+to grade their own work is to ask them for three ways they've
396+succeeded, and three ways they've failed.
397+
398+### Urbit, three battles won
399+
400+I did once want to be a real computer scientist. Before my
401+expulsion for sordid & disturbing behavior, I was once a
402+19-year-old PhD student in CS at Berkeley. I even made an
403+embarrassing bet with Raph Levien as to which of us would win the
404+Turing Award – my money is definitely on Raph at this point.
405+You can even go and read my Usenix '93 paper on ASLR-secured
406+RPC, which won Best Student Paper and has like 50 citations.
407+
408+Well. That whole scene is a bad trip, kids. Avoid it. Also, if
409+you start out as Rimbaud, you might end up as Lebowski. On the
410+other hand, to have any excuse for boiling the ocean, you do have
411+to make some serious CS problems just go away. Here are three.
412+
413+#### Validation
414+
415+20th-century languages underrate the centrality of communication
416+to computing. Their type systems expect all data to live in a
417+single memory forever. They don't consider data serialization
418+and validation to be core competencies of a programming language.
419+
420+So serialization/validation is handled either ad hoc, or by
421+intermediate data description systems which have inherent
422+impedance mismatches with the language proper. Not only is work
423+done over and over – but most network security breaches exploit
424+seams in custom or complex deserialization and validation code.
425+
426+In Urbit there is one kind of data, a noun, which is an atom
427+(unsigned integer) or a cell (ordered pair of nouns). There is
428+one serialization model, which maps noun to atom to noun, in a
429+page of code. And a type defines a set of nouns by defining a
430+function of an arbitrary noun, whose range is that set – which
431+means any data type is also its own data validation function.
432+
433+#### Idempotence
434+
435+20th-century computers have two brains: one fast and temporary,
436+the other slow and permanent. When one of these two-brained
437+computers hears a packet, and sends an acknowledgment, that only
438+means the temporary brain heard it. Acks are not end-to-end
439+transactions.
440+
441+This means you can't write a command protocol where your commands
442+get executed exactly once. You can only choose "at least once"
443+or "at most once." This problem is as ridiculous and frustrating
444+as it sounds.
445+
446+You can address it in three ways: (a) make all your commands
447+formally idempotent, so that repeating them has no additional
448+effect; (b) insert a layer of stateful middleware — a message
449+queue; (c) be fine with "almost always once." Guess which
450+approach is most popular?
451+
452+Your Urbit ship has one permanent brain. Its acks are end-to-end
453+transactions — no packet is acknowledged until all its direct
454+effects are finalized. Every message channel is its own message
455+queue. And every message is executed once.
456+
457+#### Dependencies
458+
459+20th-century languages are all at least vaguely based on a
460+formalism from the '30s called the "lambda calculus." The
461+fundamental operation in lambda calculus is variable reduction
462+from name to value. So lambda languages all have a symbol table
463+or environment which binds names to values.
464+
465+Modern build systems assemble large programs out of small files
466+by reusing this symbol table for global function names, a process
467+called "linking." Unfortunately, linking causes a problem known
468+as "dependency hell," involving baffling, unpredictable upgrade
469+failures. The fundamental problem is the "diamond dependency" —
470+when a build requires two different versions of one symbol.
471+
472+Urbit does not use the lambda calculus, an environment or symbol
473+table, or linking. Because it pushes name resolution out of the
474+fundamental interpreter and up into the language, it can play
475+many more namespace juggling tricks. And its build system has no
476+trouble including multiple versions of the same library.
477+
478+### Urbit, three battles unwon
479+
480+As I mentioned earlier, triage is essential on any long journey.
481+You have to keep moving forward, even when you have no idea where
482+you're going – which means attacking the hardest problems you
483+can solve right now.
484+
485+Unfortunately, this is a different standard than the usual rule
486+for shipping a product: solve the most important problems first.
487+This principle of triage is a general case of Knuth's apothegm
488+against premature optimization. Urbit, in fact, was absurdly
489+slow for a long time, but after a couple of engineer-months of
490+focused optimization it seems fine now.
491+
492+But there are other areas where Urbit today is surprisingly weak.
493+All look careless, but all are the result of careful triage.
494+When you find a weakness due to triage, you may think you are
495+judging Urbit's quality. You are just judging its maturity –
496+which doesn't make your judgment wrong, of course.
497+
498+#### Opacity
499+
500+Urbit's notorious opacity is the problem that makes people
501+complain the most. It's not an unwarranted complaint.
502+
503+At least, it's not all an unwarranted complaint. Part of the
504+complaint is just about novelty. Novelty is of course inherent
505+in any clean-slate stack. I do regret making 0 true and 1 false.
506+On every other count, however, I offer all critics of Urbit's
507+novelty none but the most vulgar gesture.
508+
509+But novelty is not the only problem. Urbit's external
510+documentation has gotten much better in 2018 – in particular,
511+it's now much easier to learn the language. Its _internal_
512+documentation, and general code quality, remains at best poor to
513+average. Worse: the worst code is the oldest, deepest code,
514+which is also the most fundamental. Not only is it not
515+commented, it is full of cryptic, meaningless names.
516+
517+There is now a new style guide, which should enable all reference
518+documentation to migrate into the codebase. But this style guide
519+is so new that none of the codebase complies with it. The guide
520+demands "space-rated" code that documents every variable and
521+every line – and almost none of the codebase is space-rated.
522+
523+Urbit's internal opacity persists for two reasons, one good and
524+one bad. The bad reason is just laziness. The good reason is
525+justified fear of _premature explanation_, which like premature
526+optimization ruins the annealing process.
527+
528+When you don't know exactly what you're doing, preserve as much
529+ambiguity as possible. For example, a name that means something
530+is a commitment to one specific explanation; a name that means
531+nothing is no commitment at all. A cryptic name is productive
532+procrastination; it lets the hard problem of naming get solved
533+later, and hence better.
534+
535+#### Impermanence
536+
537+Your Urbit ship needs to be _permanent_. That means it doesn't
538+lose data, sink, or get wedged, or rot. It's not complicated.
539+I wish Urbit today could make this promise, but it can't.
540+
541+There are are two problems here: short-term permanence and
542+long-term permanence. Short-term permanence means your ship
543+can't fail or lose data except via OS or hardware failure.
544+Long-term permanence means you can put your ship on a USB stick
545+in a box for 50 years, or 100, or 500, and when you turn it on
546+in a modern interpreter it will upgrade itself and work fine.
547+
548+There aren't any significant structural obstacles to each of
549+these milestones. But we can't claim them yet. We haven't
550+really even worried about them. This is another triage case:
551+in this case, the issue is _premature reliability_.
552+
553+Permanence also includes security. Except for the on-chain PKI,
554+in which case you're trusting Ethereum, you shouldn't yet trust
555+Urbit's security at all. Sorry!
556+
557+#### Duplication
558+
559+Triage can procrastinate in the other direction. It can skip
560+problems that are too hard to solve. When you procrastinate,
561+always come back – in this case, when the problem is easier.
562+Here's one way Urbit has skipped a problem that was too hard.
563+
564+Urbit, as you may recall, is a single-level store. It has only
565+one brain. And yet, we resisted the natural unification of
566+_documents_ and _applications_ and _secrets_ that a one-brained
567+computer obviously suggests.
568+
569+Instead, Urbit today is built more the Unix way (if not the
570+Windows way). It has separate subsystems for tracking and
571+updating these three kinds of data. This was my design. Like
572+Urbit's opacity or impermanence, this was always obviously lame.
573+
574+Why do it the lame way? Because, before understanding the union
575+of these problems, we had to understand each problem by itself.
576+We didn't – not even close.
577+
578+No one else ever built a purely functional operating system. No
579+one is going to go straight from zero to the right thing. You
580+have to solve a hard problem, learn from it, and do it again.
581+
582+Now that the team has built and used the specialized subsystems,
583+it's probably time to go ahead and generalize. The problem now
584+strikes me as almost straightforward. The constraints are clear
585+and so are the tools. None of this was true a year ago.
586+
587+On the low end, triage keeps you moving forward by stopping you
588+from wasting time on easy problems. On the high end, triage
589+keeps you moving forward by keeping you from leaping too far
590+ahead, and falling down an impossible rathole.
591+
592+## Further reading
593+
594+What will I do personally? I'll spend more time with my kids.
595+I'll finish reading my 1911 Britannica – I am only on the B's.
596+I have no other long-term plans.
597+
598+But I won't be back to Urbit. I am leaving not just the project
599+but the field – no less than Satoshi, or Everett, or Rimbaud.
600+Will Satoshi weigh in on the next Bitcoin Cash fork? Did Rimbaud
601+fly back from Ethiopia for his book-release tour? (Did anyone
602+want him back?) It's not so bad to be a middle-aged Rimbaud.
603+
604+Is there more to say? Of course, but not in prose. Read
605+Bunting's _Chomei at Toyama_ and _Notes on a Fly-Leaf_; Cavafy's
606+_Il Gran Rifiuto_, Keeley & Sherrard translation; Canto XV of the
607+Inferno, Pinsky translation. You might learn something.
608+
609+## Apologies and acknowledgments
610+
611+I apologize to anyone who has too little Urbit space. I refuse
612+to guilt-trip anyone who has too much.
613+
614+I appreciate my friends by not naming them. I disarm my enemies
615+by inviting them to lunch – but only if they come unarmed.
616+
617+I thank everyone who has ever worked on Urbit and everyone who
618+will work on it in the future; our backers, great and small; my
619+cofounder, Galen, and his family; my parents, wife and kids.
content/blog/a-topiary.mdnew file+38
@@ -0,0 +1,38 @@
1++++
2+title = "A Topiary: Hypertext and Urbit"
3+date = "2021-06-13"
4+description = "A brief history of hypertext and Urbit networking"
5+
6+[extra]
7+author = "Reid Scoggin"
8+ship = "~sitful-hatred"
9+image = "https://media.urbit.org/site/posts/essays/treebranches.jpeg"
10++++
11+
12+
13+
14+> Under the trees of England I meditated on this lost and perhaps mythical labyrinth. I imagined it untouched and perfect on the secret summit of some mountain; I imagined it drowned under rice paddies or beneath the sea; I imagined it infinite, made not only of eight-sided pavilions and of twisting paths but also of rivers, provinces and kingdoms... I thought of a maze of mazes, of a sinuous, ever growing maze which would take in both past and future and would somehow involve the stars.
15+
16+-- _The Garden of Forking Paths_, Jorge Luis Borges
17+
18+The pre-technological world was already [networked](https://en.wikipedia.org/wiki/Indra%27s_net). No material object and no idea has ever stood alone—"no man is an island". Language itself is a network of associations shared between a group of people. The question of technology is: how do we bring our web of associations into the realm of computers? The legacy internet has focused on social networks almost exclusively—our mammalian brains readily took to this, we all love to [signal](https://conversationswithtyler.com/episodes/robin-hanson/). But before “social media” there was something called hypertext: a seemingly modest way to connect documents shared between computers.
19+
20+A footnote in a book used to require a library, locating the referenced book, and finding the cited page (which might have footnotes itself)! Hypertext allows one to traverse a network quickly and easily with just mouse clicks, making information accessible to those without the time and resources to hunt down physical artifacts. Urbit’s “%graph-store” is not the same as hypertext but it does bear some familial resemblances. Fundamentally, %graph-store is a data structure that can accommodate disparate data types within a single edifice. It is based on [graph databases](https://en.wikipedia.org/wiki/Graph_database) and recent implementations such as [GraphQL](https://graphql.org/). To understand this data structure it is worth diving into the origins of hypertext—the original linked network.
21+
22+The story of hypertext begins at the end of WWII with an article in _The Atlantic_ that proposed to extend the human mind via machine. Vannevar Bush had seen first-hand the explosion of electronics manufacturing and scientific knowledge, recognizing the great peril and opportunity of such a revolution. His [description](https://www.theatlantic.com/magazine/archive/1945/07/as-we-may-think/303881/) of the Memex presaged the technological world of today, envisioning a personal device that would allow the user to draw upon a vast library of information, and link documents together arbitrarily—what he called "associative indexing"—a deliberate recreation of how the mind connects thoughts.
23+
24+The 1960s saw the first implementations of these ideas. Ted Nelson's [writing](https://archive.org/details/SelectedPapers1977/page/n15/mode/2up) around _Project Xanadu_ elaborated this linking between documents into what Nelson called _hypertext_. Nelson imagined "a text arranged in a graph structure", centered around a corpus arranged in nonlinear sequence, manipulable by author or audience. The concept was first demonstrated in 1968, at Douglas Engelbart's 'Mother of all Demos', where a vision of computers as a collaborative social environment was revealed to the world. "[The Journal](https://www.dougengelbart.org/content/view/137/#7)", presented alongside other revolutionary demos, exhibited collaboratively edited documents with hyperlinked connections. Any time-travellers in the audience would have immediately recognized the first webpage. From here, the idea of a linked network of documents would be developed through successive phases of computing, from the mainframe to the PC.
25+
26+Experimentation with these ideas continued through the 1970s and 80s. A team directed by Andy Lippman at MIT extended the concept to threaded visual hypermedia with the _Aspen Movie Map_, a user-directed virtual tour of Aspen, Colorado. Hypertext and hypermedia gained a mass audience for the first time with HyperCard, a program that shipped with Mac computers. Users were able to collect or create '[stacks](https://archive.org/details/hypercardstacks)' of interlinked cards; a personal body of text, art, and knowledge could be accrued and modified, or shared with others—though not yet with native networking capabilities.
27+
28+With the World Wide Web, hypertext achieved escape velocity. Initially a one-man [project](http://info.cern.ch/hypertext/WWW/TheProject.html), the world wide web was similar to Bush’s vision of the Memex—a way to share, index, and connect information between individuals and groups. The web succeeded by utilizing the physical infrastructure already available: PCs with graphical interfaces, DNS, and the internet. Critically, its method of transmitting and traversing texts was a standardized protocol, allowing a free body of information to assemble atop the new infrastructure by anyone willing to learn the tools. A new frontier was cleared and cultivated with open standards, but it would gradually face enclosure.
29+
30+In the following decade, after the first wave of social networking sites had crested but before phones became the primary web clients, Twitter was launched. Originally an awkward bridge between SMS and the web, its design eventually coalesced around static identity, posts with chronological sorting, and interlinked post threads. These simple primitives spawned a vast corpus of information, a graph-of-graphs intertwined and overlapped, mapping an entire platonic world. Twitter is fundamentally constrained by its very nature: it is the walled garden of an advertising company. The financial incentives of the server operators demanded seizure of the commons and the replacement of standardized protocols with proprietary databases.
31+
32+As the first networked services withered, a new critique was implicitly articulated in the construction of a [new kind of abstract machine](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html). Urbit learned from the past: tightly defined protocols, baked-in cryptography, and decentralization were key. If power over the network was determined by those who ran the servers, then we would run the servers ourselves.
33+
34+Urbit is not fundamentally a hypertext system; it is a new kind of computer, designed to participate in a peer-to-peer network that rejects the client-server model. All Urbit software takes its networking model for granted, it is not an ad-hoc layering of mismatched abstractions. Fundamental design decisions determine the trajectory of the future.
35+
36+Early [implementations](https://en.wikipedia.org/wiki/Neo4j) of graph databases and projects like [RDF](https://en.wikipedia.org/wiki/Resource_Description_Framework) hit on the same core idea: linked data needs its own data structure. In 2020 Urbit OS adopted an application called %graph-store that made use of a new, native [data structure](https://docs.google.com/document/d/1-Gwfg442kV3cdfG7NnWPEf2TMa3uLUTAKkZD70ALZkE/edit) which would act as a database service for social applications. Chats, long-form text, and other types of data produced in the course of social computing now share the same tent, a single structure extensible to new types of content. Each item added to it is a node in a personal graph—a tree that grows branches as your computer communicates. These nodes can be linked arbitrarily to other graphs—Urbit's global immutable namespace grants both permanence and ownership and allows the graph’s branches to intertwine with others. Graphs can accommodate a variety of content, from simple text, to code and media yet to be conceived. You own your graph, and it is a record of your digital journey with others.
37+
38+Personal hypertext graphs are leaving behind proprietary platforms and gaining independence. Graphs until now have been used as tools of surveillance and marketing, but they are being reclaimed and sewn back into the network, each bound to the cryptographic identity of an individual, permanent computer. Where the map of your life was once splintered across a thousand systems and held in the custody of strangers, it is now possessed only by you and shared only as you see fit. On Urbit, an infinite forest of digital lives can take root, nesting their boughs and stalks.
content/blog/aesthetic-culture-1.mdnew file+103
@@ -0,0 +1,103 @@
1++++
2+title = "Aesthetic Culture #1"
3+description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."
4+date = "2020-11-11"
5+
6+[extra]
7+description = "One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art)."
8+author = "~nartes-fasrum"
9+ship = "~nartes-fasrum"
10+image = "https://media.urbit.org/site/posts/essays/help-the-environment.jpg"
11++++
12+
13+
14+
15+_This post is the first in a series of digests centered on art produced within and about Urbit by a member of the community, ~nartes-fasrum. Monthly digests will be available within the Urbit Community group in Landscape, and will occasionally be compiled here on the blog to give you a sneak peek at some of what’s happening on the network. Enjoy! ~wolref-podlex_
16+
17+One of the most exciting things about Urbit is the aesthetic and design around it, developed partly by Tlon (through the design of Urbit itself) and partly by the community (by producing great Urbit art). As the community grows, it creates more art, and we have the opportunity to showcase some of the pieces we love. These works can draw curious new users in, and they give existing users ways to communicate their excitement to friends.
18+
19+To that end, I wrote [the Art by Urbit proposal](https://grants.urbit.org/proposals/636838408-art-by-urbit), a regular digest for the dissemination of Urbit art and propaganda. We'll bring you the works of both familiar faces and new users, in a variety of media types from image manipulation to 3D models and physical pieces. This first digest will cover some of the art produced in the past year, but will have a focus on the last two months. Future digests will be incremental updates summarizing the artworks of the prior month.
20+
21+## ~datnut-pollen
22+
23+~datnut- made a physical representation of their sigil from maple wood & epoxy resin, and mentioned the potential to use an Arduino to cause different lighting effects for different statuses of an urbit.
24+
25+
26+
27+## ~lagrev-nocfep
28+
29+~lagrev- [made a thread of Dinosaur Comics](https://twitter.com/sigilante/status/1299101593997127680), using the Urbit Whitepaper as the seed text.
30+
31+
32+
33+A sweet poem about the potential for Martian felines is theirs as well:
34+
35+
36+
37+## ~litmus-ritten
38+
39+~litmus- produces art full of glowing gases and colourful curves:
40+
41+
42+
43+~litmus- also drew Urbitan for the release of OS1:
44+
45+
46+
47+More of their work is available in the notebooks of the Internet Weirdness Research Unit.
48+
49+## ~minder-folden
50+
51+~minder- stylistically ranges from retrofuturistic memes to flat-out classic 50s retro:
52+
53+
54+
55+
56+
57+More of ~minder-’s work is available in his The New Era notebook.
58+
59+## ~naltyc-wornes
60+
61+~naltyc-, & by extension ~dasfeb industries, produces content related to the exploration of Urbit on small & unique computers:
62+
63+
64+
65+
66+
67+More of their work is available in the smol computers group.
68+
69+## ~nartes-fasrum
70+
71+I use GIMP to edit images I pull off various social media platforms, and usually post the results on Twitter at [@nartesfasrum](https://twitter.com/nartesfasrum).
72+
73+
74+
75+## ~norsyr-torryn
76+
77+No discussion of Urbit art would be complete without mentioning [~norsyr-'s Canvas app](https://github.com/yosoyubik/canvas), which won first place in the [Hackathon 2020](https://urbit.org/blog/hackathon-results/) event.
78+
79+
80+
81+## ~radbur-sivmus
82+
83+~radbur- writes poetry on a range of subjects, one of which could be Urbit. Interpretation of ["A Weaver's Regard"](https://t.fust.us/writing/poetry/weavers-regard) and ["Internet Absurdities"](https://t.fust.us/writing/poetry/internet-absurdities) is left as an exercise to the reader.
84+
85+## ~sitful-hatred
86+
87+~sitful- has a Martian Meme Depository chat in the Networked Subject group, which catalogs a number of the Urbit memes that have been created so far.
88+
89+
90+
91+## ~tocrex-holpen
92+
93+~tocrex- has been drawing the galaxies of Urbit, and uploading results to Twitter at [@tocrexholpen](https://twitter.com/tocrexholpen). Each galaxy has a unique design and outfit, with the galactic sigil proudly displayed as its face.
94+
95+
96+
97+## Landscape
98+
99+Something that's become quickly evident with the addition of background images to Landscape is that people love to customize their ship's appearance and make it feel more like home. To close things out, we're providing a pair of backgrounds — one darker, one lighter — for use on your ship (or your desktop, should you so desire).
100+
101+
102+
103+
content/blog/after-machine-war.mdnew file+40
@@ -0,0 +1,40 @@
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-14"
5+
6+[extra]
7+author = "Simon Kovacs"
8+ship = "~bacbec-lormur"
9+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/berlin-wall.jpeg"
10++++
11+
12+
13+
14+> 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.
15+>
16+> Really the only notable thing about it is that it was written on Urbit. And that, perhaps, has made all the difference.
17+>
18+> 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.
19+>
20+> 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.
21+>
22+> 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.
23+
24+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.
25+
26+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?
27+
28+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.
29+
30+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.
31+
32+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.
33+
34+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.
35+
36+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.
37+
38+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.
39+
40+2050 turned out to be a pretty good year after all.
content/blog/agency-daos.mdnew file+110
@@ -0,0 +1,110 @@
1++++
2+title = "The Dream of the Agency DAO"
3+date = "2022-11-04"
4+description = "As creative studios and agencies struggle for more creative freedom, DAOs and tokenization will surely take a more central role in the marketing and branding industries. Decentralization offers such entities benefits that could fundamentally reshape creatives’ relationships with clients—reducing layers of inefficiency and anti-creative incentives."
5+
6+[extra]
7+author = "Isaac Simpson"
8+ship = "~mogmet-tadnem"
9+image = "https://storage.googleapis.com/media.urbit.org/blog/skybanner.jpg"
10++++
11+
12+
13+
14+
15+Chris Callahan runs an independent brand strategy agency called [Visitor](https://visitor.agency/). Visitor wrote the line that [emblazoned](https://astra-mag.com/articles/my-weekend-with-the-martians/) the sky over the parking lot that housed Urbit Assembly. Its work focuses on Web3 blue chips and up-and-comers: dev marketing, notoriously one of the toughest niches in the branding world.
16+
17+“Devs are very sensitive to puffery and cringe,” says Callahan. “Traditional tactics like headlines and manifestos fall flat. Clarity and vision are much more important because they showcase the benefit as well as a long term potential for use.”
18+
19+Why? Because developers eschew sales. If something is good, it will rise to the top without the help of annoying salespeople. The thing is, marketing-world creatives usually agree—we’re just bogged down by salespeople of our own. So we, like devs, yearn for the day when decentralization will save us from the social climbers and “connectors” that suck up all the oxygen.
20+
21+Enter the Agency DAO. The idea—a creative agency that solicits work, receives clients, hires creatives, and makes decisions all on the blockchain—is oft-discussed because it appeals to the crunchy, anti-establishment vibe at the core of every major ad agency. A trustless, leaderless creative community where everyone has equal voice and the best creative rises naturally to the top? The dream of the ‘90s come true!
22+
23+Unfortunately, decentralization in the ad world currently occupies much more podcast time than reality.
24+
25+## Creative by Committee
26+
27+But there are some actual attempts at making the Agency DAO a reality. Koto, a top creative agency known for creating the AirBNB brand, tried it with Web3 brand Polkadot. [It pit two pitches against each other to determine the future direction of the Polkadot brand by vote](https://vote.polkadot.network/). It used a quadratic voting via Snapshot to deliver the will of the Polkadot network to four “multisig curators” who executed the vote on chain.
28+
29+While the experiment worked, it also revealed the shortcomings of the blockchain’s ability to guide creative decisionmaking.
30+
31+“To organize Polkadot token holders who wanted to participate and create the voting parameters took very long,” says Callahan. “To have the wisdom of crowds decide on two design elements was an exemplary concept for Polkadot to own. The question is, did it push the work? Or was its value in consensus alone?”
32+
33+Quadratic voting is cool, but the creative process is long and complicated. Stakeholders chose between option A and option B. At the end of the day, that doesn’t feel like a significant innovation, especially if the vote isn’t even actually happening on chain. Rebranding sprints typically take around 3 months. This process took 11. Sure, it was a good way for Koto to play ball, but it wasn’t much more than that.
34+
35+Agency DAOs face the same central problem as ordinary DAOs, which can be summed up thusly: every decentralizing force is too costly, and every cost compromise moves the system back towards traditional hierarchies. The nature of creative work even further stymies the theoretical Agency DAO. Creative products almost always suffer when anti-hierarchical principles are put in place. As David Ogivly famously said,
36+
37+_“Some agencies pander to the craze for doing everything in committee. They boast about ‘team-work’ and decry the role of the individual. But no team can write an advertisement, and I doubt whether there is a single agency of any consequence which is not the lengthened shadow of one man.”_
38+
39+So this leaves us with the question of how exactly the DAO model can help creative agencies, and what such an organization might look like, and how Urbit can help. There are roughly three paths: 1) Project Bountification 2) Talent Retention 3) Idea Valuation.
40+
41+## Project Bountification
42+
43+In the Mad Men era, a few Agencies of Record (AORs) dominated the advertising world. These massive whales took every cent of a given big brand’s yearly advertising budget and charged a simple 15% premium on all media (e.g. radio time, TV time) purchased. A very simple and very profitable system, [now long gone](https://www.genedelibero.com/the-agency-of-record-the-shift-is-on-to-specialized-agencies/).
44+
45+Today, big brands typically have many agencies—sometimes hundreds—each with a different specialty, and each fighting for their own share of the budget. I’ve been in rooms with representatives from no less than 10 agencies—digital, DEI, experiential, CSR, influencer, etc—all pitching ideas for the same holiday campaign, and all surely billing upwards of $100/hour per person to do so.
46+
47+This sounds nice for agencies, but actually it isn’t—instead of focusing on the creative work, they must dedicate their energy towards constantly re-pitching themselves to the client and fighting with procurement people on rates. The managerial class types who control the budgets care a lot less about the quality of the creative than whether you remembered their dog’s birthday.
48+
49+Crypto could provide a solution to modern agencies’ woes by creating a flatter system for project acquisition; adopting the sort of decentralized bounty system some devs already use for Web3 projects.
50+
51+“Bounties are great,” says Callahan. “Big agency players should popularize them. I feel like if there's a way to do an on-chain bounty with select members who either hold a special token that allows participation on key briefs, that would help a lot.”
52+
53+How would such a system work? First, a brand issues a bounty for a project for work it needs done. Luckily, this basically already happens in advertising, it’s called a request for proposal, or RFP. The only difference here is instead of RFP acquisition and response being 90% schmooze-fest and 10% creativity/pitching prowess, it’s a lot more like what you’ve seen on Mad Men: the client’s RFP passes trustlessly to the bold creatives who spend many drunk, sleepless nights coming up with genius ways to knock their socks off.
54+
55+“A brand issues a bounty for a stunt activation that, for example, educates the world on the psychological benefits of calm computing,” Callahan explains. “The members of Agency DAO approve it, and create their own bounty for creatives inside the DAO. Bounties burn after 10 days. Ideas submitted and sent to client in the manner set by DAO.”
56+
57+Once the job is awarded, the chosen agency will continue this pattern, effectively removing the “account guy” layer—the sales-y middle people abhorred by both creatives and devs alike—and returning more focus to creativity.
58+
59+## Talent Retention
60+
61+“Professional creative” industries, e.g. marketing, branding, etc, suffer from turnover rates orders of magnitude higher than the industries they serve. Being a creative is both kind of awesome, because a new gig is never too far away, and also scary, your current gig reliant on the slightest whims of the client.
62+
63+This means that the market for creative talent in the form of copywriters, designers, art directors, animators, producers, editors, etc, is always choppy and competitive. Staffing sucks—it’s difficult to evaluate the quality of someone’s work until you’re actually working with them, because creatives stuff their portfolios with successful projects they’ve barely touched. Beyond that, now bloated Web2 lowballers like Fiverr and Upwork bottom out the market with garbage time labor that even the biggest brands still somehow fall for. Another great opportunity for Web3 disruption.
64+
65+The Agency DAO model provides permanence. Currently, some independent agencies offer equity packages that take a long time to vest, and are only ever worth anything if the agency sells. Owning fungible tokens from day one is a much better way to incentivize both work quality and retention.
66+
67+DAOs also offer flatter and more collaborative atmospheres, which creatives at least ostensibly want.
68+
69+“There’s total transparency of who works on what. Better collaboration between members, meaning happier, more fulfilled workers. Awards will be more meaningful and accurate,” says Callahan. “Plus, the value of your tokens naturally increases or decreases based on your performance. Just by getting hired at a successful DAO you can already be doing well.”
70+
71+Finally, a system that allows democratized voting on creative products, as opposed to traditional [Hype Dad aristocracies](https://thecarousel.substack.com/p/vibe-shift-to-destroy-marketing-world), could actually foster more Darwinistic environments where the best creative has a higher chance of rising to the top.
72+
73+“Eventually group preference will select one creative over others; causing repeat elections of the same member,” says Callahan. This could occur on both the agency level—removing the Hype Dad problem, e.g. lazy incumbents making lame decisions. “There's a sort of Darwinism that is created that can determine benefits or even redundancies for those not pulling their weight or who simply aren't as talented as others.”
74+
75+## Idea Valuation
76+
77+The creative industries are perhaps the only example of a field in which the artists retain no intellectual property right for their ideas. This is why advertising creatives make so much money—an advertiser can milk a good idea for decades and we’ll never see a dime.
78+
79+The tokenization inherent to the DAO model opens up several possibilities for valuing ideas in new ways that behave more like copyright.
80+
81+“The basic thought now is starting something I’m calling General Idea; pre-created, white label ideas based on research of real creative problems that need fixing,” says Callahan. “We NFT the ideas, sell them to clients. They make them or they resell that idea to other clients or agencies. That monetary markup value on the idea trickles down the original creator. More democratic way to share ideas and defend their ownership when they’ve been recorded on the blockchain.”
82+
83+This sort of blockchain-based soft copyright is one way to value an agency’s DAOs. Another, simpler way, is to sell NFTs or NFT-related independent creations of the agency itself. Art collective/creative agency [MSCHF](https://mschf.xyz/), for example, makes its money both via brand deals and also a la carte meme-to-merch drops. Agencies with a certain amount of clout could easily tokenize the clever side projects of its creatives—making it far less reliant on client deals and more able to capitalize on its creative prowess.
84+
85+“Pool Suite [another creative studio] does a great job of being a creative company that happens to make NFTs of music and general drops and stuff,” says Callahan. “They're a studio first and then a blockchain player after. I'd still consider them a ‘diet-DAO.’”
86+
87+[Édouard Urcades](https://fabled-faster.tlon.network/writing/stars) has designed interfaces for Tumblr and IBM, and currently serves as a design lead at Tlon. His project Structure is a “cork board” for creative projects on Urbit—sort of a “mercenary guild,” for UX/UI designers looking for work. Structure is run by a gnosis safe wallet operated by its 12 members. Beyond serving as a “soft on-ramp for Urbit-related design labor,” Ed plans to monetize Structure by selling Urbit merch designed in-house, both NFT and IRL.
88+
89+## How Urbit Can Help
90+
91+The three categories discussed above—project bountification, talent retention, idea valuation—present theoretical frameworks for the Agency DAO. However, the shortcomings of current DAO infrastructure and governance make them largely impossible. Enter Urbit.
92+
93+The creative industries rely almost entirely on reputation—so any Agency DAO without permanent pseudonymous ID is dead in the water.
94+
95+“Goodby Silverstein and Partners, for example, is widely regarded as one of the best ad agencies out there,” says Callahan. “When a big name in the creative industry goes to work there, the reputation of Goodby Silverstein increases.”
96+
97+Urbit IDs let you maintain your creative and working reputations while operating within a self-owned ecosystem that can’t be deleted. Beyond that, Urbit’s design-forward OS selects for self-expression in a way that no corporate-owned platform could.
98+
99+
100+“The sigil itself is its own design feature,” says Callahan.
101+
102+Simply put, running an Agency DAO on Discord and Google Docs would be fundamentally unserious. It’s one thing for a traditional agency to use Web2 products as _tools_ for its creatives. It’s quite another for Web2 products to be the only connection the agency has with its creatives outside of the blockchain.
103+
104+Recruitment, ideation, project sharing, and even simple chat aren’t possible on Web3 without something like Urbit to tie it all together. Sure, you could get a bunch of anonymous creatives together on a shared Figma, but there will be zero accountability and likely low participation. Whereas Urbit—particularly Holium’s forthcoming Realm—brings Urbit ID into a decentralized, permanent environment that connects members P2P, and allows on-chain transactions without leaving Urbit. All while maintaining permanent IDs.
105+
106+As creative studios and agencies struggle for more creative freedom, DAOs and tokenization will surely take a more central role in the marketing and branding industries. Decentralization offers such entities benefits that could fundamentally reshape creatives’ relationships with clients—reducing layers of inefficiency and anti-creative incentives. However, a decentralized ID layer like Urbit is needed before the Agency DAO can be practically attempted.
107+
108+–
109+
110+*Isaac Simpson is a Los Angeles based writer and the founder of the marketing agency [WILL](https://willtheagency.com/). You can read his work on his substack [The Carousel](https://thecarousel.substack.com/).*
content/blog/an-email.mdnew file+84
@@ -0,0 +1,84 @@
1++++
2+title = "An Email from the Archive"
3+description = "I found this email in my archives recently and thought it might be fun to share publicly."
4+date = "2020-11-29"
5+
6+[extra]
7+author = "Galen Wolfe-Pauly"
8+ship = "~ravmel-ropdyl"
9+image = "https://media.urbit.org/site/posts/essays/moon.jpg"
10++++
11+
12+
13+
14+I found this email in my archives recently and thought it might be fun to share publicly.
15+
16+```
17+From: Galen Wolfe-Pauly <galen@tlon.io>
18+Date: Thu, Jul 2, 2020 at 9:50 AM
19+Subject: Continuing
20+To: XXXXXXXXXXXXX
21+```
22+
23+Here are a few things I was thinking about after we chatted. It may be that I'm just reiterating things I already said — but perhaps it's useful:
24+
25+1 -
26+
27+Our collective desire to depend on digital communication tools vastly exceeds what I would have ever guessed. Even if you somehow factor out what’s addictive about the platforms we use today: they serve a real need. The crux of the problem with our current platforms is that they don’t actually serve the need that we want them to serve. They’re not tools in the way we expect tools to be. For the most part, the platforms we depend on serve the needs of their shareholders or some graph or another that needs to go ‘up’, which makes them compromised in a very deep way.
28+
29+In the pre-digital world we enjoyed a few things about the way we communicated, collaborated and did business that are dwindling: simplicity, durability and ownership. I’ll try to give some straightforward examples of what I mean:
30+
31+A - When I talk to someone directly, I’m not worried that someone else is listening in. If they go tell someone else what I said to them, that’s something for us to work out between us — they’re not _always_ reporting our conversations back to a third party. The constraints of the interaction and the privacy implications are _simple_ — I don’t think about them at all. Good privacy guarantees flow from a strict focus on simplicity. When two people want to talk to each other: give them a secure channel to talk. Putting a centrally-controlled service between them is just an interim solution because no one could figure out a better way to do it.
32+
33+B - When I write something down on paper, or type into a typewriter, I have an intuitive sense of the durability of what I’ve made. I have notes on my shelf I took ten years ago. I don’t worry about them disappearing. This means I can have a very direct, high-resolution relationship with the medium. I can pour myself into my physically-written notes in a way I would never pour myself into a Google Doc. Our digital tools are deeply untrustworthy because we know they can disappear, that they won’t actually last forever.
34+
35+C - Around 2008 I started limiting myself to a few specific drawing and writing tools. I use them all the time and can actually refine my relationship to them since I know they’re not going to change out from under me. Perhaps at some point these pens wont be made anymore, but the ones I have are actually _mine_. Similarly, the things I make with them actually belong to me in a way that doesn’t require some ridiculous terms of service. A sense of ownership, when it comes to the medium of communication, determines our level of trust and commitment.
36+
37+Our digital tools have to achieve the same level of simplicity, durability and ownership that our pre-digital tools did. Until they do, we’re always going to be in conflict with them, full stop.
38+
39+The main thing is that exactly none of our present platform-centric world can survive when you see things this way. The digital world we live in is composed of an insanely complicated, ephemeral set of tools that distinctly _do not_ belong to the people that use them.
40+
41+We’re going to be in a constant struggle with technology until it conforms to these three very basic expectations. These are the expectations we try to get Urbit to fall in-line with, of course. Something else could also succeed by satisfying them. But I also don’t really see anything else, aside from Bitcoin and maybe Ethereum, falling in line with these core principles.
42+
43+So: while I wish that Urbit was more mature and ready to capture those that are being purged from mainstream social media, are bored with it or are frustrated with the constraints of ‘productivity software’ — I think this conflict is going to drag on until people realize that what we’re in conflict with is the structure of the software we use. Using software that’s managed by other people is always going to cause serious problems all the way up at the user level. For more speculation on how this might play out, watch Black Mirror.
44+
45+2 -
46+
47+(1) is, in a way, a long-winded way of saying that the state of the world hasn’t changed our direction all that much. In order for Urbit to be approachable to use, it has to be very nicely made and that takes time and iteration. As the system stabilizes, Urbit can evolve in a more traditional way: we, along with others in the ecosystem, release stuff, observe how people use it, and try to make it better. We’re at the point where we’re nearly ready to get into that feedback loop, and we very much need to get there. We’re close.
48+
49+Urbit is a distinctly different _kind_ of software than anything we have now. Your Urbit is something you actually own and can do whatever you want with: not unlike your furniture or your kitchen tools. An Urbit is a tool for individual, human-scale computing and our whole approach to designing and making things is completely different. Most computing is about industrial-scale computing: where the software system stores everyone’s data and is managed by the people who build it.
50+
51+Urbit is the opposite of industrial-scale. Urbit is much more like something that’s carefully crafted and delivered to you directly. This craftsman-like approach to building software really isn’t a part of most modern software engineering.
52+
53+When I think about this from the standpoint of the person using what we make, it’s especially important. Urbit should feel like something that’s purposefully made by hand — not something you picked off the shelf at Wal-Mart. Some of this ethos was present in the early PC movement, but it’s mostly lost today. The care and attention that goes into building the system is also exactly what we make money on. People pay us to own a piece of it, to use it. We’re incentivized to make nice things, in the Urbit model, and we take that responsibility seriously.
54+
55+3 -
56+
57+Networks are a really important social form that’s only just beginning to come into existence. A network is neither a state nor a company, but something in-between. Bitcoin is a network, Ethereum is network (but it’s still far too centralized). Urbit is a young network.
58+
59+(In my view, a real network is always decentralized. Centralized networks are basically just companies.)
60+
61+Urbit is controlled by the collective of people who use it — in varying degrees, of course. The main thing is that this collective is bound together only by private keys and a blockchain, not a set of legal documents. The agreements between everyone on the network are in some cases more formalized (in terms of ownership) and looser (in terms of content moderation) than what we’re used to in either a state controlled or company controlled model. This is a very unusual kind of institution.
62+
63+On a successful Urbit network, Facebook, Airtable, and Signal are just successful applications. You could probably build companies around them that ship software to Urbit — but they’re more like 5 - 10 people instead of thousands.
64+
65+Urbit doesn’t aim to eat away at the government per se. Instead, it’s an important communication tool for institutions of any scale to actually take control of their means of collaboration. The efficiency of inter-government communication and government to populace communication can clearly be improved by _a whole lot_.
66+
67+4 -
68+
69+The most important thing is that people can generate a vision of the future. This can only emerge from a small collective of motivated people. Our public life is overwhelmed by people shooting from the hip, aiming for likes.
70+
71+There are difficult, infrastructural problems _all over the place_ that desperately need the considerate attention of small groups of people. Urbit, as communication tooling, is aimed at improving the quality of the fabric that binds these groups together. Or, to put it another way, before you can solve any specific problem you have to improve the problem solving process overall. Everything is gated on solving the process.
72+
73+5 -
74+
75+Christopher Alexander is, indeed, probably the biggest influence on my thinking when it comes to paying close attention to making things that both generate a deep sense of connection and are shaped by the people who inhabit them.
76+
77+[http://en.bp.ntu.edu.tw/wp-content/uploads/2011/12/06-Alexander-A-city-is-not-a-tree.pdf](http://en.bp.ntu.edu.tw/wp-content/uploads/2011/12/06-Alexander-A-city-is-not-a-tree.pdf) is one of his early, well known essays that’s easy to find online. I think ‘The Nature of Order’ is the thing that had the biggest impact on me, but it’s harder to find. There’s probably a PDF floating around on the internet somewhere. It's also a beautiful (four volume) book. The first volume kind of nails it. This talk is also great: [https://twitter.com/urbit/status/1148030042846326784](https://twitter.com/urbit/status/1148030042846326784)
78+
79+The thing that comes to mind lately is Hejduk. He had passed away by the time I was at Cooper, but I feel like I was educated in the ghost of his work. This documentary gives a good impression of his thinking: [https://www.amazon.com/John-Hejduk-Builder-Worlds/dp/B07NKQ72C8](https://www.amazon.com/John-Hejduk-Builder-Worlds/dp/B07NKQ72C8)
80+
81+Hejduk was able to see that architecture isn’t about building buildings per se, but something else. That was always quite obvious to me.
82+
83+Talk soon!
84+G
content/blog/an-urbit-overview.mdnew file+215
@@ -0,0 +1,215 @@
1++++
2+title = "An Urbit Overview"
3+date = "2016-05-10"
4+description = "A high-level overview of Urbit."
5+aliases = [
6+ "/posts/essays/an-urbit-overview",
7+ "/posts/an-urbit-overview"
8+]
9+
10+[extra]
11+author = "Galen Wolfe-Pauly"
12+ship = "~ravmel-ropdyl"
13+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/an-urbit-overview.jpg"
14++++
15+
16+
17+
18+## What Urbit is
19+
20+Urbit is a virtual city of general-purpose personal servers.
21+
22+## Your old personal server
23+
24+What's a personal server? In a sense, you already have one. Your
25+personal server is the combination of all the cloud services you use
26+now.
27+
28+This "server" is a mess. It's broken into 17 different fragments
29+which are scattered all over the planet. You have no control at all
30+over any of the pieces. The more we depend on Web services, the more
31+we realize how unsustainable this situation is.
32+
33+Can you remember all the services you have accounts for? How about
34+the username and password for each? Some of them will let you pull
35+your data out somehow, some won't. Sometimes you can move your data
36+between them, sometimes you can't. But they're all good at
37+showing you ads.
38+
39+## Your new personal server
40+
41+Your urbit is your own general-purpose server. It holds your
42+data; runs your apps; wrangles your connected devices; and
43+defines your secure identity. If you still need your old
44+services, it drives them with APIs.
45+
46+Your urbit presents your whole digital life as a single web
47+service. And since it's yours, open source and patent-free, it
48+never shows you ads. Or loses your data. Or updates without
49+your consent.
50+
51+Technically, Urbit is a new kind of OS that has a precise formal
52+definition. (Urbit is actually a [single mathematical function](https://media.urbit.org/whitepaper.pdf).) One advantage of a math-based OS is that Urbit is perfectly
53+portable. It can't tell whether it's in a cloud data center or on
54+your home PC.
55+
56+Concerned about mass surveillance? Download your urbit and restart it
57+on your laptop, or move to a new host in Iceland. Urbit's formal
58+simplicity makes managing it as easy as managing an iPhone: all you
59+have to decide is what apps to add.
60+
61+Each urbit is a node on a global, encrypted P2P network. Your Urbit
62+name, a generated pseudonym like `~talsur-todres`, is also your
63+network address. Like Bitcoin, Urbit address space is a cryptographic
64+asset with a limited supply.
65+
66+By keeping addresses scarce, we make spam and abuse expensive. Urbit
67+is a "friendly network," like the Internet in 1986, where a stranger
68+is nice until proven nasty. As it matures, Urbit will grow into a
69+decentralized, self-governing virtual city both safe and free.
70+
71+## The Urbit future
72+
73+In an Urbit world, your data is no longer trapped in a jumble of
74+proprietary servers. Your urbit is a permanent, versioned, typed
75+archive the size of your digital life. Even before you move your data
76+from a Web service to a local Urbit app, your urbit can drive your
77+account with an API or scraper.
78+
79+And within Urbit, data is never locked inside apps. Imagine if you
80+could painlessly switch between Facebook and Google+, Asana and
81+Trello, Tumblr and WordPress. Not only does your urbit upgrade itself
82+and its apps automatically, you can "sidegrade" a running app to
83+another vendor without losing data.
84+
85+Your urbit is also your digital identity. Along with your data
86+lifestream of media, messages and documents, it has the keys and
87+tokens to manage all your legacy Web services. It holds the keys
88+for your cryptocurrency wallets, so it can buy and sell for you.
89+(With one personal server to secure, not 17 different accounts,
90+you actually have the bandwidth to take security seriously.)
91+
92+You still use network services. But instead of interacting with
93+the service provider's HTML UI, which phones home using
94+proprietary HTTP APIs, you interact with a third-party app on
95+your urbit, which talks to multiple service providers using
96+public, typed Urbit protocols. For example, your urbit runs a
97+single shopping app, which downloads catalogs and uploads orders.
98+This app is one store which sells everything in the world, with a
99+salesman who's 100% on your side and always has the best price.
100+Every computing experience is different when the UI is working
101+exclusively for the user.
102+
103+Finally, your urbit is the hub for your network of connected
104+devices. Your smart thermostat, your wristband, your phone and
105+tablet, all run satellite urbits which talk securely to your main
106+urbit in the cloud.
107+
108+## A chance for digital freedom
109+
110+The promise of the personal server isn't just convenience.
111+General-purpose computing is magic. This magic must be in the
112+hands of all, not just those who can master Unix. The computer
113+is a bicycle for the mind. It's an open vehicle for exploration
114+and discovery. It's not a way to optimize ad delivery.
115+
116+Urbit, as virtual city, is a platform that brings together all our
117+datastreams -- from emails to heartbeats -- in a way that we ourselves
118+control. Can we work together to match faces in photos, without
119+submitting to some panopticon in Mountain View? While the first step
120+in freedom is the right to be left alone, the second is the power to
121+form new intentional communities, to create and evolve a voluntary
122+definition of public space. We have no idea at all what people will
123+do with this power.
124+
125+General-purpose computing is digital freedom. And today, a cloud data
126+center is the technically optimal locus of computation. The cloud is
127+always on, always available, never loses data. Hosts are sometimes
128+attacked; but they never intentionally tamper with their virtual
129+computers. The cloud can never be secure against a global adversary;
130+but most people don't have a global adversary. A single portable
131+platform provides "herd immunity" for the few who do need direct
132+physical control over their main computers.
133+
134+Though even laptops are atrophying into mere browsers, mass-market,
135+general-purpose computing on the client side remains an endangered
136+species that must be protected. But on the server side, this species
137+has never even _existed_. There has never been anything like a
138+mass-market personal server. Why not?
139+
140+## Freedom is an engineering problem
141+
142+Urbit is not a difficult idea. Urbit is like a flying car: the idea
143+is not the hard part. Almost everyone we talk to about Urbit turns
144+out to have had pretty much the same idea themselves. The problem is
145+building it.
146+
147+A server is a computer. It's running some operating system. This OS
148+is a flavor of Unix. There are no alternatives. It's connected to
149+some network. This network is the Internet. It has no competitors.
150+You can have a personal server, if it's a Unix server on the Internet.
151+
152+Almost no one thinks being a Unix system administrator is fun. Not
153+even Unix system administrators think running an Internet server is
154+fun. So the personal Unix/Internet server is like the personal
155+bulldozer. This is not a consumer product. Any number of engineers
156+can't turn a bulldozer into a bicycle.
157+
158+How did we build the personal bulldozer? We didn't. We started
159+from scratch. (The people who built the first PCs didn't start
160+with a mainframe OS, either.) We created a new platform: Urbit.
161+
162+Urbit doesn't compete with Unix and the Internet. It's a new,
163+opaque layer on top of them. Your browser runs on a native OS,
164+but it doesn't give Web apps any way to talk to the native OS.
165+Urbit is like a browser for the server side: code within Urbit is
166+formally isolated from the platform it runs on top of.
167+
168+Your urbit is a Unix process, in a data center or your PC. It sends
169+UDP packets over the Internet. It can both load and serve web pages
170+over HTTP. Except for character sets and crypto, nothing in Urbit
171+reuses or depends on any 20th-century code.
172+
173+Urbit is a complete, clean-slate system software stack: a
174+non-lambda interpreter (Nock), a functional language (Hoon), and
175+an event-driven OS (Arvo), with its own encrypted protocol
176+(Ames), typed revision control (Clay), reactive web server (Eyre)
177+and functional build system (Ford). The full system, including
178+basic apps, is only 30,000 lines of Hoon.
179+
180+The first end-to-end prototype of Urbit took one engineer eleven
181+years. The current beta took three more years, with about three
182+engineers on average.
183+
184+How does it take 14 years to write 30,000 lines of code? The code
185+wasn't the hard part. The hard part was rewriting it until it was
186+right. We think we've solved all the real CS problems, and we're
187+certainly done changing major interfaces. But it will take more than
188+our small team to deliver a polished Urbit user experience that can
189+actually challenge modern web apps.
190+
191+## Where we are, what we're doing
192+
193+Urbit is in feature freeze. It's a minimum viable product in
194+early beta. It still needs quite a bit of fit-and-finish work.
195+We certainly don't recommend it for end users or consider it in
196+any way secure. But it's fun to play with, if you're a hacker.
197+
198+This summer, we're making the switch to an open and transparent
199+development and specification process. A system as unusual as
200+Urbit can't be invented in public. But it has to be finished and
201+maintained in public.
202+
203+Additionally, we're creating an open political and economic process,
204+with a small, fixed-price public presale of Urbit address space. Join
205+us and help make this future actually happen.
206+
207+To keep reading, learn more about [Urbit's address
208+space](/blog/the-urbit-address-space); share our vision of the Urbit user
209+experience, from the [top down](/blog/what-is-urbit-for) or the [bottom
210+up](/blog/magic); check out the [development roadmap](/blog/roadmap);
211+evaluate Urbit's [beliefs and principles](/blog/beliefs-and-principles) or its
212+[interim constitution](/blog/interim-constitution).
213+
214+(For technical readers, check out our [documentation](https://urbit.org/docs/) or
215+the [whitepaper](https://media.urbit.org/whitepaper.pdf)).
content/blog/announcing-urbit-grants.mdnew file+49
@@ -0,0 +1,49 @@
1++++
2+title = "Announcing: Urbit Grants Program"
3+date = "2019-08-05"
4+description = "Announcing Urbit Grants, a way to earn stars through contributing."
5+aliases = [
6+ "/posts/essays/announcing-urbit-grants",
7+ "/posts/announcing-urbit-grants"
8+]
9+
10+[extra]
11+author = "Robert Mariani"
12+ship = "~lodleb-ritrul"
13++++
14+
15+We’ve long been grateful for the hard work of our open-source community, so we’re pleased to announce Grants, a program that gives contributors the opportunity to be compensated for their efforts. It’s in beta right now at [grants.urbit.org](https://grants.urbit.org/).
16+
17+The Grants program will reward valuable contributions with Azimuth stars in one of three ways: Gifts, Bounties, and Proposals.
18+
19+### Gifts
20+
21+We’ve periodically announced gifts for important contributions to the project – like in [2018](https://urbit.org/posts/2018-2-17-update/) and [2019](https://urbit.org/posts/urbit-grants-and-mid-2019-gifts/) – but we wanted to make this more formal.
22+
23+Not everyone always works on structured projects, so the lack of formal criteria for receiving a gift is meant to reward contributors who work outside of the bounty and grant system.
24+
25+Going forward, gifts will be awarded semi-annually (every six months). They’ll retain the informal and arbitrary nature of the awards that came before: Tlon will determine who gets what. We’ll work hard to make sure these payouts are fair.
26+
27+To see the gifts that have been awarded so far, check out the [History section](https://grants.urbit.org/history) of the Grants website.
28+
29+### Bounties
30+
31+Bounties are discrete projects in search of a champion. Tlon will define a clear deliverable, and some number of stars as their reward. Larger bounties will often have their star reward spread across multiple milestones.
32+
33+Contributors can apply to claim a bounty by clicking the “Request to work on this” button. Once a contributor is selected to work on a bounty, nobody else will be able to apply.
34+
35+Bounties are listed in the [Bounties explorer](https://grants.urbit.org/rfws). Play around with the explorer by filtering bounties using the Tag and Category features.
36+
37+### Proposals
38+
39+Proposals are a way for contributors to pitch their own ideas, with a targeted number of stars. Proposals can be accepted, rejected, or accepted with changes. Unlike bounties, a proposal can only be completed by the individual or group who submitted it.
40+
41+Proposals don’t need to be fleshed out like a bounty does, at least not initially. Submit an idea and Tlon will work with you to refine it.
42+
43+You can see the list of accepted proposals in the [Proposals explorer](https://grants.urbit.org/proposals).
44+
45+### What can you do?
46+
47+[Sign up](https://grants.urbit.org/auth/sign-up) on our Grants website page, then set up your profile so we know who you are, linking your GitHub, Twitter, and your Azimuth point: reputation is a factor in determining eligibility for a grant.
48+
49+Also, check out the [Grants section](https://urbit.org/faq/#grants-1) of the new Urbit FAQ for more information.
content/blog/ares.mdnew file+51
@@ -0,0 +1,51 @@
1++++
2+title = "Ares"
3+date = "2023-06-26"
4+description = "A light technical description of Ares, the new Urbit runtime"
5+
6+[extra]
7+author = "Noah Kumin"
8+ship = "~librex-dozryc"
9+image = "https://storage.googleapis.com/media.urbit.org/blog/ares-header.png"
10++++
11+
12+
13+
14+## What is Ares?
15+
16+Ares is a new Urbit runtime that will be much faster and manage a much larger amount of data than previous versions of the runtime. Those new to Urbit commonly ask if they will be able to host photos and videos on their Urbit ships. Ares—a joint project from the Urbit Foundation, Tlon, and Zorp—sets the stage for us to be able to answer, simply, “Yes.” Ares is still a work in progress, but we expect to see the new binaries rolled out later this year. There are three components to the project. Let’s talk about them one by one.
17+
18+## 1. Code Generation
19+
20+Modern CPUs are extraordinarily fast. But until now your Urbit hasn’t been able to take full advantage of this fact. One way to conceptualize the problem is to imagine a train that is only able to go as fast as a track-worker can lay down track for it. In this analogy, your CPU is the train, and the track-worker is the Urbit runtime. The aim is to have large sections of track laid down ahead of time. Ares includes a codegen system that compiles Nock, Urbit’s assembly language, to machine code that the CPU can predict well.
21+
22+This system addresses what has until now been a problem: Nock is meant to invoke other code in a given Urbit computer’s “subject.” Or, in more common parlance, in the computer’s “state.” Your state changes with every new message your Urbit computer sends and receives, or with any new event in any app. That makes it hard to make the resulting machine code run fast, since the CPU needs to read from the subject while it’s running in order to figure out what machine code will be run next.
23+
24+The new code generation process in Ares solves this problem by using a system which the developers have called “subject knowledge analysis.” What does this mean? By analyzing how an Urbit subject might change over the course of a Nock computation, Ares will learn about the subject's tree shape and about its data dependencies (*i.e.*, the way that later parts of the computation depend on earlier parts of the computation). This allows those parts of the subject which are known at the time of compiling Nock to machine code to remain known at later points in the computation.
25+
26+To go back to our metaphor of train tracks, this is what allows the “track” to be laid down ahead of time. This set of known parts of the subject typically includes Nock formulas stored in [cores](https://developers.urbit.org/guides/core/hoon-school/F-cores#cores). This allows the resulting machine code to use direct jumps to perform Nock function calls. Without this “subject knowledge analysis,” the CPU would have had to perform an “indirect jump” by calculating the location to which a later instruction would jump. Now your computer’s CPU can jump directly to where it’s supposed to go.
27+
28+## 2. 2stackz Noun Allocator
29+
30+Ares will make use of what we’re calling the *2stackz noun allocator*. With the advent of Ares, your Urbit will be a virtual machine with two stacks and no heap. What does this mean? Traditionally, a program has a *stack* and a *heap*. The stack is a linear data structure within a program used for the program’s execution. The heap is a less structured region of memory that is used for storing large pieces of data or data that you want to keep around for a while without taking up space in the stack. However, the heap is slower, because its system for allocating memory is less orderly. (Imagine, say, trying to find a specific pair of socks in a heap of clothing.)
31+
32+Ares recognizes that because Nock is much more constrained than most languages, the Urbit runtime doesn’t actually need a heap. Instead you can take the function call stack and split it in two. The top of either stack can then be used as a little temporary heap. Whenever a function executes, you copy the data that gets returned from one stack to the other. And all the intermediate products that get created when running that function (*i.e.*, other functions that got called by the initial function) sit there as *garbage* (unwanted or unused data) in between the two stacks. But you don’t have to do the same sort of bookkeeping—tracking and updating these values—that you would have to do with a heap.
33+
34+Every piece of data in your Urbit computer is a noun. A noun is an atom (a positive integer or zero) or a cell (a pair of nouns). Before Ares, both allocating and freeing a noun in the Urbit runtime were processes that took a lot of time. (To *allocate* a noun is to put that noun in memory and to *free* it is to tell your urbit that you don’t need it any more.) Ares should make both of these processes much faster. This is good news because the Urbit runtime allocates nouns (particularly pairs of nouns, known as cells) like nobody’s business.
35+
36+## 3. Persistent Memory Arena
37+
38+Ares’s Persistent Memory Arena is for managing large amounts of data within your urbit in such a way that your urbit does not get slow. If you have terabytes of data within your Urbit, you can only have a very small subset of that within your hardware’s RAM at a given time. The rest of that data is going to have to live on disk—the section of your hardware that is more capacious but takes more time to access.
39+
40+To deal with this fact, your motherboard moves data back and forth between RAM and disk depending on what data needs to be accessed at a given time. This is known as *paging*, because it does so one *page* (usually four kilobytes) at a time. Traditionally operating systems will handle paging for you, but they do it in a generic way. The Persistent Memory Arena is designed specifically for managing Urbit's single-level store.
41+
42+A *single-level store* means that there’s no distinction in the operating system between data that lives in RAM and data that lives on disk. Instead of having two levels from which you can access data, you only have one, and the system itself manages which parts of the data are in RAM and which are in disk. The Persistent Memory Arena is an optimization for handling a large amount of data in a single level store. It is for nouns that persist between computations. Using the PMA, your urbit’s state can grow large without being hemmed in by the limitations of your hardware’s RAM.
43+
44+
45+## Updates and Links
46+
47+You can find the Ares GitHub repository [here](https://github.com/urbit/ares). The technical proposal is [here](https://github.com/urbit/ares/blob/status/docs/proposal/proposal-nock-performance.md). Check back at the Urbit Google Groups [listserv](https://groups.google.com/a/urbit.org/g/dev/), the [@zodisok](https://twitter.com/zodisok) Twitter account, and the Urbit Foundation [group](https://tlon.network/lure/~halbex-palheb/uf-public) for updates about the upcoming release.
48+
49+–
50+
51+*Noah Kumin is the founder and editor in chief of the [Mars Review of Books](https://marsreview.org/).*
content/blog/august-2022-grants-program.mdnew file+73
@@ -0,0 +1,73 @@
1++++
2+title = "August Grants Program Review"
3+date = "2022-08-30"
4+description = "The completion of the first cohort of Hoon School Live and the following App School Live program minted dozens of capable new Hoon developers. These developers are completing applications, closing out bounties, and putting together proposals at a rapid pace, with more to come as Assembly 2022 draws near."
5+[extra]
6+author = ""
7+ship = "~sarlev-sarsen"
8+image = "https://storage.googleapis.com/media.urbit.org/blog/b52.jpg"
9++++
10+
11+
12+
13+# Completed Grants
14+
15+Recently completed grant projects include Urbit micro-blogging, Hoon-native Discord bridging, Urbit’s first arcade-style game, Port application improvements, Ethereum bookkeeping and eth-provider infrastructure.
16+
17+* [Trill](https://urbit.org/applications/~sortug/trill) and sister application [Urbit Feed Aggregator](https://urbit.org/applications/~sortug/ufa) give you a way to escape from Twitter’s algorithms while still being able to share your shower thoughts with your followers.
18+* [Faux](https://urbit.org/applications/~midsum-salrux/faux) is a transformation of the python-based Urbit to Discord bridge, turning it into a Hoon native app and offering a front-end that takes you through the setup experience, letting you to bring your Discord friends a little taste of Urbit.
19+* [Slam](https://urbit.org/applications/~hanfel-dovned/slam), everyone’s favorite new arcade game, integrates with [Gora](https://urbit.org/applications/~dalten/gora) and [pals](https://urbit.org/applications/~paldev/pals), utilizing a mechanism whereby the number of gorae held by your pals will influence the way your game is played.
20+* The [Ethereum Provider](https://urbit.org/grants/eth-provider) grant gets the network a step closer to decentralized Ethereum access, particularly for those who don’t wish to rely on an infura node.
21+* A bounty for [Port Maintenance](https://urbit.org/grants/port-maintenance) delivered iterative improvements to the Port application for those who run their ships on a local machine.
22+* And Quartus delivered [Books](https://urbit.org/applications/~doller-doller-rabsef-bicrym/books), an Ethereum address and transaction manager for you to easily append notes and memos to your on chain transactions without having to rely on a third party (as a friendly reminder, [Urbit is not yet a secure environment so please be careful](https://twitter.com/pcmonk/status/1563634078779592709?s=20&t=FN7VVjMdjyIdukSvtg5_7g) what information you store on your ship).
23+
24+
25+# Proposals
26+
27+As the above grants wrap up, more grants are coming to life. Proposals are community generated and selected projects which offer contributors the space to build whatever tooling or applications they believe Urbit needs. Each of the following projects was funded in August:
28+
29+
30+
31+* [Herd](https://urbit.org/grants/herd) - Dependency management for Citadel
32+* [Full Stop](https://urbit.org/grants/full-stop) - A menstruation tracker for Urbit
33+* [Peat](https://urbit.org/grants/peat) - Urbit’s first backup utility
34+* [Quorum](https://urbit.org/grants/quorum) - A clone of stack exchange on Urbit
35+* [Gather](https://urbit.org/grants/gather) - an Urbit native meetup tool
36+* [Olif](https://urbit.org/grants/olif) - Olfactive rendering of Urbit address space
37+* [Urbit Interface Framework](https://urbit.org/grants/urbit-interface-framework) - Framework for alternative web browser interface
38+* [Whom](https://urbit.org/grants/whom) - A profile and contacts manager
39+
40+
41+# Apprenticeships
42+
43+Apprenticeships are also bringing opportunities for hands-on developer education and enabling seasoned contributors to share knowledge through real world projects. And contributors get to earn address space as they learn the stack and grow their network.
44+
45+Three new apprenticeships began in August:
46+
47+
48+
49+* [Loom Pointer Compression](https://urbit.org/grants/loom-pointer-compression) - Work to double the size of the loom
50+* [Build a UI for Volt](https://urbit.org/grants/volt-ui) - An interface for %volt, Urbit’s lightning wallet agent
51+* [Vere Profiling](https://urbit.org/grants/profiling) - Uncovering and visualized performance bottlenecks in the runtime
52+
53+
54+# Bounties
55+
56+August also brings with it the assignment of previously open bounties to developers looking to grow their portfolio of Urbit projects. Many of bounties that found contributors are a part of [Holium’s App Dev Summer](https://www.youtube.com/watch?v=dHyzH09QaZQ), and are slated to be completed by Assembly in Miami:
57+
58+* [Minesweeper](https://urbit.org/grants/minesweeper) - A classic desktop game, now natively in hoon
59+* [Abacus](https://urbit.org/grants/abacus) - A basic calculator app with the ability to convert units
60+* [Chronicle](https://urbit.org/grants/chronicle) - A news app that links articles from group channels
61+* [Lexicon](https://urbit.org/grants/lexicon) - A simple dictionary app with custom definitions for a group
62+* [Chess Improvements](https://urbit.org/grants/chess-bounty) - An enhanced chess experience with timing and ELO servers
63+
64+Even with all the claimed bounties, there remain a variety of projects which currently seek developers. Check out the following grants and apply to those that fit your skills and interests:
65+
66+
67+* [Trove](https://urbit.org/grants/trove) - A group file sharing tool
68+* [Urbit Native Ethereum wallet](https://urbit.org/grants/eth-wallet) - An ETH wallet for Urbit maxis
69+* [UrbitSwap](https://urbit.org/grants/urbitswap) - An Urbit-hosted Uniswap instance
70+* [Tune slaw/scot jets](https://urbit.org/grants/slaw-scot-jets) - Tuning jets for better performance
71+* [New Mars Persistent Memory](https://urbit.org/grants/persistent-memory) - Development of a persistent memory arena
72+
73+Have a project that you want to help fund and think would make a good bounty? Want to propose a project about which you are passionate? Looking for a mentor to better learn a part of the Urbit ecosystem? For more information on current projects and opportunities from the Urbit Foundation’s grant program, visit [urbit.org/grants](/grants) or reach out to ~sarlev-sarsen to get involved.
content/blog/azimuth-as-multipass.mdnew file+34
@@ -0,0 +1,34 @@
1++++
2+title = "Azimuth as Multipass"
3+date = "2019-05-15"
4+description = "What if everyone had a single 'civilizational key'?"
5+aliases = [
6+ "/posts/essays/azimuth-as-multipass/",
7+ "/posts/azimuth-as-multipass"
8+]
9+
10+[extra]
11+author = "Galen Wolfe-Pauly"
12+ship = "~ravmel-ropdyl"
13+image = "https://media.urbit.org/site/posts/essays/azimuth-as-multipass-1.png"
14++++
15+
16+
17+
18+Why can’t I just walk up to a door and have it open for me? Why can’t I simply arrive at a restaurant and have them know I’m there? Shouldn’t I be able to buy a ticket to a show with my Multipass then scan it at the entrance and use it to buy drinks?
19+
20+Why should I have to log in with MEGACORP? Today, in most cases, it’s a different MEGACORP for every single context. It’s a MEGAMESS.
21+
22+Why not just use one? Forget about how we get there for a moment: just imagine how simple it could be.
23+
24+An Azimuth point is an identity and a wallet. Both a driver’s license and a credit card. Identity and money. Think about it as a ‘civilizational key’ for a new society. Concretely, it’s nice to imagine it as a physical object. A slick, card sized object with an e-ink screen. You can tap it to pay, tap it to enter, and plug it into a computer to boot your Arvo OS.
25+
26+Worried about losing it? Just remember your ticket. If you use our wallet system, all you need to remember is something like `~ravmel-ropdyl` and `~habpem-sondem-pidbyt-solbyn`. A point and a ticket. That’s it.
27+
28+Woke up in the desert, no idea how you got there, but can still remember your point and ticket? Great! Just get to an internet connection and re-ticket – you’ll be fine. Although probably dehydrated.
29+
30+If you’re someone who’s worried about getting kidnapped, just use a child identity. Your Azimuth planet has ~4B of them, so you can always invalidate one if you lose it.
31+
32+Perhaps part of how we ended up in the world we’re in is that we didn’t have something like Azimuth to begin with. Today, it’s backwards: everyone has an address on the network, but no one has an identity.
33+
34+We think everyone needs an identity that can hold money and have packets routed to it. Start there, and it’s quite fun to imagine where you end up. A civilized digital society might even be possible after all.
content/blog/azimuth-is-on-chain.mdnew file+107
@@ -0,0 +1,107 @@
1++++
2+title = "Azimuth is On-Chain"
3+date = "2019-01-13"
4+description = "The Urbit address space, now called Azimuth, is on the blockchain. And too many other things to fit into a single post."
5+aliases = [
6+ "/posts/essays/azimuth-is-on-chain",
7+ "/posts/azimuth-is-on-chain"
8+]
9+
10+[extra]
11+author = "Galen Wolfe-Pauly"
12+ship = "~ravmel-ropdyl"
13++++
14+
15+
16+
17+The Urbit address space is now live on the Ethereum blockchain. We’re calling the PKI ‘Azimuth’ and you can find it at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). Owners of Azimuth ‘points’ (galaxies, stars or planets) can use [Bridge](https://github.com/urbit/bridge/releases) to manage them and view their balance now.
18+
19+Sometime in the next few days, owners of Azimuth points will be able to boot Arvo, the Urbit OS, from their Azimuth point and request access to one of our 'cities': private communities for chat and discussion. These new cities use Landscape, a brand new UI for using Urbit in the browser.
20+
21+This means you can boot a deterministic OS from an identity you own, join a totally independent, decentralized and self-governing network and run a clean, simple UI. Pretty exciting. Is it ready for ordinary users? Definitely not.
22+
23+Since 2013, you've been able to boot an Urbit and join our test network. And, since 2013, we've always had our sights set on building a personal server that can both last 100 years and be delightful to use. Urbit isn't meant just to be as good as the MEGACORP software we use today. It's meant to be much, much better.
24+
25+But Urbit is not a 'product' in the conventional sense. Urbit is a public thing. It's meant to belong to everyone. For the past six years, much of our work was research and design work. Which means lots of weird ideas thrown away, and others rewritten or redesigned many times over. Our work has always been open source, but we tend to be pretty quiet about it.
26+
27+With Azimuth on the blockchain, it's time for us to start engaging with the world more directly.
28+
29+We aren't calling this a launch. There's no keynote. There's no dancing on stage. I mean, it's 2019. You must be pretty sick of being marketed to. We'll try to stick to the specifics here. What's new, what we've been up to and what works. There's too much to fit into a single post, so we'll keep it pretty light for now. Each of these sections will probably get its own post in the near future.
30+
31+> Note: As of `~2019.1.14` we're in the process of rebooting the Arvo network. We expect it to be back online before the end of the week. We'll update this post and [tweet](https://twitter.com/urbit) when the network is online and stable.
32+
33+## Rethinking the stack
34+
35+We've started to talk about Urbit as a stack of three parts: Azimuth, the address space and identity layer on Ethereum; Arvo, the OS and overlay network; and Aegean, a pattern for building decentralized communities on the Arvo network.
36+
37+We tried to capture this separation in [the primer](/primer), a new overview of Urbit. Explaining Urbit has always been challenging. A monolithic project that is OS, network, language, VM and UI barely makes sense. Separating the layers helps, we think.
38+
39+Let's step through them to see what's new.
40+
41+## Azimuth
42+
43+
44+
45+As a quick refresher: Urbit addresses, now called Azimuth 'points', are short names like `~diblun-tidduc`. You own your Azimuth point with a private key and can use it as a routable network address on the Arvo network. You can read more about Azimuth in [the primer](/primer#what-azimuth-is). If you're curious who owns all this address space, you can find that [in there too](/primer#azimuth-distribution).
46+
47+In late 2017 we decided to migrate the yet-to-be-named Azimuth to a system of Ethereum contracts. After a year of coding, testing, auditing and migrating — they're now fully deployed to the Ethereum mainnet.
48+
49+Azimuth is basically two parts, a database of who owns which points, and a set of rules about what points and their owners can do. That set of rules is called Ecliptic, and can be found at [`0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d`](https://etherscan.io/address/0x6ac07b7c4601b5ce11de8dfe6335b871c7c4dd4d) or [`ecliptic.eth`](https://etherscan.io/address/ecliptic.eth). The top-level Azimuth points, the galaxies, can vote on upgrades to the Ecliptic contract, but they can't edit the database of who owns what.
50+
51+The ownership database contract is called Azimuth, which you can find at [`0x223c067f8cf28ae173ee5cafea60ca44c335fecb`](https://etherscan.io/address/0x223c067f8cf28ae173ee5cafea60ca44c335fecb) or [`azimuth.eth`](https://etherscan.io/address/azimuth.eth). For those of you who own address space, you can use the `getOwnedPoints` function in the 'Read Contract' tab to check your balance. The function returns the number (not the phonemic string like `~ravmel-ropdyl`) of your points. Each Azimuth point is an ERC-721, non-fungible piece of digital property.
52+
53+To manage your points, we built [Bridge](https://github.com/urbit/bridge/releases), a completely custom interface for interacting with our Solidity contracts. Interface quality is really important to us, and we couldn't find anything in the 'crypto' world that met our standards. Bridge is good, but crypto UX is a hard problem. We've already got some ideas for improvements.
54+
55+If you're curious, you can find the source for the contracts in the [`urbit/azimuth`](https://github.com/urbit/azimuth) repo. The Bridge source is in the [`urbit/bridge`](https://github.com/urbit/bridge) repo.
56+
57+We had the source for our contracts audited by Open Zeppelin, Blockchain at Berkeley and Bloctrax. Did we miss something? We sure hope not — but we'd happily compensate anyone who can find bugs. Please reach out to security@urbit.org if you find something of concern. We'd be happy to hear from you.
58+
59+
60+
61+Azimuth names have always had a pronunciation system. `~ronryd-nidseg` is 13,695,781, for example. Now, they also have a visual system. We call these strange crests from another planet 'sigils', and you'll notice them used throughout all our new interfaces. You can find the source in the [`urbit/sigil-js`](https://github.com/urbit/sigil-js) repository. Building these was a lot of fun — we'll save the details for a future post.
62+
63+So, how do you get an Azimuth point? We've left that question unanswered intentionally. Azimuth points are meant to be like digital land, not currency. They should change hands slowly. In order to get an Azimuth point, you'll need to find someone who already has one and is willing to part with it.
64+
65+## Arvo
66+
67+
68+
69+Arvo boots from Ethereum, is no longer embarrassingly slow, and has a brand new build system. [Our documentation](https://urbit.org/docs/learn/arvo/hoon) has also improved quite a lot. Hoon, Arvo's programming language, has had a lot of work done to its type system and compiler. We built new tooling for generating static sites (you're probably reading this on one right now) that are much, much faster and easier to use.
70+
71+It's tough to talk about the progress we've made on Arvo without writing a long technical post. We'll save that for later. In a way, what's remarkable about Arvo is that it has become _less_ remarkable. It's more stable, faster, and the code quality has improved.
72+
73+There's plenty of work to do, though. Should you be building on top of Arvo? Probably not yet. The kernel and kernel modules are really where the work still lies. We build things on top of Arvo, and in doing so it's pretty clear that the system can be better. Clay (the filesystem) and Gall (the application model) are due for a rewrite. A complete rewrite of the web server, Eyre is almost finished.
74+
75+## Aegean
76+
77+
78+
79+Aegean is a pattern for building 'cities': groups of people running the same 'agent' on their Arvo servers. Agents aren't just 'apps' or programs. An agent rolls together the tools that a community needs. Today, our companies, communities, cults, cliques all have to duct tape together separate MEGACORP apps and services to compute together.
80+
81+Aegean reverses this pattern. A community on Arvo is a city: just a bunch of people running the same agent. Each city is in control of its own codebase: the interface, application code _and_ data storage. This means a community can have complete agency over how to compute together.
82+
83+Aegean cities can be completely different without impacting one another at all. Cities share the neutral infrastructure of Arvo and Azimuth — but they may never even know others exist. An archipelago of hypercultures.
84+
85+It's important to note: the pattern of these cities is _not_ the pattern of Azimuth. The network hierarchy should impact the society of Urbit as much as the electrical grid impacts the life of the street in Manhattan. It matters when the power goes out — but most of the time groups form and dissipate continuously.
86+
87+Before we can let the ocean of cities grow we have to homestead a few of our own.
88+
89+Our first agent is called [Landscape](https://github.com/urbit/urbit/tree/master/pkg/interface), an agent for chat and longform discussion. We are using Landscape to run a few experimental cities over the next month or so. If you have an Azimuth point, you'll need to [request access](mailto:support@urbit.org) to join.
90+
91+Anyone can create their own city, of course. The source is open. But we're not going to encourage you to just yet. Feel free to explore, but also be patient. We've got a lot planned around this. If Azimuth is done and Arvo is young, Aegean is just being born.
92+
93+## Tlon
94+
95+
96+
97+So who is behind all of this? A team of collaborators and contributors. Many of us work at [Tlon](https://tlon.io) — the company we started in 2013 to advance Urbit platform development. Tlon has attracted an incredible group of smart, talented people who want the world to be able to own and control their computers. I'm proud to work alongside them.
98+
99+One important omission on `tlon.io` is Curtis. As of today, he's no longer working on Urbit. [His own words](/posts/essays/a-founders-farewell) are the best way to understand his thinking. It's an achievement for the team, I think, that he can depart with confidence.
100+
101+One major reason for that confidence is that Erik and Anthony have now become COO and CPO respectively. Having thoughtful, organized people leading the project is a huge benefit to the whole team. I'm very glad to have them on board.
102+
103+## Looking ahead
104+
105+I certainly forgot at least a thing or two. We'll dive in to more detail in the coming weeks.
106+
107+There's a lot for you to explore. Have fun!
content/blog/azimuth-security-bounty-program.mdnew file+40
@@ -0,0 +1,40 @@
1++++
2+title = "Azimuth Security Bounty Program"
3+date = "2019-07-21"
4+description = "Inviting you (and your friends) to help us make Azimuth as secure as possible."
5+aliases = [
6+ "/posts/essays/azimuth-security-bounty-program",
7+ "/posts/azimuth-security-bounty-program"
8+]
9+
10+[extra]
11+author = "Anthony Arroyo"
12+ship = "~poldec-tonteg"
13+image = "https://media.urbit.org/site/posts/essays/azimuth-security-bounty-program-1.jpg"
14++++
15+
16+
17+
18+Since launching [Azimuth](https://urbit.org/posts/azimuth-is-on-chain/), we’ve been running a private bounty program with [HackerOne](https://hackerone.com/). We’re now taking the program public and inviting you (and your friends) to help us make Azimuth as secure as possible.
19+
20+[Go here](https://hackerone.com/tlon) to see the live program on HackerOne.
21+
22+## What is Azimuth again?
23+
24+Azimuth is [the Urbit public key infrastructure](https://urbit.org/posts/azimuth-is-on-chain/). It’s a set of Ethereum smart contracts that allow for cryptographic ownership and management of Urbit identities. It also provides a governance mechanism whereby galaxy owners are able to propose and vote on improvements.
25+
26+People already [use Azimuth](https://github.com/urbit/bridge) to boot Arvo ships, spawn stars and planets for others and transfer points. But Azimuth is a general identity system, with great potential to be used beyond Arvo: there are primitives for reputation, payments and securing communication channels.
27+
28+## Security program details
29+
30+We had the Azimuth contracts audited by [Open Zeppelin](https://openzeppelin.org/), [Blockchain at Berkeley](https://blockchain.berkeley.edu/) and [Bloctrax](https://www.bloctrax.com/), but we don’t want to take any chances. We’re hoping that the HackerOne program will help us get more eyes on the contracts, identify vulnerabilities and get out in front of any problems. You can find more information about the program at [our page](https://hackerone.com/tlon) on HackerOne.
31+
32+We’re interested in any vulnerability in the Azimuth contracts that would allow an attacker to either seize other user’s points, impersonate points or that would result in the platform becoming unusable.
33+
34+The program page has links and instructions on how to set up a development version of Bridge and point it at either the Ropsten deployment of the contracts or at a local network to play with the contracts and look for vulnerabilities.
35+
36+## Arvo is out of scope for now
37+
38+We’re intentionally focusing our security efforts on Azimuth for now. Since Azimuth serves as our PKI layer, it’s the most crucial for the time being: it’s the source of truth for who owns what. We don’t want to have even a shred of a doubt that these cryptographic properties are secure.
39+
40+Of course, we’re working toward a future where you have a computer connected to this Azimuth point, and the computer has to be as secure as its identity. To achieve this, we have some more hard work to do on Arvo and our interpreter, Vere. When the time comes, we’ll also reach out for help testing vulnerabilities throughout the entire stack.
content/blog/beliefs-and-principles.mdnew file+134
@@ -0,0 +1,134 @@
1++++
2+title = "Beliefs and Principles Guiding the Urbit Project"
3+date = "2016-05-10"
4+description = "We believe."
5+aliases = [
6+ "/posts/essays/beliefs-and-principles",
7+ "/posts/beliefs-and-principles",
8+ "/posts/principles"
9+]
10+
11+[extra]
12+author = "Curtis Yarvin + Galen Wolfe-Pauly"
13+ship = "~sorreg-namtyv + ~ravmel-ropdyl"
14+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/beliefs-and-principles.jpg"
15++++
16+
17+
18+
19+## Beliefs
20+
21+We believe that general-purpose computing is an essential tool to
22+unlock the power of individual creativity.
23+
24+We believe that ownership, privacy and control don't need to be
25+sacrificed in exchange for usability, accessibility and reliability.
26+
27+We believe in the power of the informed crowd to develop and maintain
28+software, through the IETF principles of sincerity and rough consensus.
29+The ability of the engineering community to govern itself through
30+republican forms is not an abstract theory; it's a proven fact.
31+
32+We believe in both free speech and individual accountability. We
33+believe that a healthy network is one with diverse and well-defined
34+communities, and clear, user-controlled, boundaries between public and
35+private space.
36+
37+We believe that no software system can replace human trust and
38+communication. Dialogue, judgment and governance are essential to
39+communities of all scales. Code and law can reduce conflict in the
40+common case; they can never handle all exceptions.
41+
42+## Principles
43+
44+Here are some principles of Urbit. Where principles conflict,
45+the first stated takes precedence.
46+
47+### Digital independence
48+
49+Digital independence is independent control of your own
50+general-purpose computer which holds your own primary data.
51+Urbit's ultimate purpose is to make practical digital
52+independence a useful and widely available product.
53+
54+### Code is law
55+
56+Wherever possible, the rules of Urbit must be executable as code.
57+Wherever possible, code must be self-enforcing. If not, it must
58+be perfectly defined. If not, it must not be stated.
59+
60+### Sovereignty is conserved
61+
62+Even where code is law, exceptional situations demanding
63+effective collective action will always arise. There must
64+always be a collective authority to solve these problems.
65+
66+Two known problems in Urbit that require central authority are
67+approval of software updates and activation of the network. But
68+there will certainly be others.
69+
70+### Purpose of collective authority
71+
72+Urbit, as opposed to the Tlon corporation, is a republic. Its
73+government has one task: promoting, preserving and protecting Urbit.
74+It may take any legal action which advances this goal. Any other
75+actions are _ultra vires_, out of scope. Urbit is not a
76+general-purpose charity.
77+
78+### Decentralized control
79+
80+Urbit should never fall under any kind of central control. All
81+transitions in galaxy ownership should divide positions, not
82+unite them.
83+
84+Galaxy and star ownership should also be separated. It is
85+harmful for a single entity to hold both galaxies and stars.
86+
87+### Property is contingent
88+
89+Property rights are contingent and accidental, not moral or
90+meritorious. A property register does not record why an owner
91+deserves some property. Ownership is neither a reward nor a
92+right; it is a fact.
93+
94+### Governance is by stake
95+
96+Ultimately, Urbit must be governed by those who own it. In each
97+tier, equal stakes must hold equal authority.
98+
99+### Content-neutral
100+
101+Urbit does not admit a tradeoff between anarchy and tyranny,
102+order and liberty. Urbit has zero tolerance for abuse, nor does
103+it facilitate censorship.
104+
105+Urbit will do everything possible to help you block content you
106+don't want to see. It does nothing to help you block content you
107+don't want others to see.
108+
109+### Trolling considered harmful
110+
111+If you post content on Urbit which may offend or disturb any
112+significant group of users, it is your responsibility to mark it
113+properly for automatic blocking.
114+
115+### Sockpuppets considered harmful
116+
117+The only legitimate reason for one individual to use multiple
118+identities is to maintain multiple active pseudonyms. But
119+multiple identities must never interact in the same context.
120+
121+### Not a darknet
122+
123+Urbit is not a darknet. It does not break real-world laws. It
124+is not designed to facilitate the breaking of real-world laws.
125+For any problem that lawbreakers have, there must always be a
126+better solution that is not Urbit.
127+
128+### Responsibility to route
129+
130+As long as they are not facilitating violations of any of these
131+principles, or laws in their own jurisdictions, stars and
132+galaxies are responsible for routing their children. They are
133+also collectively responsible for escape-routing the children of
134+stars and galaxies which fail in their responsibility.
content/blog/bootstrapping-urbit-from-ethereum.mdnew file+394
@@ -0,0 +1,394 @@
1++++
2+title = "Bootstrapping Urbit from Ethereum"
3+date = "2017-09-19"
4+description = "We've decided to launch Urbit's constitution as a system of Ethereum contracts."
5+aliases = [
6+ "/posts/essays/bootstrapping-urbit-from-ethereum",
7+ "/posts/bootstrapping-urbit-from-ethereum",
8+ "/blog/2017.9.20-bootstrapping-urbit-from-ethereum/",
9+ "/blog/2017.9-eth/"
10+]
11+
12+[extra]
13+author = "Curtis Yarvin + Galen Wolfe-Pauly"
14+ship = "~sorreg-namtyv + ~ravmel-ropdyl"
15++++
16+
17+_TL;DR:_
18+
19+We've decided to launch Urbit's constitution as a system of Ethereum contracts.
20+
21+We'll instantiate a land registry for Urbit address space; an ERC20 "spark"
22+token which is burned to create a generic star; and a voting system for
23+self-governance. We'll also create template contracts which galaxies can use to
24+auction stars, and stars to distribute planets.
25+
26+## A bit of background
27+
28+One thing we realized after the last sale was, 'oh hey, the network has been up
29+for about a year.' Not bad! It wasn't that long ago that we were rebooting the
30+universe every few weeks. We still have plenty of work to do — but Urbit has
31+matured to the point where public ownership of the network really should be
32+cryptographically real.
33+
34+But even when the servers stay up, Urbit is still a testnet and remains
35+centralized in practice. We (Tlon) retain the ability to reset the network keys
36+at any time. This just isn't very 2017.
37+
38+In theory, Urbit doesn't need a blockchain, because real estate moves slowly.
39+In digital real estate, as opposed to digital currency, a low-friction,
40+zero-trust solution to the double-spend problem isn't an economic necessity.
41+
42+In practice, though, we have a hard chicken-egg problem. In the current design,
43+the key you use to secure your urbit is the same key that you use to sign your
44+network packets. Abstractly, this is the right design -- you want one
45+definition of who owns an identity.
46+
47+But concretely, since Urbit keys are valuable, you don't want to put them in an
48+operating system that isn't generally recognized as systematically secure. It's
49+hard to achieve this status while you're a testnet. So the virtuous cycle never
50+gets started.
51+
52+Moving the Urbit land registry to Ethereum is an easy and obvious solution to
53+this problem. If your urbit is owned by an offline Ethereum key, there's now a
54+mature ecosystem for protecting this property. And its security doesn't depend
55+on the security of Urbit. So, we realized, maybe Urbit actually does need a
56+blockchain for its land registry. While the system matures, we can bootstrap
57+off of Ethereum, without changing the design of the Urbit cryptosystem.
58+
59+And best of all, you can get your Urbit star or planet entirely through the
60+blockchain, without interacting with any centralized database or payment
61+mechanism. So we're really living in 2017.
62+
63+Sounds good, right?
64+
65+It does sound good. Although, as usual, we care about making things that _work_
66+above all else. So, rather than a 'announcing the Urbit token sale' post, this
67+is going to get fairly technical. We want to start the discussion about how
68+this change is going to work, and how it's going to get implemented. We'll save
69+the hype for later.
70+
71+First, we'll walk through the costs and benefits of using Ethereum. Then,
72+we'll refresh our memories on how the Urbit address space works, and finally
73+we'll walk through some of the details of how we plan on implementing this.
74+We've thought quite thoroughly about these things, but public criticism is
75+really important.
76+
77+## Weighing the choice of Ethereum
78+
79+Our engineering style is to build the whole stack, from axioms to UI, from
80+custom, super-minimal parts. When these parts don't fit perfectly, we rewrite
81+them until they do. With a few exceptions, such as crypto algorithms, Urbit
82+doesn't reuse existing code or designs, depend on existing tools, or expect
83+outside contributors to solve problems essential to a complete experience.
84+
85+Instinctive minimalism is essential in a custom full stack. The best solution is
86+always to not solve the problem. The natural engineering response to the
87+pre-blockchain difficulty of solving Byzantine consensus agreement was: do we
88+really need it?
89+
90+### The case against Ethereum
91+
92+Since Urbit network address space is a land registry, not a currency,
93+transactions are low-frequency. A low-frequency transaction system can succeed
94+economically even if it has high friction. The double-spend problem, which
95+consensus computing solves, becomes easy or at least tractable given high
96+friction.
97+
98+We reinvent the wheel if we have to, throw it away if we can. So depending on
99+Ethereum goes against all Urbit's instincts.
100+
101+Let's enumerate the problems, as critically as we can:
102+
103+And Ethereum's user experience is notorious; its governance is suspect and
104+unstable; its dilution rate is unconscionable; its dev environment is full of
105+bugs and misfeatures; in short, it's a classic MVP. It has only one real goal:
106+success. It seems to be doing pretty well with that.
107+
108+We prefer [SLC](https://blog.asmartbear.com/slc.html) to MVP. Urbit under
109+construction is fun to play around in. But we certainly won't ask real users or
110+real developers to set foot in Urbit until their experience is truly simple,
111+lovable and complete. The original iPhone set the bar for this, and we'll get
112+as close as we can.
113+
114+### The case for Ethereum
115+
116+It's obvious that Urbit has a practical problem in deploying a self-hosted PKI.
117+When does the testnet become a realnet? You wouldn't put real, valuable keys in
118+your urbit, until you know the system is mature and secure.
119+
120+But how does anyone know that Urbit is mature until more daring users have used
121+it with real, valuable keys? But who wants to be the first person to hop into
122+the box?
123+
124+There is no clear way to bootstrap past the testnet phase. Except, well, reboot
125+Urbit onto an existing blockchain, with a tested and reasonably-secure
126+key-handling infrastructure, that can also validate the Urbit PKI rules. Then
127+each user can decide on their own whether sensitive data is safe in their own
128+urbit.
129+
130+## An Urbit refresher
131+
132+Maybe some people are here because they know what Ethereum is, but not so much
133+Urbit.
134+
135+For those of you not familiar, let's try to refresh your memories.
136+
137+### What Urbit is
138+
139+One simple way to think about Urbit is as a "personal blockchain." Like a
140+blockchain, Urbit is a deterministic virtual computer. Its semantics are defined
141+by a frozen lifecycle function, which maps its event history to its current
142+state. But, unlike a blockchain, an Urbit instance is a private computer for one
143+user, not a public record for everyone.
144+
145+Urbit's lifecycle function is a nano-interpreter called Nock. A typed functional
146+language, Hoon, compiles itself to Nock. An event-driven OS, Arvo, is written in
147+Hoon. Everything above Nock can upgrade itself over Urbit's own overlay packet
148+network, Ames. Ames is live and stable with test keys.
149+
150+Our Urbit interpreter runs on any Unix machine. The Urbit server is a
151+single-level store -- both database and application engine. Every Urbit event is
152+a transaction. Urbit is semantically frozen and cannot call out to Unix.
153+
154+Your Urbit instance is your personal server. Your urbit should eventually
155+contain and manage your whole digital life. You may compute at home or in the
156+cloud, based on your security/privacy tradeoff, but Urbit's formal semantics
157+makes ships trivial to migrate. You'll never be locked in to one computing
158+provider.
159+
160+### The Urbit address space
161+
162+An Urbit address is called a "ship." A ship is a network address, a
163+cryptographic identity, a pronounceable name, and a permanent memory. A ship's
164+name is just its numeric address, written in a syllabic base-256.
165+
166+Smaller addresses mean shorter, more memorable ships. Ships are classified in a
167+hierarchy: 8-bit "galaxies" (like `~dyl`), 16-bit "stars," (`~ropdyl`), and
168+32-bit "planets" (`~ravmel-ropdyl`). Galaxies and stars are network
169+infrastructure. Regular users have planets. The tight 32-bit address space makes
170+names short enough to remember, and costly enough to deter Sybil attacks.
171+
172+Planets are created by their prefix star; stars are created by their prefix
173+galaxy; galaxies were created by the founders. Parents assist their children,
174+providing essential services like peer-to-peer packet routing, but don't own or
175+control them. The prefix is just an initial default -- a ship can switch to any
176+parent that's willing to adopt it.
177+
178+## Summary of the integration model
179+
180+In the new integrated model, every planet, galaxy or star is owned by an
181+Ethereum address. The secret that controls this address is the ship's "master
182+key."
183+
184+The master key is not needed to operate the ship and should not be stored on it,
185+at least not until Urbit is more mature. Master keys should be kept as "cold" as
186+possible. They are only used to perform lifecycle operations on your ship, by
187+signing Ethereum transactions which are sent to the Urbit constitution.
188+
189+We'll fork an open-source Ethereum browser and add a custom UI for Urbit
190+transactions. New users will acquire their urbits entirely on the blockchain.
191+
192+The most basic Urbit transaction is starting a ship you own. To start your ship,
193+you use Urbit to generate an Urbit keypair, and use Ethereum to register the
194+Urbit public key (a 512-bit pair of Curve25519 for encryption and Ed25519 for
195+signature) on the Ethereum blockchain.
196+
197+For users who want to hold generic stars without starting or even selecting
198+specific ships, we'll create a divisible "spark" (USP) ERC20 token. A spark is
199+the right to create one star. Sparks are a convenience tool: they leverage the
200+mature ERC20 infrastructure for holding and trading token utility rights.
201+
202+Instead of launching stars directly, galaxies can cede their unlaunched stars to
203+the Urbit constitution. The issuing galaxy receives one spark in exchange for
204+this star. Any Ethereum address can redeem one spark in exchange for the right
205+to start one star from the constitution's pool.
206+
207+Once all the galaxies are created, Urbit is fully decentralized. We retain no
208+ownership powers over the Urbit constitution.
209+
210+The Urbit galaxies will mirror the state of the constitution, distribute its
211+state and events within Urbit, and post any transactions created within Urbit.
212+Generally an Urbit ship trusts its parent -- if not, it should find a new one
213+fast. But a deeply paranoid ship can still listen to Ethereum directly.
214+
215+## Contract designs
216+
217+The Urbit constitution is four contracts: certificate storage, spark storage,
218+election storage, and logic controller.
219+
220+Following Ethereum best practice, we'll use separate storage and logic
221+contracts. The logic contract is stateless, and can upgrade itself without
222+replacing the storage contracts.
223+
224+We'll walk through how we have designed these contracts in detail here. You can
225+also view our in-progress source at the
226+[`urbit/azimuth` GitHub repo](https://github.com/urbit/azimuth).
227+
228+### Certificate storage contract
229+
230+For every galaxy, star or planet, the certificate contract holds a current
231+state: `%latent`, `%locked`, `%liquid` or `%living`.
232+
233+The default/empty state is `%latent` (nothing has happened to this ship). The
234+contract stores no data for a latent ship.
235+
236+A `%locked` ship has an owner and an activation date. It cannot be activated
237+until the given date. Until activated, the locked ship can't be transferred,
238+vote, liquidate or launch children.
239+
240+A `%liquid` ship is held by the Urbit constitution to be redeemed for a spark.
241+It has no other state.
242+
243+A `%living` ship is active. Its state: an Ethereum address which owns it; an
244+Urbit public key; a revision number, which increments on any lifecycle
245+operation; and (for planets and stars) both current and requested (for escaping)
246+parent ships.
247+
248+The certificate contract throws an event on every state change.
249+
250+### Spark storage contract
251+
252+The spark contract is a divisible ERC20 token (you can't hold half a star, but
253+you can hold half a spark). Only the logic contract can create and destroy
254+tokens.
255+
256+### Governance storage contract
257+
258+The governance contract records galaxies' votes on governance proposals.
259+
260+There are two kinds of proposals: concrete and abstract. A concrete proposal is
261+the address of a new logic contract for the constitution. An abstract proposal
262+is the hash of a document.
263+
264+Voting is one-bit -- the default vote is "no" -- and irreversible. A 256-bit
265+bitfield records the set of galaxies that have voted for each proposal.
266+
267+Only active galaxies may vote. A counter records the number of active galaxies.
268+A proposal passes if more than 50% of active galaxies support it. If the
269+proposal is concrete, the old logic contract is terminated and the new one
270+receives storage control. Abstract proposals have no further effects on the
271+blockchain.
272+
273+### Logic contract
274+
275+The logic contract is stateless and supports the following ops:
276+
277+#### Create a galaxy
278+
279+What: move a galaxy from `%latent` to `%locked` state.
280+
281+Who: the founders only.
282+
283+Comments: this is the only founder-privileged operation.
284+
285+#### Liquidate a star
286+
287+What: move a specific star from `%latent` to `%liquid` state, granting one spark
288+to the galaxy owner.
289+
290+Who: owner of the active galaxy which is the star's prefix.
291+
292+#### Claim a star
293+
294+What: move a specific star from `%liquid` to `%locked` state, with the
295+activation date set to the present, and the owner as claimer; remove one spark
296+from the owner.
297+
298+Who: any Ethereum address which owns a spark.
299+
300+#### Launch a star or planet
301+
302+What: move a specific star or planet from `%latent` to `%locked` state, with the
303+activation date set to the present, and set the Ethereum address which owns the
304+ship.
305+
306+Who: owner of the parent of the launched ship.
307+
308+#### Start a ship
309+
310+What: move a specific ship from `%locked` to `%living` state, setting its Urbit
311+public key.
312+
313+Who: owner of the locked ship.
314+
315+#### Transfer a ship
316+
317+What: change the owner of a `%living` ship, also resetting the Urbit public key.
318+
319+Who: current owner of the ship.
320+
321+#### Rekey a ship
322+
323+What: in a living ship, change the Urbit public key, without changing the
324+Ethereum address that owns the ship.
325+
326+Who: owner of the ship.
327+
328+#### Request adoption
329+
330+What: in a living ship, set the requested-parent field.
331+
332+Who: owner of the ship.
333+
334+#### Accept adoption
335+
336+What: in a living ship, set the current parent to the requested parent, and
337+clear the requested parent.
338+
339+Who: owner of the requested parent.
340+
341+#### Create a proposal
342+
343+What: create a proposal, which is either the hash of a document (abstract) or
344+the address of a new logic contract (concrete).
345+
346+Who: owner of any living galaxy.
347+
348+#### Endorse a proposal
349+
350+What: register support for a proposal. If the proposal is concrete and this
351+vote takes it over 50%, upgrade the contract.
352+
353+Who: any galaxy who has not yet voted on this proposal.
354+
355+### Planet sales and spark auctions
356+
357+We'll also write contracts that help galaxies and stars distribute their stars
358+and planets.
359+
360+#### An auction contract for spark sales
361+
362+The ERC20 spark token creates a liquid market in stars, or rather star
363+precursors. But a galaxy liquidating sparks may not want to just sell a large
364+block into this market, which may have weak depth, especially when the token is
365+initially launched.
366+
367+So we'll validate and deploy the Nick Johnson design for an
368+[off-chain second-price auction](https://www.reddit.com/r/ethereum/comments/6igsdq/a_proofofconcept_of_a_better_crowdsale_contract/)
369+
370+To run an auction, the seller liquidates a block of stars, then transfers the
371+spark tokens to a seller-owned copy of the auction contract. The Urbit
372+constitution is not involved with the auction.
373+
374+#### A distribution contract for planet sales
375+
376+There is no generic token for planets. To start a planet, you need a star to
377+launch it with your Ethereum address as the owner.
378+
379+To distribute planets on the blockchain, a star instantiates a private copy of
380+the planet sale contract. Since the star is the contract's owner, the contract
381+can send launch operations to the Urbit constitution.
382+
383+The star owner configures the planet sale contract with two parameters: the
384+price in ether of a planet, and the number of planets available.
385+
386+## Okay, so
387+
388+That was quite a lot of information! There's also a blog post about the constitution
389+[here](https://urbit.org/blog/interim-constitution/), and GitHub issues on the
390+[urbit/azimuth repo](https://github.com/urbit/azimuth) are more
391+than welcome.
392+
393+There's a lot more to come on this front as our contracts get closer to getting
394+live, and we begin migrating toward an on-chain Urbit PKI.
content/blog/common-objections-to-urbit.mdnew file+725
@@ -0,0 +1,725 @@
1++++
2+title = "Common Objections to Urbit"
3+date = "2016-06-27"
4+description = "Some common objections to Urbit, discussed."
5+aliases = [
6+ "/posts/essays/common-objections-to-urbit",
7+ "/posts/common-objections-to-urbit",
8+ "/posts/objections/"
9+]
10+
11+[extra]
12+author = "Curtis Yarvin"
13+ship = "~sorreg-namtyv"
14+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/common-objections-to-urbit-1.jpg"
15++++
16+
17+
18+
19+We love crowdsourced criticism. We've heard a lot of great
20+objections to Urbit. Surely there's more out there! We'll
21+revise this document to include anything new and interesting.
22+
23+Here's our list right now:
24+
25+- [Urbit is not ready for prime time.](#prime)
26+- [Nock jets are a total hoax.](#jets)
27+- [Urbit needs an infinitely extending packet/event log.](#log)
28+- [Urbit is a total scamcoin. It's 100% premined.](#scam)
29+- [Urbit isn't even really decentralized! It has a government!](#gov)
30+- [Sandstorm/IPFS/Ethereum is way ahead of Urbit.](#sand)
31+- [Urbit doesn't have enough planets for every human being.](#planet)
32+- [Cloud computing is inherently non-private.](#pwned)
33+- [Urbit will never be able to call any existing code.](#code)
34+- [Hoon is too weird. No one will be able to program in it.](#program)
35+- [Urbit programmers are stuck with Hoon.](#stuck)
36+- [Ordinary users will never be able to manage an Urbit server.](#user)
37+- [Urbit has no killer app.](#killer)
38+- [Urbit is sniffed at by Houyhnhyms.](#horse)
39+
40+_"We choose to go to the moon, not because it is easy, but because it is hard."_
41+— [John F. Kennedy](https://www.youtube.com/watch?v=g25G1M4EXrQ)
42+
43+## Urbit is not ready for prime time. {% #prime %}
44+
45+_TLDR_: we agree.
46+
47+Urbit right now is a fun toy. It is fun to learn Hoon. It is
48+even fun and quite practical to make actual contributions.
49+(Hoon's IEEE floating-point was written by someone we've never
50+met: `~nym`, formerly `~nodpet-rinned`.) In fact, we have never
51+seen anyone _not_ have fun with Urbit.
52+
53+But there is all kinds of stuff wrong with the codebase. Urbit's
54+documentation is much improved, but remains incredibly weak --
55+Arvo is almost totally undocumented. Scaling is poor at best.
56+Urbit's reliability is dubious. Its security is nil.
57+
58+Urbit is feature-frozen. The only thing we're working on now,
59+and for the rest of 2016, is doc, debugging and and self-hosting.
60+In that order of importance -- teaching Urbit is more important
61+than fixing it, which is more important than making it useful.
62+But we're quite confident that these are all solvable problems.
63+
64+The most important milestone about Urbit today is that it's ready
65+for technical decisions to be made collectively. A system like
66+Urbit can only be invented by a mad auteur. It can't be
67+maintained or stabilized by a mad auteur. Our primary goal today
68+is expanding the number of people who understand Urbit, and we
69+expect these pioneers to participate in technical governance.
70+
71+## Nock jets are a total hoax. {% #jets %}
72+
73+_TLDR_: all of computing is a hoax. You can't compare a hoax
74+to nothing. You can only compare it to all the other hoaxes.
75+
76+A "jet" is a sort of software device driver in Urbit. Urbit is
77+precisely defined in terms of an interpreter that fits on a
78+T-shirt, Nock. But a naive implementation of Nock is nowhere
79+near practical, because Nock has only one integer operation:
80+increment. For example, to decrement a number in Nock, you
81+increment a counter up to the number under it.
82+
83+The only way an efficient Nock interpreter can work is to
84+recognize algorithms like decrement, and implement them
85+non-naively. By far the easiest way to do this is not to analyze
86+arbitrary code as it's being executed, but to register and match
87+well-known implementations in the standard library. No one
88+should be writing their own decrement.
89+
90+But the semantics of the interpreter, _so long as the jet and the
91+jet harness are defined correctly_, are exactly those of Nock.
92+We are not extending or changing Nock in any way. We are just
93+taking a shortcut in certain cases we understand perfectly.
94+
95+It's not at all unprecedented to have implementations much more
96+complex than the corresponding specification. The x86
97+instruction set is relatively simple; the complexity of its
98+decoding and execution path in a modern CPU is enormous. This
99+path may well have "peephole optimizations" that replace matched
100+algorithms, and if it doesn't the modern compiler does. People,
101+_bad_ people, use "jets" to cheat on benchmarks all the time.
102+
103+Nock is designed as a standard. It's built like a standard.
104+Typically what causes real problems in standards is ambiguity.
105+Two implementations are incompatible, but each swears it has the
106+right interpretation of the natural-language spec. This simply
107+cannot happen in the Nock world. If two implementations
108+disagree, at least one of them is incorrect. This puts us firmly
109+in "with enough eyeballs, all bugs are shallow" territory.
110+
111+The fact remains, however, that a Nock interpreter without jets
112+is completely useless. And there is not even an informal
113+document that tells you what jets you need for a reasonably
114+efficient Urbit. (There should be such a document.)
115+
116+The correct way to think about jets is not to compare them to a
117+perfect interpreter created by unicorns. Jets are a combined
118+replacement for two other techniques in language implementation:
119+intrinsics and a foreign-function interface.
120+
121+Compared to both intrinsics and an FFI, your jets have one key
122+disadvantage: they need to be specified in pure code. You may
123+not have this executable specification, which means you need to
124+write it. Is this really so bad for your development process?
125+An executable specification? Which can be trivially tested
126+against the efficient implementation?
127+
128+Compared to intrinsics, jets give you true separation between
129+mechanism and policy; only the interpreter, not the programmer
130+and not the compiler, needs to know what's accelerated.
131+
132+Compared to an FFI, jets preclude I/O, so can be trivially
133+sandboxed. Except that the programmer needs to mark routines
134+which may benefit from optimization with a hint, here too we
135+separate mechanism (efficient implementation) from policy.
136+
137+Yes, formal verification of jet equivalence is desirable.
138+However, in the real world, many specifications, including quite
139+complex ones, are tested into equivalence by brute force.
140+
141+Urbit has some jet abuses. The equivalence between our markdown
142+parser in Hoon and the CommonMark C library is super dubious. It
143+should be revisited.
144+
145+But the miscomputation resulting from a minor jet discrepancy is
146+not a security hole or even fatal. It effectively means the
147+event history, computed correctly, does not match the current
148+state. The way to resolve this conflict is for the current state
149+to win, and the event history to be discarded -- not abnormal
150+anyway. See the next question.
151+
152+## Urbit needs an infinitely extending packet/event. {% #log %}
153+
154+_TLDR_: no, it doesn't. Urbit can prune the log.
155+
156+We can prune the event log because the Urbit transition function
157+doesn't have any access to the event history -- just the current
158+state and the current event.
159+
160+Urbit defines the semantics of a complete event log. It doesn't
161+and can't require an implementation to maintain the whole log.
162+It can maintain a checkpoint and the log since that checkpoint.
163+
164+However, any practical urbit maintains a periodically updated
165+checkpoint. Our present implementation doesn't provide a way to
166+prune the event log. But that's just a missing feature. We have
167+one or two of those!
168+
169+## Urbit is a total scamcoin. It's 100% premined. {% #scam %}
170+
171+_TLDR_: yeah. But at least it's not the DAO.
172+
173+Like a cryptocurrency, Urbit is a digital title. But Urbit is
174+digital land, not digital money. If you assess it as a currency,
175+it's a lousy currency. If you assess a cat as a dog, it's a
176+lousy dog.
177+
178+In real-world economics, the crucial distinction between land and
179+money is that land (a) has intrinsic utility and (b) is
180+non-fungible.
181+
182+Because of (b) alone, frictionless transactions in land are
183+impossible. A blockchain is only needed to ensure zero-cost
184+high-frequency transactions. So digital land doesn't need a
185+blockchain. Which means it doesn't need mining.
186+
187+Of course, just because a digital title system doesn't need
188+mining, doesn't mean it can't distribute an initial allocation by
189+proof-of-work -- or by any other arbitrary method which is
190+careful not to benefit the system's own developers. Could we
191+give away the Urbit address space randomly? Sure. But why?
192+
193+Probably the purest design is the "proof-of-burn" initial
194+allocation used by some coins. By any standard, proof-of-burn is
195+technically beautiful and results in an extraordinary level of
196+ethical independence. We can't help but admire it.
197+
198+But any altcoin or metacoin is just way less work than Urbit. An
199+altcoin can afford to burn even its creation energy, capturing no
200+value at all from its seigniorage. Your altcoin doesn't have a
201+clean-slate system software stack to drive. If your rocket has
202+to go to the moon, it's going to leave a little bit of smoke in
203+the air.
204+
205+Ethically, what makes "premining" feel wrong is that the creators
206+of the currency are rewarded disproportionately for their effort.
207+The scamcoin is a get-rich-quick scheme, vaguely pyramid-shaped.
208+Nothing about Urbit matches this pattern at all.
209+
210+Curtis invented Urbit. So by the [homestead
211+principle](https://en.wikipedia.org/wiki/Homestead_principle), he
212+started out owning all of it. But by now, Urbit's 8-bit galaxies
213+have already been distributed among [57 separate individuals](https://github.com/urbit/arvo/blob/master/sys/vane/ames.hoon#L118-L373).
214+Curtis owns 20, or about 8%.
215+
216+Tlon, the corporation which still runs Urbit development, has 95.
217+(Without Tlon, there is basically no Arvo.) 50 are reserved for
218+a hypothetical Urbit Foundation. Tlon employees have another 16.
219+
220+The rest of the galaxies belong to donors, investors,
221+contributors, contest winners, and just random people who were in
222+the right place at the right time. One is a Silicon Valley
223+tycoon. Another is an Orthodox nun in a monastery in Greece. A
224+couple are ex-Tlon employees who might totally hate us. There is
225+nothing they all have in common, which is sort of the point.
226+
227+This property distribution looks a lot like land ownership in the
228+real world -- complex and asymmetrical. That's no accident. If
229+you have a problem living in New York because New York's real
230+estate is not distributed equally among its residents, you may
231+have a similar problem with Urbit. The reality is that Urbit,
232+like New York, wasn't born yesterday and comes with a complex
233+ownership history which we couldn't possibly change, even if we
234+wanted to.
235+
236+Decentralization is hard. The only real goal of a property
237+system in address space is to create and maintain
238+decentralization. The whole network has to exhibit centrifugal
239+force, not centripetal force. Proof-of-work systems certainly
240+seem to have unexpected centripetal qualities, producing
241+unanticipated concentrations of centralized hashpower. See the
242+next objection.
243+
244+## Urbit isn't even really decentralized! It has a government! {% #gov %}
245+
246+_TLDR_: it's technically impossible for Urbit to be
247+decentralized at this stage of its life. Urbit is designed to
248+achieve decentralization, not be born with it.
249+
250+A young network can't afford to be decentralized. It has to act
251+as a unit. Because it has no network effect, it needs every
252+scrap of efficiency it can get.
253+
254+A decentralized general-purpose computing network like Urbit can
255+_only_ be bootstrapped by a central government. For example, by
256+default your urbit upgrades its OS automatically (like an
257+"evergreen" browser) with signed network updates. Whoever signs
258+these updates is a government by definition.
259+
260+When it's impossible to eliminate centralized power, it becomes
261+necessary to tame, stabilize, and limit it. This should not be
262+surprising to anyone living under a constitutional government.
263+
264+As we found out with the DAO, if a network isn't ready to be
265+decentralized, its developers shouldn't even try. If Ethereum is
266+hard-forked to roll back the DAO (which looks like the most
267+probable result), it acknowledges that it both has a central
268+government, and needs a central government. Decentralization is
269+good. Pretend decentralization -- "decentralization theater" --
270+is harmful, and not a effective path to actual decentralization.
271+
272+A key test of a free software project's health is whether it can
273+fork. So long as the unity of the public-key hierarchy and the
274+network protocol is maintained, the Arvo kernel and Urbit system
275+can fork in all kinds of ways without disrupting the network.
276+Any stress will fragment the "government" that develops the
277+kernel, and as it fragments it grows more limited and stable.
278+
279+Urbit is designed to govern itself collectively by address space
280+ownership -- effectively, "proof of stake." Any arbitrary power,
281+will tend to fracture along these property lines. For instance,
282+our hot updates are sent through the galaxy hierarchy; in a
283+development fork, active galaxies would pick upstream sources.
284+Two implementations of a standard are better than one.
285+
286+And by fragmenting the galaxy space into 57 separate partitions,
287+we've created a global property map which is much more likely to
288+splinter further, than reunite.
289+
290+In the long run, every galaxy should have a separate owner, who
291+is a human being rather than a corporation. Combining galaxy
292+holdings will damage the reputation of both galaxies. The only
293+reason to merge ownership is to move toward incipient monopoly.
294+Whether a galaxy admits this openly or denies it dishonestly, its
295+reputation will suffer.
296+
297+The technical goal of Urbit is to create a network which, _if it
298+actually takes over the world_, inevitably becomes decentralized.
299+Even if Urbit takes over the world, no individual or coherent
300+organization takes over the world. There is nothing even close
301+to a single point of failure in a mature, successful Urbit.
302+
303+This is the goal of all the new "web3" decentralized systems. If
304+IPFS, Sandstorm or Ethereum takes over the world, nobody takes
305+over the world. (The same is almost true of the Internet --
306+though it wouldn't be that surprising if a time traveler from
307+2116 revealed that ICANN had become a planetary government.)
308+
309+Urbit, by starting out as a centralized network, just reduces the
310+technical problem to match the actual goal. Only long-term
311+decentralization matters.
312+
313+It's very important that Urbit in 2116 be fully decentralized.
314+For Urbit in 2016, pretending to be decentralized would be a joke
315+at best, and a hoax at worst. And of course, no one can DAO us
316+-- since the property system is still just a central registry.
317+Among other things, we check it into GitHub. GitHub is not a
318+blockchain -- but still, good luck with that.
319+
320+## Sandstorm/IPFS/Ethereum is way ahead of Urbit. {% #sand %}
321+
322+In general, web3 (next distributed web) solutions don't compete
323+with each other. They support each other. Concretely, they are
324+all part of each others' network effect.
325+
326+IPFS, Sandstorm, Ethereum, and Urbit can all take over the world
327+at the same time. None of them competes with the others. They
328+enable each other.
329+
330+For instance, IPFS and Urbit are both global immutable
331+namespaces. IPFS is a chord-routed, content-addressed namespace.
332+Urbit is a direct-routed, identity-addressed namespace. Urbit is
333+a typed revision-control system; IPFS is a blob store. IPFS
334+isn't a computer; the work hasn't been done, but Urbit can easily
335+mount the IPFS namespace and compute functionally against it.
336+
337+So the better IPFS does, the less Urbit needs to struggle against
338+its lack of network effect. The better Urbit does, the easier it
339+is for IPFS to point to a functional language that can actually
340+use its referential transparency directly. So their relationship
341+is symbiotic, not competitive at all.
342+
343+The closest thing to a general-purpose competitor that Urbit has
344+is Sandstorm. Sandstorm, which by the way rocks, is also a
345+personal server built around a network protocol.
346+
347+But Sandstorm and Urbit compete in the way that, on the PC, the
348+OS and the browser compete. In theory, the OS could solve the
349+problems that the browser solves; or the browser could be the OS.
350+In practice, Windows is a great OS to run a browser on.
351+
352+Similarly, a world in which Sandstorm takes off is an awesome
353+world for Urbit, because everyone who has a Sandstorm instance
354+has a great platform for running Urbit on. Urbit on Sandstorm
355+will be a sort of "double-hulled" personal server, safer and more
356+friendly than either system alone.
357+
358+Sandstorm and Urbit have very different approaches to network
359+identification; Sandstorm uses capabilities, Urbit identity.
360+Broadly speaking, we believe, capabilities are optimal for
361+expressive power; but identity is optimal for the UI of the
362+common case. We'd need to see the Powerbox, Sandstorm's UI, more
363+fully fleshed out to understand its UI approach better.
364+
365+## Urbit doesn't have enough planets for every human {% #planet %}
366+
367+A 32-bit planet is a tool, not a toy. Like a car, it's a device
368+for a responsible and independent adult. There aren't 4 billion
369+cars in the world, nor 4 billion independent adults.
370+
371+If you aren't an independent adult, and you don't need or even
372+shouldn't have unconditional digital freedom (no one's 8-year-old
373+daughter needs unconditional digital freedom), a moon from
374+someone else's planet is fine. (Even most of today's independent
375+adults don't complain enough about being Facebook's moons.)
376+
377+And limiting the supply of anything doesn't create a shortage.
378+It sets a price. Ideally, in the long run, we think a planet
379+should cost about $10. This could be off by an order of
380+magnitude either way, and it wouldn't be the end of the world.
381+
382+If a planet costs $10, that means you paid $10 to get a planet.
383+A planet with no reputation has a positive reputation, because
384+someone paid $10 for it and hasn't yet done anything wrong.
385+Positive default reputation is the single quality that makes a
386+social network social.
387+
388+There is always a tradeoff between free speech and free beer.
389+Urbit will always choose free speech.
390+
391+## Cloud computing is inherently non-private. {% #pwned %}
392+
393+_TLDR_: a general-purpose cloud computer is much, much more
394+private than a special-purpose cloud computer. In general, a
395+cloud VM is secure against corporations but not governments.
396+With a global adversary, compute in your closet -- or even on
397+your body.
398+
399+One reason we want the decentralized Internet is that we're tired
400+of giant corporations spying on us. Think about it this way:
401+Amazon is Netflix's main competitor. And yet, Netflix runs its
402+whole operation on AWS. Why is Netflix sure that Amazon won't
403+spy on it?
404+
405+A general-purpose virtual machine is special from a privacy
406+standpoint, just because it's commercially realistic to design
407+terms of service that prevent the host from peeking and poking at
408+the customer's machine. Crossing this moat is technically
409+nontrivial and can't possibly happen by any reasonable accident.
410+No hosting contract could contemplate it.
411+
412+Whereas when your cloud computer is a special-purpose machine --
413+just a database row on some corporation's mainframe -- there is
414+no way these services can promise not to handle your data.
415+Handling your data is _what they do_. On a special-purpose
416+server, the concept of privacy is not even defined.
417+
418+Where even a general-purpose server falls down is where the user
419+has a sovereign adversary, which can secretly violate explicit or
420+implicit hosting contracts. Users with a sovereign adversary
421+must rely only on their own physical security.
422+
423+However, most users don't have a sovereign adversary. And those
424+who do maximize their "herd immunity" if they can use the same
425+protocols as those who don't. Otherwise, the adversary could
426+simply focus on everyone who uses the secure protocols.
427+
428+Also, the portability of a cloud server image is critical. Of
429+course, since Urbit is formally specified, it's trivially
430+portable. In fact, one strategy against sovereign adversaries
431+may be continuous rotation between hosts, like an MX missile.
432+
433+## Urbit will never be able to call any existing code. {% #code %}
434+
435+_TLDR_: neither will Javascript. And dear Unix, the browser
436+does not miss interacting with your `$LD_LIBRARY_PATH` at all.
437+
438+You can't talk to the OS or use system libraries from Javascript.
439+Therefore, there is no point in having any kind of gateway,
440+compatibility bridge, native methods, or other interface between
441+Javascript and C.
442+
443+When in doubt, remember that Urbit is "the browser for the server
444+side." It plays by the same general rules. Isolation means
445+isolation.
446+
447+## There's no way Urbit will ever be adopted. It's too weird. {% #weird %}
448+
449+_TLDR_: Urbit adoption is designed to be driven by ordinary end
450+users. Urbit isn't ready for ordinary end users yet. We're
451+working on it -- come help.
452+
453+Right now, Urbit is a developer tool. Or rather, a developer toy
454+-- since the only thing it's useful for is developing Urbit. It
455+also could be a much better toy. We're working on that too.
456+
457+But it's absolutely wrong to think of Urbit being adopted as a
458+developer tool in the conventional sense. If you think this is
459+almost impossible, you're right.
460+
461+If we look at the way most successful platforms are adopted,
462+they're not adopted for their own virtues. They're adopted
463+because they're part of a larger solution. It's very hard to
464+displace a native component of an existing platform. Urbit is
465+not trying to do this.
466+
467+C is a better language than Pascal, but it didn't beat Pascal
468+because it's a better language. C beat Pascal because C was the
469+native language of Unix, and people wanted to program in Unix.
470+People don't use Javascript because Javascript is a great
471+language, but because it's the native language of the browser.
472+Replacing the native language of a platform may be doable -- but
473+it's incredibly hard.
474+
475+Hoon is not competing with C, or even Haskell, as a Unix
476+programming language. The only reason to program in Hoon is that
477+it's the native language of Urbit. Urbit is not competing with
478+node.js or Rails as a Web backend. The only reason to run Urbit
479+is to run a personal server.
480+
481+Nock is cool, but it only gets adopted if Hoon gets adopted.
482+Hoon is cool, but it only gets adopted if Urbit gets adopted.
483+Urbit only gets adopted if it's useful as a personal server for
484+human beings -- most of whom won't be Hoon programmers, or
485+programmers at all.
486+
487+## Hoon is too weird. No one will be able to program in it. {% #program %}
488+
489+_TLDR_: Hoon is ridiculously simple. Our documentation and
490+tooling are just immature.
491+
492+It's pretty fair to assume that (a) functional programming is
493+hard and weird, (b) Hoon is weird even for a functional language,
494+so (c) Hoon must be hard-squared.
495+
496+Actually, Hoon is weird even for a functional language because
497+it's an attempt to remove the hardest things about functional
498+programming: category theory, lazy evaluation, and gratuitous
499+abstraction. To know a language is to know what the compiler is
500+doing; all the semantics of the Hoon compiler fit in 2000 lines
501+of code.
502+
503+It's too easy for us to wind up living in Isaac Asimov's Trantor,
504+a world in which everything got invented thousands of years ago
505+and the idea of new technology is just weird and scary. History
506+isn't over yet, and nor is technical history.
507+
508+New things are harder to learn than old things. We ask smart
509+high-school students to learn calculus. Think about how much
510+harder it was for Newton and Leibniz to invent calculus, or for
511+their first students to pick it up. Hoon is nowhere near as hard
512+as calculus.
513+
514+Most of the difference is just the collective certainty that our
515+society conveys to a high-school student that calculus is
516+learnable. When you're learning Urbit, you don't have this
517+collective knowledge; so you don't have the confidence that the
518+problem is solvable. Confidence makes a huge difference.
519+Moreover, any bug or glitch in the developer experience destroys
520+this confidence and takes a long time to heal.
521+
522+Yes, we know: Hoon remains quite hard to learn. Again, we have
523+no reason to think this problem isn't solvable. Public
524+enlightenment remains our main priority.
525+
526+## Urbit programmers are stuck with Hoon. {% #stuck %}
527+
528+_TLDR_: patience, grasshopper.
529+
530+There's quite a straightforward way to implement any perfectly
531+specified language with a reliable interpreter in Hoon. First,
532+write an interpreter for that language in Hoon. Second, jet that intepreter function with the existing implementation.
533+
534+It is not clear that Javascript is _quite_ well-defined enough
535+for this treatment. But Lua probably is.
536+
537+## Ordinary users will never be able to manage an Urbit server. {% #user %}
538+
539+_TLDR_: Urbit's technical simplicity has always been designed
540+to drive human usability. But the polish is the last thing that
541+goes on. So we can't evaluate this claim right now.
542+
543+Right now, Urbit is only for geeks. You already need to be able
544+to wrangle a Unix machine to run it. What's the point?
545+
546+This Urbit isn't the real Urbit. It's an early milestone on the
547+way to the real Urbit.
548+
549+The real Urbit -- for normal human beings -- is a hosted service.
550+Getting a planet is as easy as signing up for Facebook. Probably
551+many users will think of it as another web account. They might
552+not even know it can run more apps than the ones they use.
553+
554+A deterministic, persistent cloud computer is something different
555+from a traditional server. Normally when we think of a server in
556+the cloud, we think of it like a live animal -- a creature that
557+needs to be cared for, fed, and herded. A file in the cloud is
558+more like a rock -- you can forget about it for ten years.
559+
560+An urbit is a general-purpose computer, but it doesn't even have
561+the concept of a reboot. It upgrades itself. If you don't feed
562+it any packets for ten years, then turn it back on, it will spend
563+a day or two upgrading itself, then be back to normal. Maybe
564+it's something in between a rock and an animal -- a cactus?
565+
566+Another huge difference versus an Internet server is that we're
567+confident that Urbit's limited supply of identities will make it
568+easy to keep abusers off the network. So far, so good -- but of
569+course, no one abuses a young network.
570+
571+The bottom line is that managing your urbit has to be as easy as
572+managing your iPhone. Normally, it consists of deciding what
573+apps you want to be running, and how much you trust them.
574+Resources can't be free, so sometimes you have to play memory
575+police. Humans have shown that they can handle these tasks.
576+
577+Our '70s OSes and networks, which were great designs in their day
578+and have matured into excellent industrial tools, give us a
579+totally misleading impression of how hard it should be to manage
580+a general-purpose computer. Computing isn't scary or dangerous.
581+Unix and the Internet are scary and dangerous. That's fine for
582+an industrial tool, but not a personal tool.
583+
584+## Urbit has no killer app. {% #killer %}
585+
586+_TLDR_: the killer app is personal API aggregation.
587+
588+It's a truism that any new platform has to be fundamentally much
589+better at solving some problem than the mature platform it seeks
590+to replace.
591+
592+We can look at Urbit's killer app from two perspectives: as a
593+developer, and as a user.
594+
595+From the developer's perspective, Urbit's advantage is that it's
596+a network stack which provides exactly-once delivery of typed,
597+validated, transactional, encrypted and authenticated messages.
598+The difference between an Urbit API and a REST API is like the
599+difference between a paved road and a dirt road. On the other
600+hand, you do need to learn a new functional language.
601+
602+From the user's perspective, there's one task that any personal
603+server can perform, that can't be performed by any Web service:
604+unrestricted API aggregation.
605+
606+Well before Urbit is ready to _replace_ any conventional web
607+services, it should be ready to _command_ them in place by API.
608+(Or if needed, by scraping.) If all you care about is being in
609+control of your own data, it's fine to leave it in the hands of
610+these services, as you have the API secrets to get it out.
611+
612+Managing a set of security connections to your existing services
613+is one of the first important tasks of a modern personal server.
614+This is a stateful task that typically requires both a durable
615+API key and a temporary OAuth token. APIs change all the time,
616+so connection maintenance also requires evergreen updates.
617+
618+The origin of this API key will vary, but usually the best way to
619+set it is BYOK: the user registers their own urbit as an "app."
620+And the neat thing about having your own API keys, for multiple
621+services, on a single general-purpose computer, is that none of
622+these services really has any practical way to control what you
623+do with your own data.
624+
625+Terms of service which constrain the use of data (as opposed to
626+the abuse of the service) simply aren't realistic and will no
627+longer apply. This enables a variety of novel user experiences
628+which aren't implementable as traditional web services, and also
629+aren't available via conventional third-party API aggregators.
630+
631+Also, since Urbit is after all quite immature, it doesn't make
632+much sense to restrict this security state to code within Urbit.
633+The Urbit interpreter `vere` runs as a Unix daemon that
634+implements the FUSE user-level filesystem protocol, and maps the
635+data on your services into the Unix filesystem. For example, one
636+of our demos lets you `ls` your GitHub issues.
637+
638+So it's straightforward to build, for instance, a Python app that
639+uses Urbit as a gateway to mash up a bunch of web services. As a
640+Unix programmer, you might even just regard Urbit as a generic
641+Web API gateway daemon, without worrying about its internals.
642+
643+We have other ideas for initial killer apps. But this, we feel,
644+is the best one. API libraries for `npm` et al abound.
645+Stateful, self-updating, generic API aggregators with FUSE
646+integration, also integrated with a reactive web server, are
647+rarer.
648+
649+## Urbit is sniffed at by Houyhnhyms. {% #horse %}
650+
651+It's difficult to categorize [this awesome
652+essay](http://ngnghm.github.io/blog/2016/06/11/chapter-10-houyhnhnms-vs-martians/)
653+in a single bullet point. So I've saved it for last.
654+
655+When reading this essay, it's important not to forget the amazing
656+absence of genuine, mutually critical discourse in computer
657+science (as in most sciences today). You never hear what Swift's
658+designers think of Go, or vice versa. And critical public
659+discourse decreases, not increases, with increasing academic
660+legitimacy.
661+
662+The basic test of any field purportedly scientific in nature is
663+whether its researchers are genuinely interested in each others'
664+work, and willing to share these genuine responses publicly. If
665+this practice does not exist, the field may still be useful
666+and/or interesting. But it is not science.
667+
668+What's awesome about Fare's essay is that he's _doing it right_.
669+All the actual details are irrelevant. And mostly wrong. But
670+that's of very little importance compared to _doing it right_.
671+
672+Anyway, we've already addressed the idea that jets are a sham.
673+Some other points:
674+
675+### Event-sourcing and/or caching is a pattern, not a layer
676+
677+Fare' is perfectly right that "one size does not fit all" in
678+persistence. Generally, Urbit uses event-sourced persistence.
679+
680+But it has multiple layers of event-sourcing: in the definition
681+of Urbit itself; in the application sandbox vane (Gall), and in
682+the application itself. Urbit also has a completely orthogonal
683+revision control system (Clay).
684+
685+And there is not a single cache across the whole system, though
686+arguably there should be; for instance, the functional build
687+system (Ford, which Fare' the master of build systems might
688+appreciate) has its own internal cache.
689+
690+It is a common mistake to confuse a design pattern with a layer
691+or feature, and equally fatal whichever direction you fail.
692+
693+### Let's be clear about why DSLs suck
694+
695+DSLs suck not because they are difficult to newbies in the base
696+language. DSLs suck because every time a programmer, even one
697+_experienced_ in the base language, comes into a new codebase or
698+project, she has to learn a new custom language.
699+
700+You need enormous wins to justify this cost. It's the goal of
701+the base language designer to preempt these wins, creating a
702+language which is almost never so tiresome and full of
703+boilerplate that it requires a DSL or template layer.
704+
705+Hoon is almost entirely made of macros -- but they are internal,
706+fixed, built-in macros (with no gensyms). This fixed set of
707+macros is essentially enough. Occasionally we want to add one or
708+two. But we never, ever pine for context-dependent macros.
709+
710+### Determinism is not consensus, and is not constraining
711+
712+Fare' is totally right that an urbit's data is meant for itself
713+alone. In fact, an urbit has the right to compute incorrectly if
714+it wants. We go to considerable lengths to ensure that you can't
715+gain any particular advantage by incorrect computing.
716+
717+The whole point of Nock is that it's so low-level that there is
718+no conceivable advantage in upgrading it. Divergence is just
719+pointless. This is not a question of network integrity, just of
720+practical standardization.
721+
722+This consistency stops at Nock. Without anyone violating the
723+correctness of their lifecycle functions, anyone or everyone in
724+Urbit could replace Hoon with Javascript. Determinism does not
725+cramp Urbit's semantic style in any way, shape or form.
content/blog/community-spotlight-the-portico.mdnew file+138
@@ -0,0 +1,138 @@
1++++
2+title = "Community Spotlight: The Portico"
3+date = "2021-05-03"
4+description = "Interview with The Portico founder Josh Reagan"
5+
6+[extra]
7+author = "Matt"
8+ship = "~tirwyd-sarmes"
9+image = "https://media.urbit.org/site/posts/essays/orthodoxchurch.jpg"
10++++
11+
12+
13+
14+_One of the most striking things about Urbit is the ideological diversity between communities. The Community Spotlight blog series will focus on various Urbit communities via interviews with founding members._
15+
16+For the first week of the Community Spotlight series, I (~tirwyd-sarmes) will be speaking with Josh Reagan (~taglux-nidsep). Josh is the founder of The Portico, an Urbit community of Eastern Orthodox Christians.
17+
18+The Portico is a very active group with conversations taking place over multiple channels. There are channels for posting Orthodox iconography, discussing the broader Christian culture war, and just talking about Orthodoxy in general. Of particular interest is Josh’s “Euthyphro” blog series which investigates the relationship between logic and the Orthodox faith. This is a topic that Josh is well qualified to talk about: he has a PhD in Philosophy from Rice University. His dissertation on the epistemology of logic and truth-preservation was titled "Knowing Your Limits: Logic for Limited Beings”. Josh is also the co-author of a forthcoming textbook on formal logic.
19+
20+To read Josh’s blog is to be inducted into two esoteric traditions: theory of logic and Orthodox theology. With titles like “St. Gregory the Theologian and the Liar Paradox” and “The Existence of Abstract Objects”, Josh does not pull punches.
21+
22+Accordingly, our conversation focused on the idiosyncratic and niche community that The Portico is home to. There, you won’t find cussing or much talk about “life partners”, but you will find cutting critiques of liberalism and the best way to raise Orthodox children.
23+
24+As other users have pointed out, Urbit is pre-[Eternal September](https://en.wikipedia.org/wiki/Eternal_September). In fact, there’s some hope that the very nature of Urbit, how it tries to protect the sovereignty of niche communities via decentralization, might foil the Eternal September phenomenon. If Josh’s community persists, it will be a testament to both Josh and the decentralized Urbit network. As of now The Portico is a refreshing, perhaps jarring (as Josh might say), reminder of what the internet looked like back in the early days—a place for those who are different.
25+
26+I encourage you to take a look. Find The Portico at ~topnup-firber/the-portico.
27+
28+\-\-\-\-
29+
30+**Do you see any connection between Rod Dreher’s _The Benedict Option_ and your community on Urbit? Dreher sees a need for American Christians to create self-sustaining communities outside of the mainstream to protect the Christian religion and culture.**
31+
32+It’s tough to say with certainty—I’ve never read _The Benedict Option_.
33+
34+A few years ago, while he was writing the book, I was a regular reader of Dreher’s blog. From his descriptions there, I was never clear about what exactly he was proposing. Much of his “clarification” came by way of metaphor: don’t “run for the hills”, but stop “shoring up the American imperium”. I didn’t read his book because I didn’t have much confidence that he would be especially precise or insightful.
35+
36+[There is an interesting review I’d recommend](https://handleshaus.wordpress.com/2020/10/06/review-of-rod-drehers-live-not-by-lies/), however, of his later book, _Live Not By Lies_. I believe it accurately characterizes the scale of the threat Christians will soon face in this country.
37+
38+My upbringing was conservative Christian and self-consciously counter-cultural. I've inherited that understanding of what it means to be a Christian in an increasingly secular world. It comes naturally to me, so I find it obvious that Christians should form self-sustaining communities. But the details matter. What do such communities look like? How do we secure the freedom to pursue such communities? How do we sustain them, when myriad external forces seek to undermine them? How do we solve the long-term problem of the declining cultural importance of Christianity (which surely erodes the plausibility of our religion to many, even to some of those with sympathies toward it)?
39+
40+I don’t claim to know the answers to these questions.
41+
42+One kind of answer is that we should redouble our efforts to support and maintain a religiously and morally neutral liberal political order, which leaves room for subcultures to live and self-regulate as they wish. I disagree. Those who support a kind of “neutral” liberalism view it as an attempt to go “meta” and rise above various parochial metaphysical, moral, and religious disputes. I view this as a cop-out, a refusal to grapple with the most important questions.
43+
44+Does the liberal have metaphysically-rooted moral reasons for going “meta”? If so, then he’s just another sectarian and he should be honest about it. The only difference is that his team has had the whip hand for the last several generations. On the other hand, if the liberal claims no underlying metaphysical justification then his project can succeed only to the extent that he can arrange and adjudicate unprincipled (and therefore ad hoc) agreements between otherwise hostile moral communities. But how stable can such an arrangement really be?
45+
46+Orthodox Christians have theologically rich, metaphysical foundations for their social and moral teachings. With these we can form healthy, thriving, and growing communities. We can do so even under actively hostile political orders. If the early Church could make it under the Romans, so can we today. But it’s going to be difficult and sound judgment is necessary. Unfortunately, we lack strong leadership and that leaves us vulnerable. If we stay uncoordinated we dissipate our energies needlessly. If we latch onto the wrong leaders we can be led astray.
47+
48+The challenges are immense. There is no technological solution. Even so, I’m an Urbit early-adopter for a reason. Over the years I’ve come into contact with a number of Orthodox and Ortho-curious Urbit followers. Why not try to bring them together in an Urbit group?
49+
50+As far as I know, no one in the group is clergy. We’re all just a bunch of laymen with no authority to do much of anything. But I’d like to think we can still contribute in some way. I have an academic background in analytic philosophy so my inclination is to emphasize theory, but we have room for a bit of everything. Someone in the group wrote a script to take the texts of various Church Fathers and convert them to audio using AWS Polly. Those turned out pretty well!
51+
52+At times I entertain ambitions to do a bit more, but for now perhaps it’s better to keep expectations in check. If nothing else, we can read and discuss the Scriptures and Church Fathers together, and try to understand better how to apply and live out their teachings. As we continue to grow the community and develop a consistent internal dynamic perhaps opportunities will arise that aren’t yet on the horizon. One thing I can say is that I’m committed to keeping the group active and growing.
53+
54+**I’d like to talk about your blog on The Portico. It combines two of your main interests: logic and theology. In broad strokes, do you think theology and logic are compatible? What is the relevance of this intersection to both of these disciplines?**
55+
56+I feel obligated to answer this question in two ways.
57+
58+(1) If by “logic” you mean “first-order predicate calculus”, then I think there’s no special conflict between logic and theology. There are certain puzzles about their relationship, but similar puzzles exist between logic and other disciplines. Theology isn't especially endangered.
59+
60+For example, in the 1930s, Alfred Tarski proved his famous Undefinability Theorem. Crudely put, it says that a plausible truth predicate cannot consistently be contained in any formal system with axioms strong enough to model arithmetic. Superficially it seems like our options are (a) get rid of the concept of truth, (b) get rid of arithmetic, or (c) throw away parts of logic until all inconsistency disappears.
61+
62+None of these options is appealing. Tarski came up with a solution that mostly satisfies many logicians: reduce the concept of truth to “truth in a language” and forbid any language from containing its own truth predicate. If you want to talk about truth in a language L-1, you have to do it from a “metalanguage”, L-2.
63+
64+Is Tarski’s definition of truth in a language the definitive solution for preserving truth, math, and logic? Perhaps not many philosophers think so, and there’s a massive literature in which logicians have attempted to improve on or extend his results.
65+
66+Sometimes people seem to think formal logic is an infallible gift from heaven that must always be right. Kant said in the _Critique of Pure Reason_ that formal logic is essentially a completed field. In fact, [the logic of his day](https://en.wikipedia.org/wiki/Port-Royal_Logic) was an early-modern Cartesian variation of a medieval scholastic synthesis of ancient Stoic and Aristotelian logics. Roughly 100 years after Kant’s first critique was published, C. S. Peirce and Gottlob Frege independently discovered first-order mathematical logic as we know it today, inaugurating the greatest advance of logic since Aristotle. Kant was wrong.
67+
68+Mathematical logic is a convenient, generally reliable, man-made tool that, when used carelessly in certain untamed domains, can lead one astray. Probably most people reading this are familiar with such puzzles as the Liar paradox. When one understands that logic is not a completed science, and perhaps never will be, there is less reason to worry about whether it can be used to nuke entire disciplines, like theology.
69+
70+For more on this topic, see the blog post in my Urbit group: “St. Gregory the Theologian and the Liar Paradox”.
71+
72+(2) There is perhaps a deeper challenge than the one I’ve just sketched. The Stoics used the term “logic” to encompass what we might today call “epistemology”. If the word “logic” is meant in some such broad and normative sense, then we may restate the challenge as one about rationality and theology. Is it irrational to pursue theology in our modern age?
73+
74+As an undergraduate under the influence of Kierkegaard, I was attracted to a romantic, vaguely irrationalist notion of faith. Dawkins-mania was at its peak and I was disgusted by the pop-rationality (or was it empiricism?) of his annoying followers. Their view seemed to be that rationality just means “following the evidence”. The raw evidence is foundational, and theories are built atop by generalizing from the evidence. The ghost of logical positivism is with us even now.
75+
76+I was dimly aware that Quine and others had made it difficult to sustain epistemic foundationalism. However, being unable to supply a more clear and cogent notion of rationality, I became skeptical of the idea altogether. But I went too far.
77+
78+Instead, the proper response is to develop a superior account of rationality. Readers can probably guess where I went looking!
79+
80+The word “logic” comes from the Greek “λόγος”. This is also the word used to describe Jesus Christ in the Gospel of John: “In the beginning was the Logos, and the Logos was with God, and the Logos was God.” This connection is not merely etymological.
81+
82+For many ancients, the term “λόγος” meant something like “divine principle”. You might think of it as akin to a law of nature, but with stronger theological connotations. Christians appropriated this term and made it rather more exalted: the Logos is begotten of the Father, and yet somehow one with Him.
83+
84+We are told that all things come into being through the Logos (John 1:3), giving Him an intimate relationship to the whole of creation. He gives structure and order to all created things, and in His divinity He understands them as so structured and ordered. He is also sinless, perfectly holy, and good. In Christ we have a perfect unity of the knowledge of all truth and righteousness.
85+
86+Man was created in the image of God, which means that we bear a likeness to Christ. And we are commanded to realize that likeness with ever greater fidelity (Romans 8:29). The Church calls the pursuit of this likeness [“theosis”](<https://en.wikipedia.org/wiki/Theosis_(Eastern_Christian_theology)>).
87+
88+Thus we have the explanation of all normativity, according to Orthodox Christianity. In moral matters we must take on the holiness of Christ. In epistemic matters we aspire to the wisdom and knowledge of Christ, which includes an understanding of the whole created order. Socially we (the community of believers, i.e. the Church) are called to be in ever greater communion with God, cooperating with His work just as the Son cooperates with the Father.
89+
90+Sadly we are conceived in sin and ignorant; hence the need for redemption by Christ.
91+
92+Accordingly, my understanding of what it means to be rational is just to be Christ-like. The only perfect exemplar of reason, so construed, is Christ Himself. Any deviation from Him is irrational. What could be more logical than to be conformed to the Logos? But we cannot attain rationality without redemption. Hence we cannot become rational without first being saved from sin.
93+
94+Doubtlessly many will find all of this too much to take, just too implausible. What about the development of mathematics, or the advances of the sciences? These are canonically ennobling, intellectual achievements. Jesus wasn’t a mathematician or a scientist! Nowhere in the Scriptures is He recorded as having applied Bayes’ theorem.
95+
96+Undoubtedly my construal of rationality de-emphasizes the pursuit of knowledge by labeling it as merely one of several normative ends. To seek knowledge without seeking holiness is to be understood as dangerously unbalanced. To try to attain holiness and knowledge without communion with God is arrogant.
97+
98+On the other hand, we need not exaggerate matters. St. Paul affirms the need for specialization of labor within the Church (1 Cor. 12). There is room for some to specialize in intellectual endeavors, so long as they act in a cooperative setting in which the other virtues are pursued as well. (Nor should anyone neglect the development of such virtues in himself.) Mathematicians and physicists are more than welcome in the Church.
99+
100+According to this (all too briefly put) theory of rationality, there can be no conflict between ‘logic’ and theology. Theology is compatible with rationality because the account of rationality in question derives from a theological tradition. Naturally I’ve only given a sketch; much more could be said. But even if some readers are put off by the theory presented here, I hope it’s at least clear that there are conflicting notions of rationality. Anyone who wants to be rational confronts the task of figuring out which theory of rationality is correct.
101+
102+**In terms of community moderation, The Portico follows norms that are quite different than other online communities, often times quite drastically. For instance, living with women that you are not married to, is not something that should be talked about lightly. Can you talk about the importance of norms and how they relate to a healthy community?**
103+
104+Orthodox Christians are not commanded to “get along” with the rest of the world (John 15:18-25). We’re different, and our norms of interaction should likewise differ from those of outsiders. There is no one, monolithic “Orthodox culture”, but there are standards governing which local expressions of culture are legitimate and which are sinful. We should live in a way that enables and promotes holiness and discourages sin.
105+
106+We have rules that may seem unusual from the outside. I don’t permit profanity, lewd jokes, or irreverent comments about God. In your question you mention a living arrangement that is prevalent in the world. Another rule I have is that we shouldn’t talk causally about sinful practices or lifestyles as if they are unremarkable parts of ordinary life. If Orthodox Christianity is true then such things aren’t minor peccadilloes. They’re spiritually destructive. The marriage-bond sanctifies activities that would otherwise be sinful.
107+
108+If someone wants to analyze what is destructive about men and women living together before marriage, we’re open to that. But if you want to be affirmed in your sin, we’re not the place for you. Anyone of any religious creed is welcome to show up—but as a guest in an Orthodox Christian community. Hosts should be courteous to guests, but my first priority is not to make you feel good about your choices. We’re here to encourage each other, learn, and grow spiritually as Orthodox Christians. Naturally that means a little gate-keeping may sometimes be necessary if someone ever comes along who doesn’t share those goals. Being different is difficult and takes work.
109+
110+In a way the cultural contrast is meant to be jarring. It can force you to confront moral and cultural presuppositions that you didn’t even know you had. When you become aware of the wider choices of culture available to you, you become free to look with a critical eye on the culture you’ve hitherto taken for granted. I think anyone could see how that might be liberating, even before considering the particulars of the cultures in question. Of course, as an Orthodox Christian, I think we have a good case to make about the particulars of our subculture.
111+
112+I’ve never had to kick or ban anyone from the group. The group is relatively small (~180 people at the moment) so that probably helps. The vast majority of conversations are relaxed and friendly. Occasionally there are intense debates about one issue or another but I enjoy it, as long as it doesn’t become bitter or the primary mode of discourse. But everything ought to be done in a spirit of truth-seeking, not of one-upmanship.
113+
114+**The fact that The Portico can exist side-by-side with atheist communities on Urbit is pretty striking. On Urbit, a user is able to create niche communities and governance structures and yet still participate in a larger network. In other words, Urbit is trying to thread the needle between sameness and difference through federation at multiple levels. It seems to me that modern culture has become homogeneous due to an inability to maintain, or distinguish between, different communities. People who have nothing in common are forced to engage as if they were roommates, while those who are similar have trouble creating their own home. In other words, what is the role of community formation in the modern world and how does it connect to your critique of liberalism? Does Urbit have anything to say about this?**
115+
116+As I said in an earlier response, I see the liberal project as more or less an attempt to sidestep (not solve) difficult metaphysical and religious disputes between various distinct moral communities. Liberals have tried several methods of governance to achieve their ends. We can divide such attempts into two broad categories: centralized and decentralized.
117+
118+Social media companies in the US confront similar governance challenges, so we can analyze them in similar terms.
119+
120+A social network like Facebook takes a centralized approach. Zuckerberg spoke early and often of his desire to connect people and “bring the world closer together”. There was a sense that if people from various communities could get to know each other a little better, we would see how much we have in common and make progress toward some kind of universal cosmopolitan consensus.
121+
122+But that didn’t happen. With centralized social media you’re practically guaranteed to interact with people whose moral and metaphysical commitments are sharply at odds with your own. As a result, you face a persistent, nagging risk of conflict. Without warning, a friendly disagreement can explode into an all-out flame war. Most choose one of two basic approaches for dealing with this threat:
123+
124+(1) You live a compartmentalized life. You keep your moral and metaphysical commitments to yourself and cultivate a culturally homogenized persona for your social media activities. No one disagrees with you because there’s nothing to disagree with.
125+
126+(2) You can enlist to fight in the culture war and display your regimental colors with pride. And because you take your smartphone everywhere you’re always on the front line.
127+
128+These aren’t the only options, of course. With some combination of charisma, patience, and grace you can be relatively open about your beliefs without getting into too much trouble. But even if you have the talent to pull it off, it takes time and energy. Many of us aren’t willing to go to all that trouble. Social media is supposed to serve us, not the other way around.
129+
130+Urbit is decentralized which, in my opinion, means that it isn’t really a network in the way that Facebook is. I see Urbit as more of a network platform. The users create the networks, or migrate them in from elsewhere. We’re all using Landscape and running our VMs on Nock, so obviously there can be interaction between different communities. But anyone who doesn’t want that cross-community interaction doesn’t have to have it.
131+
132+I’ve followed Urbit’s progress since 2016, so I’m plugged into groups with other Urbit people I’ve come to know over the years. Other than that, however, I don’t know much about who’s out there. It’s not like The Portico is in one neighborhood and the atheists are in the next neighborhood over. There’s a real sense in which we’re not even on the same network—different Urbit communities share a common protocol, but a protocol isn’t a network.
133+
134+Some people may want to see a little of everything. If atheists want to join our group they’re welcome to do so! We’ll be friendly. I don’t seek out their groups, though.
135+
136+One virtue of decentralized social media is that it offers a totally different set of trade-offs with respect to how you share and act on your beliefs. What if you could talk earnestly about philosophy and religion without having to worry about alienating many of your friends and family? I guess that’s somewhat possible on Facebook—do they still have “groups”?—but Urbit was designed for it.
137+
138+Having said all that, I don’t think decentralization is a panacea. Even if Urbit takes off, it will likely face problems that are difficult to anticipate now. My hope is simply that Urbit’s trade-offs are healthier than the ones we’ve had before.
content/blog/convivial-networks.mdnew file+27
@@ -0,0 +1,27 @@
1++++
2+title = "Convivial Networks"
3+date = "2022-05-27"
4+description = "Like the relationships that we build within them, our platforms should yield satisfaction precisely because they’re non-trivial; they demand effort, which is another way of saying they require engagement with the world."
5+[extra]
6+author = ""
7+ship = "~witwyt-widlyr"
8+image = "https://media.urbit.org/blog/convivial-computers.jpg"
9++++
10+
11+
12+
13+In 1989, when the idea of forging a community online was still niche enough to feel like a radical dream, an essay in the inaugural issue of cyberpunk magazine Mondo2000 already had the audacity to ask: have we missed the revolution? Penned by Lee Felsenstein, the text takes stock of the potential, promised by the advent of the personal computer, for new technologies to contest control and engender greater forms of interpersonal connection. This opportunity, of course, was not a given. “If people can gain control over their own channels, and have the technological means available to do that directly”, he wrote, “then they can control their own communities.” If the revolution in question was not to be missed, then ownership and control over one’s own means of communication were central affordances of any technology that would lend itself to genuine community-building, or what Felsenstein called “convivial” interaction.
14+
15+His use of that term brings to mind Ivan Illich, whose “Tools for Conviviality” expressed the need for technology that can be grasped and reconstructed – tools of “high, independent efficiency” that a user could take responsibility for. Convivial tools are the opposite of industrial or institutional; Illich argued for making things usable and re-inserting the personal dimension into their construction. This was 1973, and he was talking about urban planning, but the resonance with Felsenstein’s point doesn’t seem so far a reach. If personal computing was indeed to offer any radical possibility, and especially any claim to agency over the ability to build and be in communities, it ought to be grounded in simple, accessible tools that we ourselves can operate.
16+
17+From a present standpoint, we could understand both Illich and Felsenstein’s texts as calls for human-scale technology. Simplicity is a central ingredient of this prescription; it’s hard to feel much ownership over something that one can’t use, manipulate, or maintain without deferring to an external expert every time something needs tinkering under the hood. In the decades since these treatises’ publication, personal computing has become totally commonplace, yet, with the elaboration of social networking and Cambrian Explosion of communication tools brought about by Web 2.0, it feels increasingly, and noticeably, less convivial.
18+
19+Why did this trajectory – and not one of “personal computing leagues” and ad-hoc hacking, of the nature Felsenstein and his _Mondo_ co-conspirators so passionately envisioned – take hold? My hypothesis is that, as [Rich Hickey](https://www.youtube.com/watch?v=SxdOUGdseq4&ab_channel=StrangeLoopConference) lays out, simplicity actually demands a lot of _work_. In a culture of convenience, the concerted and enthusiastic effort necessary to achieve real agency over our tools can, paradoxically, come across as prohibitively hard. Yet conflating accessibility with frictionlessness works to our collective detriment. The technologies capable of fostering conviviality _ask something of us_: engagement, patience, the will to understand. In our offline social lives, these are accepted as necessary labors of love: intimacy without investment is an impossible, irresponsible fantasy. To invoke the oft-quoted Simone Weil, “attention is the rarest and purest form of generosity.”
20+
21+And as we well know, in the present mediatic environment – tellingly termed the “attention economy” – the dynamics of directing our focus online are deeply broken. Is it any surprise that, on the platforms that have pioneered a business model out of stealing and selling that attention, community and conviviality feel so hard to come by? Effort, labor, and understanding are fundamental to relationships online and off. But the spaces where we’re meant to share these qualities online disingenuously sell us (or, rather, do they _buy us?_) with promises of ease that amount to empty calories, or worse.
22+
23+By removing friction from the equation (think: Log In With Facebook), they wall us in and transform our connections, conducted within their borders, into spaces of extraction. The mainstream communications platforms we have access to today are marketized to the hilt. Our interactions and the relational graphs they chart – in short, the tender data of our sociality – is made into fodder for surveillance capitalism. When nothing short of interpersonal intimacy is on the line, we ought to be very concerned with what is being occulted away in the name of convenience.
24+
25+If we want to create technologies that are conducive to meaningful community, where “engagement” is not just a quantitative metric or empty piece of advertising parlance, then, we need to re-orient our values beyond “ease of use”. Like the relationships that we build within them, our platforms should yield satisfaction precisely because they’re non-trivial; they command effort, which is another way of saying they require engagement with the world. Attention; generosity. In step with these values, I’m inspired to ask: what would a convivial social network look and feel like? Human-scale, peer-to-peer, open-source, and non-extractive are all descriptors that come to mind. You can probably anticipate where I’m going with this: a network with many of these merits exists today, ready to be used, tinkered with, and built on top of, and if you’re reading this, you’re probably familiar with it.
26+
27+Getting started on Urbit takes some work: investment in address space; effort to acquire a planet; possibly even bearing with some confusion during the booting process if you, like me, are an armchair network theorist who often shies away from the technical. But these costs are up-front, not black-boxed out of sight or hidden in an epic-length user agreement. Once it’s up and running, it even feels, dare I say, easy, though the healthy extension of my comfort zone that getting onto the network entailed – especially when I joined in November, a few months shy of the [L2 rollout](https://urbit.org/using/id/layer-2-for-planets) – sticks in my mind. It reminds me of the dynamics that have strengthened my closest relationships online and off: the ability to navigate challenges together and find a connection strengthened, not diminished, by our shared time spent swimming around in that vulnerable space of learning. By re-materializing a little bit of the friction of computing, not _gatekeeping_ but commanding effortful engagement, Urbit has created a platform that is purpose-built for conviviality.
content/blog/creating-sigils.mdnew file+172
@@ -0,0 +1,172 @@
1++++
2+title = "Creating Sigils"
3+date = "2020-02-03"
4+description = "The origin and design process informing Urbit's generative user avatar system, Sigils."
5+
6+[extra]
7+author = "Gavin Atkinson"
8+ship = "~ridlur-figbud"
9+image = "https://media.urbit.org/site/posts/essays/sigils3.png"
10++++
11+
12+<!--  -->
13+
14+
15+
16+One of the basic building blocks of Urbit is Urbit ID, our naming and identity system. Your Urbit ID is a short, recognizable name that’s also a network address for your Urbit OS instance. (You can find a complete, high level description of Urbit ID [here](https://urbit.org/understanding-urbit/urbit-id/).)
17+
18+Your Urbit ID is meant to feel a bit like a secret code name. It doesn’t leak any information about the real you — but it’s still memorable and recognizable. Getting an Urbit ID should feel exciting, like getting a brand new identity in a new world.
19+
20+From a design standpoint, some of this is accomplished simply by having a system for the names themselves. Under the hood, Urbit IDs are actually just numbers. There has always been an algorithm for turning these numbers into pronounceable names like `~tacryt-socryp` (13,304,832) or `~litzod` (1,280) or `~nes` (212).
21+
22+While the names are great, they’re not quite enough, especially in a rich interface. Each Urbit ID really needed some form of visual representation, image, or crest. A digital identity needs to be something you can really attach to, both yours and those that belong to your friends.
23+
24+There are 2^32^ or 4.2 billion unique Urbit IDs. Clearly there’s no way that we were going to do this by hand. And purely algorithmic solutions can often produce disappointing, undifferentiated output.
25+
26+Regardless, we set out to tackle this problem. By the end of this process, every Urbit ID got its very own ‘sigil.’
27+
28+In this post we’ll walk through how we thought about the problem, iterated through possible solutions, and the toolchain we used to arrive at the final result.
29+
30+## Background
31+
32+What are the basic primitives of a visual language? There aren’t any completely authoritative answers to this question, of course. But we knew that to produce such a large number of visually distinct items we’d need some way to reason about form that’s closer to letterforms.
33+
34+So we started by collecting influences.
35+
36+{% iframe src="https://www.are.na/tlon/seal-zp3irwad52y/embed" className="arena-iframe" width="100%" /%}
37+
38+The ‘chop’ or [seal](<https://en.wikipedia.org/wiki/Seal_(East_Asia)>) is conceptually pretty close to what we wanted to get to.
39+
40+<br /><br />
41+
42+{% iframe className="arena-iframe" src="https://www.are.na/tlon/kamon/embed" width="100%" /%}
43+
44+[Kamon](<https://en.wikipedia.org/wiki/Mon_(emblem)>) are even closer — especially since they have very little visual complexity.
45+
46+<br /><br />
47+
48+{% iframe className="arena-iframe" src="https://www.are.na/tlon/grids-jd_xbmspxkm/embed" width="100%" /%}
49+
50+We also spent a good amount of time with both Anni Albers and Agnes Martin. Both of these painters had an incredible mastery of the grid as a means of creating engaging visual work. These paintings all have a wonderful tension between an underlying system and their specific expression.
51+
52+<br /><br />
53+
54+{% iframe className="arena-iframe" src="https://www.are.na/tlon/stella-xfroicotm_4/embed" width="100%" /%}
55+
56+Frank Stella is a master at producing incredibly dynamic work from only a few elements. His ability to create a sense of depth from simple overlapping elements is fantastic.
57+
58+<br /><br />
59+
60+{% iframe className="arena-iframe" src="https://www.are.na/tlon/ledoux-palladio/embed" width="100%" /%}
61+
62+The plans of both Ledoux and Palladio are incredibly dynamic. They’re mostly gridded, use only a few elements, and use lots of symmetry — but they’re at once distinct, engaging, and fresh.
63+
64+<br /><br />
65+
66+{% iframe className="arena-iframe" src="https://www.are.na/tlon/flags-k9moxiayuvq/embed" width="100%" /%}
67+
68+Another influence: international maritime signal flags. We like these not only because of their striking visual qualities, but also because they correspond with a letter system, just like our sigils. Each one conveys useful information; for example, “Keep clear of me; I am maneuvering with difficulty,” a flag we all feel like raising from time to time. This influence was key to the idea that pairing symbol to phoneme was a possibility.
69+
70+You can see the whole collection of our visual research [here](https://www.are.na/tlon/2019-sigils-research).
71+
72+Ultimately, we didn’t specifically draw on any of these influences very consciously. The goal of visual research is to get a sense of the territory, what has been tried, and what works. We think these threads of prior work are evident in the final result — you can _feel_ them, but it’s tough to point to them individually.
73+
74+## What’s in a name?
75+
76+> _“Lev’s sigil appeared, strobing, as Netherton was getting out of the cab in Henrietta Street. “Yes?” Netherton asked.”_
77+>
78+> **— William Gibson, The Peripheral**
79+
80+Before we get to how we worked through the problem of actually designing these things, let’s talk about the problem of naming.
81+
82+We went through so many names for these things. Crest, symbol, seal, tag, pictograph, stamp, emblem, signet, icon, glyph, holomark, visage, radigy, pattern, the list goes on for an incredibly (embarrassingly) long time. We argued about this, we went back and forth about it.
83+
84+Sigil won, ultimately, because of the way that it’s personified in William Gibson’s _The Peripheral_. In the far future, characters talk to each other by some kind of telepresence. When a call comes in from someone else, they first appear as a ‘sigil.’ It’s a strange word, but we were imagining a similar use-case.
85+
86+While we can’t point to any specific parts of our visual research that reappear directly, sigil is lovingly borrowed.
87+
88+## Experiments + iterations
89+
90+So, how did we actually end up making these things?
91+
92+We iterated through plenty of possibilities before landing on our final approach. Let’s walk through the two we remember best.
93+
94+<br /><br />
95+
96+
97+
98+The first attempt was a series of images in the style of Karel Martens. Overall this technique was just too cluttered and sometimes difficult to parameterize in a predictable way. We kept iterating.
99+
100+<br /><br />
101+
102+
103+
104+Just like the previous example, the main idea was that we could take a set of geometric primitives, combine them, then alter their appearance along a set of parameters, like color, rotation, and size.
105+
106+But also just like the previous attempt, the technique of overlapping symbols made the images too difficult to read and differentiate. We wanted to create sigils that were not only great to look at, but visually ordered. Since overlapping elements didn’t seem to quite hit the mark, on we went.
107+
108+## Closing in
109+
110+Eventually, we realized: tiles! With tile designs there are no overlaps, which in early experiments immediately started to take on the consistent, legible appearance we were after. Each element is discrete and clearly visible. Tile designs were also easier to create and control from an implementation standpoint.
111+
112+Best of all, tiles made it clear that we should be thinking in terms of creating representations of individual syllables rather than entire names. Urbit IDs are constructed from two sets of 256 three-letter syllables. `~fallyn-balfus` is `fal` `lyn` `bal` `fus`, for example. (There are two syllable sets in order to prevent duplicates — we always alternate between the two when composing names.)
113+
114+Thinking in terms of syllables greatly reduced the complexity of the problem, but there was still some work to do.
115+
116+<br /><br />
117+
118+
119+
120+At first, we thought about using a 4 x 4 tile grid, as shown here. These designs were tricky to implement because of the detailed lines and arcs spanning across individual tiles. In order to generate a result that matched these mockups, a program would have to generate a data model that knew about which tiles touched which other tiles.
121+
122+We felt this was too complicated and had an unknown performance profile. Plus, they proposed a deterministic color scheme and we felt strongly that color is personal, not to mention hard to parameterize. In the end we thought it better to create something that had the potential for user customization.
123+
124+<br /><br />
125+
126+
127+
128+Around this stage, we were thinking a lot about how architectural plans aren’t unduly constrained by the fact that they’re only one color. We had a feeling we could make the grid smaller and assign details to the tiles individually.
129+
130+<br /><br />
131+
132+
133+
134+So, we scaled it down to a 2 x 2 grid and stuck with it. It’s simple to implement, visually unique, consistent, and the color scheme is black and white, leaving room for user customization. We felt we had reached a semblance of a final result. Now all we had to do was manually draw 512 unique but consistent individual ‘phonemes’.
135+
136+<br /><br />
137+
138+
139+
140+As it turns out, drawing 512 consistent, abstract elements by hand isn’t easy. We had to strike a balance between authorship and automation — we wanted each tile to look well-made, but not too authored. To do so, we took advantage of Figma’s web API which helped us design in SVG but iterate programmatically.
141+
142+## Final process
143+
144+
145+
146+We took a look at our hand drawn mockups and drew each individual visual building block of the tiles separately. Then we loaded the SVG elements into a script that programmatically combined them to create trillions of layered symbols. This way, we were able to easily select candidate phoneme symbols that worked visually.
147+
148+We eventually added a rule system to find higher quality phoneme symbols — but this combination of programmatic generation and hand selection was working pretty well.
149+
150+<br /><br />
151+
152+
153+
154+The final step, using the tool we built, was to hand select individual phoneme symbols and create a complete index.
155+
156+<br /><br />
157+
158+
159+
160+This allowed us to start looking at possible combinations and selecting phoneme symbols based on their interplay with others.
161+
162+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.
163+
164+<br /><br />
165+
166+
167+
168+We think sigils are pretty successful. They look nice in our native Urbit interfaces, people have made them into shirts and posters and cards, even laser-cut them to make stamps.
169+
170+Urbit ID and the sigils are components of Urbit that are totally separate from the OS — you can use them on their own and potentially even extend their functionality. We’re happy with what we’ve done with them so far, and hope that people will experiment with what’s possible with this naming and identity system.
171+
172+
content/blog/desire-lines.mdnew file+35
@@ -0,0 +1,35 @@
1++++
2+title = "Desire Lines to a New Internet"
3+date = "2022-05-06"
4+description = "As more DAOs, NFT and digital communities find their way to Urbit, others are likely to follow their paths, making them their own, just like the network itself."
5+[extra]
6+author = ""
7+ship = "~dalwes-migdec"
8+image = "https://media.urbit.org/blog/desire-lines.jpg"
9++++
10+
11+
12+
13+The beginning of a migration is usually imperceptible. First comes discontent, then comes the decision to either stick with inadequate, but familiar circumstances or to try something new and foreign. Eventually, someone makes the jump. A few others join. Then, seemingly all at once, a rush precipitates a trend, signaling the migration's final wave before broad and broader adoption.
14+
15+By now it's obvious that the tooling web3 communities and DAOs rely on day-to-day are, at best, deficient. Pointing this out verges on parody. Still, stuck between a disjointed terrain of engagement-oriented apps and data-harvesting services, where are these newly nomadic syndicates supposed to go? If you spend more than ten minutes on Twitter, reading the same canned takes on digital itinerancy, you will come across a variety of answers, and the figureheads of several recently incorporated Delaware LLCs claiming to be building the OS for web3. Some of these endeavors appear promising, to be sure, but none are more mature or as [well-positioned](https://datnut-pollen.discordja.net/discordja/giving-daos-a-brain) to satisfy this need than Urbit. A few communities are already on the network and [thriving](https://urbit.org/blog/urbit-for-creators), and another swell is approaching.
16+
17+To understand why Urbit is so appealing for web3 communities, start by examining the principles that motivate its development. Ownership of data, durability, and digital sovereignty underpin the entire project, from its earliest days to its present, evolved form. Without ownership, your tools control you more than you control them. Without built-in longevity, your tools can't be easily passed from one generation to the next, which is the premise of Urbit's technological page one rewrite. (For those interested in learning more about Urbit's clean slate stack, you can read documentation [here](https://urbit.org/docs).) Finally, without sovereignty, you're powerless to the whims of a centralized stronghold of corporate and bureaucratic control.
18+
19+As an open source peer-to-peer network, Urbit offers communities the reliability absent elsewhere in the ecosystem, and the assurance that there will never be surreptitious terms of service changes, nor shareholders to appease. By design and in spirit, Urbit is the only viable alternative to the hodgepodge of competing chat rooms, voting services, blogs, and wallets presently available. Building dapps that supplant these services ultimately leads to similar impractical quandaries. Every dapp requires that a server be online, in a friendly jurisdiction, for you to be able to access its interface and once you access its interface, a dapp can't store any data about you that isn't on a (slow) public blockchain. Why can't a dapp wallet show you all of your assets, your transaction history, and all the contacts you trade with? Because running and operating the necessary server is at odds with the premise of a dapp.
20+
21+An Urbit app retains its decentralized integrity while providing the ability to share data between apps, run regular computation, and call out to the blockchain as needed—all on a cohesive platform. Fundamentally, Urbit is yours: to own, to customize, to turn into a digital home. When more communities ditch the dance between MEGACORP-operated servers and create new homesteads on Urbit, it gets significantly easier for others to mirror their steps and relocate themselves.
22+
23+Communities that find their way to Urbit are essentially traversing desire lines, taking paths that "emerge gradually and organically, almost of their own accord" as [described](https://books.google.ca/books?id=mW7RCwAAQBAJ&pg=PA3&dq=%2522christopher+alexander%2522+organically+%2522paths%2522&hl=en&sa=X&ved=0ahUKEwjN7dqN6fbPAhUqr1QKHTB9BBsQ6AEIHjAA%23v=onepage&q=%2522christopher%2520alexander%2522%2520organically%2520%2522paths%2522&f=false#v=onepage&q=%2522christopher%2520alexander%2522%2520organically%2520%2522paths%2522&f=false) by the late architect Christopher Alexander. Before Urbit's [L2 launched](https://urbit.org/blog/layer-2-guides), distributing a tranche of planets to community members would have been cost prohibitive. Now that it can be done, and done simply, planet activations are rapidly increasing, [doubling](https://twitter.com/jmrphy/status/1517533689118306304) in the last two months. Desire lines to Urbit exist as invitations for the next community, to pass over, and to make their own, just like the network itself.
24+
25+The limitations of operating on the clearnet appear to be at long last irrevocable. Multiple desire lines to Urbit are materializing concurrently. Remilia Collective, aka Remco, aka the creators of Milady, has been [vocal](https://blog.remilia.org/urbit-with-port/) about the network for quite some time, but more community members than ever have onboarded as the result of a [headless](https://twitter.com/TheCombineDAO/status/1514000804235120644), [grassroots](https://twitter.com/hastuc_dibtux/status/1514031235135377421) collaboration between Urbit maximalists and miladies.
26+
27+DAO tooling is also proliferating on Landscape, Tlon's interface for navigation on Urbit and a platform from which developers can release apps directly to users with minimal effort. [Holium](https://www.holium.com), a team working specifically on unifying the DAO tech stack, released a ballot app last month that allows for flexible voting, delegating, and result-related actions. [PointDAO](https://pointdao.notion.site/pointdao/Point-DAO-bc8fc478b67a49ac92358a2a40d77d35), a collective of more than two hundred people that owns a galaxy, serves as a prototype for other communities to crowdfund purchases of Urbit address space—a procedure that they are aiming to make replicable and scalable.
28+
29+Growing your own society on Urbit can be as straightforward as using ownership of one token as the prerequisite for claiming another token (in other words: token gating a token). The Urbit Foundation just funded a [grant](https://urbit.org/grants) that simplifies the process of deploying Urbit IDs via another NFT's minting. Development is still ongoing, but [Dusko](https://dusko.world), the NFT project that received the grant, did a trial run last week to coincide with the release of a fresh batch of character pfps. For each mint, the collector could [custody](https://www.mintdusko.world) their very own planet—all authenticated via Metamask. (To track their progress, join [~panrut-ragbyl/dusko](https://urbit.org/groups/~panrut-ragbyl/dusko).) Dusko's approach represents the first desire line of its kind, and other communities are likely to take their path.
30+
31+The adage goes something like as soon as you notice a migration is underway, you've already missed the boat. But there's no boat to miss because an overabundance of communities could never exist on Urbit—it's as vast as it is cozy. Angling to get your community onboard? Share planets with a NFT-based community using Valve, the distribution mechanism Dusko is working on, or apply to build your own version. Crowdsource the funds for a star. Set up your group and send out a [flare](https://tirrel.io): everyone else will follow.
32+
33+
34+
35+
content/blog/eliza.mdnew file+46
@@ -0,0 +1,46 @@
1++++
2+title = "Eliza"
3+date = "2021-02-22"
4+description = "Building things, even Calm™ things, makes noise."
5+
6+[extra]
7+author = "Christian Langalis"
8+ship = "~pindet-timmut"
9+image = "https://media.urbit.org/site/posts/essays/valleys.jpg"
10++++
11+
12+
13+
14+## The Storm before the Calm
15+
16+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.
17+
18+We call her Eliza. She is a data-collection robot.
19+
20+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.
21+
22+## What Eliza is and isn’t
23+
24+> Replicants are like any other machine - they're either a benefit or a hazard. If they're a benefit, it's not my problem.
25+>
26+> **Rick Deckard**
27+
28+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.
29+
30+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.
31+
32+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.
33+
34+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.
35+
36+## A New Internet Economics
37+
38+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.
39+
40+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.
41+
42+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.
43+
44+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.
45+
46+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.mdnew file+53
@@ -0,0 +1,53 @@
1++++
2+title = "Urbit Events Series"
3+description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."
4+date = "2020-10-29"
5+
6+[extra]
7+description = "These events are an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another)."
8+author = "Lane Rettig"
9+ship = "~naplet-hildec"
10+image = "https://media.urbit.org/site/posts/essays/bau.jpg"
11++++
12+
13+
14+
15+_TL;DR: Urbit is launching a series of community events, the first of which is a developer call taking place on Thursday, November 5 at 9am PT. [Sign up here](https://www.meetup.com/urbit-sf/events/274279522/), and read on for all of the details._
16+
17+--
18+
19+If you’re familiar with the project, you’ve probably noticed that Urbit folks talk a lot about the fact that [Urbit is for communities](https://urbit.org/blog/urbit-is-for-communities/). This is central to what Urbiteers believe: Urbit is a platform that any group of people should be able to use to build, communicate, and transact in precisely the way that makes sense to them. Today, Urbit is already capable of facilitating many of these activities, and it’s already a big part of the daily workflow for many people. I think we’re off to a pretty good start, and over time Urbit will become accessible to more communities.
20+
21+Something we tend to talk less about is the fact that Urbit itself is also a community. If you’ve spent any amount of time hanging out in Landscape in the Urbit Community group, you already know this—but getting to know the community takes time and effort.
22+
23+One 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.
24+
25+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.
26+
27+We 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.
28+
29+One way that seems to work well is getting everyone together once in a while for events. Over the last few years, I and others in the community have collectively attended hundreds of community events, virtually and in person around the world, from small developer chats to massive, global developer conferences with thousands of attendees. Urbit has even hosted [a few of our own](https://www.meetup.com/urbit-sf/).
30+
31+As a newcomer to the Urbit community I recently found myself seeking exposure to cultural knowledge. I know from experience attending and organizing events in other communities that regular events are a good way of making this knowledge more accessible, and of helping newcomers like myself onboard. I applied for [a grant](https://grants.urbit.org/proposals/1751024973) to bootstrap a new event series, and I’m excited to announce that this series is launching next week with the support of [urbit.org and the grants program](https://urbit.org/blog/first-steps-towards-urbit-org/).
32+
33+The event series has three components. The first is a series of developer calls. These will be shorter and more narrowly focused on the technologies that underpin Urbit, from the top of the stack to the very bottom. They’re an opportunity for the people developing and contributing to Urbit to share their knowledge and expertise, including things that typically don’t make it into the docs, such as how and why Urbit works the way it does. It’s recently become much easier to build applications on top of Urbit, so I hope these events will help developers see what sort of things they can already use Urbit to build, and how to get started. These events are also an opportunity for Urbit contributors to share real-time updates that don’t make it into this blog, and for the community to get to know the contributors (and one another!).
34+
35+The first developer call will take place on Thursday, November 5 at 9am PT, and you can [sign up to attend here](https://www.meetup.com/urbit-sf/events/274279522/). The second call will take place two weeks later on Thursday, November 19, and we’ll continue holding these calls about every two weeks.
36+
37+The second component is a larger Town Hall event to take place on Thursday, December 17. The Town Hall will feature multiple speakers and will cover topics including technology but also design, community, and our overall progress towards our vision for Urbit. You can think of it as part show and tell, part “State of the Network,” part meet-and-greet.
38+
39+The third component is a larger conference, tentatively called UrbitCon, to take place early next year. This event is still in a conceptual phase. It’ll be an opportunity for the global Urbit community to celebrate how far the project has come, to share technical as well as cultural knowledge, and, maybe most importantly, to hang out together and have some fun as well. Watch this space for more information on the Town Hall and UrbitCon.
40+
41+Collectively, these events allow the community to achieve several goals. Firstly, they’re a great way for community members to meet one another, exchange cultural knowledge, and share what they’re working on. Events provide excellent motivation to get something that’s a work-in-progress to a state where you can share it with others!
42+
43+Secondly, the content from these events will be recorded and published, and will form the cornerstone of a new knowledge base on urbit.org that will augment existing documentation. This will make it much easier for newcomers, even those that can’t attend the events live, to benefit from the wealth of knowledge and expertise of the Urbit community.
44+
45+Finally, these events are a great opportunity for community members to contribute things other than code. While Tlon will provide speakers for the first few events of the series, it’s important to emphasize that the initiative is entirely community-led and that we’ll need lots of help to organize and host events. If you’re interested in helping out with any of the events in the series, please find me and others helping out with events on Landscape in the Urbit Community group (the channels called “Events Series”).
46+
47+They say that a project’s community has reached critical mass when new things are happening that even the project’s earliest and most active contributors aren’t aware of. By this standard, the Urbit community reached critical mass sometime in the past few months, as even core team members tell me they’re regularly surprised to learn of another new project or initiative launched by a community member.
48+
49+Tlon could no longer catalog the Urbit community even if it wanted to. This is a good thing. As Tlon [has also said](https://urbit.org/blog/hosting-the-future/), it’s natural that Tlon and Urbit drift apart a bit over time. Just as Urbit itself is self-hosted, so the community, over time, should become self-hosting: it should play a more active role in shaping the future of the project. A community-run event series can be an important catalyst for this trend. I’m looking forward to the first event, and I hope to see you there, and at many events to come.
50+
51+--
52+
53+_Sign up to attend [the first event](https://www.meetup.com/urbit-sf/), and join the channels called “Events Series” on Landscape in the Urbit Community group to get involved._
content/blog/first-contract.mdnew file+289
@@ -0,0 +1,289 @@
1++++
2+title = "Azimuth’s First Contract Upgrade"
3+date = "2021-06-04"
4+description = "Galactic Senate makes first concrete action"
5+
6+[extra]
7+author = "Jonathan Paprocki and Mark"
8+ship = "~datnut-pollen and ~palfun-foslup"
9+image = "https://media.urbit.org/site/posts/essays/land3.jpg"
10++++
11+
12+
13+
14+Recently, the [first upgrade](https://github.com/urbit/azimuth/pull/35) to the
15+[Azimuth](/docs/glossary/azimuth) smart contracts which make up Urbit ID was
16+put up to an [upgrade proposal vote](/docs/glossary/upgrade) by the
17+[Galactic Senate](/docs/glossary/senate). This vote is still open and will
18+last for 30 days (June 20th) or until an absolute majority is reached. We’d like
19+to take this opportunity to discuss two things. [First](#changelist), what the
20+proposed changes are, and [second](#senate), a review of how Urbit governance
21+works and where we’re at in the decentralization process.
22+
23+Before we dive into what the proposed changes are, let’s review what the Senate
24+is actually capable of changing. Urbit ID is really two sets of smart contracts:
25+Azimuth and [Ecliptic](/docs/glossary/ecliptic). Azimuth is the data of the
26+public key infrastructure - roughly, this is the list of
27+[ships](/docs/glossary/ship) and which Ethereum addresses own them, along
28+with other data such as networking keys and sponsorship status. The Senate has
29+no ability to touch this data directly. This is in direct contrast to all
30+existing centralized services, where your account is always at risk of being
31+taken away from you. What the Senate can change is Ecliptic, which is the
32+“business logic” that decides how you can interact with the data in Azimuth.
33+These are mechanisms such as what powers various
34+[proxies](/docs/glossary/proxies) have, how stars/planets are released over
35+time, and how sponsorship works. Put another way, the data and database format
36+must remain the same, but the rules by which we interact with it may change
37+according to the governance rules we [detail below](#senate).
38+
39+## Changelist {% #changelist %}
40+
41+The Galactic Senate is voting on the following changes to Ecliptic:
42+
43+- Fixed ERC721 compatibility
44+- Self-modifying proxies
45+- Upgraded Claims contract
46+
47+### Fixed ERC721 compatibility
48+
49+In Ecliptic, the contract includes various functions and events
50+that make it conform to the ERC721 (non-fungible token) standard. However, two
51+events have [ever so slightly
52+non-confirming](https://github.com/urbit/azimuth/issues/8) descriptions. This
53+causes Ethereum explorers like Etherscan to incorrectly recognize Azimuth as
54+ERC20 (fungible token), rather than ERC721.
55+
56+The proposed change simply modifies the event descriptions to accurately match
57+the ERC721 definition. This does not affect any functionality within the
58+contract itself.
59+
60+### Self-modifying proxies
61+
62+Owners of Azimuth assets are allowed to configure "proxy addresses" for those
63+assets: Ethereum addresses allowed to act "as" the owner, but only for a subset
64+of operations. For example, setting the management proxy will let you change
65+your networking keys and sponsor using that address, just like your ownership
66+address can. This is useful for keeping the ownership keys in very cold storage
67+while still letting you perform lower-value operations.
68+
69+Currently, only the ownership address is allowed to change proxy addresses.
70+Fairly early on after Azimuth's deployment, we realized it might be nice for
71+proxies to be able to change themselves.
72+
73+This means that, in addition to being able to configure networking keys and
74+sponsorship, your management proxy would be able to assign a new management
75+proxy. This would allow you, or a trusted third party holding your management proxy,
76+to rotate your proxy keys without needing to take your ownership keys out of cold
77+storage.
78+
79+### Upgraded Claims contract
80+
81+[The Claims
82+contract](https://github.com/urbit/azimuth/blob/master/contracts/Claims.sol)
83+lets asset managers associate various "claims" with their identity. For
84+example, an Ethereum address to send donations to, or proving ownership of a
85+Twitter account.
86+
87+For ease of use by off-chain tools and services, the contract emits events
88+(notifications) whenever any claims are updated. However, the current version of
89+the contract has a bug where it does not emit events when all claims are removed
90+at once (clearClaims()). This "gap" in the event stream makes it much more
91+difficult to write off-chain tools around this contract. Considering Claims has
92+seen [practically no
93+use](https://etherscan.io/address/0xe7e7f69b34d7d9bd8d61fb22c33b22708947971a#events)
94+since it was first deployed, it should not be a problem to simply start over
95+fresh with a new contract that contains [the
96+fix](https://github.com/urbit/azimuth/pull/32) for the described bug.
97+
98+The reason we must do an Ecliptic upgrade to switch to a new Claims contract, is
99+that it is tied in with the logic for transferring an asset. If an asset is
100+flagged for "reset" (common when transferring to/from someone other than
101+yourself), its configured proxies, networking keys and claims are cleared during
102+transfer. As such, Ecliptic will need to know about the address of the new
103+Claims contract.
104+
105+## Urbit Governance {% #senate %}
106+
107+
108+
109+The ultimate goal of Urbit is to become a digital republic manifested as a peer
110+to peer network owned and controlled by its users. The goal of Tlon, then, is to
111+become one of many companies who build products for Urbit rather than being the primary
112+driving force behind its development. We’d like to take this opportunity to
113+spell out our perspective on where we’re at in that process. Here are some previous posts that are relevant, but please note that
114+some of them are several years old and as such may not accurately reflect our
115+current position, but still serve as useful historical markers. We hope to
116+revisit and refresh these documents soon.
117+
118+- [2016.5.16 - Interim
119+ Constitution](/blog/interim-constitution)
120+- [2016.5.16 - The
121+ Urbit Address Space](/blog/the-urbit-address-space)
122+- [2016.6.24 - The DAO as a Lesson in Decentralized
123+ Governance](/blog/the-dao-as-a-lesson-in-decentralized-governance)
124+- [2019.1.11 - Governance of
125+ urbit.org](/blog/governance-of-urbit)
126+
127+### Galactic Senate
128+
129+The Galactic Senate is composed of all [galaxy](/docs/glossary/galaxy)
130+holders, which at present consists of more than 100 individuals and a few
131+organizations, including Tlon and the Urbit Foundation. Using the Azimuth
132+voting contract, the Senate can present and vote on two kinds of proposals:
133+[document proposals](/docs/glossary/docvote) and [upgrade
134+proposals](/docs/glossary/upgrade). Thus far, all matters which the Senate
135+has voted on have been document proposals. The [most recent
136+vote](https://github.com/urbit/azimuth/pull/34) declared the Urbit network as
137+(i) being secure (as confirmed by a [third party
138+audit](/blog/security-audit)) and (ii) having reached continuity (as in, no
139+further [network breaches](/docs/glossary/breach) are expected). Previous votes
140+were to declare that [Azimuth is live](https://github.com/urbit/azimuth/pull/25)
141+and that [Arvo is stable](https://github.com/urbit/azimuth/pull/24).
142+
143+### Address space distribution
144+
145+Perhaps the most informative measure of how decentralized Urbit is in terms of
146+how many independent parties hold address space. By the very nature of Urbit, it
147+is impossible to know this with great accuracy (a common feature of
148+decentralized projects). However, the movement of galaxies is closely watched
149+and thus we have a fairly good idea of how distributed they are.
150+
151+In the beginning, Urbit’s creator Curtis Yarvin was in possession of the entire
152+address space - all 256 galaxies, and everything underneath it. A network of one
153+is no network at all, and so over the last decade Urbit’s development has been
154+primarily driven by selling or giving away these galaxies. On [June 1,
155+2016](/blog/the-urbit-address-space), the allocation was:
156+
157+> 95, to the Tlon Corporation. 50, to urbit.org, the future community
158+> foundation. 40, to Tlon employees and their family members (24 to Curtis, who
159+> started in 2002; 16 to everyone else, who started in 2014). 34, to outside
160+> investors in Tlon. 37, to 33 other individuals, who donated to the project,
161+> contributed code or services, won a contest, or were just in the right place
162+> at the right time.
163+
164+Since then, Tlon has sold a number of
165+its galaxies to fund development and others have changed hands to the point
166+that Tlon and urbit.org no longer possess a majority share of galaxies. In
167+January 2019, [Curtis gave all of his galaxies](/blog/a-founders-farewell) to
168+Tlon when he left the project. In August 2020 we shared an update on the [known
169+distribution of address space](/blog/value-of-address-space-pt3), where
170+Curtis’ galaxies are marked as Tlon’s “naked galaxies”. Shortly thereafter, Tlon
171+disbursed its naked galaxies among the employees that wanted one who did not
172+already possess one, thus removing Tlon and urbit.org’s controlling share of the
173+Senate. Galaxies held by current and former Tlon employees are entirely
174+independent of Tlon Corporation—they may do with them, and vote with them, as
175+they please. `~ravmel-ropdyl` plans to give more color to this decision in the
176+near future.
177+
178+Distribution of stars is much more difficult to know. There is an active market
179+for stars on [OpenSea](https://opensea.io/collection/urbit-id), so we know that
180+they are changing hands frequently, but checking the number of distinct Ethereum
181+addresses that hold stars does not tell you very much information since a single person can control multiple adresses.
182+
183+### Software and smart contracts
184+
185+As was written in [The DAO as a Lesson in Decentralized
186+Governance](https://urbit.org/blog/the-dao-as-a-lesson-in-decentralized-governance/),
187+we are keenly aware of the threat of _decentralization theater_. Urbit has
188+undergone steady progress towards decentralization, and with the developments we
189+outline below, it’s never been more clear that the project is beginning to leave
190+the cradle of Tlon. It’s also important to note that the decentralization of a
191+project is always a movement away from an initial centralized state—you cannot
192+go from A to Z without first traversing every letter in between. While Urbit was
193+centralized at the beginning, the journey towards a network owned and
194+controlled by the users is now well underway.
195+
196+In the past, nearly all Urbit software was written by Tlon. While Tlon is still
197+the only corporation actively updating Urbit’s MIT-licensed open source
198+software, namely [Vere](/docs/glossary/vere) (the runtime),
199+[Arvo](/docs/glossary/arvo) (the kernel),
200+[Landscape](/docs/glossary/landscape) (the client), and
201+[Bridge](/docs/glossary/bridge) (the ID manager), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).
202+
203+The only real power Tlon holds over Urbit is the ability to push [OTA
204+updates](/docs/glossary/ota-updates) via `~zod`, and suggest that people
205+download our binaries. To the best of our knowledge, all extant galaxies
206+retrieve their OTA updates from `~zod`, who forward it to their stars, who
207+forward it to their planets. This software distribution route is merely a
208+convenient default setting. Ships initially retrieve OTA updates from their
209+sponsor, but they have full authority to retrieve updates from whoever they want
210+with the `|ota` command, or even to only install software updates by hand if
211+they so choose.
212+
213+In the future, one can easily imagine many organizations shipping their own
214+distributions of Urbit from their own urbit nodes, somewhat analogously to the
215+large number of Linux distributions which exist today. There is nothing we can
216+do to stop a group from forking Urbit, declaring `~sampel-palnet` the new `~zod`
217+(both for updates and for sponsorship purposes), and retrieving all OTA updates
218+via that route and building their own binaries. This is all by design, and we
219+wouldn’t want it any other way.
220+
221+The use of the Azimuth smart contracts is also somewhat optional. By changing a
222+few lines of code to point their ships at another set of PKI smart contracts,
223+they could rid themselves of hierarchical peer discovery entirely and make use
224+of some other routing strategy such as [Kademlia based DHT
225+routing](https://en.wikipedia.org/wiki/Kademlia). This would likely give rise to
226+an entirely separate network. The fact that the network is fully capable of such
227+a schism helps keep the Senate honest and accountable to the users. If they ever
228+were to vote on a contract modification that greatly angered or upset a portion
229+of the user base, they would be inviting such a schism and be entirely deserving
230+of it. In that sense, the power to control the network is already held by the
231+users, they just have not yet had a reason to make use of it.
232+
233+### Legitimacy
234+
235+The only way by which Tlon and the Senate hold any power is via legitimacy.
236+Vitalik Buterin recently wrote a [very informative
237+article](https://vitalik.ca/general/2021/03/23/legitimacy.html) on the role of
238+legitimacy in decentralized governance, and I do not know of a better source to
239+understand how Tlon and the Senate are kept in check by the users. Besides the
240+DAO split resulting in Ethereum and Ethereum Classic mentioned in the article,
241+perhaps the most prominent example of the power users have over a decentralized
242+network is the saga of [Steem and Justin
243+Sun](https://www.coindesk.com/justin-sun-bought-steemit-steem-moved-to-limit-his-power).
244+The short version of the story is that Justin Sun bought a controlling share of
245+the Steem blockchain and attempted to exert control over it, and the users
246+banded together to fork the blockchain into one called Hive, which was identical
247+to Steem except with Sun’s token balance set to zero. An analogous outcome for
248+Urbit would be that the Senate makes sweeping changes to the PKI and invites a
249+schism like that outlined above.
250+
251+For these reasons, there are strong disincentives for any one organization or
252+individual to acquire too many galaxies. If galaxy ownership becomes more centralized, individuals will be less incentivized to build on the network which will reduce the value of address space. Furthermore, such centralization might provoke a fork if such centralized powers are perceived as malicious by the users. This is in contrast to real-life republics, where there is little risk
253+for one party to accumulate as much power as they can manage since the cost to
254+the citizens to overthrow that power is enormous. Thus, only especially
255+egregious displays of power ever result in rebellion. Within the Urbit republic,
256+users need only to change the code they run to leave the Senate powerless, and
257+so the threat of rebellion is much more real. We estimate that within a digital
258+republic like Urbit, the centrifugal forces outweigh the centripetal forces, and
259+that the outcome of this is more stable than the reverse.
260+
261+### Why have governance at all?
262+
263+An important question the reader may still have lingering is: why does Urbit
264+need governance at all? The short answer is: (i) there will always be necessary
265+protocol upgrades that cannot be foreseen, and (ii) a total lack of governance
266+inevitably gives rise to a shadow government with undefined powers that is
267+almost impossible to hold accountable.
268+
269+With (ii), we see this to be the case on many early blockchain projects where
270+power is shared by the developers and the miners, but what each is capable of
271+doing has never been codified, and thus users of the blockchain can never have a
272+great deal of certainty of what changes might occur in the future. This doesn’t
273+guarantee a bad outcome, but it does create more wariness among developers when they cannot know whether they really have a say in
274+the project's direction. Recognizing this issue, many newer blockchain and
275+blockchain-adjacent projects have built-in governance mechanisms that lay out
276+exactly what an individual can expect should they join and contribute to that
277+network.
278+
279+As for (i), with Urbit being a wholly new kind of network, it would take
280+incredible luck to get the PKI exactly right on the very
281+first try without ever needing another modification. Thus, some mechanism was
282+needed to guarantee that the PKI’s logic could be altered. Leaving control of
283+Azimuth in the hands of Tlon would have just granted Tlon dictatorial power, which Tlon nor Urbit users desired. There’s certainly
284+room to argue that the Galactic Senate is not a perfect system: our interim
285+constitution did outline potential roles for stars and planets to play in
286+governance in the future, so there is ample opportunity for the system to evolve
287+in response to the will of the users. As always, it is important to keep in mind
288+the unfinished nature of the Urbit of today and the still moldable clay of the
289+Urbit of tomorrow—nothing yet is set in stone.
content/blog/first-steps-towards-urbit-org.mdnew file+52
@@ -0,0 +1,52 @@
1++++
2+title = "First Steps Towards urbit.org"
3+date = "2020-08-11"
4+description = "With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real."
5+
6+[extra]
7+author = "Josh Lehman"
8+ship = "~wolref-podlex"
9+image = "https://media.urbit.org/site/posts/essays/first-steps.png"
10++++
11+
12+
13+
14+## Summary
15+
16+It’s been a long time since we last discussed separating the [governance of urbit.org](https://urbit.org/blog/governance-of-urbit/) from Tlon. In the last few weeks, we’ve taken steps to make such a separation real. In this update we’ll discuss the background that led us here, why we’re doing this now, and what this means for Urbit.
17+
18+## Background
19+
20+At present Urbit is an open-source project developed primarily by the company Tlon. Urbit is an ambitious project with a long roadmap, which has required both careful guidance and resources to sustain its development. These resources have been Urbit’s address space, which have value in direct proportion to the value of Urbit as a platform. Naturally, Tlon has been focused thus far on making Urbit into a platform that people want to use.
21+
22+Ultimately, Urbit presents more possibilities than any one organization can manage. We anticipated this, and set aside address space for urbit.org, which we’ve often thought of as some type of software foundation. As Urbit matures to the point where Tlon can shift from developing the platform to developing products _on_ the platform, urbit.org is meant to continue to improve and maintain the parts of Urbit that many will come to rely upon.
23+
24+When we last discussed this, in early 2019, we weren’t quite ready to pull the trigger on setting up urbit.org. We weren’t sure if a software foundation would be the right structure, didn’t have the resources to tackle the overhead, and Urbit wasn’t yet stable enough for Tlon to focus on anything _but_ platform development.
25+
26+## The Present
27+
28+Urbit is really starting to look like a platform. Tlon has put tons of work into making Urbit stable and performant, we’ve launched OS1, and hosting services are on the horizon. Meanwhile, the grants program and Hoon School were initiated, and community members have been [contributing](https://github.com/natareo/hooncard/blob/master/hooncard.pdf) [learning](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview.md) [materials](https://github.com/lukechampine/rote/blob/master/urbit/app/rote.hoon), [issuing](https://github.com/urbit/urbit/pull/2885) [patches](https://github.com/urbit/urbit/pull/3202) [to](https://github.com/urbit/urbit/pull/3238) [Urbit](https://github.com/urbit/urbit/pull/2867), and [building](https://github.com/ryjm/srrs) [new](https://github.com/dclelland/UrsusChat) [applications](https://github.com/yosoyubik/canvas) [in](https://github.com/yosoyubik/urbitcoin) [userspace](https://github.com/taalhavras/ucal).
29+
30+With a stable platform taking shape and a strong community forming that wants to help build Urbit, it’s time to make urbit.org real. We’ve had plenty of time to think about what it should look like, how it should work, and who should lead it.
31+
32+Our plan is to run urbit.org as a protocol—we’ll treat it like a real entity, but instead of dealing with the administrative details of setting up such an organization, we’ll incubate it within Tlon and give it a mandate: To competently distribute address space as a means of improving Urbit.
33+
34+## Moving Forward
35+
36+On that note, allow me to introduce myself: I’m Josh[^1], the new Interim Director of urbit.org. I’ve been a follower of this project for several years now and more recently a fairly active community member. I first became fascinated by Urbit as a programmer that saw the potential in a clean-slate OS; I later became compelled by a future in which social computing becomes small, friendly, and human-scale again.
37+
38+My background is predominantly in building software, companies, and teams—most notably [Starcity](https://starcity.com), where I am a co-founder and CTO. Starcity[^2], like Tlon, is focused on enabling communities to flourish. While the approaches couldn’t be more different, the goal of bringing people together in fundamentally human ways is shared.
39+
40+My goal is to leverage urbit.org to ensure Urbit’s success. I want to see a world in which Urbit is used by my friends, family, colleagues, everyone I know. To get there, much is left to build.
41+
42+To that end, the first objective of urbit.org is to recruit builders and give them the tools to succeed. I’ll be focusing heavily on providing technical support to developers that engage with us via Grants, outreach to the wider developer community, supporting the efforts of those that are creating educational courses and documentation, and enlarging the contribution surface by exposing it to other programming languages[^3].
43+
44+The product work that Tlon is doing is crucial to Urbit’s long-term success, so I’ll also be leveraging bounties to more directly accelerate their development efforts. Landscape represents the clearest example of a cohesive vision for Urbit’s use. The existence of a polished product built on Urbit demonstrates to the world that the platform is robust and capable, and the growing community seems eager to help. You can expect more bounties very soon that provide a direct connection to the Landscape roadmap.
45+
46+As I’m only just getting started, I’d love to hear your thoughts. If you’re working on any grants you’ll hear from me soon, and if you have an idea that you want to pursue, I’m here to help you make it happen. You can reach me directly via Urbit as `~wolref-podlex` or by email at josh@urbit.org.
47+
48+I look forward to working with you.
49+
50+[^1]: But my friends call me ~wolref-podlex.
51+[^2]: We’re also really into the idea of being the first builder of housing on Mars. Just saying...
52+[^3]: We call this project Airlock. You’ll hear more about it soon.
arvo/ford/ford.md → content/blog/ford-fusion.mdrenamed+31−32
@@ -1,15 +1,17 @@
11+++
2−title = "Overview"
3−weight = 1
4−template = "doc.html"
5−aliases = ["/docs/learn/arvo/ford/"]
2+title = "Ford Fusion"
3+date = "2020-07-14"
4+description = "Ford Fusion was an overhaul of Urbit's over-the-air upgrade process and a rewrite of its build system. The new update system corrects a few long-standing bugs with the previous one, and the new build system is simpler, smaller (by around 5,000 lines), and easier to manage."
5+
6+[extra]
7+author = "Ted Blackman"
8+ship = "~rovnys-ricfer"
9+image = "https://media.urbit.org/site/posts/essays/ford-fusion.png"
610+++
711
8−*The Ford vane was refactored so drastically in 2020 that it was completely
9− removed as a standalone vane, with its functionality merged into
10− [clay](@/docs/arvo/clay/clay.md). The following is a reproduced [blog
11− post](https://urbit.org/blog/ford-fusion/) that documents this transformation,
12− which we called "Ford Fusion".*
12+
13+
14+## Overview and Rationale
1315
1416Ford Fusion was an overhaul of Urbit's over-the-air upgrade process and a rewrite of its build system. The new update system corrects a few long-standing bugs with the previous one, and the new build system is simpler, smaller (by around 5,000 lines), and easier to manage.
1517
@@ -21,13 +23,14 @@ Urbit isn't exactly a traditional operating system, so the comparison is somewha
2123itself in the general case, not just some special cases.
2224
2325Ford Fusion has fixed the major upgrade issues of the past by guaranteeing three properties that in retrospect are obvious requirements, but, like much of Urbit, took many years and rewrites to identify as such:
26+
2427- Atomic: the update should complete or fail in one transaction. If it
2528 fails, the system shouldn't get stuck.
2629- Self-contained: there must be no implicit dependencies or hysteresis
2730 (dependence on previous system states) when building the new software
2831 from source.
2932- Ordered: updates must be monotonically sequenced from the system's
30− lowest layer to highest.
33+ lowest layer to highest.
3134
3235Let’s walk through them one by one.
3336
@@ -37,9 +40,9 @@ In previous versions of Urbit, updates failed atomicity by deferring parts of th
3740
3841We've learned that asynchronicity is an entropic state. A system will tend toward more asynchronicity over time unless effort is put into keeping it synchronous. [As Jonathan Blow has noted](https://youtu.be/pW-SOdj4Kkk?t=2547), the language server protocol has turned every editor plugin into a distributed system, since now it has to communicate asynchronously with the main editor process.
3942
40−Consider an update system that took multiple Arvo events to complete. An ad-hoc higher-level transaction system would need to be built to roll back the effects of the first few events in case of failure. It’s important for various parts of the system to be able to emit effects on upgrade; since those effects would need to be rolled back if a later event in this upgrade fails, the system would need to maintain a queue of those events and only apply them once all the other upgrade events have completed.
43+Consider an update system that took multiple Arvo events to complete. An ad-hoc higher-level transaction system would need to be built to roll back the effects of the first few events in case of failure. It’s important for various parts of the system to be able to emit effects on upgrade; since those effects would need to be rolled back if a later event in this upgrade fails, the system would need to maintain a queue of those events and only apply them once all the other upgrade events have completed.
4144
42−Note that the asynchronicity has now spread. Some effects that would normally be guaranteed to be processed synchronously might now be asynchronous. Entropy has begun to take hold, chipping away at the set of invariants the system is capable of guaranteeing.
45+Note that the asynchronicity has now spread. Some effects that would normally be guaranteed to be processed synchronously might now be asynchronous. Entropy has begun to take hold, chipping away at the set of invariants the system is capable of guaranteeing.
4346
4447This observation is not purely theoretical. False modularity was the cause of internal asynchronicity in Clay where it had to wait for responses in a complex dance with Ford, which was another vane (Arvo kernel module); moving Ford into Clay allowed function calls that were synchronous from Clay’s perspective, which allowed further simplifications, culminating in about a twenty percent reduction of source code size of the Arvo kernelspace.
4548
@@ -74,17 +77,17 @@ Emerging from this underworld required making a number of changes to the Arvo ke
7477
7578These are the layers of the stack that update themselves on the fly, from lowest to highest:
7679
77−+ hoon: the hoon language definition and compiler, defined in `/sys/hoon/hoon`
78−+ arvo: the arvo kernel proper and related type definitions, in `/sys/arvo/hoon`
79−+ zuse: the standard library, in `/sys/zuse/hoon`
80−+ vanes: arvo kernel modules, including clay itself, in folder `/sys/vane`
81−+ userspace: apps, marks, ancillary source code like libraries, and user data
80+- hoon: the hoon language definition and compiler, defined in `/sys/hoon/hoon`
81+- arvo: the arvo kernel proper and related type definitions, in `/sys/arvo/hoon`
82+- zuse: the standard library, in `/sys/zuse/hoon`
83+- vanes: arvo kernel modules, including clay itself, in folder `/sys/vane`
84+- userspace: apps, marks, ancillary source code like libraries, and user data
8285
8386An update to one layer necessitates a reload of all layers above it; e.g. a change to Zuse should trigger updates to the vanes and userspace. Conversely, an update to a higher layer should not cause a spurious reload of lower layers, which should not be affected by the change; for example, an update to just userspace should not cause any reloads of system code.
8487
85−Clay is responsible for enforcing the layering of updates. An update to a module is triggered when an attempt is made to commit a change to Clay that affects one or more files needed to build the module. For example, if the 'foo' agent's source, defined in `/app/foo/hoon`, imports the 'bar' library from `/lib/bar/hoon`, then a modification to `/lib/bar/hoon` triggers an update to the 'foo' agent. All vanes and userspace files depend on Zuse, which depends on the Arvo and Hoon sources, so a change to the Hoon, Arvo, or Zuse sources will trigger updates to all vanes and userspace files.
88+Clay is responsible for enforcing the layering of updates. An update to a module is triggered when an attempt is made to commit a change to Clay that affects one or more files needed to build the module. For example, if the 'foo' agent's source, defined in `/app/foo/hoon`, imports the 'bar' library from `/lib/bar/hoon`, then a modification to `/lib/bar/hoon` triggers an update to the 'foo' agent. All vanes and userspace files depend on Zuse, which depends on the Arvo and Hoon sources, so a change to the Hoon, Arvo, or Zuse sources will trigger updates to all vanes and userspace files.
8689
87−When asked to perform a commit, Clay determines which layers need to be updated based on which files have changed and which modules depend on those files. For now, all running programs load their source from the `%home` desk, so only changes to `%home` trigger stateful updates. Files in other desks can be built, but not installed into the system. This might be relaxed in the future.
90+When asked to perform a commit, Clay determines which layers need to be updated based on which files have changed and which modules depend on those files. For now, all running programs load their source from the `%home` desk, so only changes to `%home` trigger stateful updates. Files in other desks can be built, but not installed into the system. This might be relaxed in the future.
8891
8992The process of updating varies by layer. The Hoon and Zuse layers are stateless, so their newly rebuilt cores (Nock executables) must be stored (somewhere in the system’s Nock tree, in memory; remember, Urbit is a single-level store), but they have no state that would need to be migrated. The Arvo kernel, vanes, and userspace agents are all live, stateful programs, so in order to update one of those, the system must extract the state from the old program, pass that data into the newly built program, then discard the old program and store the new one. Arvo and agent state injection routines can emit effects, but vane updates cannot.
9093
@@ -125,7 +128,7 @@ When Gall receives a newly rebuilt agent from Clay, it calls the gate produced b
125128It is a bit counterintuitive that an app reload failure could prevent a kernel update. The reason is that we don't want the system to update itself into a broken state. An Urbit can be rendered practically unusable by the presence of broken agents, even if the kernel hasn't lost integrity,
126129so it's kinder to the user not to break their agents by installing an incompatible kernel update. This also puts virtuous pressure on kernel developers not to "break userspace", the importance of which has been insisted on for decades by Linus Torvalds, among others.
127130
128−If an agent does crash a commit event that included a kernel update, the attempted commit is now trivially rolled back, and the system can deliver an error message to the user. This does not leave the system in an inconsistent or stuck state, so the user could modify the failing agent and try the kernel update again later. Supporting better workflows for keeping third-party agents up-to-date will be an important aspect of Urbit’s upcoming software distribution work.
131+If an agent does crash a commit event that included a kernel update, the attempted commit is now trivially rolled back, and the system can deliver an error message to the user. This does not leave the system in an inconsistent or stuck state, so the user could modify the failing agent and try the kernel update again later. Supporting better workflows for keeping third-party agents up-to-date will be an important aspect of Urbit’s upcoming software distribution work.
129132
130133## Ford Build Semantics
131134
@@ -141,7 +144,7 @@ Clay exposes file builds into the scry namespace with `%ca`: as an example, `.^(
141144
142145#### Mark Builds
143146
144−A mark build produces a `$dais` mark-interface core. It first performs a file build on the Hoon file in `/mar` that defines the mark core, then it does some metaprogramming to make the operations more convenient to use. If the raw mark core delegated revision control operations to another mark core, the mark build will also load the delegate mark core and resolve the result into the `$dais`.
147+A mark build produces a `$dais` mark-interface core. It first performs a file build on the Hoon file in `/mar` that defines the mark core, then it does some metaprogramming to make the operations more convenient to use. If the raw mark core delegated revision control operations to another mark core, the mark build will also load the delegate mark core and resolve the result into the `$dais`.
145148
146149Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(dais:clay %cb /~zod/home/3/mar/foo/hoon)` builds a `$dais` for the `%foo` mark.
147150
@@ -149,15 +152,14 @@ Clay exposes mark builds into the scry namespace with `%cb`: as an example, `.^(
149152
150153A cast build produces a `$tube`: a gate that takes a value of one mark as input and converts it to a valid value of another mark or crashes. To convert from mark `%foo` to mark `%bar`, Clay tries the following operations, in order:
151154
152−+ direct grow from `%foo`
153−+ direct grab from `%bar`
154−+ indirect jump from `%foo` through `%qux`
155−+ indirect grab from `%bar` through `%qux`
155+- direct grow from `%foo`
156+- direct grab from `%bar`
157+- indirect jump from `%foo` through `%qux`
158+- indirect grab from `%bar` through `%qux`
156159
157160The `%foo` mark can “grow to” `%bar` by providing an arm in its `+grow` core named `+bar`. `%bar` can convert from `%foo` using a `+foo` arm in its `+grab` core. `%foo` can also chain a conversion through an intermediary using an arm in its `+jump` core, and `%bar` can specify an “indirect grab” by having a `+grab` arm produce a delegate mark instead of directly defining a conversion gate.
158161
159−Clay exposes cast builds into the scry namespace with `%cc`: as an example, `.^(tube:clay %cc
160−/~zod/home/3/foo/bar)` builds a `$tube` conversion gate from `%foo` to `%bar`.
162+Clay exposes cast builds into the scry namespace with `%cc`: as an example, `.^(tube:clay %cc /~zod/home/3/foo/bar)` builds a `$tube` conversion gate from `%foo` to `%bar`.
161163
162164### Ford Runes
163165
@@ -202,8 +204,7 @@ A valid userspace hoon file must contain a nonempty list of hoons (hoon source e
202204
203205Urbit still needs to make better use of desks other than `%home` and the development process should be adjusted given the tighter coupling between source code and kernel and tighter criteria for accepting an update.
204206
205−This work also hopefully provides a good foundation of a package management and software distribution system for Urbit. As `~wicdev-wisryt` has said, a user should be able to run `|install
206−~norsyr-torryn/canvas` to load and build remote source. No one should experience dependency hell on Urbit, but we're not there yet.
207+This work also hopefully provides a good foundation of a package management and software distribution system for Urbit. As `~wicdev-wisryt` has said, a user should be able to run `|install ~norsyr-torryn/canvas` to load and build remote source. No one should experience dependency hell on Urbit, but we're not there yet.
207208
208209At least now, building a desk has no dependencies, other than a Ford with a compatible Hoon compiler. No decisions have been made on this yet, but
209210Ford might get moved to inside the desk, possibly by making Zuse callable. This could allow a desk to expose a Nock interface in addition to a typed Hoon interface, which could even let a desk be used as a "pill" bootloader.
@@ -216,8 +217,6 @@ In early 2020, `~master-morzod` suggested moving Ford into Clay to reduce asynch
216217
217218The first time I rewrote Ford, it took me six months, with help from `~littel-ponnys`, and it weighed in at 6,000 lines of code. The second time, in late 2018, took a few weeks. The third time, in January 2020, took a week. I wrote `+ford` in Ford Fusion in one long day, and it’s about 500 lines of synchronous, functional code.
218219
219−It has taken me two or three years to understand this problem as well as I do, and I expect there are parts of it I still don’t understand. The code itself isn’t the issue; it’s finding the right answer to ontological and teleological questions. What *is* Ford? What will it be in a hundred years? I’m confident Ford Fusion is more similar than its predecessor to the Ford of 2120, because it’s smaller, more functional, and easier to understand and administer.
220+It has taken me two or three years to understand this problem as well as I do, and I expect there are parts of it I still don’t understand. The code itself isn’t the issue; it’s finding the right answer to ontological and teleological questions. What _is_ Ford? What will it be in a hundred years? I’m confident Ford Fusion is more similar than its predecessor to the Ford of 2120, because it’s smaller, more functional, and easier to understand and administer.
220221
221222As an engineering discipline and organizational practice, working on a system intended to be frozen yields surprising simplifications like this every so often. Urbit is now reaching the point where we’re starting to see more of the obsidian edges of the frozen future system emerge from the lava.
222−
223−
content/blog/foss-1.mdnew file+64
@@ -0,0 +1,64 @@
1++++
2+title = "Urbit's Open Source Culture, Part I"
3+date = "2023-05-31"
4+description = "How did Urbit cultivate a unique open source software culture? Let's take a look at how we got to where we are today."
5+
6+[extra]
7+author = "N E Davis"
8+ship = "~lagrev-nocfep"
9+image = "https://upload.wikimedia.org/wikipedia/commons/a/a9/SR71_factoryfloor_SkunkWorks.jpg"
10++++
11+
12+
13+
14+> “Open source is an intellectual property destroyer. I can't imagine something that could be worse than this for the software business and the intellectual-property business.” (Jim Allchin, Microsoft executive)
15+
16+A founder's personal enquiry into the foundations of practical computing grew into a skunkworks startup to build an alternative basis for principled computing, and has now evolved into a burgeoning open source platform and community.
17+
18+- [Moron Lab, “Maxwell's equations of software (Nock)” (~2010.1.9)](https://moronlab.blogspot.com/2010/01/nock-maxwells-equations-of-software.html)
19+- [Moron Lab, “Urbit: functional programming from scratch” (~2010.1.13)](https://moronlab.blogspot.com/2010/01/urbit-functional-programming-from.html)
20+
21+How did Urbit cultivate a unique open source software culture? Let's take a look at how we got to where we are today.
22+
23+Open source culture really got going in the 1980s with the restrictive Unix licensing scheme and the consequent publication of the GNU software tools. With the marriage of GNU to Linux ([“I'd like to interject for a moment”](https://copypastatext.com/id-just-like-to-interject-for-a-moment/)), a full stack, from the bare metal to the end user, was possible. Usenet and early Internet forums furthermore encouraged interested developers to start contributing actively.
24+
25+The ethos of open source software drew on a number of sources, from William Gibson's _Neuromancer_ trilogy to “A Cypherpunk's Manifesto.” Those involved were often motivated by a healthy distrust of proprietary software. The big break for open source software (OSS) came with the [Unix ownership lawsuits](https://en.wikipedia.org/wiki/Unix_wars), which gave GNU/Linux a chance to break into the bigtime for systems software. The [2001 case against Microsoft](https://en.wikipedia.org/wiki/United_States_v._Microsoft_Corp.) as a monopoly lent further credence to the open source mandate.
26+
27+During this time, Urbit began life as a personal dissertation, in a sense, to derive a minimalist practical set of computing expressions as a combinator calculus. The early concepts that became part of Urbit, such as kelvin versioning and Maxwellian code, show up during its first decade. Nock was not open source for two reasons: the founder's conviction that as software it was already public domain, and the fact that there was no one yet to collaborate with.
28+
29+It was about a decade before Tlon was started as a small bespoke programming house to work on the esoteric project of defining something usable on top of the minimalist Nock specification. No one knew about Urbit besides some blog readers, and unless you worked in or next to Tlon you had basically zero chance of following the project via software alone.
30+
31+Early Tlon did a fairly good job of putting their software out there, but the documentation and nomenclature were considered obscurantist and the project was described as performance art or a deliberate wild goose chase. These combined to make Urbit appear fairly opaque, despite open development using GitHub and the liberal MIT license. System components like Nock and Arvo were declared public domain or liberally licensed.
32+
33+To this point (let's say 2019), Urbit was by license and by code an open source project, but had a reputation for being basically impossible for an outsider, even one with a fair amount of coding experience, to really figure out what's going on without serious handholding from the core devs. (Nor is this inappropriate for a small startup at this stage—it simply is the way most nominally OSS projects function.) However, the mystery engaged others beyond Tlon to brave the wilds and figure out what this Urbit project was all about.
34+
35+Urbit’s goal has always been to produce a stable kernel for all time, referred to by a metaphor of losing heat energy and entropy. As Urbit gradually cooled from red hot slag to what we'll call a developer alpha, Tlon began a project of greater outreach to the developer community. In particular, crypto software developers saw attractive aspects in Nock's concision and apparent provability and in Urbit's functional-as-in-math approach to operating system and application state. Tlon started a Discord for onboarding and troubleshooting, including community concierges who were tasked with engaging anyone with ship troubles. This tapped into and fostered a culture of Urbiters aggressively helping others debug and troubleshoot their ships, which continues to this day. Tlon also began Hoon 101 to teach outsiders how to actually build things on Urbit.
36+
37+As Urbit slowly grew into a larger developer community, some hard strategic questions about project scope and direction came into focus. There had always been a provision for Urbit to have some sort of foundation with stewardship over the project—either the Urbit Educational Foundation or something similar. Like the Linux Foundation, this organization would serve to coordinate activity between various companies and individuals contributing to the Urbit project. The foundation would receive an endowment of galaxies earmarked to fund Urbit's development.
38+
39+Urbit's use of address space to fund development means that the builders, even those who have discovered Urbit relatively recently, are able to acquire a significant stake in the project and its success.
40+
41+In practical terms, Tlon started the Urbit Foundation internally first as `urbit.org`, then rolled it out as a standalone company with a mandate to first build itself into a viable cultivator of Urbit, then to take over Urbit core development. By early 2023, the Urbit Foundation was in a position to take over core development for the platform.
42+
43+There have been several aspects of this journey that have led Urbit to have a thriving and promising open source software culture:
44+
45+1. Urbit's nature as a functional operating system has a deep appeal to software developers and others who find appeal in a mathematically elegant system, including the guarantees made by innovations such as the scry namespace bindings and the public key infrastructure.
46+2. Hoon is a mood. What I mean by that is that Hoon's unique aesthetics, subject-oriented paradigm, and the utility of cores give coders a unique experience, like systems programming in APL would feel like.
47+3. The developer docs are finally prioritized and made publicly legible. Large swaths of the operating system and standard library are finally documented.
48+4. Third-party software distribution is made trivial. Decentralized peer-to-peer open source software distribution without having to go through a GitHub intermediary changes the game.
49+5. Urbit's educational program expands from Tlon's initial offerings to a community program (Hooniverse/Hooniversity), then to a dedicated program with specific course milestones under the auspices of the Urbit Foundation.
50+6. Urbiters start meeting in person at Assembly and other events. After the 2020 efflorescence of the Urbit community, this is the first time most of the newer people were able to meet in real life. (This is a substantially different situation than the pre-2019 Urbit environment—most people didn't know Tlonners first, they knew Urbit first and mainly online.)
51+7. Three major active groups form dedicated to all-purpose coding on Urbit:
52+ A. Hooniverse, ~hiddev-dannut/new-hooniverse, originally strictly for the community Hoon School but now for all of the UF's educational efforts.
53+ B. The Forge, ~middev/the-forge, for advanced technical discussion.
54+ C. `[battery payload]`, ~dister-dozzod-lapdeg/battery-payload, the UF's developer community group.
55+8. The Urbit Foundation begins an active grants program. At first focusing on userspace and cultural grants, this eventually leans back into kernel work.
56+9. As the Urbit Foundation takes over core development, this necessitates changing that process from being a one-company project to requiring coordination, said coordination being much easier in the open than in closed meetings. (This also enables Tlon to focus on product delivery over core development.)
57+10. The Urbit Foundation begins using a `gather.town` “Urbit Hacker House,” which puts people together for synchronous interrupts. Any community member can wander in and be a fly on the wall or an active interlocutor.
58+ A. This enables the UF to start hosting daily pull request triage and a rapid assignment of tasks in the open.
59+ B. Communications strategy meetings are also public.
60+ C. Build parties (originally conceived as app-in-a-day) demonstrate pair programming, achieve inter-programmer communication of information akin to IRL programming, and allow anyone to participate.
61+
62+We find ourselves, as Urbit developers, having grown together a strong and unique culture of open source software development verging on radical transparency. It's not just code and license being open—it's the entire ensemble of programmer culture and on-platform dogfooding (to the extent possible). The greybeards and the noobs encounter each other directly and openly all the time, in `gather.town` and in Urbit groups.
63+
64+From modest beginnings, Urbit has achieved some small traction in the world and grown an exemplary open source culture. What will it take for Urbit to succeed in the future? That's the next entry.
content/blog/foss-2.mdnew file+59
@@ -0,0 +1,59 @@
1++++
2+title = "Urbit's Open Source Culture, Part II"
3+date = "2023-06-13"
4+description = "How will Urbit continue to foster its innovative open source software culture?"
5+
6+[extra]
7+author = "N E Davis"
8+ship = "~lagrev-nocfep"
9+image = "https://spacecenter.org/wp-content/uploads/2023/02/img-apollo-mission-control-3.jpg"
10++++
11+
12+
13+
14+> God watches over fools, drunks, and the United States of America. (Otto von Bismarck, apocryphal)
15+
16+In our last installment, we considered how Urbit has grown its own robust open source culture. Now we look to the future: what will it take for Urbit to succeed, not only as an exemplary open source project but as a computing platform that delivers on its promise?
17+
18+Part of what makes an open source culture vibe is remix culture, the ability to rework the source material to produce novel components or manifestations. Urbit has the raw materials for this in spades, memetically and technically. It is up to us to keep these tools in our developers’ and enthusiasts’ hands.
19+
20+The default answer, which isn't terrible, is that Urbit should keep doing what it's done to get this far:
21+
22+1. Urbit should continue to prioritize decentralized development.
23+2. Urbit should lean into ownership-based incentives. Indeed, this is the most effective lever that the Urbit Foundation has.
24+3. Urbit should maintain the developer's republic. Core developers should rub shoulders with first-time Hooners.
25+4. Urbit should continue to ship source with code, since that is how code is actually distributed. The means of open source software are _necessarily in the user's hands_ with Martian software.
26+
27+There are some areas in which we hope to improve. Our documentation continues to expand, as do our educational offerings. We have a mandate to use the Urbit Foundation’s endowment of stars to produce the mature Urbit.
28+
29+What else should we have an eye to in the near future? There’s always more to do, but by prioritizing the items on this short list we would continue to elaborate our open source bona fides as a community and a steering foundation.
30+
31+1. **Code accessibility should be a priority.** Any computer language falls on the spectrum between machine legibility (the pole of machine code and assembly language) and human legibility (the pole of [Scratch](https://scratch.mit.edu/). All code must walk this line.
32+
33+ Hoon has had a reputation for being a language of dense expressions, which we believe is now being cleared by sunshine. However, Hoon's extensive sugar syntax and irregular expressiveness can make it challenging for those relatively new to Hoon to decipher programs. We can support their learning and entry into the ecosystem by defining a subset of Hoon syntax that we adhere to in all of the docs and some of the userspace code. Even if there is a "better" way to write it, we should prefer this restricted discipline in those cases. Let's call this subset "Hoon Prime." Hoon Prime will not always be the most concise Hoon code, and it will likely fail to maintain certain well-established preferences, like heavier expressions going to the bottom, but it should encourage developers to produce generators and agents from `%base`-distributed models as quickly as possible.
34+
35+ Hoon Prime should also adopt a standard of literate programming. Several example files already display such a self-documenting nature:
36+
37+ - [`simple.hoon` for solid-state subscriptions](https://github.com/wicrum-wicrun/sss/blob/master/urbit/app/simple.hoon)
38+ - [`deco.hoon` for doccords](https://github.com/urbit/urbit/blob/develop/pkg/arvo/lib/deco.hoon)
39+ - [`pals.hoon`](https://github.com/Fang-/suite/blob/master/app/pals.hoon)
40+ - [`rudder.hoon` for serving websites](https://github.com/Fang-/suite/blob/master/lib/rudder.hoon)
41+
42+ Our userspace code accessibility model should allow contributors from widely different skill levels to interact. We need to surface and document code patterns as cleanly as possible in the code we distribute. We need to include comments and unit tests so people can see how and why code works like it does.
43+
44+ Code accessibility cannot be an afterthought. We need to upgrade as much code as possible to A standards [per the style guide](https://developers.urbit.org/reference/hoon/style#grading).
45+
46+2. We need to improve the developer experience. Part of this involves better coding support, and part of this involves better debugging support.
47+
48+ To promote better coding, we should continue to develop IDE integrations like the Hoon Language Server. We've had some significant wins here, but rust never sleeps. We should also continue to produce userspace and middleware support libraries. We need to pay attention to how developer preferences are manifesting in their workflows and tooling.
49+
50+ Better error messaging and debugging support, perhaps even a framework for line-by-line code execution, would be invaluable. Upgrading Dojo and generator support is an easy win. Any tool friction is a sin and we need to track this and think about how to improve use.
51+
52+3. We need our open source culture to continue to develop in the sunlight. We need to highlight and communicate user stories for developer tools, new and old. We need to share these from inside of companies in the ecosystem. I'm not going to call for “best practices”—it's too early and that's too corporate—but tacit knowledge and horizontal skill transfer need to be encouraged through active pair programming and utilization of build parties and the like.
53+
54+ We need to expose how bugs occur, propagate, and are corrected. The core development team has committed to public [postmortems](https://github.com/urbit/urbit/issues/6583) when things go wrong.
55+
56+4. Ultimately, Urbit has to stay playful. Urbit makes programming, even systems programming, a lot of fun. Fun is open-ended and surprising. It allows for whimsy in code and product.
57+
58+Our developer onboarding and open source culture should be a model for the entire open source world. This is neither impossible nor impractical—we've made huge strides in legibility, and we're sailing with the wind.
59+
content/blog/gifts-q3-2020.mdnew file+72
@@ -0,0 +1,72 @@
1++++
2+title = "Gifts Q3 2020"
3+date = "2020-09-22"
4+description = "Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our Gifts program, the gifting of address space has been part of Urbit long before we had a grants program."
5+
6+[taxonomies]
7+grant_type = [ "Gift" ]
8+grant_category = [ ]
9+
10+[extra]
11+author = "Josh Lehman"
12+ship = "~wolref-podlex"
13+image = "https://media.urbit.org/site/posts/essays/gifts.png"
14++++
15+
16+
17+
18+Twice a year we distribute address space to those that have made valuable contributions to Urbit. Now called our _Gifts_ program, the gifting of address space has been part of Urbit long before we had a grants program.
19+
20+I'm happy to announce that urbit.org has a record number of gifts to distribute to community contributors for the period from February to August of 2020. Because the gifting of address space is an old tradition, and the last several months have seen an unprecedented amount of user growth, let’s talk about why we do this.
21+
22+## Why gifts?
23+
24+One way to think about Urbit is as _infrastructure for powering digital communities._ We’ve talked about this before in [some detail](https://urbit.org/blog/urbit-is-for-communities/), so while I won’t rehash the “why” of that here, I’ll reiterate that what we really want is a digital world that's generated by the communities that inhabit it.
25+
26+We know that digital communities need better technology with which to generate their world; just as importantly though, they need _people_ to inhabit and develop them.
27+
28+Tlon and urbit.org can’t bring the world into Urbit alone—we need community members to help us. By distributing address space to a variety of people that can invite their friends and families, the network can grow faster, more organically, and with a wider range of diversity.
29+
30+Currently, the majority of available address space is owned by Tlon and urbit.org, but it won’t stay that way. Instead, we want to give address space to folks that want Urbit to succeed. Because we’re custodians of something valuable it’s important that we are intentional about how we handle it. We treat that responsibility seriously.
31+
32+Gifts are one of the ways we invest in the future of the network. We look for others that see Urbit’s value and engage in building the digital home that they want to live in. They ease the learning curve for people new to Urbit, contribute to the technology, and create thriving communities.
33+
34+## Recipients
35+
36+Gifts are being awarded for a variety of reasons this quarter. As usual, there have been plenty of code and documentation contributions, but this time around we’re also recognizing those who have evangelized Urbit, been active in guiding newcomers to the system, and developed thriving communities within Landscape.
37+
38+Gifts are being awarded using the following criteria:
39+
40+**Bronze**: one star for continuous contributions over the last six months in at least one of the above areas.
41+
42+**Silver**: two stars for creation of something exceptional and/or contributing across many categories.
43+
44+**Gold**: three stars awarded to one contributor who has contributed at a volume that indicates a high degree of care and ownership.
45+
46+Without further ado, here are the recipients:
47+
48+### Gold
49+
50+[`~radbur-sivmus`](https://github.com/tylershuster) has more or less become an unofficial member of the interface team by tackling an absolutely [immense](https://github.com/urbit/urbit/pulls?q=is%3Apr+author%3Atylershuster+) amount of Landscape-related work.
51+
52+### Silver
53+
54+- [`~littel-wolfur`](https://github.com/ryjm): Jake maintains the premier development group in Urbit, The Forge, and has led the way for other developers by authoring [srrs](https://github.com/ryjm/srrs), one of the more popular community-developed applications on Urbit.
55+- [`~botter-nidnul`](https://github.com/botter-nidnul): `~botter` has been instrumental in furthering [Urbit on ARM](https://botter-nidnul.github.io/), has made contributions across Vere and our documentation, and been highly active in onboarding newcomers on our Discord server.
56+- [`~timluc-miptev`](https://github.com/timlucmiptev): `~timluc` is highly engaged in many groups and the maintainer of some, wrote the [Nock for Everyday Coders](https://blog.timlucmiptev.space/part1.html) guide, and has gone far above and beyond in teaching the community about developing Landscape applications.
57+- [`~lanrus-rinfep`](https://github.com/dclelland): Daniel has done extensive development on iOS by writing Swift libraries for interacting with Urbit, and employed all of these towards the development of an [iOS client for chat](https://github.com/dclelland/UrsusChat).
58+- [`~minder-folden`](https://twitter.com/the_pritchard): Jonathan is a prolific member of the community. His group _The Sanctorium_ is always active, he's always around to help newcomers to the system, is an active evangelist on Twitter, and a creator of much excellent content.
59+
60+### Bronze
61+
62+- [`~watter-parter`](https://github.com/lukechampine): Luke has made a number of [contributions](https://github.com/urbit/urbit/pulls?q=is%3Apr+is%3Aclosed+author%3Alukechampine) to Arvo, and wrote a great [introductory guide](https://github.com/lukechampine/rote) to developing Gall agents.
63+- [`~naltyc-wornes`](https://github.com/JohnELester): `~naltyc` runs the popular group “Smol Computers” both inside and outside of Urbit where discussions ensue about various forms of computing on small devices like Android and ARM, and actively evangelizes the project.
64+- [`~nartes-fasrum`](https://twitter.com/nartesfasrum): `~nartes` evangelizes Urbit on Twitter by creating artwork, and maintains the popular food-centric group “Urbytes.”
65+- [`~fonnyx-nopmer`](https://twitter.com/fonnyx_nopmer): `~fonnyx` maintains an active presence throughout many groups on Urbit and runs the first Urbit-centric podcast, [Hooked on fonnyx](https://www.twitch.tv/fonnyx).
66+- `~libhut-samwes`: `~libhut` started and maintains one of the most popular groups on Urbit centered on crypto and investing, and contributes to conversations throughout Urbit.
67+- `~salmus-master`: In addition to embodying the quality of high-level, respectful debate we like to see, `~salmus` created the group: “The Tribal Network,” where he maintains one of the most active long-form notebooks on Urbit.
68+- [`~fostyr-solfyr`](https://github.com/cmarcelo): `~fostyr` has submitted a number of PRs against Arvo, including a much-requested feature to reset the web login code.
69+- [`~sarpen-laplux`](https://github.com/xiphiness): `~sarpen` has done a significant amount of research and work on Ethereum ABI parsing and other Ethereum-related topics in addition to being an active participant in dialogues throughout Urbit.
70+- `~mister-todteg`: `~mister` is a top evangelist of Urbit on Twitter, has brought many newcomers onto the network, and has even made several hires for his company from within the network.
71+
72+Thank you to all who contributed to making Urbit what it is today!
content/blog/governance-of-urbit.mdnew file+43
@@ -0,0 +1,43 @@
1++++
2+title = "Governance of urbit.org"
3+date = "2019-01-10"
4+description = "Stewardship of the Urbit Project."
5+aliases = [
6+ "/posts/essays/governance-of-urbit",
7+ "/posts/governance-of-urbit"
8+]
9+
10+[extra]
11+author = "Erik Newton"
12+ship = "~patnes-rigtyn"
13++++
14+
15+
16+
17+## Summary
18+
19+Long before Urbit first appeared as a prototype in 2013, we considered Urbit address space to be property. Granted, Urbit property ownership was only reflected as a text file in a github repository – but it was always designed to be cryptographically owned, and we've always taken that file seriously.
20+
21+If you've ever looked at that text file, you've probably noticed that there has been a pool of Urbit assets there marked "urbit.org" since the beginning. Now that we're moving our property registry out of that repository and onto the Ethereum blockchain, we wanted to be as clear as we can be about what the plan is for those urbit.org addresses.
22+
23+The TL;DR is that "urbit.org" will likely split into a separate entity from Tlon in the future. For now though, Tlon and urbit.org have the same mandate, so separating them doesn't make sense. For the time being, Tlon will continue to manage and use urbit.org assets directly for platform development. As a first step toward making urbit.org independent we've started to develop a board of advisors who we hope will one day manage those assets independently.
24+
25+## Background
26+
27+The history of a few lines in a text file doesn't give a whole lot of context. So, first, let's fill in a few more of the details.
28+
29+In 2013 Curtis and Tlon each contributed 32 galaxies to a pool newly called "urbit.org." The idea at the time was to set aside address space to fund "platform development" – in the spirit of the IETF or the Mozilla foundation. This was long before anyone had heard of a Swiss blockchain foundation or anything of the sort. Our view was that it was going to take a lot of resources to build a system as robust and far reaching as Urbit intends to be, and 64 galaxies (25% of the total network) seemed sufficient. It was thought at the time that urbit.org might eventually take the form of a separate foundation, but we were simply too small and under-resourced a team to figure out the right legal structure at the time.
30+
31+Tlon – as distinct from urbit.org – has always been imagined as a future service provider in the urbit ecosystem. But Urbit is still young, so those services aren't really needed yet.
32+
33+Instead, what is needed is platform development. So Tlon has acted, in a way, as urbit.org was supposed to, by taking on the bulk of platform development efforts. This work consists of everything from kernel development to interface design and documentation. Tlon has sold (and granted) both its own galaxies, and some of those originally designated as urbit.org galaxies towards this end. We'll continue to do this for the foreseeable future, since Urbit's development needs (though finite) remain ongoing. We can't predict exactly how long this will continue, although we wish we could!
34+
35+## Future plans
36+
37+As Urbit becomes more widely used, we expect to make the Tlon/urbit.org separation real.
38+
39+We've considered the foundation model, but have come to the conclusion that it doesn't really make sense. For one, it's quite expensive in terms both of administrative overhead, and the associated legal costs. For another, there just isn't anyone we trust enough to take over high level management of such an organization (see Tezos). Finally, our view is that foundations are not entirely effective in their mandates (see [this article](https://nadiaeghbal.com/foundations) from our friend Nadia).
40+
41+One step we're pursuing is the creation of a board of advisors to guide our use of the urbit.org assets at Tlon. We're in discussions with several potential board members now. Our goal with this structure is to include more voices outside of Tlon in the process of governing the urbit.org assets, and to make their advice transparent to the public.
42+
43+As with all of our projects, we think it's better to walk before we run. For now, Tlon will continue to act as urbit.org and use both pools of resources for ongoing platform development. Next, we'll create a board to advise on the use of those resources. Eventually, Tlon and urbit.org will likely become separate entities. We'll get there – one step at a time.
content/blog/hackathon-results.mdnew file+59
@@ -0,0 +1,59 @@
1++++
2+title = "Hackathon Results"
3+date = "2020-06-11"
4+description = "We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality."
5+
6+[extra]
7+author = "Robert Mariani"
8+ship = "~lodleb-ritrul"
9+image = "https://media.urbit.org/site/posts/essays/hackathon-results-wide.png"
10++++
11+
12+
13+
14+Results of the Urbit Hackathon
15+
16+We recently held an invite-only Urbit Hackathon for graduates of our Hoon School program, and the submissions really impressed us across the board. Submissions were judged on several criteria: creativity, usefulness, and code quality.
17+
18+Congratulations to all the participants, especially the winners—their projects are seriously impressive.
19+
20+### First Place: Eight Stars
21+
22+Jose’s `~norsyr-torryn` Canvas is a peer-to-peer, collaborative drawing app that comes in the form of a Landscape tile. It’s kind of like a multiplayer MS Paint, but better.
23+
24+Canvas uses Urbit in a way that we think it’s supposed to be used: the stuff that doesn’t require peer-to-peer or storage heavy lifting, such as the actual “drawing” component of the app, is done outside of Urbit.
25+
26+In addition to a freehand template for the classic Paint experience, you can choose from a number of templates to work with, such as a grid of fillable hexagons, or maps of parts of the world and of continents with fillable country divisions. Have you ever wanted to compare which countries you visited, color-coded for how much you liked them? Canvas has a built-in feature for sharing your work on chats in Landscape.
27+
28+Check out a video [demonstration](https://www.youtube.com/watch?v=S6DySv730Hw) of Canvas, and view [the code](https://github.com/yosoyubik/canvas).
29+
30+Jose wins eight stars, and he also wins [le internet for the day](https://news.ycombinator.com/item?id=23228058). Bravo!
31+
32+### Second Place: Four Stars Each
33+
34+Luke Champine’s (`~watter-parter`) flashcard app for Landscape, Rote, has been awarded one of two second-place prizes.
35+
36+Rote users write decks in udon, review them, and share them with other ships. His immaculate backend code-style and documentation secured his high placement in the Hackathon—his Hoon code also functions as a full-blown walkthrough. If you’re a Gall novice and you’re looking to learn, take a look at his [code](https://github.com/lukechampine/rote). Luke also kept a Notebook documenting his experience at `~watter-parter/hackathon`.
37+
38+Luke also included example decks for flashcards on Hoon runes and their irregular forms. So, all said and done, everything about Rote is an excellent resource to the eager Hoon neophyte.
39+
40+Pyry Kovanen (`~dinleb-rambep`) was also awarded second prize for his reading-list-sharing app, Books. Also a Landscape tile, and it’s pretty darn useful, with the ability to import books from Goodreads. Check out [the code](https://github.com/pkova/urbit/tree/books/pkg/interface/books) and the [video demo](https://youtu.be/Spy7FoPdfx8).
41+
42+### Third Place: Two Stars Each
43+
44+N E Davis (`~lagrev-nocfep`) brought the heavy infrastructural artillery with Roessler, and won third prize. Roessler is actually three related Hoon tools:
45+`roessler` proper, a library for solving the differential equations producing the [Roessler attractor](https://en.wikipedia.org/wiki/R%C3%B6ssler_attractor).
46+`lazytrig`, a library for transcendental functions.
47+`proj-3d`, a generator that takes the 3D coordinates produced by `Roessler`.
48+
49+The Roessler project is full of cool, novel features. You might enjoy taking a look at the [GitHub repo](https://github.com/sigilante/roessler) ...if your brain is big enough.
50+
51+John Franklin (`~dirwex-dosrev`) also secured third place for his Notes application. True to its name, it’s a Landscape tile that allows the user to create and search notes by keyword. Look at the [code](https://github.com/jfranklin9000/notes/) and the [demo video](https://www.youtube.com/watch?v=7DurNjCFOmA).
52+
53+Jon (`~ribnes-fonbex`) was awarded third prize for his Quadratic Voting project. It implements for Urbit ships a [quadratic voting system](https://en.wikipedia.org/wiki/Quadratic_voting), which is sort of like ranked-choice voting but allows people to express their stronger preferences.
54+
55+Congratulations to the winners and to everyone who submitted—nice work!
56+
57+### The Future
58+
59+We were thoroughly impressed with all of the projects from this inaugural Hackathon. Not only did this Hackathon demonstrate the talent and dedication of our community members, it’s an encouraging sign about the maturity of the Urbit system. We’re going to hold more Hackathons in the future, with one big change: they will be open to anyone who applies.
content/blog/haleek-maul-interview.mdnew file+71
@@ -0,0 +1,71 @@
1++++
2+title = "NFTs, Urbit IDs, and Communities w/ Haleek Maul"
3+date = "2021-09-09"
4+description = "An interview with the founder of Holdersland"
5+[extra]
6+author = "Matt"
7+ship = "~tirwyd-sarmes"
8+image = "https://media.urbit.org/site/posts/essays/haleek_sigil.jpg"
9++++
10+
11+
12+
13+*Check out the Holdersland x Urbit collection: [holders.land/urbit](https://holders.land/urbit)*
14+
15+We sat down recently with Haleek Maul to discuss the current state of NFTs and the future of Urbit IDs and digital communities.
16+
17+Are Urbit IDs NFTs? Sure, they're ERC-721 non-fungible tokens which you can buy on OpenSea—but to be clear, we made them way back before the word "NFT" had entered mainstream consciousness. An Urbit ID is a number that is used to generate both a phonetic name and an avatar (what we call [sigils](https://urbit.org/blog/creating-sigils)), but it is so much more than your average NFT—it is a key to an entire digital world.
18+
19+We built Urbit IDs for digital communities and the people they’re made of. An Urbit ID is a decentralized and pseudonymous identity perfect for your collective, commune, squad, team, or DAO. Unlike most addresses or social identities, you own your Urbit ID like you own your crypto. Your Discord handle might be free for now, but as the saying goes, if it’s free then you’re the product. On Urbit your ID is actually yours and you pay for it up front. You can log into third party apps or software without ever relinquishing control of your data. What is yours stays with you. IDs themselves can be owned collectively—there are already DAOs on Urbit who jointly own stars and galaxies.
20+
21+Urbit IDs are evolving and generative. They’re generative because some IDs spawn additional NFTs which themselves can be bought and sold. For instance, each star can spawn 65,535 planets, and each galaxy can spawn 255 stars. The network itself is evolving, meaning that the network can be upgraded via a majority vote by galaxy holders. Urbit IDs and the Ubit network itself are inherently dynamic.
22+
23+At Urbit, we support communities of all kinds. We recently granted Holdersland ten Urbit IDs: four stars and six planets to be auctioned off. Haleek Maul (his Urbit ID is `~fosmex-hocmel`) will be creating custom artwork for each of the sigils. The proceeds of the auction will help support Holdersland in bringing blockchain technologies to the Caribbean. The auction will go live on September 16th, 2021 on [holders.land/urbit](https://holders.land/urbit).
24+
25+Without further ado, here’s Haleek Maul.
26+
27+---
28+
29+**Tell us a little bit about yourself and Holdersland.**
30+
31+Sure. My name is Haleek Maul and I’m a multi-disciplinary artist. I was born in America and came to Barbados when I was three years old. I’ve been making music since 2007. I put out my first debut project in 2012 and since then it has been a process of creating art from the stuff flowing through my mind.
32+
33+Holdersland is a digital extension of my artistic project—a way of creating change in the world around me. When I was younger, there weren’t many artists like me coming from Barbados. I was into a lot of niche electronic and club music and felt alienated from the larger conversation. Holdersland is a way to help creative people in the Caribbean connect with like-minded people around the world, especially using new technologies like blockchain. So I founded Holdersland in 2020 when I left my record label after four years. I felt like music institutions was archaic and didn’t feed into my other artistic practices. I wanted to create an institution that captured the full creative practice—all the way from creating to selling. Most importantly, I wanted to get artists from Barbados and the Caribbean involved in global conversations around art and technology.
34+
35+**What exactly is Holdersland?**
36+
37+It’s a company centered around Caribbean intellectual property. We’re trying to help people get connected with new web3 technologies, especially artists. Holdersland is an aggregator that helps connects those who are interested in new technology with those those who actually develop it.
38+
39+For example, there is a lot of math that underlies music. Part of our project is to extract these mathematical principles and see how they can help generate new forms of art that can be widely distributed. So we’re working to build our own projects and work with users to adopt some of these new technologies. It’s a community of people centered around these values. We plan to implement voting, governance, and incentive structures into the community soon.
40+
41+**What do you think is the link between your two main interests: music and technology?**
42+
43+I’ve always been interested in technology. Anyone who has made music in the last twenty years has had to get involved with tech. Especially if you’re a producer. There are many young kids who are downloading music software and messing around with it, and in the process becoming knowledgeable about music production and design. Science and math live right beside art.
44+
45+I was also into web development when I was a teenager and was very interested in how the internet worked. This led into the work I’m doing with Holdersland. Technology, more often than not, is concerned with collaboration and communication. But in order to develop new technologies we often need to talk about nitty-gritty details. This requires detailed knowledge of particular technologies.
46+
47+**What is the great hope or promise with new decentralized technologies like blockchain or Urbit?**
48+
49+They lower the barrier to communication and trade. Especially for countries like Barbados, we don’t have access to the world market. But now with these networks, and assets like NFTs, we can engage in commerce without borders. It allows new entrants to join the market.
50+
51+It also allows new financial relationships and funding structures to emerge. Rather than have a few people contribute $20k, you can have hundreds of people contribute $100. Once again, this lowers the entry for people to invest is early-stage projects. This changes the way that companies build and ship products.
52+
53+Brain drain is when skilled workers move abroad for more profitable employment. These new technologies allow native Carribeans to stay where they are while earning money. Using these new technologies, the Carribean can prosper while not losing its unique character and cultural identity. Crypto is permanently going to change the distribution of wealth and culture around the world.
54+
55+Discord is a fine community solution, but it’s not ideal. There’s an endless array of plugins and dependencies that makes Discord unstable. However, it is a good mixture of an office, a storefront, and a club: I can do my work, sell assets, and just have fun. Communities are important. People naturally want to be in communities, we just need a better solution than Discord. Especially one that’s crypto-native and allows for commerce. Urbit is a one-stop shop that could fill that gap.
56+
57+**What is the collaboration between Holdersland and Urbit that’s happening this week?**
58+
59+I’m producing some custom sigil artwork for a set of stars and planets. Both the Urbit assets and artwork will be auctioned off together. The proceeds from the event will go towards creating a community music studio here in Barbados and technology education around the island.
60+
61+A lot of people here in Barbados don’t even understand what crypto is. A lot of the work being done around this project is to raise awareness about the potentials of this new technology. I want this to be a general springboard for the Caribbean to gain greater technological literacy. That literacy is an important step for lower-income people to drastically change their situation.
62+
63+**What are you looking forward to talking about on the New World Energy panel at Assembly 2021?**
64+
65+I want to talk about how to migrate communities onto Urbit. How to use Urbit as a new platform for niche cultures found around the current internet. Also the great strength and power provided by Urbit’s digital identities.
66+
67+NFTs can be very powerful—there are a lot of possible applications of a unique digital asset. It’s already dissolved geographical boundaries which will help countries to export their intellectual products freely. Countries need first to gain knowledge around these technologies and their economies will follow.
68+
69+**Thanks for chatting!**
70+
71+See you at Assembly 2021!
content/blog/hoon-4-lispers.mdnew file+764
@@ -0,0 +1,764 @@
1++++
2+title = "A Perspective on Lisp and Hoon"
3+date = "2023-06-15"
4+description = "Lisp is an éminence grise of programming. How does Hoon compare?"
5+
6+[extra]
7+author = "N E Davis"
8+ship = "~lagrev-nocfep"
9+image = "https://engineering.stanford.edu/sites/default/files/styles/card_1900x950/public/images/news/john_mccarthy.jpeg?h=3751da6c&itok=6tPSih53"
10++++
11+
12+
13+
14+> In the beginning, von Neumann created the machine. And the machine was with rigorous form and code, and no compiler yet moved upon the face of the tubes. And the evening and the morning were the first day.
15+>
16+> And John Backus said, Let there be FORTRAN, and there was Fortran. And Fortran ruled over the assembly.
17+>
18+> And John McCarthy saw the lambda calculus, that it was very good. And McCarthy made the LISP and divided the programmers who were for the array from the programmers who were for the list.
19+>
20+> And the Fortran and the Lisp were the second day. And God set them in the firmament to give light upon the earth.
21+
22+Two great temperaments of programming language design span these poles: Fortran as the engineer of assembler-first hard-nosed array coding and Lisp as the math professor running down to the machine room waving papers. While they have ceded some to the practicalities of the other over time, each is a trope of a particular computing paradigm. In this article, we will examine the Lisp pole in light of Urbit's development language, Hoon.
23+
24+Hoon is a statically typed functional programming language that is designed to be safe, efficient, and expressive. Hoon has a unique syntax relying heavily on symbolic expressions (using “runes”) rather than traditional keywords and operators. Hoon's underlying execution language, Nock, has been described as a “pico-Lisp“, making reference to its nature as a cell-based combinator calculus. Both languages (Nock and Hoon) follow very much in the philosophical steps of Lisp but seek to improve the genre.
25+
26+Lisp is known for its powerful macro system, which allows developers to write code that generates more code at compile time, and for its powerful `eval` function; while Hoon provides a flexible metaprogramming system that allows developers to manipulate code at compile time and hot-swap code at runtime.
27+
28+This article will contrast classical Lisp syntax and assumptions with Hoon's design. As Lisp is a family of languages rather than a single implementation, I will strive to make generally applicable statements or qualify the discussion—I welcome nuance in your responses about the different major Lisp dialects.
29+
30+Hoon's characteristic structure has arisen from these overarching design principles:
31+
32+1. Hoon must compile to Nock, and benefits from reflecting Nock's calculational worldview.
33+2. Hoon must be capable of live upgrades; that is, conscious brain surgery on itself.
34+3. Hoon should grow organically based on actual developer usage patterns.
35+
36+Our investigation of Lisp and Hoon will compare their syntax, their metaprogramming affordances, and their underlying philosophies.
37+
38+
39+## Syntax
40+
41+Hoon has many commonalities with Lisp and its most common calling convention is sugared to appear like Lisp. The conventions of Nock differ—e.g. using `[]` brackets instead of `()` parentheses—and Nock does not have non-numeric tokens or names. Hoon serves as a more human-friendly syntax which mediates common expressions and structures much as C overlays assembly language. For practical purposes, we never need to write Nock code by hand, and so while Nock informs Hoon's design choices, we don't need to understand any Nock to talk about Hoon.
42+
43+Both Lisp and Hoon are homoiconic, meaning that code and data are directly represented the same way: Lisp code is represented as Lisp data structures, and Hoon code is represented as Hoon data structures. Homoiconicity means that code can be manipulated and transformed as data at runtime. While the most compelling investigation in this article focuses on metaprogramming, we need to start with a comparative syntax and grammar so we understand how code and data are represented.
44+
45+Before all of that, let us compare a simple program implemented in both Lisp and Hoon. Both programming languages are species of functional languages for which expressions result in values, but they handle side effects differently: in Hoon side effects are strictly impossible (although a runtime workaround permits I/O and necessary effects), while in Lisp side effects are permitted (although opinions on their use vary). We will therefore not use a trivial “Hello World” example. Instead we will calculate the arithmetic mean of a set of numbers of known size.
46+
47+```scheme
48+(define (mean a)
49+ (if (null? a)
50+ 0
51+ (/ (apply + a) (length a))))
52+```
53+
54+```hoon
55+:: Common (sugared) form
56+++ mean
57+ |= a=(list @ud)
58+ ?~ a 0
59+ (div (roll a add) (lent a))
60+
61+:: Rune (unsugared) form
62+++ mean
63+ |= a=(list @ud)
64+ ?~ a 0
65+ %+ div
66+ %- roll [a add]
67+ %- lent a
68+```
69+
70+The Scheme code has the advantage that it reads almost English-like as one works through the logic, but implicitly relies on familiarity with the `if`/`then`/`else` structure and function application using `()` (on which more soon).
71+
72+The Hoon code uses the `%` function application runes (differentiated by number of arguments) to apply the function calls. With syntactic sugar, this looks similar to the Lisp call, with `++roll` instead of `apply` and `++lent` instead of `length`.
73+
74+Throughout I will use code examples for Lisp taken from [Rosetta Code](https://rosettacode.org/wiki/Category:Scheme). I will select or compose Hoon examples to be structurally similar to the Lisp code in order to facilitate comparison. I will also avoid sugar syntax that would obscure the structure of the Hoon code; in some cases this will make it slightly less readable than its equivalent in practice.
75+
76+### Syntax in Lisp
77+
78+#### Types
79+
80+Lisp types are dynamic, checked at runtime rather than on compilation. Since everything is an object, some assumptions can be made about manipulation and behavior. Most Lisp dialects share these types:
81+
82+- Numbers, including integers and floating-point numbers.
83+- Characters.
84+- Strings, as a sequence of characters.
85+- Lists, as a sequence of objects (including lists).
86+- Symbols, names used to refer to a function, variable, or other object.
87+- Arrays, a fixed-size multidimensional indexed object collection.
88+
89+Lisp code, being dynamically typed, is inclined to try a value and see if it works in a given context. However, some restrictions can be made, such as an argument type declaration on a function:
90+
91+```lisp
92+(defun add-two-integers (x y)
93+ (declare (type integer x y))
94+ (+ x y))
95+```
96+
97+Lisp types are to some extent (justly) influenced by the underlying platform architecture: Lisp is generally compiled directly to machine code (like a C program), with the notable exception of [Clojure](https://clojure.org/reference/lisps) which runs on the Java Virtual Machine.
98+
99+#### Operators, Functions, Macros, and Thunks
100+
101+Lisp syntax is characterized by its use of nested lists, called S-expressions (symbolic expressions), which consist of parentheses enclosing atoms or other S-expressions. The basic structure of an S-expression is an operator (or function) followed by its arguments, all enclosed in parentheses. For example, the following S-expression performs a simple arithmetic operation:
102+
103+```lisp
104+(+ 1 2 3)
105+```
106+
107+Lisp uses prefix notation, where the operator comes before the operands, and parentheses are used to group expressions. The S-expression is evaluated from left to right (in most Lisps save Scheme), with the operator being applied to its arguments.
108+
109+Operators in Lisp operate on values of different basic types. Lisp dialects vary in their particular base types, but typically include numbers, strings, booleans, and so forth. The core data type is the list, of course (LISP is for LISt Processing). Since Lisp biases towards list processing, many operators are comfortable receiving an arbitrary number of values as inputs, as in the code sample above.
110+
111+In Lisp, [`cons`](https://en.wikipedia.org/wiki/Cons) describes the procedure to construct a pair of objects. This seemingly modest capability is fundamental to how Lisp builds lists—and since everything is a list, `cons` has consequences. One fundamental convention is the `cons` cell, which consists of two other Lisp objects and is how lists are actually constructed.
112+
113+
114+
115+Lisp operations are built either as functions or as macros. Functions produce results directly from their inputs. Macros by contrast are basically function-building functions, and produce expressions that can be evaluated with inputs to get a result.
116+
117+A Lisp function is created using `defun`:
118+
119+```lisp
120+> (defun square (x) (* x x))
121+SQUARE
122+
123+> (square 2)
124+4
125+```
126+
127+(Lisp dialects tend to not be case-sensitive.)
128+
129+Lisp functions are first-class objects and can be manipulated and passed like values of basic types as well.
130+
131+Before we can look at macros, we need to consider Lisp's notion of evaluation and in particular deferred evaluation. For Lisp, an expression can be marked as a literal value rather than evaluated to produce a result. The quote `'` symbol is used to mark expressions for prevented evaluation:
132+
133+```lisp
134+'(1 2 3) ; evaluates to the list (1 2 3)
135+'foo ; evaluates to the symbol FOO
136+(1 5) ; evaluates to the list (1 5)
137+'(1 (+ 2 3)) ; evaluates to the list (1 (+ 2 3))
138+```
139+
140+Backtic or backquote `` ` `` allows you to switch an expression in and out of evaluation mode, along with `,` to mark evaluated components for splicing back into the unevaluated expression.
141+
142+```lisp
143+`(1 2 3) ; evaluates to the list (1 2 3)
144+`foo ; evaluates to the symbol FOO
145+`(1 ,(+ 2 3)) ; evaluates to the list (1 5)
146+```
147+
148+A Lisp macro is essentially a compile-time function.
149+
150+```lisp
151+> (defmacro square (x)
152+ "Returns the square of the input value."
153+ `(* ,x ,x))
154+
155+> (square 2)
156+4
157+```
158+
159+(The `` ` `` notation constructs the expression with values spliced in by `,`.)
160+
161+A deferred evaluation, called a thunk, is a closure that inherits its lexical environment but is deferred for later computation. Thunks enable lazy code evaluation and separate the computation’s definition from its execution.
162+
163+```lisp
164+(defun create-thunk (function &rest arguments)
165+ (lambda () (apply function arguments)))
166+
167+(defun invoke-thunk (thunk)
168+ (funcall thunk))
169+
170+;; Creating a thunk that calculates the factorial of a number
171+(defvar factorial-thunk (create-thunk #'(lambda () (factorial 5))))
172+
173+;; Invoking the thunk to get the result
174+(print (invoke-thunk factorial-thunk)) ; Output: 120
175+```
176+
177+In this code example, `create-thunk` accepts a function and returns a thunk created using a lambda function to encapsulate the computation. `invoke-thunk` is used to invoke the thunk to get the actual result. The actual application creates a deferred factorial implementation and then finally invokes it. Without the last line, the actual calculation would never be executed.
178+
179+As Paul Graham wrote, “The unusual thing about Lisp-- in fact, the defining quality of Lisp-- is that it can be written in itself.” A Lisp program is an S-expression, and in principle we can run the equation the other way: certain S-expressions are valid Lisp programs. Although uncommon in practice due to code safety issues, the `eval` function is illustrative of Lisps’ ability to evaluate a Lisp expression that is represented as a data structure. It takes a single argument, which is a Lisp expression, and returns the value of that expression. Lisp programs can in principle generate new code—or modify existing code—and evaluate it on the fly, since code is data.
180+
181+```lisp
182+(defvar x 10)
183+(defvar y 20)
184+(defvar z '(+ x y))
185+
186+(eval z)
187+```
188+
189+Besides explicitly named functions and macros, Lisp frequently employs lambda expressions to produce functions on demand at the point of use.
190+
191+```lisp
192+> ((lambda (x y) (+ x y)) 5 10)
193+15
194+```
195+
196+Naturally, we have not covered all of Lisp, but the above should motivate how Hoon differs from Lisp. Furthermore, Lisp is really a family of languages, so there is a fair amount of variation in specifics.
197+
198+- [Paul Graham, _On Lisp_](http://www.paulgraham.com/onlisptext.html)
199+
200+### Syntax in Hoon
201+
202+#### Types
203+
204+Hoon compiles to Nock and runs on a Nock virtual machine interpreter. Nock knows only about nouns, that is to say either simple unsigned integers or pairs of other nouns.
205+
206+> To be exact, a noun is an S-expression, except that classic S-expressions have multiple atom types ("S" is for "symbol"). Since Nock is designed to be used with a higher-level type system (such as Hoon's), it does not need low-level types. An atom is just an unsigned integer of any size.
207+
208+
209+One of the biggest differences between Hoon and Lisp lies in their respective type systems: Hoon is statically typed while Lisp is dynamically typed. Furthermore, since Hoon compiles to Nock, ultimately every value, expression, and program in Hoon results in a noun (an atom or unsigned integer, or a cell or pair of nouns). (The compiler may make this process slightly opaque, but it is deterministic.) Types, if values are known, must match or nest properly at compile time.
210+
211+Hoon implements types as a metadata layer over bare Nock numbers and atoms. (The implementation details do not concern us but can be seen using the `!,` zapcom rune, which produces the abstract syntax tree of an expression.) Hoon atom types include various numeric types (signed and unsigned, hexadecimal, binary, etc.); address space identifiers (such as ~zod); IP addresses; UTF-8 text; and floating-point values, [among many others](https://developers.urbit.org/blog/literals). As these are interpretations laid over the bare integer, it is trivial to convert among them, a convenience like C affords.
212+
213+```hoon
214+:: raw unsigned decimal integer
215+> 123
216+123
217+
218+:: hexadecimal integer
219+> `@ux`123
220+0x7b
221+
222+:: UTF-8 text
223+> `@t`123
224+'{'
225+
226+:: relative datetime (a small fraction of a second)
227+> `@dr`123
228+~s0..0000.0000.0000.007b
229+
230+:: address mnemonic (ship name)
231+> `@p`123
232+~rux
233+
234+:: IPv4 address
235+> `@if`123
236+.0.0.0.123
237+
238+:: IPv6 address
239+> `@is`123
240+.0.0.0.0.0.0.0.7b
241+```
242+
243+A cell is a pair of two nouns, and of course many compound types exist, including lists (a null-terminated series of cells). A file path in Urbit is, for instance, a list of resource names (a `path`). A manipulable text string is a list of single bytes for characters (a `tape`). Maps (associative arrays), sets, and other containers round out the basic data structure types, but more complex types such as HTTP headers and app metadata are available. Even app actions have an associated type so that the set of actions is enumerable and validated. Here, for instance, are some cryptographic types from the standard library:
244+
245+```hoon
246++$ jacobian [x=@ y=@ z=@] :: jacobian point
247++$ point [x=@ y=@] :: curve point
248++$ domain
249+ $: p=@ :: prime modulo
250+ a=@ :: y^2=x^3+ax+b
251+ b=@ ::
252+ g=point :: base point
253+ n=@ :: prime order of g
254+ ==
255+```
256+
257+Hoon expressions are ultimately binary trees of cells and atoms—Hoon is homoiconic and so code is directly represented as a data structure which can be interpreted as a value as well. This facilitates Hoon's ability to upgrade itself in place, as we will see.
258+
259+Hoon commonly implements types structurally via _molds_, or functions which coerce to type or crash. A mold is a way of asserting known type information over a value, typically at compile time, in a way that allows for data transformation and data validation. This leads to some interesting cases such as the difference between a null-terminated tuple and a true list, which some functions require.
260+
261+```hoon
262+> ~[1 2 3]
263+[1 2 3 ~]
264+
265+> `(list @)`~[1 2 3]
266+~[1 2 3]
267+
268+> (snag 2 ~[1 2 3])
269+mull-grow
270+-need.[i=@ud t=%~]
271+-have.%~
272+nest-fail
273+dojo: hoon expression failed
274+
275+> (snag 2 `(list @)`~[1 2 3])
276+3
277+```
278+
279+Hoon implements a unique character literal syntax for every single atom type, allowing any value to be unambiguously interpreted by the parser per the developer's intent. You can see this somewhat in evidence in this comparison chart:
280+
281+| Type | Lisp Type | Hoon Type |
282+| --- | --- | --- |
283+| (Unsigned) integer | `1` | `1` |
284+| Signed integer | `-1`, `1` | `-1`, `--1` |
285+| Symbol | `x` | `%x` |
286+| Real/FP | `1.5` | `.1.5` |
287+| Character | `#\c` | `'c'` |
288+| Text | `"Hello"` | `'Hello'` (as atom); `"Hello"` (as list) |
289+| Rational | `2/3` | (no Hoon equivalent) |
290+| Address | (no Lisp equivalent) | `~sampel-palnet` |
291+
292+Much of Hoon's practical power derives from how it represents and manipulates nouns as data and as code.
293+
294+> The type of type is just a normal datatype in Hoon, and a lot of the system manipulates types. In particular, the `!>` rune, when applied to a piece of data, uses compile-time type reflection to produce something called a "vase": a pair of type and data, similar to a `Data.Dynamic` in Haskell, or a limited form of a dependent pair. Since the Arvo kernel does a lot of dynamic compilation, it uses vases to implement something akin to a dynamically typed language using Hoon. This allows for type-safe dynamic program loading, program execution, and data migration. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))
295+
296+A `vase` in Hoon is a cell of type and value. Typically `vase`s are produced with the `!>` zapgar rune. We use `vase`s to carry type information where otherwise it may be lost, such as in transmission over the wire to another Urbit instance.
297+
298+```hoon
299+> !>('hello')
300+[#t/@t q=478.560.413.032]
301+
302+> !>([5 10])
303+[#t/[@ud @ud] q=[5 10]]
304+
305+> !>(`(list @)`~[1 2 3])
306+[#t/it(@) q=[1 2 3 0]]
307+
308+> !>(`(list @)`~)
309+[#t/it(@) q=0]
310+```
311+
312+A `vase` can be used at runtime to resolve a value from a dynamic context into an executable Hoon expression, and this is commonly done with web-based input, for instance, where insufficient information will be available at compile time to resolve the type correctly.
313+
314+#### Expressions
315+
316+Nock explicitly consists of binary trees, since any Nock structure or program consists entirely of atoms (bare values) and cells (pairs of nouns).
317+
318+
319+
320+Expressions are oriented around runes, which act as operators to join or manipulate expressions. To construct a cell of two values like `1` and `2`, one uses the `:-` cencol rune. (Hoon cells implement what we call an “implicit `cons`”, meaning that two nouns composed together are simply unified in a shared binary tree.)
321+
322+```
323+ :-
324+ / \
325+1 2
326+```
327+
328+To invoke a function named `add`, one can provide a `%-` cenhep rune with the function name and the arguments.
329+
330+```
331+ %-
332+ / \
333+add :-
334+ / \
335+ 1 2
336+```
337+
338+We write this Hoon expression one of two ways, either separated by whitespace or using parentheses:
339+
340+```
341+> %- add :- 1 2
342+3
343+
344+> %-(add :-(1 2))
345+3
346+```
347+
348+Hoon employs “sugar syntax” for many common code patterns to make them easier to write and (sometimes) to read. Since Hoon had the advantage of knowing about Lisp's syntax beforehand, the standard invocation syntax in Hoon (formally a `%` rune) uses the irregular `()`-based syntax like Lisp. In this case, we could instead write the Lisp-like expression:
349+
350+```hoon
351+> (add 1 2)
352+3
353+```
354+
355+which results in basically the same expression once the parser is done.
356+
357+(Although Hoon ultimately compiles to Nock, it is more natural in some ways to approach the syntax of a program as an array of $n$-ary trees, where each “slot” in an expression can have zero, one, or many children. Zero children refers to a tree address containing a terminal value like a symbol or an integer.)
358+
359+Rune syntax is Hoon's answer to the Lisp proliferation of parentheses—by restricting expressions to a definite number of children, Hoon avoids needing to explicitly terminate most expressions. In some ways, runes are an ASCII-based equivalent of APL's symbolic character operators.
360+
361+```apl
362+life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
363+```
364+
365+Rather than permit polymorphic language statements, Hoon requires each rune to be extremely tightly defined. While many statements may be functionally equivalent to an `if` or a `cond` statement, for instance, Hoon allows the developer to select a particular expressive rune if desired.
366+
367+- `?:` typical `if`/`then`/`else` branch
368+- `?=` branch on type
369+- `?@` branch if atom
370+- `?^` branch if cell
371+- `?+` switch on type with default
372+- `?-` switch on type without default
373+- `?~` branch if null
374+
375+The next examples explore an interesting difference between Lisp `cond` and Hoon `?+` wutlus swtich statements: Hoon switches over _types_ not _values_, and `term` symbols as constants are instances of self-matching types.)
376+
377+```scheme
378+(define (weather f)
379+ (cond ((> f 80) 'too-hot)
380+ ((> f 60) 'nice)
381+ ((< f 35) 'too-cold)
382+ (else 'typical-midwest)))
383+```
384+
385+```hoon
386+|%
387+++ weather
388+ |= f=@ud
389+ ?: (gth f 80) %too-hot
390+ ?: (gth f 60) %nice
391+ ?: (lth f 35) %too-cold
392+ %typical-midwest
393+++ symbol-to-message
394+ |= msg=term
395+ ?+ msg 'Typical Midwest'
396+ %too-hot
397+ 'Too hot outside'
398+ %nice
399+ 'Nice outside'
400+ %too-cold
401+ 'Too cold here'
402+ ==
403+--
404+```
405+
406+Lisp expects a program to be a running series of expressions, naturally composed together as a list. Hoon, in contrast, expects everything to be an evaluable expression (no implicit `progn`, for instance): thus, series of expressions must be composed together, e.g. using `=>` tisgar to concatenate two expressions.
407+
408+This code example defines an expression and immediately evaluates another expression against it:
409+
410+```hoon
411+=> [a=1 b=2 c=3]
412+::
413+b
414+```
415+
416+Hoon code is compiled to Nock, but it is not a simple macro over Nock—multiple Hoon expressions could result in an identical Nock expression, and the same Hoon expression evaluated against different subjects could result in different Nock expressions. Hoon code is parsed to an abstract syntax tree first, which includes type metadata, then compiled into the appropriate Nock statement. Here we use the `!,` zapcom rune to turn a Hoon expression into its AST, then `!=` zaptis to compile a Hoon expression to Nock.
417+
418+```hoon
419+> !,(*hoon `@ux`+(1))
420+[ %ktls
421+ p=[%sand p=%ux q=0]
422+ q=[%ktls p=[%sand p=%$ q=0] q=[%dtls p=[%sand p=%ud q=1]]]
423+]
424+
425+> !=(`@ux`+(1))
426+[4 1 1]
427+```
428+
429+Hoon has much more syntactic sugar than Lisp. Not only is the Lisp-like `()` execution convention sugar for `%:` cencol to invoke a function, there are in fact many ways to evaluate code expressions. Consider, for instance:
430+
431+| Rune | Usage |
432+|---|---|
433+| `%-` | Evaluate a function against a single noun. |
434+| `%+` | Evaluate a function against a cell (pair of nouns). |
435+| `%^` | Evaluate a function against a trio of nouns. |
436+| `%:` | Evaluate a function with many arguments ($n$-ary, unspecified number of nouns). |
437+| `%~` | Evaluate a higher-order function to produce a function. |
438+
439+This gives a Hoon developer an extreme amount of flexibility in constructing and laying out code expressions. In fact, many Hoon programs read as a hybrid of imperative code and functional code, since the ability to lay out intent line-by-line feels rather like C.
440+
441+Hoon conventions and sugar syntax have evolved organically as core developers discovered or invented useful design patterns and appropriately concise syntax.
442+
443+#### Functions (Gates) and Cores
444+
445+The most important structural concept in Hoon is the core, which organizes code into a binary tree of `[code data]`, or as we call it in Hoon, `[battery payload]`. Since cores have a standard structure, this means that many kinds of direct manipulations (metaprogramming) are possible, such as altering the input arguments to a function or manipulating the code variance model. Cores play a role in Hoon similar to that of objects in many other languages.
446+
447+Any function (“gate” in Hoon parlance) is a core, whose `battery` is the compiled Nock code and whose `payload` includes its view of the system, including the standard library, and its input arguments. The `|=` bartis rune is most commonly used to make a gate:
448+
449+```hoon
450+:: Select the larger of two values ("max").
451+|= [a=@ b=@]
452+?: (gth a b)
453+ a
454+b
455+```
456+
457+The gate definition rune `|=` bartis has two children, a specification of the expected input and the expression. When invoked, the values of the specification (or "sample") are provided to the expression, which then evaluates to return a noun.
458+
459+One quirk of Hoon is that since everything is an address (or “axis”) in a binary tree, you can access anything in your scope (“subject”) through its axis. Most commonly you attach a face to a value (like a gate), but you don't have to. At any point, to refer to the previous statement, you can invoke the head of the tree, `-`; to wit,
460+
461+```hoon
462+> =/ a 5
463+ -
464+a=5
465+```
466+
467+The name `a` is also attached to the value and can be used to identify the value. (To the Hoon parser there is no real difference; this is a programmer quality-of-life affordance.)
468+
469+```hoon
470+> =/ a 5
471+ a
472+5
473+```
474+
475+Thus faces (names) are attached to gates (functions) within a particular scope or context, such as a `|%` core. Each core defines a collection of values and gates (collectively termed “arms”) which occupy a shared scope. For example, the following library demonstrates a few floating-point operations in Hoon. Each function can see the parent subject (including `hoon.hoon` and some other cores) as well as its neighboring arms (such as `++pow-n` called by `++exp`).
476+
477+```hoon
478+|%
479+:: Factorial, x!
480+++ factorial
481+ |= x=@rs
482+ =/ t=@rs .1
483+ |- ^- @rs
484+ ?: =(x .1) t
485+ $(x (sub:rs x .1), t (mul:rs t x))
486+:: Absolute value, |x|
487+++ absolute
488+ |= x=@rs
489+ ?: (gth:rs x .0) x
490+ (sub:rs .0 x)
491+:: Exponential function, exp(x)
492+++ exp
493+ |= x=@rs
494+ =/ rtol .1e-5
495+ =/ p .1
496+ =/ po .-1
497+ =/ i .1
498+ |- ^- @rs
499+ ?: (lth:rs (absolute (sub:rs po p)) rtol) p
500+ $(i (add:rs i .1), p (add:rs p (div:rs (pow-n x i) (factorial i))), po p)
501+:: Power, restricted to integeres only, x**n
502+++ pow-n
503+ |= [x=@rs n=@rs]
504+ ?: =(n .0) .1
505+ =/ p x
506+ |- ^- @rs
507+ ?: (lth:rs n .2) p
508+ $(n (sub:rs n .1), p (mul:rs p x))
509+--
510+```
511+
512+Ultimately, however, the faces resolve back to an axis and the code is composed by the compiler into a Hoon syntax tree and thence to Nock for the runtime interpreter.
513+
514+The nature of cores derives from Nock and is key to understanding how Hoon works. All nontrivial structures in Hoon are cores. For instance, even a gate is a regular `|%` core, with `|=` expanding to `|%`. The following code snippets are identical to the Hoon compiler after parsing.
515+
516+```hoon
517+:: increment a number by two
518+|= p=@ud
519++(+(p))
520+```
521+
522+```hoon
523+:: increment a number by two
524+=+ ^~(*p=@ud)
525+|%
526+++ $
527+ +(+(p))
528+--
529+```
530+
531+Although Lisp's `'` quoting has no direct equivalent in Hoon, there are a couple of structures that can provide a similar effect. The most important of these is the `|.` trap, which defines an expression to be evaluated at a later time—Hoon’s equivalent of Lisp’s thunk. For instance, traps are used when testing code that _should_ fail, as the expression can be defined and deferred until the test framework is ready to process it.
532+
533+```hoon
534+> =foo |.((add 1 41))
535+
536+> -:foo
537+[8 [9 36 0 2.047] 9 2 10 [6 [7 [0 3] 1 1] 7 [0 3] 1 41] 0 2]
538+
539+> (foo)
540+42
541+```
542+
543+(To understand the second entry, recall that code is the in head of the core—here, we see the Nock code for the operation defined in the `|.` trap.)
544+
545+[Wet gates](https://developers.urbit.org/guides/core/hoon-school/R-metals) present the most macro-like feature in Hoon. A regular function, or “dry gate” (as above), receives an argument (the sample); the type system tries to cast the sample to the type specified by the gate, and fails if not possible. Wet gates instead defer type evaluation and instead attempt to use the sample (or arguments) directly in the expression. This produces a parametric polymorphism. (This comes close to dynamic typing, but type is still checked at compile time.) Wet gates are commonly used as gate-building gates, such as mold-producing gates like `++list`.
546+
547+Consider a function like `++turn` which transforms each element of a list.
548+
549+```hoon
550+> `tape`(turn ~[77 97 114 115] @t)
551+"Mars"
552+```
553+
554+To use `++turn`, we need a list and a transformation function. The type of the list we produce depends on the type of the list and the type of the transformation function. The actual gate `++turn` should work to transform each element of the list for on any function and any list, so long as the function's argument is the list item.
555+
556+Wet gates are therefore used when incoming type information is not well known and needs to be preserved. This includes parsing, building, and structuring arbitrary nouns. (Beyond Lisp analogues, you can think of C++'s templates and operator overloading, and Haskell's typeclasses.)
557+
558+This example compares the Lisp deferred factorial thunk with an equivalent Hoon trap. (Hoon includes `++factorial` since it is not part of the standard library.)
559+
560+```scheme
561+(defun create-thunk (function &rest arguments)
562+ (lambda () (apply function arguments)))
563+
564+(defun invoke-thunk (thunk)
565+ (funcall thunk))
566+
567+;; Creating a thunk that calculates the factorial of a number
568+(defvar factorial-thunk (create-thunk #'(lambda () (factorial 5))))
569+
570+;; Invoking the thunk to get the result
571+(print (invoke-thunk factorial-thunk)) ; Output: 120
572+```
573+
574+```hoon
575+=>
576+|%
577+++ factorial
578+ |= n=@ud
579+ |-
580+ ?: =(n 1) 1
581+ %+ mul n
582+ %= $
583+ n (dec n)
584+ ==
585+++ factorial-5
586+ |. (factorial 5)
587+--
588+(factorial-5)
589+```
590+
591+### Subject-Oriented Programming
592+
593+Urbit programming employs a paradigm deriving from the nature of Nock (_a fortiori_ Hoon), subject-oriented programming. Every expression of Hoon is evaluated relative to its subject, a piece of data that represents the environment, or the context, of an expression.
594+
595+The subject refers to the parent binary tree of an expression, more or less, and serves as state, lexical scope, environment, and function argument. (We can be precise about the definition in all cases—e.g. the subject of a gate in a core is the core itself—but don't need to for this essay.) Lisp supports variable scope and global variables, such that any part of the program can access a particular binding. Hoon's subject-oriented programming model naturally provides its equivalent of scope: all code is evaluated against a subject and name bindings proceed by depth-first match (with permitted skips to prevent unwanted masking).
596+
597+> Subject orientation in Nock and Hoon stems partly from minimalism (there's just one subject, which serves as state, lexical scope, environment, and function argument), partly from a desire to simplify compilation (the type of the subject is a full specification of the compile-time environment for a source file), and partly in order to give the language a more imperative feel.
598+>
599+> Everything about a scope, including name bindings, aliases, and docstrings, is stored in the subject's type. This allows Hoon's compilation discipline to be similarly minimal: the compiler is a function from subject type and Hoon source to product type and compiled Nock. Running this Nock against a value of the subject type produces a vase of the result. It's hard to imagine a more streamlined formalism for compilation. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))
600+
601+The subject is typically the core in which an expression is evaluated, but can be more narrowly defined; consider, for instance, our example from above:
602+
603+```hoon
604+=> [a=1 b=2 c=3]
605+::
606+b
607+```
608+
609+A slightly different program fails:
610+
611+```hoon
612+=> [a=1 b=2 c=3]
613+::
614+(add a b)
615+```
616+
617+because the `++add` gate is not defined in the subject against which the expression is evaluated, the first statement.
618+
619+### Comparative Examples
620+
621+#### Find in List
622+
623+```scheme
624+(define index-of
625+ (lambda (needle haystack)
626+ (let ((tail (member needle haystack)))
627+ (if tail
628+ (- (length haystack) (length tail))
629+ (throw 'needle-missing)))))
630+```
631+
632+```hoon
633+:: Produces the index of the first occurrence of nedl in hstk
634+:: as the unit of an atom.
635+++ find
636+ |= [nedl=(list) hstk=(list)]
637+ =| i=@ud
638+ |- ^- (unit @ud)
639+ =+ [n=nedl h=hstk]
640+ |-
641+ ?: |(?=(~ n) ?=(~ h))
642+ ~
643+ ?: =(i.n i.h)
644+ ?~ t.n
645+ `i
646+ $(n t.n, h t.h)
647+ ^$(i +(i), hstk +.hstk)
648+```
649+
650+#### Filter a List
651+
652+```scheme
653+(define filter
654+ (lambda (fn lst)
655+ (let iter ((lst lst) (result '()))
656+ (if (null? lst)
657+ (reverse result)
658+ (let ((item (car lst))
659+ (rest (cdr lst)))
660+ (if (fn item)
661+ (iter rest (cons item result))
662+ (iter rest result)))))))
663+```
664+
665+```hoon
666+:: Cycle through the members of a list a, passing them to a gate b
667+:: and produce a list of all of the members that produce TRUE.
668+++ skim
669+ |* [a=(list) b=$-(* ?)]
670+ |-
671+ ^+ a
672+ ?~ a ~
673+ ?:((b i.a) [i.a $(a t.a)] $(a t.a))
674+```
675+
676+- Several examples in the above section were drawn from [UW's CSE 341 course notes](https://courses.cs.washington.edu/courses/cse341/03wi/scheme/basics.html) and from [Rosetta Code](https://rosettacode.org/).
677+
678+
679+## Metaprogramming
680+
681+A Lisp program is really a list, or a list of lists (nested as much as necessary). While this can be interpreted as an $n$-ary tree, tree structure is not the preferred structural metaphor. A Hoon program is a noun, or equivalently a binary tree. Every component of it is directly addressable and thus in principle reflective. Both languages are homoiconic, with code and data representations being the same. What are the consequences of homoiconicity?
682+
683+### Metaprogramming in Lisp
684+
685+Metaprogramming is the practice of writing code that manipulates other code at either compile-time or runtime. In Lisp, metaprogramming is a core feature of the language, and it allows developers to create programs that are incredibly powerful and flexible. Lisp's metaprogramming capabilities are primarily built on two features: macros and syntax manipulation.
686+
687+Macros in Lisp are a way to define new language constructs that are more expressive and more powerful than those provided by the language itself. When a Lisp program is compiled or interpreted, macros are expanded into regular Lisp code, allowing the macro to generate new code based on its input arguments. Since Lisp code is represented as data, it can be manipulated using the same functions and operators used to manipulate other data structures.
688+
689+For instance, Lisp macros could allow you flexibility in expressing a common operation. Imagine you're working on a project that requires a lot of complex math calculations. Rather than writing out each calculation manually, you could define a macro that takes an expression in infix notation (e.g. `2 + 3 * 4`), and transforms it into a Lisp expression that can be evaluated directly. Thus you could compose math expressions in a more human-natural way without having to worry about details of Lisp syntax.
690+
691+Lisp can also manipulate its own syntax. This is sometimes done through the use of reader macros, which operate at the level of the Lisp reader, which is responsible for converting textual input into Lisp expressions. Reader macros can be used to extend the syntax of Lisp, allowing developers to define new conventions or domain-specific languages for specific types of data or operations. Beyond reader macros, Lisp can permit the developer to change the parser (and as long as the result is a Lisp expression, the interpreter or compiler will be fine with this). Top-level functions can be replaced or modified (“advised”). Symbol macros can change source code.
692+
693+Lisp's `'` quote and the `eval` statement allow single expressions to be inhibited or evaluated at will, which is incredibly useful when dealing with symbols that may not be defined yet or in the composition of macros.
694+
695+In addition to macros and syntax manipulation, Lisp dialects typically provide a number of other features that make metaprogramming easier, such as the ability to inspect and modify the runtime environment, and the ability to create or redefine functions and classes at runtime.
696+
697+### Metaprogramming in Hoon
698+
699+While Hoon explicitly avoids macros and domain-specific language specializations, there are many aspects of Hoon which allow or exploit code reflection and manipulation.
700+
701+In practice, Hoon is intended as a systems programming language for the Urbit Nock VM. Hoon's metaprogramming has as a consequence mainly focused on aspects of core manipulation (such as code building and wet gates) and on live code upgrades (what I'll call hot-swapping code). Hoon eschews macros and in particular has a philosophical stance against domain-specific languages (DSLs). (There are some exceptions, notably Sail, Hoon's XML/HTML syntax; and JSON reparsing.)
702+
703+Hoon has the ability to parse arbitrary text strings (typically files) into executable ASTs and Nock. Symbols can be directly converted to and from regular text strings.
704+
705+As the programming language for a “hundred-year computer”, Hoon needs the ability to hot-swap code at runtime. Elements of cores can be removed or replaced. (Really, Hoon code is immutable: the system is actually making a copy with a specified change.) Every app and even the OS itself can define a state transition function and upgrade along a deterministic pathway.
706+
707+Hoon is in principle extremely reflective as it simply compiles to a Nock noun. Since everything is a stationary tree, it is straightforward to manipulate any object. There are no magic binary blobs or opaque data types: if you have a file handle or an Ethereum block or a websocket connection object, it is a tree and you can work with it directly. (Cf. [“Why Hoon”](https://urbit.org/blog/why-hoon).) Obtaining—or changing—details about gate sample or core behavior becomes a routine part of the Hoon developer’s toolkit. Given such regularity, it would be desirable to expose further capabilities of code reflection and introspection explicitly for the interpreter and IDE.
708+
709+One of the most common design patterns in Hoon is that of the higher-order function, or what Hoon calls “gate-building gates”. These are gates (functions) that produce gates (functions). For instance, as Hoon is statically typed a list must have an associated element type at compile time. `++list` is a gate builder that produces a type gate, which can then be applied to the actual values:
710+
711+```hoon
712+list :: gate builder
713+(list cord) :: gate for list of cords (strings)
714+`(list cord)`~['a' 'b' 'c'] :: list type applied to value
715+```
716+
717+Hoon represents a “hyperlambda” with respect to anonymous function creation: one very often defines gates at their point of use, particularly when operating on each member of a list or set. Similar to Lisp's frequent use of `lambda`, the one-time-use function is available at the point of call as an anonymous gate. (More generally, every gate is anonymous and we have to attach a name to it as a search path, but that's a bit out of scope here.)
718+
719+```scheme
720+((lambda (x1 x2)
721+ (* (- x1 x2) (- x1 x2)))
722+ 2 -5)
723+```
724+
725+```hoon
726+%- |= [x1=@ x2=@]
727+ (pro:si (dif:si x1 x2) (dif:si x1 x2))
728+[--2 -5]
729+```
730+
731+Like Lisp, Hoon yields a lot of power to the user–developer. One could implement a fairly regular Lisp on top of Hoon with very few changes—and perhaps even implement a pure-Hoon discipline yielding a statically-typed Lisp à la TypeScript from JavaScript.
732+
733+- [~tacryt-socryp, “Hick, a more traditional Lisp than Hoon”](https://gist.github.com/tacryt-socryp/b08dc66b7bcc760e914c4db5c9fd7ba7)
734+
735+
736+## Philosophy
737+
738+Hoon's focus on atoms, static typing, and symbolic expressions make it a highly expressive and efficient language for building applications on the Urbit platform, while Lisp's flexible syntax and macro system make it a popular choice for a wide range of programming tasks.
739+
740+Lisp has evolved greatly since John McCarthy's founding. Like Unix, a complicated family tree has finally settled down into a few strong contenders: Scheme, Common Lisp, Clojure, Racket.
741+
742+Lisp has tended to be fractious: as many have noted, and [Mark Tarver eloquently expressed](http://web.archive.org/web/20080803193859/http://www.lambdassociates.org/blog/bipolar.htm), the Lisp platform appeals to idiosyncratic visions for completist platforms. There's a looseness in the community's coherence as a result.
743+
744+For a few reasons, the Urbit community has managed to avoid such splintering (the [Urbit Classic joke](http://urbit-classic.org/) aside). With a single sponsoring organization, first Tlon Corporation and since 2022 the Urbit Foundation, to steward the ecosystem and a philosophical commitment to protocol-as-platform, Urbit should avoid partition into competing bazaars.
745+
746+Urbit's governing philosophy as a technical program is laid out in the [Precepts](https://urbit.org/blog/precepts). A sampling:
747+
748+> A.13. If you don't completely understand your code and the semantics of all the code it depends on, your code is wrong.
749+
750+> A.16. Explicit state is better than implicit state.
751+
752+> A.20. One hundred lines of simplicity is better than twenty lines of complexity.
753+
754+> D.3. Not being qualified to solve a problem is no reason not to solve it.
755+
756+There is significant overlap here with the ideals of the Lisp developer community present. Scheme like Hoon aims at minimalism and ample use of lambda expressions. [Clojure](https://www.clojure.org/about/rationale) aims at strengthening Lisp by building it on a modern platform (the JVM); it would agree with Urbit's disdain for nondeterminism: “pervasive, unmoderated mutation simply has to go”. Racket was designed for production systems and to some extent with a hope to unify parts of the developer stack.
757+
758+In many ways, Hoon is more Lisp-y than Lisp: that is, it represents a point more polar towards the telos of Lisp than any extant Lisp. By shedding the skin of lists and focusing on binary trees, Urbit achieves a deeper conceptual unification within itself. Hoon doesn't properly supersede Lisp—it requires running on a particular VM architecture, for instance—but Hoon's focus on typing, the nature of Hoon's binary-tree homoiconicity, and its employment of pure functional concepts make it a strong new tool for those to whom Lisp already appeals.
759+
760+Hoon goes farther than Lisp, however. Hoon is an accessible and practical, if unconventional, tool for simplifying the developer stack, ultimately to a single language. Ultimately, Urbit is a technical project to encode human digital freedom into the very protocol we use—with Hoon its nose-to-tail _lingua franca_. Hoon carries the torch that Lisp kindled into a new user-oriented future.
761+
762+To close, I quote Urbit Foundation CTO Ted Blackman on why Urbit follows its particular design discipline:
763+
764+> The promise of Urbit lies in its reimagination of the digital world using components that are as constrained and limited as possible. By adhering firmly to principle and doubling down on minimalism at every turn, we get an OS that provides far stronger guarantees than Unix with a thousand times less code. Given the complexity of modern software, this is what's required to put personal computing back into the hands of people. (Ted Blackman ~rovnys-ricfer, [“Why Hoon”](https://urbit.org/blog/why-hoon))
content/blog/hosting-the-future.mdnew file+30
@@ -0,0 +1,30 @@
1++++
2+title = "Hosting the Future"
3+date = "2020-09-30"
4+description = "The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption."
5+
6+[extra]
7+author = "Nick Simmons"
8+ship = "~simfur-ritwed"
9+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/200930-hosting-by-tlon.jpg"
10++++
11+
12+
13+
14+Urbit users tend to be interesting, creative, and capable people; we’re genuinely impressed with the communities that have formed on the network, and with the quality of discourse there. But for the number of communities to continue to grow, getting on the network has to become dramatically easier. It’s not realistic to expect most people to configure their own Urbit OS node in the command line.
15+
16+At the moment, the biggest lever we have here is to help ordinary users get online, so they can participate in communities inside Urbit, and eventually form their own. This means hosting their Urbit nodes and showing them around the network when they first arrive. There are already several businesses overlapping with this space to varying degrees: [planet.market](https://planet.market/), [urth.systems](https://urth.systems/), and [geturbitid](https://www.geturbitid.com/). Now, Tlon is releasing its own hosting offering. For the uninitiated, “Hosting” just means that we run your urbit ship for you, making it easier for you to get onto the network. We’ve been testing our hosting service with friends and family for the past few months, and now we’re ready to bring it to the rest of the world.
17+
18+To learn more about Tlon hosting and sign up for the waiting list, check out the new [tlon.io](https://tlon.io/) website. We are officially launching the service on October 9th, with a virtual event and demo; we’ll also show off some of the new features and improvements to Landscape, the Urbit web client.
19+
20+To be very clear, hosting isn’t for everyone; if you’re deeply security-conscious or privacy-oriented, you’ll still want to self-host so that nobody else needs to touch your keys. That said, hosting isn’t a walled garden; you’ll get a planet when you sign up for hosting, which you will own 100% and forever. You’ll also always have the option to roll up your data and take it with you if you choose to stop using our service. Your Urbit data is just a single file, and we’ll happily hand it back to you if you ever decide to leave. Nothing will ever stop you from self-hosting.
21+
22+We’ve talked for a while about how the ultimate destiny of Urbit is to escape the control of Tlon. For Urbit to really succeed, it has to be managed by its own community. We started Tlon in order to solidify the foundation of this young platform. Now that Urbit is starting to grow up, Tlon and Urbit will naturally drift apart a bit.
23+
24+Urbit is meant to be universal, ubiquitous infrastructure. Tlon exists to make that infrastructure useful and usable. We expect Urbit, as a platform, to be cared for by the community in collaboration with the emerging [Urbit Foundation](https://urbit.org/blog/first-steps-towards-urbit-org/). We intend Tlon to become increasingly focussed on providing a great user experience for anyone interested in this new network, so the network can continue to grow and thrive.
25+
26+The way we see it, hosting is the most important thing, next to Landscape, that Tlon can do to help Urbit continue toward widespread adoption. We don’t expect to be the only ones providing this service—and look forward to including more contributions from the community here on urbit.org as they continue to mature.
27+
28+If you’re curious to keep up with what Tlon is doing here, head to [tlon.io](https://tlon.io) and join the waiting list. We’ll be posting updates to that list as well as to the Tlon Transmissions notebook in the Urbit Community group. Going forward we’ll do our best to keep urbit.org neutral and focussed on the technology itself.
29+
30+See you all on the network!
content/blog/immunology-for-the-internet-age.mdnew file+118
@@ -0,0 +1,118 @@
1++++
2+title = "Immunology for the Internet Age"
3+date = "2022-04-07"
4+description = "A consideration of the history of the Internet motivates introspection on the nature and causes of social dysfunction in a globally shared space. Centralized solutions fail to yield satisfactory outcomes for human freedom and thriving. Decentralized autonomous organizations and their technological apparatus together represent the evolution of an immune system against a corporatized Internet."
5+[extra]
6+author = ""
7+ship = "~lagrev-nocfep"
8+image = "https://live.staticflickr.com/4322/35891780782_4179f476f9_k.jpg"
9++++
10+
11+_A version of the following was presented by ~lagrev-nocfep at the [MTAConf 2022 conference on “The Decentralization of Power”](https://www.mtaconf.org/)._
12+
13+**✿**
14+
15+IN THE BEGINNING, _God created the prokaryotes. And the prokaryotes were without nucleus and organelle; and structural simplicity was upon the face of the deep. And chemotaxis moved it upon the face of the waters._
16+
17+A single-celled organism possesses many advantages, notably simplicity of form. Being largely indistinguishable, they have no differentiation or specialization. Prokaryotes often form large colonies, such as the cyanobacteria. Some prokaryotes discovered early on that it paid better to consume resources that had already been processed into usable form by another cell, rather than to process those resources oneself. Thus predator and prey were born, and they have always exemplified divergent competitive evolutionary strategies. The resulting arms race meant that predators were continually adapting to better extract resources from prey, while prey were evolving to evade, resist, fight, or poison predators. Selection pressures applied at individual, species, and clade levels, lead to speciation across deep time.
18+
19+More complex forms seemed better able to evade predators, and thus simple symbiotic alliances between differentiated prokaryotes evolved into the eukaryotes (yielding specialized features such as the nucleus and mitochondria) and multicellular life forms. Simpler forms also abounded, including the liminal virus. Viruses are forms of near-life so simple that they simply exploit cells to reproduce. They are entirely predatory or at best symbiotic with other life. Evasion of pathogenic disease, or disequilibrated colonization by simpler forms of life, has been a---if not the---primary driver towards increasing complexity in multicellular life.[^1]
20+
21+**✿**
22+
23+The Internet began in the late 1960s, born of scientific alliance between the Cold War Department of Defense and the academic research community.[^2] This community had a signal advantage over many subsequent communities: it was dominated by strong norms of discourse which shaped the professionalism of the community. This is not to discount the significance of courtly intrigue, of course, which deftly exploited tensions between competing systems.[^3].
24+
25+Throughout this era, though, the Internet generally functioned as a real-name high-trust environment---if not exactly of peers, at least of colleagues.
26+
27+The Internet evolved as a coordination mechanism---literally a nervous system incarnate in copper and silicon---particularly through the Usenet days of the 1980s. In our days of heightened online tension and mediated preference cascades, it is rather quaint to go back and look at what qualified as email flame wars at the time (e.g. Torvalds/Tanenbaum). One hallmark of the Usenet era, however, is a gradually eroding social trust: spam was invented[^6] and Internet-based scams started to spin up.
28+
29+Pseudonymity gained in popularity as a countermeasure to both of these as well as restrictions on discourse. The revelation that persistent digital records could cost someone's job further fueled a cyberpunk-like obsession with identity control and hacking.[^7]
30+
31+Computer viruses could propagate for the first time: it never made much sense to build a computer virus until systems were connected. Although John von Neumann and others early explored the possibility of mathematical or code structures which could self-replicate, it was not until the Creeper virus in the 1970s that self-replicating code was observed in the wild. And like a bacillus in an immune system-free host, code-based computer viruses began to spread from the 1980s onwards.
32+
33+The crisis arrived in the form of the World Wide Web. Founded initially on a belief in the democratization of information, the Web rapidly became dominated by a handful of large corporations (henceforth "megacorps"). User experience became the predominant driver of adoption, leading to rapid preference cascades as new platforms became available. Any child of the 90s or earlier can recite the lived litany: Ebay, MySpace, Friendster. Initially these served as proofs-of-concept, then became the only significant player (until the next killer app came along). Search engines drove discovery, then focused attention asymmetrically. The "walled garden" approach of AOL, then Apple and Facebook, led to concentrations of users which tipped the balance from single webpage hosts presenting their own idiosyncratic views to corporate-approved genericity and ultimately censorship.[^8]
34+
35+**✿**
36+
37+When was the first time you did something in the physical world because of something you read or encountered online? For generations born after the advent of the Web, they may not recall such a time when meatspace existence wasn't driven by life online. As Internet data sources have overwhelmed traditional media, publishing, and distribution services, the resulting tsunami of information and informatization has swept into every corner of lived human experience in technological societies. The psychological (memetic) virus problem is much greater than actual code viruses. The ongoing universal exposure to alien and internally incoherent value systems has undergirded the well-documented crisis of credibility (collapse of meaning) that all Western institutions are experiencing today. The World Wide Web and its technological predecessors acted as a cultural petri dish of clean agar, which grew every spore and germ which fell upon it. We live in the midst of a memetic epidemic because of the World Wide Web, and the dominant strain is corporate, approved by a marketing department and run through a search-engine optimization algorithm.
38+
39+The turn towards a low-trust then zero-trust environment was inevitable if anything like an analogy with prokaryotic evolution holds true. The megacorp platforms are in a way worse than a purely zero-trust environment, because they don't advertise that the world is zero-trust. Thereby they lure the unwary into transgressing arbitrary global norms and courting the wrath of social media mobs and the concomitant loss of access to their data held in "trust." To mix a metaphor, megacorps are apex predators---at best, sheepdogs with a strong strain of wolfishness; at worst, tar pits manned by various bad-faith actors. The pre-Web cypherpunks were right: "Privacy is the power to selectively reveal oneself to the world."[^9]
40+
41+If anything, they were too narrow; not only their valued "open society" (polyvalent crypto-anarchy) but _any_ non-megacorp society at all requires true privacy.
42+
43+What cyberspace (and human culture writ broadly) needed was an immune system---and in good Darwinian form, such an immune system has been evolving before our eyes. An immune system formally consists of layers with increasing specificity: first surface barriers, then the innate immune system, and finally the adaptive immune system. The objective of the immune system is to protect the organism: in this case, human sociality and agency.
44+
45+First, what is human sociality? Human culture has been the means of participating in the Great Discussion which ranges from the earliest days of oral culture to the birth of literacy and libraries down to our day. High culture and low culture have both articulated and preserved valuable insights and forms of human flourishing. However, throughout the 20^th^ century and particularly by the means of the consumer revolution, our lives have been thoroughly colonized by capital and commercial instruments. So-called "economies of scale" have disrupted smallholders, artisans, and shopkeepers to the extent that these have been virtually eradicated from the modern landscape in favor of the plastic and polluting "dark Satanic mills." Although small-scale "provident living" has supported gardening, canning, and home production, none of this has survived across a large enough cultural segment to matter macroscopically, and it has unfortunately been tarred with the "prepper" brush that delegitimizes economic downsizing as antisocial because anticapitalist. The siren call of cheap consumer goods has ushered in a generational collapse in self-sufficiency and resulted in the complete colonization of entertainment, food consumption, and self-care by massive corporate brands. Not only have physical goods entered a post-consumer phase, but only certain classes of ideas, attitudes, political stances, regional accents, and sensibilities enjoy the sanction of megacorp sociality. There is essentially no native culture left, only that forged in the enterprise brand management office.[^10]
46+
47+In an immune system, _surface barriers_ are designed to make it hard for exogenous agents to enter a cell or organism; in our analogy, the primary surface barrier was the match of physical separation to psychological separation. Surface barriers were rendered finally obsolete by the launch of the World Wide Web and its subsequent infiltration of every aspect of human culture. To the extent they exist today, it is a matter of ignorance, self-discipline, or happy accident.
48+
49+The _innate immune system_ responds non-specifically to pathogens. Any immune system must have a way of deciding what is _me_ and what is _not-me_. Framed as an identity problem in a zero-trust environment, users have evolved several ways to uniquely identify agents without reference to legacy systems. Chief among these means is the blockchain, introduced by Bitcoin for control and transaction of digital assets and since much exploited beyond its design intent. Ethereum-based ERC tokens represent tweaks of this identity concept, as do many other blockchain platforms.
50+
51+Identity is still fluid and polysemous, but in certain key instances it is indelibly demonstrable.[^11]
52+
53+The individual actor has the capability to express itself with many public faces or none; one of these typically enjoys government sanction and liability, but it is no more _real_ than the others, only more legible to regulation and taxation.[^12]
54+
55+Another aspect of the innate immune system is the public visibility of code. Open source has developed an ethic of transparency on epistemological grounds (i.e. you have a right to know what code you are running) and practical grounds. (Linus's law: "given enough eyeballs, all bugs are shallow."[^13])
56+
57+The _adaptive immune system_ responds to specific pathogenic incursions. Particular conditions arise, whether through social, regulatory, military, or other requirements, which must be met with specialized forms that are thereafter in evolutionary competition with the external factor. For instance, one megacorp solution to what it perceives as a threat, i.e. unsanctioned memes, is to attempt to mandate the ultimate traceability of any image's provenance.[^14]
58+
59+The Internet immune system thus evolves to further obfuscate legibility and enhance individual control and self-determination by shifting to less-traceable technologies such as the InterPlanetary File System (IPFS). The point is not whether or not a salient technology such as deepfakes, 3D-printed firearms, deviant scientific or political thought, or even the DRM-free sharing of copyrighted material can be contained.
60+
61+The experience with export-grade cryptography has already shown that regulatory attempts ultimately fail.[^17]
62+
63+The philosophical question is what kind of world will evolve (a _fait accompli_ driven by factors beyond any individual or office) and the practical question is how any particular group of actors can preserve their own agency, autonomy, and ambit of action.
64+
65+The first decentralized autonomous organization, "The DAO" (Đ) itself[^18], was created in 2016 as a way of distributing ownership and stake in a joint venture capital fund. Đ was a new form of organization in that it was essentially a mathematical entity, a set of smart contracts on the blockchain to which anyone had access. Đ lived up at least to "decentralized" and "autonomous." No money was held centrally, with token-based authentication yielding the right to vote on projects. Having set the criteria for membership and investment, Đ then operated in truly democratic fashion until an exploit of imperfectly written smart contract code led to theft, crisis, and the reorganization of the Ethereum blockchain itself.
66+
67+While the heirs of Đ serve a role in the current Internet immune system, the original was formed in response to exogenous regulatory concerns, notably ongoing governmental insistence on restricting investment to the already-wealthy. The U.S. Securities and Exchange Commission and other agencies have in place arbitrary investor requirements which would make little sense even if pegged to something like inflation or index rather than the rapidly-devaluing petrodollar. Nominally put in place to protect the naïve from getting scammed, these restrictions have had the pernicious effect of pulling up the ladder behind the _actuel riche_.
68+
69+DAOs have rapidly evolved as a way of distributing ownership and stake in a purely democratic way. (As an aside, the word "democracy" has been much abused, but here I use it in a sense much like the Greek original: the holders of an immutable and indelible token cast their secured votes to govern their society.) DAOs represent a resurgence of the sovereign city-state in new guise. Will this be enough to evade "imperial" aggregates which dominate today's Web?
70+
71+Decentralized autonomous organizations, zero-knowledge cryptographic proofs, cryptocurrencies, proof-of-identity systems, and their as-yet-unborn kin represent the evolution of an immune system on top of the Darwinian churn of the legacy Internet. The stakes are necessarily high: possession is _de facto_ ownership, the other end of the stick from "not your keys, not your coins" (the old cryptocurrency chestnut). The focus is currently on ownership of money, non-fungible tokens, and similar assets, but broadly speaking such systems allow the authenticated ownership of all data and assets one holds, from chat messages to market shares to physical real estate. There may be good reasons to retain the legacy system for some classes of physical or legal artifacts, but at minimum these will be in competition with purely autonomous constructs. (As an aside, I am of the philosophical opinion that legal recognition should not be sought generally for new forms of organization, as any legibility to legacy systems opens new attack surfaces in an immunological sense.) "Code is law."[^19]
72+
73+A decentralized autonomous organization seems to be at least the first two. Having set the criteria for membership, the organization can act as the (distributed, possibly unknown in the zero-knowledge proof sense) stakeholders direct.
74+
75+This form is still somewhat "yeasty" in that like cyanobacteria it acts as an undifferentiated mass. We should expect further innovations in DAO-like entities.[^21] The most salient epithet of a DAO is "decentralized"; one can imagine hierarchical, concentric, or role-specialized DAOs as well as other taxonomically related forms, just as one can imagine progressively less organized instances in a chaos-happy Internet.
76+
77+Like the first mutant with a new gene, Đ itself failed. Many lessons can be drawn from that failure, including the criticality of getting smart contract code absolutely correct ("code is law"), and how to administer a blockchain in the presence of massive fraud. And indeed, what has happened to the blockchain world of decentralized finance? Millisecond differentials in responsiveness lead to huge swings in profitability of transactions. Frontrunner bots watch algorithmically for transactions they can complete faster than the original source, thereby making money on asymmetric knowledge.[^22] Zero-day exploits of code abound, heralding a need for more thorough vetting and more expressive and secure smart contract languages.
78+
79+Blockchains (and thus DAOs via Ethereum) operate as proof-of-work, proof-of-stake, etc. This provides node operators with a way of verifying consensus reality and thereby cementing a record of digital transactions. Future innovations hold forth the possibility of secure proof-of-identity blockchains (such as the Uqbar Layer 1 smart contract blockchain on Urbit[^23]), wherein each node which can provide concrete cryptographic evidence of its identity gets a vote on the consensus.
80+
81+We must consider modern systems to necessarily interact at the pinnacle intensity of competence and competition: any differential advantage that can be exploited to outcompete an adversary not only can be exploited but _should_ be. Illegibility, redundancy, and apposite complexity are allies in the immune fight to maintain identity and ownership in the modern Internet.[^24] Any system which does not have an operational DAO-like layer is immunocompromised. All tools for the individual and collective need to be architected around a zero-trust adversarial world. They also need to guard the embers of community and enable new growth.
82+
83+In a nutshell, the early Internet was a cocktail party. By the age of Usenet and into the World Wide Web era, the Internet evolved into a player-versus-player defect--defect equilibrium in which brigading, spamming, and anonymity are rational adaptive behaviors. Indeed, anonymity is barely a protection given the lengths to which governments and megacorps go to prevent truly untraceable usage. This approach is adaptive for agencies which have given up on any other model of reality, fundamentally lacking a vision of humans as other than atomized individual krill for the megacorp apex predators: consumers for the consumers. The legacy megacorp Internet has become a crab bucket, always drawing everything back into itself in a dysfunctional and frankly satanic way.
84+
85+Communities built on decentralized Web3 platforms such as Mastodon, Fediverse, and Urbit[^25] have stepped back from the purely PvP world of the globally-namespaced social media Internet. These today have more of a block party feel, wherein one can wander from house to house or room to room and encounter some of the same faces in the same or new guise. Conversations can drop and resume anew in very different locales with largely the same composition. Marrying the underlying cryptographic identity requirements of DAOs to communication tools and databases yields a strong stable solution to the problem of retaining a foothold of personal identity from which to coordinate one's multifaceted digital life. IPFS, Sovrin Foundation, Tim Berners-Lee's Solid, and Urbit all offer their take on this requirement. Even a Signal chat group running its own server is a kind of token-free DAO.
86+
87+Since the Renaissance, essentially all theology has been humanist in nature, concerning itself with how man should live to flourish in this world and inherit in the next. Even secularized descendants enjoin an ethos of ritual behaviors and practices. The social and cultural "stack" (in software parlance) upon which we build provides for a variety, broad or narrow, of human cultural forms. Lately, the variety of forms has been diminishing both by cutting off older forms from the modern world and by cultivating only certain state-legible apex predators[^26] and their preferred ovine repast.
88+
89+Contra this monoculture, the _telos_ of social computing is to recreate the village green, not the penitentiary. Revisiting a thesis from above: "All tools for the individual and collective need to be architected around _using cryptographic proofs to create stable high-trust havens in an otherwise_ zero-trust adversarial world." The village is a stable, long-term tribe well below Dunbar's limit which shares values and assets in common, from which a member occasionally ventures out into the broader social web but always has a home. Every village will grow its own culture, perhaps even its own _cultus_, enabled by decentralized technologies to protect their assets and precious peculiarities. The World Wide Web has been an extinction-level event for many forms of life, livelihood, and culture. For others, it has offered strange forms of life support and even thriving. With a new immune system evolved and now operational, human endeavor stands on the cusp of a Cambrian explosion, unconstrainable by a rent-seeking boardroom-and-bureaucracy world that never comprehended the light shining in its darkness.
90+
91+_The header image is [Volvox sp. microscopic algae](https://www.flickr.com/photos/picksfromoutthere/35891780782/in/photolist-WFCKYA-XPdGLq-2k9Cew6-ViCgrB-23QUBQR-21rF362-CCSE2n-23AwZ7m-CbKedu-gznqa-2dHUv3k-EE8eoq-gznq9-i5zqqk-WYSwcf-XWVgQk-WabAAG-gLjRj-gDcLp-4VvECm-259cDCS-i5zqRk-25cV246-i5yNvM-gupiMJ-PXLbhr-LUACZ7-ihvxSH-ihvvVg-ihwjbF-ihvxDX-i5yQDd-ihzQwK-fWwpxb-rarKrm-8LWTQf-qVar5j-ihzAPA-JNrgyK-ihzBrC-ca6Ex9-2kCTSrj-ihz67k-qfJsYd-248ePDL-ihztbm-ihzuyS-LQYZQq-2kCTRxL-ihvWPA) by Picturepest on Flickr._
92+
93+[^1]: Kaufman, Jim. (2010) ["Evolution and immunity"](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2913256/). _Immunology 130_, iss. 4, pp. 459--462.
94+[^2]: President Eisenhower's original coinage was likely "the military-industrial-academic complex."
95+[^3]: E.g., Richard Bellman of the RAND Corporation on the origin of "dynamic programming," a mathematical discipline: in dealing with a recalcitrant secretary of defense who hated the word "research," Bellman instead chose the word "dynamic" arbitrarily because "it's impossible to use the word 'dynamic' in a pejorative sense. ...It was something not even a Congressman could object to. So I used it as an umbrella for my activities." (Bellman, Richard. (1984) [_Eye of the Hurricane_](https://books.google.ch/books?id=4FwGCwAAQBAJ&lpg=PA159&dq=#v=onepage&q=).)
96+[^4]: The nuclear triad doctrine, joining the Air Force's Strategic Air Command bombers, the Navy's nuclear submarines, and the Army's ICBMs and other assorted nuclear warheads, was based less on strategic considerations than on appeasing constituent departments of the military. Strategists developed a formal justification decades later in a magnificent demonstration of motivated reasoning. (Woolf, Amy. (2016) "U.S. Strategic Nuclear Forces: Background, Developments, and Issues". [CRS 7-5700](https://digital.library.unt.edu/ark:/67531/metadc847627/m2/1/high_res_d/RL33640_2016Mar10.pdf).)
97+[^5]: The Air Force early commissioned the RAND Corporation on contract with Douglas Aircraft Company as the first "think tank"; RAND soon upended the traditional role of passive reception of studies by making its own recommendations and showing their analytical chops. Other service branches followed suit, such as the U.S. Navy's Center for Naval Analyses and the Battelle Memorial Institute for various federal contracting agencies; compare also the role of the national laboratory system, e.g. Los Alamos, Sandia, Livermore, etc. for the Department of Energy and Department of Defense. (Rich, Michael. (2003) "RAND: How Think Tanks Interact with the Military". [RP-1050](https://www.rand.org/pubs/reprints/RP1050.html).)
98+[^6]: "On January 18, 1994, the first large-scale deliberate USENET spam occurred. A message with the subject "Global Alert for All: Jesus is Coming Soon" was cross-posted to every available newsgroup." ([Wikipedia, "History of email spam"](https://en.wikipedia.org/wiki/History_of_email_spam))
99+[^7]: The first instance which seems to have brough this to general public awareness was the submission of Judge Robert Bork's video rental history as evidence in his Supreme Court hearings before the U.S. Senate. The resulting Video Privacy Protection Act was delightfully naïve. Besides relying on "video rental" narrowly construed, users have effectively no leverage against unilaterally-imposed terms of service and end-user license agreements. (See, e.g., [Electronic Privacy Information Center, "Video Privacy Protection Act"](https://archive.epic.org/privacy/vppa/).)
100+[^8]: E.g. Tumblr and OnlyFans and adult content; Twitter and right-wing content; Youtube and Facebook and unsanctioned medical content, etc. Note that this is regardless of the viability of a given view or the necessity of vigorous debate within a field, but focuses on the palatibility of politics to the megacorp entity providing the platform, even if the content drives platform usage.
101+[^9]: Hughes, Eric. (1993) [_A Cypherpunk's Manifesto_](https://nakamotoinstitute.org/cypherpunk-manifesto/).
102+[^10]: The mass shift to remote work from March 2020 onwards due to the COVID-19 pandemic has accelerated the trend of corporate colonization of private spaces. At first, this was occasionally humorous, as when a child ran into the background of a Zoom call, or underwear or private materials were inadvertently left in view of the remote audience. In the end, it demanded that individuals reconfigure their homes to accommodate mass corporate preferences, thus another invasion of private space by the megacorp panopticon. I note as well an invasive doctrine demanding "truth in communication" under names like ["radical transparency"](https://www.bridgewater.com/principles-and-culture) and ["radical candor"](https://third-bit.com/2018/11/24/afraid-of-change/) put forward by partisans of power over against vulnerable employees, clients, and customers, who may be disproportionately affected by a megacorp demand for one-sided transparency.
103+[^11]: Several have pointed to the failure of Craig S. Wright to demonstrate cryptographically that he is Satoshi Nakamoto, the pseudonymous inventor of Bitcoin. (C.f. Khaosan, Venzen. (2016) ["Craig Wright is Not Satoshi Nakamoto---The Technical Proof"](https://www.ccn.com/technical-proof-craig-wright-not-satoshi-nakamoto/).)
104+[^12]: Davidson, Dale, and Rees-Mogg, William. (1999) _The Sovereign Individual: Mastering the Transition to the Information Age_.
105+[^13]: Raymond, Eric. (1999) [_The Cathedral and the Bazaar_](http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s04.html).
106+[^14]: The [Coalition for Content Provenance and Authenticity](https://c2pa.org/) "addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content."
107+[^15]: Cf. Walker, Shawn, et al. (2019) ["The disinformation landscape and the lockdown of social platforms."](https://www.tandfonline.com/doi/full/10.1080/1369118X.2019.1648536) _Information, Communication & Society 22_, pp. 1531--43. Walker et al. lament that "highly ephemeral mis/disinformation campaigns" are not susceptible of study due to closed platform APIs. "Social media platforms \[attempt\] to rekindle trust by appearing to reinforce individual privacy within a newly secured user community, a set of measures that also locked academic and non-profit researchers out from studying social platforms while preserving corporate and business access to social media users' data." They fail to address the tension between community self-determination and academic exploitation.
108+[^16]: "If in fact you can't crack \[the encryption\] at all, government can't get in, then everybody is walking around with a Swiss bank account in their pocket -- right? So there has to be some concession to the need to be able to get into that information somehow." ([Barack Obama in March 2016 at SXSW](https://www.businessinsider.com/obama-comments-on-encryption-at-sxsw-2016-3))
109+[^17]: Heninger, Nadia. (2016) ["The Legacy of Export-Grade Cryptography in the 21^st^ Century"](https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf).
110+[^18]: Chohan, Usman. (2017) ["The Decentralized Autonomous Organization and Governance Issues"](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3082055). Discussion Paper Series: _Notes on the 21^st^ Century_.
111+[^19]: Lessig, Lawrence. (1999) _Code and Other Laws of Cyberspace_.
112+[^20]: Hobart, Byrne `~lableg-tadrex`. (Nov 17, 2021) ["The Promise and Paradox of Decentralization"](https://urbit.org/blog/2021-11-18-the-promise-and-paradox-of-decentralization). _The Diff_.
113+[^21]: See, e.g., the Governor Alpha smart contract protocols. Solari, R. (2021) ["The case for Governor Alpha".](https://medium.com/tally-blog/the-case-for-governor-alpha-15c1362d49eb)
114+[^22]: Robinson, D. (2020) ["Ethereum is a dark forest"](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest). Paradigm blog.
115+[^23]: [Uqbar Network](https://uqbar.network/); ["Introducing Uqbar Network"](https://uqbarnetwork.substack.com/p/introducing-uqbar-network); \~hocwyn-tipwex/uqbar-event-horizon (Urbit group)
116+[^24]: This is not to deny the benefits of system-legibility, in particular legal protections. As common law develops around DAOs, I hope for similar affordances where they must interact with the legacy legal system.
117+[^25]: Originally this list included Discord, as there has been substantial growth in stable goal-oriented communities thereon. However, more recently the company [adopted a user policy](https://discord.com/blog/addressing-harmful-off-platform-behavior) which subjects use of their product to judgment calls about "off-platform behavior"---a clear violation of a cypherpunk ethos which Discord likely never espoused anyway.
118+[^26]: E.g., Auerbach, David. (Mar 3, 2022) ["The metaverse will steal your identity"](https://unherd.com/2022/03/the-metaverse-will-steal-your-identity/). _UnHerd_. Auerbach correctly recognizes and decries the looming "monetisation of identity" which will allow any platform controller to incentivize prosocial or antisocial behaviors at will.
content/blog/infrastructural.mdnew file+73
@@ -0,0 +1,73 @@
1++++
2+title = "Infrastructural"
3+date = "2020-04-09"
4+description = "A reflection–meditation on OS 1’s initial form development, and the attitude we brought to bear in designing it."
5+
6+[extra]
7+author = "É. Urcades"
8+ship = "~fabled-faster"
9+image = "https://media.urbit.org/site/posts/essays/infrastructural-2.jpg"
10++++
11+
12+
13+
14+## Seasons
15+
16+It’s early 2020, the transition between winter and spring, and Tlon’s interface group has concluded a series of projects that mark a transition point for the Urbit project. We’ve named the culmination of our efforts “OS 1,” as in “Operating System 1.”
17+
18+For those who have yet to try it out, OS 1 is a bundling of “essential digital utilities” in the form of 1) a linear chat, 2) a long-form text editor and publishing/discussion medium, 3) a link bookmarking/discussion software, and most importantly, 4) a grouping mechanism that allows you to bundle the above services in the context of a group of friends, acquaintances, or family. We see these utilities as being archetypical “software shapes” that are inherently flexible and open for interpretation in terms of their use, but we have wild expectations for how these software shapes will evolve in the near future. Later design output and supplementary writing will expand upon what we mean by this.
19+
20+Functionally, OS 1 has been designed to serve as a bridge between [OS 0](https://urbit.org/blog/landscape-a-portrait/) (The first interface in Urbit’s evolutionary chain) and OS 2 (Urbit’s eventual departure from the web browser context). In its service as a “bridge”, we designed OS 1 to extend from the baseline app-like “module” experience first defined in OS 0, while granting it new affordances that gesture towards nascent conceptions of “communal computing” we have planned for OS 2 onward.
21+
22+This year, as the warmer seasons give way to chillier ones, we plan on further demonstrating our vision of what new computers and networks can be and how they feel to use. Until then, we'll be building upon OS 1, our foundation and initial take on what we deem "human-shaped infrastructure."
23+
24+This post serves as a reflection–meditation on OS 1’s initial form development and the attitude we brought to bear in designing it. I will be highlighting a few disparate-yet-interconnected themes we encountered in our design work, and how we materially began to address them.
25+
26+## Products
27+
28+Urbit’s interfaces, and the process by which we build them, are resolutely not projections of the world’s current conception of digital design—that of mass digital product design. Products are sold, bought, and discarded as they are in their physical sense. Digital products are slotted into the [vending machines](https://urcad.es/writing/personal-computer-vending-machine/) we call our phones and are mass produced as candy is produced. Candy is _essentially_ free, and contemporary digital products are _absolutely_ free of cost. If you’re reading this, you probably already have a good idea of what free corporate digital products mean for your privacy.
29+
30+Urbit is distinctly _not_ free (as in freely offered as a service via a corporate entity), and your urbit is distinctly _not_ a product. As we trace over the interfaces we design with our cursors, we’re not building a product, we’re not selling a product, we’re not painting a product, and we’re certainly not decorating a product.
31+
32+Here at Tlon, we’re assembling thoughtful infrastructure you can spend your life using, learning, and extending. We’re attempting to assemble spaces you can one day pass on to friends, close collaborators, or possibly your grandchildren. We are resolute in our practice and stay our hands to the greatest degree possible as a result of this mindset.
33+
34+## Beautiful Infrastructure
35+
36+OS 1, while incremental in its initial expression from OS 0, serves to outline our stance of what sublimely beautiful, useful, and durable digital infrastructure should feel like to inhabit. For the purposes of OS 1, we can imagine “Beautiful Infrastructure” to form the spirit of what we’re building:
37+
38+**Beautiful infrastructure is inhabitable**. You’re not floating in an infinite feed of content streams. You are situated in a defined space with edges you can shift at-will, as your needs deem fit. Our model for inhabitable computing is new and in limited flux, but our vision is long.
39+
40+**Beautiful infrastructure is a gravitational force**. Even if you can’t feel it or directly experience it, well-designed infrastructure is a cohering force. One is grounded with respect to the infrastructure they live alongside.
41+
42+**Beautiful infrastructure is like a [shell](https://en.wikipedia.org/wiki/Shell)**. Well-considered infrastructural projects provide durable, generalized, reusable, and most importantly, _self-designed_ containers around otherwise formless flows of information.
43+The current state of mass software design has gotten many of the “reusable” elements of design down pat, but these structures are optimized to pump ads and information into your brain, algorithmically-sorted-linear-feed style.
44+In Urbit, I can take the conceptual container of "temporal linearity" and use this to shape communication data as I see fit. I should be able to shape once-linear communication and cast it into a nodal communication model: My DM is now a MUD.
45+
46+Truly beautiful infrastructure undergirds the daily exchanges people actually care about—I don’t drink plumbing, I drink the water it carries and protects.
47+
48+Another way of thinking about “Infrastructure” (here defined loosely as “the _truly_ essential structures that allow society at varying scales to operate”) is to think about it in terms of interpersonal support structure.
49+
50+We deeply hope that Urbit can form a support structure for you and your community.
51+
52+These self-evident statements underlie the core problems we sought to address in designing a userspace for OS 1: How do we design an _actually_ personal digital infrastructure? What does infrastructure look like when shared with immediate friends? With a cooperative organization? How can we impress upon Urbit's earliest adopters that once they've obtained an Urbit ID, their computer is at that moment _literally_ entirely theirs?
53+
54+
55+
56+## Expressing Infrastructure
57+
58+OS 1 was optimized from an interface design standpoint to ensure that a new inhabitant viscerally felt like there was a “space to inhabit”, or a “canvas to be painted”, or a set of simple and fundamental digital structures they could arrange to make their computer their own.
59+
60+Counterintuitively, designing around this notion of a "rich blank slate” required OS 1 to be designed in a manner that _almost_ results in it feeling incomplete, or on the verge of appearing deeply unremarkable.
61+
62+A few key design decisions emphasized the above gestalt we sought to express:
63+
64+- We decided very early on to revert the colorful presentation of Modulo to a literal blank slate—OS 1 is much like a sheet of graph paper now.
65+- All typography and typographic representation was severely flattened. This decision was one of our more drastic ones, and granted OS 1 a sense of being somewhat more "undirected" in terms of its form. We hope that as our system becomes more robust, users can decide which elements of their systems require emphasizing, to feel most at home with their information.
66+- The majority of graphics used throughout the system were rendered into black and white line drawings. As architectural schematics and orthographic projections flatten their representation of reality so an architect can “see structure” easier, we made the decision to express a visual foundation that felt more like a diagram than an ergonomic user interface.
67+- In its visual simplicity, OS 1 was essentially arranged to emanate the quality that modifying the underlying system was a simple task. Rather than present Urbit's first users with beautiful artistry and a sense that our infrastructure was to remain untouched and sacred, we decided to present a visual face to the project that felt nearly rudimentary, nothing outside the realm of editorial capability for the average person.
68+
69+Many other small constraints have been set into place to build what we truly believe to be simple, durable, personal, digital infrastructure.
70+
71+While visually primitive, OS 1 has managed to manifest a rich systematic expressiveness based on how it seems to be currently inhabited. We've been enjoying witnessing the ways people are beginning to interpret and make use of the faculties provided to create communal computing experiences of their own.
72+
73+What's most wonderful to observe is the fun people are having in striking out on their own in this collective endeavor. More than anything, we hope Urbit’s inhabitants are having a good time and learning to enjoy computers again.
content/blog/interim-constitution.mdnew file+145
@@ -0,0 +1,145 @@
1++++
2+title = "Interim Constitution"
3+date = "2016-05-15"
4+description = "The governing rules for the early days of the Urbit network."
5+aliases = [ "/posts/essays/interim-constitution", "/posts/constitution" ]
6+
7+[extra]
8+author = "Tlon"
9+ship = ""
10+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/interim-constitution.jpg"
11++++
12+
13+
14+
15+## Declaration of purpose
16+
17+Urbit is a new network created by the Tlon Corporation. Tlon's
18+broad intention is to surrender governance of Urbit to its users,
19+as soon as the community is collectively ready to receive it.
20+
21+This constitution (which is not a legal contract, just our present
22+intent, which may be updated arbitrarily) describes our governance
23+process during this interim period. Its design borrows from validated
24+historical structures, mainly Roman and Anglo-American.
25+
26+The last and most important task of the interim government is to
27+write the next version of the constitution. This document may or
28+may not incorporate any or all of the interim structures.
29+
30+## Beliefs and principles
31+
32+See our document of [beliefs and principles](/blog/beliefs-and-principles).
33+
34+## Governance structures
35+
36+The interim republic has four branches: an executive consulate, a
37+galactic senate, a stellar congress and a planetary assembly.
38+
39+For the interim, full authority is held by the (Roman style)
40+consulate. The legislature (senate, congress, assembly) is
41+advisory. The senate is never consulted and the congress is
42+almost never consulted.
43+
44+In the future, the assembly of planets specializes in technical
45+governance. The congress of stars specializes in internal, but
46+nontechnical, governance. The senate of galaxies selects the
47+consuls and holds them accountable, and specializes in compliance
48+with external powers. All votes, elections and other public
49+actions are logged in the Urbit global namespace.
50+
51+As in most parliamentary systems, each of these structures sets
52+and enforces its own internal rules of operation.
53+
54+### Consulate
55+
56+A consulate is a two-person executive. The consuls must work out
57+their own organization and division of labor. Disagreements
58+between consuls are resolved by the senate.
59+
60+A consul must be a senator. The senate, voting per galaxy,
61+replaces the consulate whenever either a vacancy exists, or a
62+vote of no confidence gains a majority. When electing consuls,
63+first a plurality selects one consul; then the plurality of those
64+who voted for anyone but the winner selects the second.
65+
66+### Senate
67+
68+The _senate_ is the set of all galaxy holders, voting per galaxy.
69+It does not convene except to replace the consuls. Its
70+proceedings are in private.
71+
72+To avoid growing the network too quickly, galaxies are activated
73+gradually. Initially, only one galaxy is active, the root `~zod`
74+(galaxy 0).
75+
76+Further activation is at the discretion of the consuls, who
77+control `urbit.org` and will only bind activated galaxies to
78+`galaxy.urbit.org`. Routing at the galaxy layer is by DNS, so
79+unbound galaxies, and any stars or planets they launch, hear no
80+packets.
81+
82+When any galaxy, activated or not, creates its initial
83+certificate, the consuls add its fingerprint to the galaxy table.
84+Non-activated galaxies can still be rekeyed.
85+
86+### Congress
87+
88+The _congress_ is the set of all active independent stars.
89+voting per star. An _independent star_ is any star _not_ owned
90+by anyone who is either a senator, or has some connection to one
91+that would pose a conflict of interest.
92+
93+The congress of stars is designed to exercise project and
94+community governance. Its proceedings are in private. The
95+consuls convene it at their pleasure, and keep it informed.
96+
97+### Assembly
98+
99+The _assembly_ is the set of all active primary planets, voting
100+per planet. A _primary planet_ is the main planet of a unique
101+human (no sockpuppets).
102+
103+The assembly is responsible for technical governance. Its
104+proceedings are in public.
105+
106+### The next constitution
107+
108+The congress proposes, and the senate approves, the next version
109+of this constitution. Future constitutions should be defined in
110+a smart contract platform, such as Ethereum.
111+
112+## Galaxy table
113+
114+95 galaxies are held by the [Tlon Corporation](https://tlon.io/). 50,
115+reserved for urbit.org, the future community foundation. 40, by
116+Tlon employees and their family members (24 by Curtis, who
117+started in 2002; 16 by everyone else, who started in 2014). 34,
118+by outside investors in Tlon. 37, by 33 other individuals, who
119+donated to the project, contributed code or services, won a
120+contest, or were just at the right place at the right time.
121+
122+Note that while Tlon and its employees still control a majority
123+of galaxies, the senate is a ceremonial body; the consulate is
124+effectively equivalent to Tlon.
125+
126+## Inception
127+
128+This constitution takes effect as soon as the initial public
129+presale of Urbit address space is complete.
130+
131+## Endowment
132+
133+The 50 galaxies marked "urbit.org" in the galaxy table are
134+intended as property of the republic, and will be used only in
135+the interests of the republic and Urbit as a whole.
136+
137+Externally, these galaxies are held by Tlon; internally, they are
138+managed and voted by Tlon. Once the republic acquires a legal
139+identity and an independent human organization, Tlon pledges to
140+donate the `urbit.org` galaxies, the DNS domain, and the GitHub
141+`urbit` account to it.
142+
143+## First consuls
144+
145+The first consuls are Galen Wolfe-Pauly and Raymond Pasco.
content/blog/interplanetary_commerce.mdnew file+37
@@ -0,0 +1,37 @@
1++++
2+title = "Interplanetary Commerce"
3+date = "2021-04-08"
4+description = "OS-level commercial primitives."
5+tags = ["bitcoin"]
6+
7+[extra]
8+author = "Christian Langalis"
9+ship = "~pindet-timmut"
10+image = "https://media.urbit.org/site/posts/essays/ocean.jpeg"
11++++
12+
13+
14+
15+## Paying
16+
17+A year ago, we started [integrating](https://urbit.org/blog/urbit-and-bitcoin/) Bitcoin into Urbit to be an OS-level primitive for money. Our initial objective: build a payments wallet, equally sovereign and ergonomic. The first public version, releasing this month, will have a broad set of capabilities including ship-to-ship payments, hardware wallet support, and full node integration. We’ll be unveiling this wallet on [April 27th](https://www.meetup.com/urbit-sf/events/276741426/). Do join us.
18+
19+Things only accelerate from here. Our next objective, to integrate Lightning Network capability, is now an [active bounty](https://gist.github.com/timlucmiptev/53ef1d290e55ea2fa25d9df681c32695) and open for applicants. Early on, we [recognized](https://www.youtube.com/watch?v=DTvRVHMbrcY) the congruence and compatibility between the Urbit and Lightning networks. Routing Lightning payments is an obvious business model for Urbit providers, one that can even nucleate new features onto Lightning itself. What we’re ultimately driving at is fully-sovereign Bitcoin usage, with the UX of the Cash App.
20+
21+## Being Paid
22+
23+> And there is all the difference in the world between paying and being paid. The act of paying is perhaps the most uncomfortable infliction that the two orchard thieves entailed upon us. But being paid,—what will compare with it?
24+>
25+> **Herman Melville**
26+
27+However, a good wallet is only half the equation for a holistic P2P commercial experience. Interfaces for selling goods and services is the other half. While we don’t part with our Bitcoin [easily](https://nakamotoinstitute.org/mempool/everyones-a-scammer/), two initial markets appear logical and attractive: content and Urbit-native services.
28+
29+First, digital cottage industry, the “creator economy”, is blossoming. Streaming, podcasting, and writing on platforms like Youtube, Patreon, and Substack has been big business [lately](https://otherlife.co/barbarians-past-the-gate/). What fintech did to “unbundle the banks", we will now do to media monopolies and their centralized distribution platforms. With the introduction of Urbit payments, you can syndicate, distribute, and monetize your media on Urbit. By selling access to a private group containing content, digital creatives can begin doing this today.
30+
31+Second, Urbit-native [service providers](https://urbit.org/blog/providers/) are now operating at scale. Companies offering Urbit hosting, onboarding, Urbit IDs, and software now communicate with their customers directly on the network. A basic set of commercial tools will make their processes more efficient. Storefront interfaces, paywalls, CRM, and reputation tools will replace the ad-hoc assemblages they currently use.
32+
33+The Urbit Foundation is soliciting contributors to this project through Urbit Grants. If you’re interested in working on any of these components [send us a proposal](https://grants.urbit.org/create).
34+
35+## An Ocean
36+
37+After honing our commercial tools on these use-cases, we’ll sail into a blue ocean. On the horizon: beautiful products, deployable at scale, built with the robust primitives of Urbit OS. Extensibility is Urbit’s promise to middle-men: every Web2.0 service they use to scalp us will find its P2P analog on Urbit. We invite developers and entrepreneurs of all stripes to join in the feeding frenzy. Ideas are constantly nucleating in [Urbitcoiners](web+urbitgraph://group/~pindet-timmut/urbitcoiners) and [Urbit Community](web+urbitgraph://group/~bitbet-bolbel/urbit-community/graph/~darrux-landes/business-building-on-urbit).
content/blog/introducing-os1.mdnew file+140
@@ -0,0 +1,140 @@
1++++
2+title = "Introducing OS 1"
3+date = "2020-04-29"
4+description = "OS 1 is somewhere between ‘productivity software’ and a ‘social network’. We think it’s the beginning of an altogether new breed of social computing."
5+
6+[extra]
7+author = "Galen Wolfe-Pauly"
8+ship = "~ravmel-ropdyl"
9+image = "https://media.urbit.org/site/posts/essays/intro-os1-landscape.png"
10++++
11+
12+<video class="ba w-100" autoplay loop src="https://media.urbit.org/site/posts/essays/intro-os1.mov"></video>
13+
14+## Introducing OS 1
15+
16+OS 1 is a simple, unified system for building digital communities. OS 1 is for groups of people sharing messages, links, and notes on Urbit.
17+
18+We designed and built OS 1 for ourselves, and we’re really enjoying using it every day. Instead of figuring out how to duct tape together apps and services, we use a single system to stay connected with the company and broader Urbit community that we really trust. OS 1 makes it feel like our company and community has a place in the digital world to call home.
19+
20+Most groups of friends and collaborators juggle apps and services to stay connected in the digital world today. We think OS 1 is a much better model. It’s still too early to ask the whole world to switch over to it — but we’re ready to help onboard our friends and adjacent communities into Urbit to have them try it out and get their feedback.
21+
22+First, let’s walk through what OS 1 is and how we’ve been using it. Then, if OS 1 is interesting to you, we’ll tell you how to apply for a community grant.
23+
24+Here we go:
25+
26+## What is OS 1?
27+
28+OS 1 is a very simple, integrated tool for messaging, sharing links, and writing with a group of people. OS 1 is somewhere between ‘productivity software’ and a ‘social network’. We think it’s the beginning of an altogether new breed of social computing.
29+
30+OS 1 isn’t our first attempt to build an interface for Urbit, but it’s certainly the most complete. OS 1 is the first Urbit interface that doesn’t feel like an experiment.
31+
32+Today, when you boot Arvo (the Urbit OS kernel) and connect your browser to it, you’ll see OS 1. OS 1 isn’t the only possible client for Arvo, though. Anyone could build their own client or, since it’s completely open source, modify OS 1 however they like.
33+
34+For most people, out of the box, OS 1 feels like an app. Given that it’s running on Urbit OS — it’s much more than that. It’s a full-fledged general purpose virtual computer that’s secure and private to you. We’ll come back to what that means at the end.
35+
36+Let’s walk through the features of OS 1 one by one to see what it’s like.
37+
38+### Groups
39+
40+
41+
42+The group is the main building block in OS 1. A group is simply a list of people that share a set of chat, links, and publish channels. A group is sort of like a super powerful group chat.
43+
44+A group of friends might just share a few chat channels. A reading group might just share a publish channel for discussion of what they’re reading and a links channel for upcoming books. As a company, we share a variety of chat, publish, and links channels to get things done and communicate. There are chats for each area of work, publish channels for digests and feature discussion, and links channels for music, influences and references, for example.
45+
46+Each person in a group is identified by their [Urbit ID](https://urbit.org/understanding-urbit/urbit-id/): a short, memorable name that you own with a private key (and belongs to you completely). Each group is private and requires an invite. Groups aren’t discoverable. They’re meant to be high-trust communities of people. More like a commune than a public event.
47+
48+Let’s walk through each module and talk about what they can do.
49+
50+### Chat
51+
52+
53+
54+Chat is chat: a sequential list of messages meant for synchronous communication. There are already a million ways to chat — but Urbit chat differs in a few important ways.
55+
56+First, each chat channel is only shared between the host and the members of a chat. When you DM with people, messages are sent peer to peer. The system is, in fact, decentralized and pseudonymous by default. No one knows anything about you outside of your Urbit ID.
57+
58+Second, each chat message is encrypted and signed by your Urbit ID. Again, we don’t call Urbit ‘secure’ yet since it’s unaudited — but we’re working to have Urbit audited this year.
59+
60+Third, chat in Urbit OS is a protocol for sending messages between computers on the network (known as “[ships](https://urbit.org/docs/glossary/ship/)” and identified by their Urbit IDs). It’s easy to imagine extending chat in all kinds of fun and interesting directions: chats that only accept certain message types, chats that have disappearing history, chats that you can only post to during certain times of day, and so on.
61+
62+(If you’re curious to try one of these things, or have an idea about something you’d like to experiment with — consider submitting a proposal in our [grants program](https://grants.urbit.org/). We regularly reward contributor work with address space.)
63+
64+We think of chat as a primitive, not simply a ‘better IRC’. But even in the rudimentary form it’s in today, chat is essential to delivering a feeling of being at home. There’s no way to deliver a complete interface for groups without chat.
65+
66+Anyway, not everything can happen in a chat. Let’s keep moving.
67+
68+### Links
69+
70+
71+
72+Links is a bit like Hacker News or Reddit. It’s just a collection of links with comments. There’s no upvoting or sorting. We decided that with a small group it’s more about collecting references than deciding what’s most exciting — but permutations of Links could be a great area for contributors to experiment with.
73+
74+We use links to collect external references and track things we’re thinking about. We’re always looking at things going on outside our small digital universe and talking about them. Links lets us keep an archive of those discussions.
75+
76+We originally imagined links as evolving into more of a general-purpose ‘collection creation’ interface. One where you can pull together images, video, URLs, maybe even runnable code and so on into a single channel. We’ll get there.
77+
78+### Publishing
79+
80+
81+
82+Publishing is somewhere between a blog and a note-taking system. A Publish notebook is a list of markdown files with optional comments. A private Publish notebook is like a journal, a group notebook can be like a forum (with comments on) or a collaborative blog.
83+
84+We use publish for both long-form discussion and one-way communication about what we’re working on in its current form. The editor is calm and simple. In distraction-free mode, it’s a nice place to put a note together.
85+
86+Publish, like all our other modules, is an interface to a generalized protocol for storing text. We have high hopes for how Publish can evolve into a flexible tool for notetaking and discussion with richer content types and better controls over structuring discussion.
87+
88+### Modules
89+
90+
91+
92+You’ll find a few other things on the home screen: a clock, the weather, and a simple command-line that we call the Dojo. These are system-wide utilities that aren’t group-specific.
93+
94+The clock and weather tiles are simple indications of the state of the outside world. We built them because they’re things we wanted to be able to check in on often. When you’re spending much of the day in front of a computer, it’s nice to know if you have enough daylight left to get some exercise in.
95+
96+### Dojo
97+
98+
99+
100+The Dojo gives you a quick way to see that, under the hood, Urbit OS is a powerful general-purpose system. The system hasn’t evolved to the point that our libraries, frameworks, and modules are polished to our standards. Since it’s still early, we can’t claim that it’s easy to develop on top of this platform. But we want it to become much easier.
101+
102+## Why we made OS 1
103+
104+We made OS 1 because we wanted to begin the process of re-centralizing our digital lives on a platform we actually control. Replacing all the services we use all at once is impossible — so we picked a suite that we felt would work nicely together. We’ve always felt that one of the most exciting things about Urbit is in bringing your digital life together in a way that feels like home.
105+
106+The digital home, we think, is what our computers are meant to be but simply can’t be in a world of cloud services. Once upon a time, thirty years ago, your personal computer was an open-ended tool that was reasonably simple to understand and use, lasted a pretty long time, and belonged to you in every way.
107+
108+OS 1 is a first step down the road back to a system that’s simple, durable, and belongs to you in every way. It’s a long road, and we feel like we’ve made a very significant step forward.
109+
110+One really critical thing about OS 1 is the pattern of ‘groups sharing modules’. This pattern makes it perfectly clear how a virtual computer can outcompete a bunch of different services. As the collection of modules in OS 1 → N grows, we make it easier for others to contribute modules, and we increase the flexibility of connecting modules our system quickly outruns the messy, disconnected world we’re currently stuck in.
111+
112+OS 1 isn’t mature enough to be _easy_ for outside contributors to add modules — but it is [open source](https://github.com/urbit/urbit), and anyone is welcome to tinker and experiment with modifying it. We run a [grants program](https://grants.urbit.org/) to reward contributors for improving any part of Urbit OS. As the system matures we expect this program to expand and accelerate.
113+
114+## Looking ahead
115+
116+By using OS 1 you inherit all the benefits of running Urbit OS. Each user runs their own node completely independently. Everyone using Urbit OS owns their own identity and data. And every Urbit OS node communicates over an encrypted and authenticated network. (Again, We don’t yet call Urbit OS ‘secure’ because it hasn’t been audited.)
117+
118+OS 1 is just a client for Urbit OS, of course. Other people could write their own clients that are completely different — like different windowing systems for Linux. Our hope is to build a client that includes interface components and frameworks that make it exceptionally easy to build modules for groups of people to share. Other clients could potentially invent entirely new ways of interacting with the underlying system.
119+
120+There are two threads by which OS 1 evolves into OS 2 and beyond. First, by becoming a more powerful system and second, by adding modules to expand our supported modes for interacting.
121+
122+In its current form, OS 1 by no means exposes all the power of the underlying system. Our approach to building OS 1 was to focus on the quality of the UI, and accept that it will feel like a monolithic app. We’re already working to evolve our interface into something that feels flexible to an ordinary user and developers can easily extend and build on top of.
123+
124+Specifically, we want better affordances for putting multiple streams of data on the screen at once, better keyboard shortcuts and navigation affordances, better libraries and frameworks for building modules. We want a standalone client and a single login system. These are some of the things currently on the drawing board.
125+
126+As far as modules are concerned, there are too many things we’d like to build to list them all. We’d really like to have threaded conversations; short, Twitter-style messages; biometric and status tracking; an e-book reader and annotations system — and that’s just to name a few we see in the near term.
127+
128+We’ve long since felt that the most powerful thing about Urbit is that it’s a general-purpose system. OS 1 puts us on the road to giving people an actual material sense of what using a general-purpose networked computer feels like.
129+
130+As we expand the affordances of the system and add modules over the course of OS 1, 2, and beyond we expect to deliver a system that can foster everyday creativity. There’s a long road ahead, in the best possible sense. We’re really excited about what the future holds.
131+
132+### Becoming a homesteader
133+
134+
135+
136+As a distributed team trying to stay connected, we like using OS 1 from day to day. We’d really like to hand-onboard a small group of like-minded groups of people who want to experiment with living on the fringe of the digital world. Toward this end, we started the community grants program.
137+
138+Each community that’s selected will get a block of address space to share, direct support, and (in the near future) free hosting.
139+
140+Please tell us a bit about yourselves [here](https://urbit.org/community/community-grants/).
content/blog/introduction-to-the-combine-dao.mdnew file+46
@@ -0,0 +1,46 @@
1++++
2+title = "Introduction to the Combine DAO"
3+date = "2022-07-01"
4+description = "Inside the mind of the Combine"
5+
6+[extra]
7+author = "Anthony Arroyo"
8+ship = "~poldec-tonteg"
9+image = "https://media.urbit.org/blog/cortina-ampezzo.jpg"
10++++
11+
12+
13+
14+_This is cross-posted from [The Combine DAO Blog](https://blog.the-combine.org). If you'd like to comment, join the public [Urbit group](https://urbit.org/groups/~famreb-todmec/the-combine-public)_
15+
16+Until a couple of weeks ago, The Combine was a subdivision of the Urbit Foundation with a budget earmarked to invest in new projects. As of Urbit NYC that all changed. Now we’re an honest-to-goodness DAO built on Urbit—by Urbit maximalists, for Urbit maximalists. We pool assets to invest in teams building new tools, products and services for the Urbit Universe. Our members are investors, engineers, founders and galactic senators.
17+
18+In this post we'll talk about what we're aiming to do and why we’re in the best position to do it. In a future post, we'll dive into technical and strategic insights drawn from building a DAO on Urbit.
19+
20+## Our Objective
21+
22+Our objective is simple: support organizations in building high-value projects on Urbit. Urbit address space has intrinsic, tradeable value, as is the case with many crypto assets. But, unlike most crypto, that’s just the tip of the Urbit iceberg. Where most crypto assets are built to be owned and exchanged, Urbit is built to be owned and used. It has the potential to replace virtually every centralized part of Web2 you use (but don’t own) today.
23+
24+The Combine DAO invests in teams working on projects that generate and capture value beyond Urbit address space. The price of address space reflects confidence in Urbit's user growth, but every increase in utility to an Urbit user — that is, every time a user can do more with their Urbit — creates additional value. The Combine takes advantage of this upside.
25+
26+For example, one of our portfolio companies, [Uqbar](https://uqbar.network), is building a smart contract platform on Urbit. The Uqbar network will use Urbit ships as nodes in their network, as ZK provers and sequencers, creating an ZK Rollup L2 with the full power of general compute and identity. While their use of the Urbit network as part of their infrastructure will drive demand for planets, stars and galaxies, the value of Uqbar is potentially much greater than that demand.
27+
28+So, members of The Combine DAO should believe at least one of two things:
29+
30+- That products built on Urbit can outpace the value of address space alone, and that The Combine is in the best position to capture that value.
31+- That successful projects built on Urbit will enhance the value of Urbit address space.
32+
33+## Our Pipeline
34+
35+The Combine works hand-in-hand with the Urbit Foundation, meaning we have unparalleled visibility into the development of new projects and teams on Urbit. The Foundation has been working hard to shore up Urbit's developer pipeline, with Hoon School constantly bringing in new developers. The last cohort had 61 finishers, seven of whom had no previous programming experience. The Foundation’s [Grants](https://urbit.org/grants) program is active with over 40 active grants. The Combine and The Foundation continue to work together to identify, nurture and launch projects in need of funding.
36+
37+## Our Membership
38+
39+Startups are risky by nature. Add Urbit’s novel technology and you’ve got more than your share of pitfalls. The Combine mitigates these risks through its membership. Combine members are long-time supporters of the project who have run startups, exchanges and have invested in successful technology on Urbit and beyond. The membership can help lead teams past challenges inherent to all new ventures. We're familiar with the technical and product landscape of Urbit and its adjacent technologies. All of us have experience building technology, on Urbit and outside it, which enables us to provide valuable coaching and due diligence.
40+
41+Another of our portfolio companies, [Holium](https://holium.com), is building unified tooling for DAOs. They started with an application that the Combine DAO uses internally: a voting app called “Ballot.” Holium’s founder has been working on a unified environment for DAOs for some time, but it wasn’t until he came to Assembly 2021 that the pieces finally clicked and he realized that Urbit was the correct stack for Holium’s projects. As he built Ballot on Urbit, The Combine provided product feedback, investor intros, and access to experienced contractors and personnel. Now we’re actively dogfooding Ballot as a core element in The Combine stack.
42+
43+In the coming weeks we’ll dive into the details of why we think Urbit is the natural home for DAOs. For now, we’ll just say that Urbit’s unified stack opens up a unique level of ownership and customizability to DAO builders. The Combine, as a DAO built on Urbit, to support Urbit, is test driving this use case. What we learn here will feed back into diligence, outreach and development priorities for the Foundation.
44+
45+In the next post, we’ll share technical insights for DAOs gleaned from our own experiences building The Combine DAO on Urbit.
46+
content/blog/io-in-hoon.mdnew file+342
@@ -0,0 +1,342 @@
1++++
2+title = "Input and Output in Hoon"
3+description = "Let's talk about IO in Urbit."
4+date = "2020-12-15"
5+
6+[extra]
7+author = "Philip Monk"
8+ship = "~wicdev-wisryt"
9+image = "https://media.urbit.org/site/posts/essays/zion-canyon-1.jpg"
10++++
11+
12+
13+
14+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.
15+
16+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!
17+
18+## The three styles of IO
19+
20+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.
21+
22+### Imperative IO
23+
24+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.
25+
26+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.
27+
28+```
29+output = fetchUrl(stripWhitespace(readFile(cliInput())))
30+```
31+
32+For readability, intermediate variables would be a good idea, but nothing stops you from nesting IO this way.
33+
34+### Monadic IO
35+
36+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.
37+
38+```
39+fileName <- cliInput()
40+url <- readFile(fileName)
41+output <- fetchUrl(stripWhitespace(url))
42+```
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+```
51+event :: Initialize
52+ | CLIInput text
53+ | FileInput text
54+ | HTTPResponse body
55+effect :: CLIInput
56+ | ReadFile fileName
57+ | FetchUrl url
58+ | Print text
59+main(event) {
60+ switch event {
61+ Initialize -> [CLIInput ~]
62+ CLIinput fileName -> [ReadFile fileName]
63+ FileInput url -> [FetchUrl stripWhitespace(url)]
64+ HTTPResponse body -> [Print body]
65+ }
66+}
67+```
68+
69+The effects produced are not functions but data.
70+
71+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.
72+
73+## A stateful, loopy example
74+
75+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.
76+
77+Imperative:
78+
79+```
80+text = "no text entered yet"
81+while (true)
82+ cli = readCli()
83+ if (cli != Null)
84+ text = cli
85+ request = readHttp()
86+ if (request != Null)
87+ respond(request,text)
88+```
89+
90+Monadic:
91+
92+```
93+loop("no text entered yet")
94+
95+where:
96+
97+loop :: text -> IO Null
98+loop =
99+ input <- readInput()
100+ switch input
101+ CLIInput newText -> loop(newText)
102+ HTTPRequest request ->
103+ _ <- respond(request,text)
104+ loop(text)
105+```
106+
107+State machine:
108+
109+```
110+text = "no text entered yet"
111+main(text,event) {
112+ switch event {
113+ CLIInput newText -> [newText, Null]
114+ HTTPRequest request -> [text, HTTPResponse text]
115+ }
116+}
117+```
118+
119+Again, note the response in the state machine is data, not a function.
120+
121+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.
122+
123+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]`.
124+
125+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.
126+
127+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.
128+
129+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.
130+
131+## In Urbit
132+
133+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.
134+
135+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://developers.urbit.org/reference/glossary/agent). Arvo, the vanes, and agents are all structured as explicit state machines.
136+
137+In addition, there are ["threads"](https://developers.urbit.org/reference/glossary/thread), 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.
138+
139+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.
140+
141+Agents are:
142+
143+- 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.
144+
145+- 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.
146+
147+- Permanent. Since it's upgradable and robust, there's no reason to stop its running.
148+
149+- 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.
150+
151+Threads are:
152+
153+- 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.
154+
155+- 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.
156+
157+- 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.
158+
159+- Easy to write long sequences of IO. Just...write the IO one line at a time.
160+
161+Arvo proper and the vanes are permanent pieces of software and, for this reason, state machines are more natural.
162+
163+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.
164+
165+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.
166+
167+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:
168+
169+```
170+loop()
171+
172+where:
173+
174+loop =
175+ request <- receiveRequest()
176+ agent = lookupAgent(request)
177+ response <- callAgent(agent, request)
178+ _ <- sendResponse(request, response)
179+ loop()
180+```
181+
182+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?
183+
184+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".
185+
186+In a state machine, the naive solution is:
187+
188+```
189+state :: (map request agent)
190+main(state, event) {
191+ switch event {
192+ HTTPRequest request ->
193+ agent = lookupAgent(request)
194+ [put(state, request, agent), CallAgent agent request]
195+ AgentResponse request response ->
196+ [del(state, request), HTTPRespond request response]
197+ }
198+}
199+```
200+
201+Upgrading this is trivial, since the state (map of requests to outstanding calls to agents) is explicit. It also trivially handles concurrent requests.
202+
203+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.
204+
205+Userspace agents similarly are permanent entities that need to not lose data or get stuck. For this reason they’re structured as state machines.
206+
207+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!
208+
209+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.
210+
211+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.
212+
213+Monadic:
214+
215+```
216+topStories <- fetch(topStoriesUrl)
217+loop(topStories)
218+
219+where:
220+
221+loop :: topStories -> IO Null
222+ if topStories is Null
223+ return Null
224+ comments <- retryLoop(5,head(topStories))
225+ otherComments <- loop(tail(topStories))
226+ append(comments,otherComments)
227+
228+retryLoop :: [n story] -> IO Comments
229+ comments <- fetchComments(story)
230+ if comments is HTTPError:
231+ if n == 0:
232+ bail
233+ else:
234+ retryLoop(n-1, story)
235+```
236+
237+State machine:
238+
239+```
240+state :: Initial
241+ | FetchingTop
242+ | FetchingStory comments stories retries
243+ | Done comments
244+
245+main(state, event) {
246+ switch event {
247+ Initialize ->
248+ assert state == Initial
249+ [FetchingTop, Fetch topStoriesUrl]
250+ HttpResponse response ->
251+ switch state {
252+ FetchingTop ->
253+ [FetchingStory Null stories 5, FetchComments head(stories)]
254+ FetchingStory comments stories retries ->
255+ if response is HTTPError:
256+ if retries == 0:
257+ [Initial, Null]
258+ else:
259+ [FetchingStory comments stories retries-1,
260+ FetchComments head(stories)]
261+ else:
262+ comments = append(response,comments)
263+ if tail(stories) is Null:
264+ [Done comments, Null]
265+ else:
266+ [FetchingStory append(comments,response) tail(stories) 5,
267+ FetchComments head(tail(stories))]
268+ }
269+ }
270+}
271+```
272+
273+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.
274+
275+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.
276+
277+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.
278+
279+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?
280+
281+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.
282+
283+These aren't completely mutually exclusive, but it's surprising how often they are.
284+
285+### Jael: a case study
286+
287+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).
288+
289+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.
290+
291+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.
292+
293+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.
294+
295+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.
296+
297+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:
298+
299+```
300+syncEthereum oldBlockNumber -> IO [newBlockNumber, newTxs]
301+```
302+
303+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.
304+
305+From Jael's perspective, it looks something like:
306+
307+```
308+state :: State block txs outstandingThread
309+main(state,event) {
310+ switch event {
311+ Initialize -> [State 0 Null Null, StartTimer (now + five minutes)]
312+ TimerFired ->
313+ effects = If outstandingThread is Null
314+ then Null
315+ else [Kill outstandingThread]
316+ newId = newThreadId()
317+ [State txs newId,
318+ append(effects,
319+ StartThread newId syncEthereum(block),
320+ StartTimer (now + five minutes))]
321+ ThreadFinished Failure -> [State block txs Null, Null]
322+ ThreadFinished Success newBlockNumber newTxs ->
323+ [State newBlockNumber append(txs,newTxs) Null, Null]
324+ }
325+}
326+```
327+
328+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.
329+
330+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.
331+
332+## Recap
333+
334+Let's recap what we've covered:
335+
336+- There are three styles of IO: imperative, monadic, and explicit state machines.
337+- Urbit supports explicit state machines (agents) and monadic IO (threads).
338+- Explicit state machines are preferred for permanent, robust, concurrent code.
339+- Monadic IO is preferred for short-lived code with complex IO.
340+- 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.
341+
342+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/iot.mdnew file+445
@@ -0,0 +1,445 @@
1++++
2+title = "Lunar Urbit and the Internet of Things"
3+date = "2021-04-29"
4+description = "Potential future use cases of moons for industry and consumers"
5+
6+[extra]
7+author = "Jonathan Paprocki"
8+ship = "~datnut-pollen"
9+image = "https://media.urbit.org/site/posts/essays/phobos.jpeg"
10++++
11+
12+
13+
14+Each of the ~4B 32-or-fewer-bit or [Azimuth](/docs/glossary/azimuth)
15+identities, namely [planets](/docs/glossary/planet),
16+[stars](/docs/glossary/star), and [galaxies](/docs/glossary/galaxy), may
17+spawn ~4B 64-bit child identities known as [moons](/docs/glossary/moon).
18+Moons are the undeveloped wild outback of Urbit, with a story waiting to be told
19+that promises to be as enormous in scale as the cloud personal computing story
20+told by planets, and possibly even more so.
21+
22+Throughout this piece, we use "Earth" and "Mars" in the Urbit sense. "Earth"
23+refers to the [current computing
24+paradigm](https://en.wikipedia.org/wiki/Big_ball_of_mud). "Mars" refers to the
25+perfected computing paradigm that Urbit aspires to be, but also to the current
26+and future state of Urbit.
27+
28+Today we will review the prehistory of moons on Earth, give a snapshot of how
29+moons are being utilized on Urbit in 2021, cover existing issues with consumer
30+IoT and how Urbit resolves them, and speculate what the lunar locus of the Urbit
31+ID address space may become in the future. To keep the futurist scope limited,
32+we primarily speculate on the usage of moons in (industrial) internet of things
33+settings, especially with respect to agriculture, and how they may manifest as
34+the workhorse collection unit of decentralized data markets.
35+
36+For those unfamiliar, moons differ from all other
37+[ships](/docs/glossary/ship) in that they are not independent identities
38+with total sovereignty over their data and keys. Instead, their cryptographic
39+keys are issued and controlled by their parent identity. The relationship
40+between the keys of a parent ship and its moons are analogous to the
41+relationship between primary keys and subkeys in a system like
42+[PGP](https://en.wikipedia.org/wiki/Pretty_Good_Privacy). The parent may revoke
43+or change its child moons' keys at any time. A typical relationship between a
44+planet and a moon may be like one of a human and their smartphone. If you lose
45+your phone, you don't want someone to pretend they are you, operating one of
46+your moons, on the network. The planet can revoke the keys, and the moon stored
47+on the phone becomes inert, no longer able to communicate with the network.
48+While planets and stars also depend on their sponsor to assist with peer
49+discovery and software updates, these relationships rely on mutual agreement,
50+since either party may choose to discontinue the relationship and establish a
51+new one elsewhere. Moons possess no such freedom.
52+
53+### Lunar prehistory
54+
55+
56+
57+It may come as a surprise to you that you are already very familiar with moon
58+identities—they've just never been explained as such because the context in
59+which that terminology makes sense didn't exist before Urbit. Moons, in fact, are not
60+a new concept at all. Virtually your entire experience of the internet in the
61+modern era is the experience of someone who possesses some number of moons
62+subordinate to planets who mostly refuse to talk to one another. The feeling you
63+get of constantly moving between silos, juggling accounts, not controlling your
64+own data, etc., is a direct result of the fact that, on Earth, you only possess
65+moons. No planets.
66+
67+We're speaking, of course, of the client-server relationship. From the Urbit
68+perspective, the Facebooks, Twitters, and Googles of the world are planets, and
69+accounts held with these services may be thought of as moons subordinate to
70+those planets. Your account with these megacorps is only yours for as long as
71+they please. If you happen to step on a digital landmine, such as a virus that
72+causes Google's servers to believe you are a bot, you are suddenly banned from
73+their service, often with no recourse. All your data, your connections, your
74+network—vanished. We are all Mark Zuckerberg's moons, and they're armed to the
75+teeth with surveillance equipment.
76+
77+There are two classes of internet users: those with servers who hold all the
78+power, and clients who use those servers in the way prescribed by the owners.
79+Running a server is theoretically accessible to anyone, but practically
80+difficult: server maintenance is a technical endeavor that requires specialized
81+knowledge and substantial time investment. Other barriers exist beyond just the
82+technical: for instance, if you wish to set up your own email server, you will
83+probably be blocked by large providers because unknown email servers are almost
84+always spam. The root cause of this circumstance is that the email protocol
85+lacks [Sybil resistance](https://en.wikipedia.org/wiki/Sybil_attack). Urbit has
86+Sybil resistance built in, eliminating certain kinds of incentives for
87+gatekeeping such as this.
88+
89+We seek to level the playing field by giving everyone a server. We accomplish
90+this by making the process of running your own server (planet) as easy as
91+running your personal computer today. We aren't quite there yet, but we've made
92+leaps and bounds over the past couple of years.
93+
94+Of course, this analogy isn't perfect—Urbit moons are servers themselves, but as
95+they may only act in accordance with the wishes of its parent, they are
96+effectively as locked in degrees of freedom as a client is to a server. The
97+moon's keys may be revoked at any time by the parent. To distinguish these
98+prehistoric moons from Urbit moons, we will refer to them later as "primitive
99+moons".
100+
101+Urbit contends that moons are not the appropriate digital exocortex for a
102+responsible adult. They are for devices, experiments, or your children. We hope
103+that the dominant server-client relationship, which is the primary weapon of the
104+surveillance-industrial complex, will meet its end in the near future.
105+
106+### Moons in the early Martian era
107+
108+
109+
110+In 2021, moons are mostly unused on Urbit. There's a smattering of minor use
111+cases which we'll describe here, but they represent only a tiny fraction of
112+their ultimate potential.
113+
114+Tlon recently launched a survey bot called [Eliza](/blog/eliza), which was
115+initially a comet. We frequently got questions on whether Eliza was actually
116+Tlon's bot, because it could just as easily be a malicious actor posing as Tlon.
117+We soon plan to relaunch Eliza as a moon of `~zod`, which is the most
118+recognizable official galaxy of Tlon. This is to establish that the bot is
119+indeed official; only someone with access to `~zod` is capable of creating a
120+moon of `~zod`, and so a moon of `~zod` automatically carries with it a
121+cryptographic guarantee that you are communicating with an official digital
122+representative of Tlon. On Earth something like this would need to be
123+accomplished with certificate chains but, on Mars, this sort of authentication
124+is baked into the very fabric of the network, rather than as an additional layer
125+on top. This is a very good representative case of how moons naturally inherit
126+the reputation of their parent, even in the absence of any formal reputation
127+systems on Urbit.
128+
129+We see folks using moons as backup identities in case they can't or don't want
130+to access their primary planet for one reason or another. Again, since anyone
131+may verify the parent of a moon, the moon inherits the reputation of its parent.
132+These backups could be vanity identities—for instance, every `~sampel-palnet`
133+has underneath it a moon named `~master-sampel-palnet`[^0].
134+
135+Some use moons to host group(s). Hosting a group inevitably means that that ship
136+will process more network traffic, and a heavily trafficked group may impact a
137+ship's performance. Thus one may wish to offload group hosting duties to a moon
138+to maintain a more performant planet.
139+
140+As we currently lack a real system for 3rd party software distribution (though
141+see this recent [developer call](https://youtu.be/XwICC6Its1E) on a solution in
142+progress), one stopgap has been to download software by syncing a foreign
143+[desk](/docs/glossary/desk) to your ship. This is risky, as buggy software
144+may make break your ship and make it difficult to get running properly again.
145+For this reason, testing new software on the livenet is frequently performed on
146+moons, so as not to risk the parent ship if something were to go wrong.
147+
148+### Internet of Things
149+
150+
151+
152+Now we start to look towards the future by examining the problems faced by IoT
153+in the present and speculating on how Urbit might solve them.
154+
155+The Internet of Things is much maligned by technologists as a privacy, security,
156+and maintenance nightmare. These products usually depend on phoning home to
157+perform their service, which is inevitably a funnel by which personal data is
158+harvested, an attack surface for hackers to gain access to your home network,
159+and a single point of failure which may render the device useless, all in one!
160+One need look no further than the recent [Ubiquiti
161+breach](https://krebsonsecurity.com/2021/03/whistleblower-ubiquiti-breach-catastrophic/)
162+to see all of these failure modes happening on a massive scale, and this is par
163+for the course. This sort of dynamic is completely antithetical to the Urbit
164+philosophy, so any involvement of Urbit with IoT will reject many fundamental
165+assumptions on how IoT operates today.
166+
167+However, it's important to understand why the current IoT model works like this
168+at all. We posit that it ultimately stems from the fact that today's IoT
169+products are primitive moons for which you do not operate the parent planet.
170+Almost every IoT device operates in the Software as a Service (SaaS) paradigm
171+because most people don't have personal servers that could do all the processing
172+work actually necessary for an IoT device to operate. This is not the _only_
173+reason for this—it's also just more profitable to collect consumer data.
174+However, it's the SaaS aspects which make the whole thing such a catastrophic
175+mess.
176+
177+Imagine a different world: if the server that your device reports to is your
178+own, there is no loss of control over personal data. If the device only
179+communicates on the local network, it will prevent remote hackers and disruption
180+if you internet fails. And if the manufacturer goes out of business, the device
181+will still work-it is not dependent on the manufacturer's servers.
182+
183+The wants and needs of the individual are at odds with the wants and needs of
184+the megacorp, and that mismatch manifests as the antifeatures that plague IoT.
185+By eliminating the SaaS aspect, Urbit solves many of the largest outstanding
186+issues with IoT in a single blow. Digital personal AI assistants have long been
187+an anticipated science fiction prediction and their full realization is on the
188+horizon. But in their current manifestation, many privacy- and
189+security-conscious people would never consider using them at all, since they are
190+inevitably presented as SaaS that requires intimate knowledge of your devices
191+and their stored data. Recommendation engines such as the one used by YouTube
192+offer helpful guidance towards content you'll find appealing, but they're also
193+designed to keep you hooked to the service. These kinds of programs can be
194+useful, but they're dystopian when they come saddled with anti-consumer
195+subroutines. Since your Urbit belongs to you, it can never act against your own
196+interests without your consent. In our lunar vision, your digital personal AI
197+assistant will live on one of your moons, rather than on megacorp's cloud.
198+
199+For web-exposed devices, Urbit offers the same security guarantees that it
200+offers for your personal computer: everything is end-to-end encrypted by
201+default, and signed with keys that one can easily verify as belonging to the
202+node sending the message.
203+
204+[Vint Cerf](https://en.wikipedia.org/wiki/Vint_Cerf) has outlined the case for a
205+system like Urbit ID for IoT use
206+[here](https://cacm.acm.org/magazines/2018/12/232883-self-authenticating-identifiers/fulltext).
207+In brief, that the Urbit ID system allows one to match public keys with devices,
208+bestowing devices with self-authenticating identities. This allows one to trust
209+the communications received from the device to whatever degree the private key
210+is held secure. IP addresses, GPS coordinates, MAC addresses, etc., are not
211+sufficient to generate high levels of trust—they're all temporary, easily
212+spoofed, or both.
213+
214+> One might imagine applying this to the Internet of Things (IOT) in which the
215+> IOT device self-generates a public- and private-key pair and registers the
216+> public key. For example, with a hub or controller so the hub can confirm it
217+> has reached the right IOT device. By the same token, configuration of the IOT
218+> device into an ensemble could include incorporation of the public key of the
219+> controller into a list of valid devices that can command or obtain data from
220+> the now-configured IOT device. Both ends can verify they are talking to the
221+> originally configured devices, assuming no device has lost its private key.
222+
223+Here, the hub or controller referred to would be your planet.
224+
225+Urbit has many other features that make it well-suited for IoT, above and beyond
226+eliminating the SaaS model and providing self-authenticating identities. Many of
227+these additional advantages derive from the fact that Urbit is a [solid state
228+interpreter](/docs/arvo/overview#solid-state-interpreter) and that
229+[Ames](/docs/glossary/ames) is a network of solid-state interpreters
230+equipped with cryptographic identity. We explore this in the next section.
231+
232+### Future lunar cosmotechnics
233+
234+
235+
236+We now polish off the old crystal ball and imagine future uses of Martian lunar
237+technology. Particularly, how the tech may develop over time once it becomes
238+widely exposed to the evolution-inducing forces of industry and culture. This
239+section is pure speculation, and I only aim to offer a small glimpse of a
240+potential future, rather than an exhaustive one. This picture will necessarily
241+be biased by my personal proclivities and expertise, or lack thereof.
242+
243+Any discussion on the future of moons is incomplete without mentioning the
244+possibility of [lunar emancipation](https://urbit.org/faq/#more-planets) in
245+order to increase the number of planets. This fascinating topic sees regular
246+discussion in the Urbit Community group, but is outside the scope of this
247+article.
248+
249+In order to respect the reader's time, I'm narrowing our scope to a particular
250+topic: the agriculture industry. I'm also assuming a future with specialized and
251+increasingly small hardware to run Urbit. Right now, a 4 GB Raspberry Pi is the
252+standard for "small Urbit". If someday there are CPUs specifically designed for
253+running [Nock](/docs/glossary/nock), one could imagine going much smaller.
254+Ultimately, I'm going to assume that there will someday be [solid-state
255+interpreter](#ssi) microcontrollers - so the inclusion of Urbit on a device may
256+require nothing more than a couple [surface-mount
257+devices](https://en.wikipedia.org/wiki/Surface-mount_technology) on a larger
258+chip.
259+
260+Urbit is intended first and foremost as a personal computer. When I unravel its
261+potential usage in industry, I adopt the forecast of a drastic increase in the
262+manufacturing capacity for individuals and small groups. Agriculture is a great
263+microcosm of this long-standing trend; less human input is needed to produce the
264+same amount of food, whether it be crops or livestock. The modern era is
265+distinguished by the fact that small numbers of people can manage enormous farms
266+which produce food for vast populations. Thus, computation on modern automated
267+farms may be thought of as existing at the intersection of both personal and
268+industrial scale, and show how computerized and mechanized workflows add to the
269+amazing productivity of modern farms and demonstrate that individual-sized
270+inputs are able to create industrial-sized outputs. I predict that the set of
271+trades for which this dynamic holds will only increase over time.
272+
273+Agricultural automation has been a primary engine for the growth of
274+civilization, but it has been hampered by the downsides of IoT elaborated in the
275+previous section. One bellwether of this dynamic is the right to repair one's
276+own equipment. [John
277+Deere](https://www.thetruthaboutcars.com/2020/03/its-payback-time-right-to-repair-movement-targets-john-deere/)
278+has long been at the center of this controversy. Farmers have lost the ability
279+to repair their own equipment due to vendor locks and a dependency on remote
280+servers. Furthermore, any suite of sensor products designed to gather important
281+data such as genomics, hydrology, soil health, weather, etc., inevitably only
282+cooperate with other products by the same vendor. It's the same story all over
283+again—you are a client of a megacorp server. Or in Urbit terms, you have a bunch
284+of primitive moons belonging to different planets held by megacorps, and no
285+planet to call your own.
286+
287+Again, Urbit resolves these issues in the same fashion as above. One might argue
288+that using Urbit is another form of vendor lock-in—but this is evaluating Urbit
289+at the incorrect level. Since Urbit is an open source operating system, its
290+functionality may be extended and modified arbitrarily by any party. _Some_
291+computational infrastructure is necessary— that fact can never be escaped. But
292+you can escape from closed source software that does not permit you to modify,
293+to open source software that allows you to tinker at will. Thus we do not
294+consider open source software to be a form of lock-in, or at least, it's a much
295+milder form of lock-in compared to something like Apple's walled garden.
296+
297+So let us focus on the additional meritorious aspects of Urbit (or more
298+generally, solid state interpreter networks) that make it not merely a band-aid
299+to the broken IoT system but a permanent and sound replacement.
300+
301+#### Solid state interpreter networks {% #ssi %}
302+
303+
304+
305+Urbit is the world's first solid-state interpreter (SSI). This concept is
306+summarized in the [white paper](https://media.urbit.org/whitepaper.pdf) as
307+follows:
308+
309+> Imagine it as a chip. Plug this chip into power and network; packets go in and
310+> out, sometimes changing its state. The chip never loses data and has no
311+> concept of a reboot; every packet is an ACID transaction.
312+
313+Also,
314+
315+> Briefly, an SSI is an interpreter which is also a database. In more depth, an
316+> SSI combines three properties: uniform persistence, source independent packet
317+> networking, and high-level determinism.
318+
319+We do not wish to segue into a lengthy examination of what this really means—
320+that's what the white paper is for—but we will attempt to explain why these
321+properties are of great benefit in an industrial IoT context such as
322+agriculture. We'd also like to predict that Urbit will not be the only SSI.
323+Other sorts of SSI's specialized to various tasks may one day roam the planet,
324+and these may be better suited for particular IoT tasks than
325+[Arvo](/docs/glossary/arvo). However, this article will be couched in terms
326+of SSIs communicating with an [Ames](/docs/glossary/ames)-like networking
327+protocol and Urbit ID-style cryptographic identity, rather than Urbit in
328+particular.
329+
330+For a SSI, losing power is less of a catastrophic event than it is for ordinary
331+computers with volatile memory. Knowing that you can never lose any state is a
332+powerful guarantee on the integrity of your data. Loss of power will always mean
333+loss of any data potentially collected while power is down, regardless of the
334+device you use, but with a SSI you at least have assurance that you will never
335+lose data that was collected before it could be transferred from the cache to
336+the disk. Of course, this is actually the sort of guarantee that [ACID
337+transactions](https://urbit.org/docs/arvo/overview/#acid-database) have—it is
338+just that this set of guarantees emerges naturally as a consequence when you
339+have a SSI. Put another way, every SSI is a database; having every device be a
340+database is a major boon in situations where enormous quantities of data are
341+being collected across a distributed network. The standard today is that data is
342+only collected at hubs, and any data that doesn't reach a hub is irretrievably
343+lost.
344+
345+SSIs are also deterministic at a high level. While all computers are
346+deterministic at the CPU level, interruptions to power can result in an
347+undefined semantic state and result in the random erasure of half of its brain.
348+This determinism is what begets ease of maintainability of Urbit—problems
349+generally only need to be solved once by experts and the solution propagates to
350+the rest of the network via [OTA updates](/docs/glossary/ota-updates). We
351+addressed this maintenance issue previously—we only remark now that this
352+property is derived from being a SSI, rather than something particular only to
353+Arvo or Urbit. When one has hundreds or thousands of devices to manage, the
354+guarantees on ease of maintenance provided by determinism are extraordinarily
355+convenient.
356+
357+Packet routing on SSI networks is source-independent, and in the context of an
358+Ames-like networking protocol, are always delivered exactly once and in a
359+precise order due to the fact that nodes on an Ames network are in a permanent
360+session. Source-independent means that the identity that originated a packet
361+does not need to be the one to deliver it—packets are _facts_, and the truth of
362+a fact does not depend on who you heard it from. This means that it is possible,
363+for instance, to send instructions to a moon before it even exists and be
364+guaranteed that that moon will receive them and perform the tasks given, even if
365+the device that originally sent the packets no longer exists. As long as
366+somebody has kept the packets on hand, they will eventually be delivered. So,
367+one could imagine transmitting directions to a crop harvesting robot into which
368+a moon will be installed before the robot has even been purchased, know that
369+once it is delivered it will automatically begin its task, and know that those
370+tasks will be completed in the correct order, without any accidental repeats.
371+Taken to the limit, one can imagine preplanning the automated tasks for an
372+entire farm before a single device is purchased, with powerful guarantees on the
373+integrity of those instructions no matter how much time elapses between sending
374+and receiving.
375+
376+#### P2P data markets
377+
378+
379+
380+As was mentioned above, today's IoT devices ferry all sorts of your personal
381+data to megacorp, where they package it and sell it to the highest bidder.
382+Though personal data in aggregate is quite valuable, the value of a single
383+individual's data is quite low. On the other hand, industrial scale data such as
384+that collected on digitized farms could be quite valuable. Here we briefly
385+examine how Urbit can be utilized to populate and facilitate a market for data.
386+
387+All data collected by your moons may be digitally signed by that moon,
388+certifying the exact origin of that data. This is one advantage of having
389+cryptographic identity baked into the core of the operating system and
390+networking protocol. One could imagine collecting large amounts of such data and
391+packaging it for exchange with other local and regional farmers. This can, of
392+course, already be done in principle with current systems. But current systems
393+do not automatically come equipped with the sort of provenance, immutability,
394+and reputation that comes for free when you make use of SSI networks.
395+Manipulated or faked data becomes easier to spot, and you'll know who it came
396+from, so supplying such data puts one's reputation at stake.
397+
398+One major issue facing conjoining data gathered from disparate sources is simply
399+how to do it. Data arriving in random order, from different software versions,
400+running different hardware, is all very difficult to bundle into a good
401+dataset - and indeed wrangling this sort of task forms a large part of the data
402+scientist profession. As devices in SSI networks utilizing an Ames-like protocol
403+are engaged in permanent sessions, leading to properties such as exactly-once
404+delivery and well-ordered message sequences, issues about the order in which
405+data arrives are dramatically simplified. I do not wish to get mathematical
406+here, but I personally have confidence that the emerging discipline of
407+[categorical informatics](http://math.mit.edu/~dspivak/informatics/), as well as
408+the relevance of [low-dimensional topology to data
409+fusion](https://arxiv.org/abs/1409.5505), resolves many of these issues. I
410+promise to explain this in more detail in the future. For now, it suffices to
411+say that SSI networks seem well-positioned to utilize these techniques.
412+
413+Cryptographic techniques such as [(composable) zero-knowledge
414+proofs](https://en.wikipedia.org/wiki/Zero-knowledge_proof), [secure multi-party
415+computation](https://en.wikipedia.org/wiki/Secure_multi-party_computation),
416+[ring signatures](https://en.wikipedia.org/wiki/Ring_signature), and even
417+[homomorphic encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption)
418+offer a variety of ways in which data may be shared in an IoT context with
419+mathematical guarantees on what sort of privacy is maintained. This is perhaps
420+less relevant in the context of agricultural IoT, where personal private data is
421+largely absent, but we mention them here to invite further speculation from the
422+reader about the possibilities of IoT and SSI networks.
423+
424+We end our discussion with an adaptation of a scenario borrowed from my brief
425+time working on [Ceptr](http://ceptr.org/) that begins to show how a lunar
426+IoT-connected world evokes properties of a hypothetical ["global nervous
427+system"](https://en.wikipedia.org/wiki/Global_brain). This example is
428+purposefully mundane to illustrate how deficient our Earth systems are, and
429+while it is possible to accomplish in theory, it is impractical on a wide scale
430+due to the numerous problems with IoT. Imagine that you suffer headaches from
431+low atmospheric pressure. You'd like to know when a low-pressure front is an
432+hour away from you so that you can pre-emptively take aspirin to prevent the
433+headache. Your personal digital assistant, running on Urbit, can then
434+periodically query the moons of sensors in your region for weather data to
435+predict whether or not you will soon be passing through a low pressure front.
436+This could be a free service or paid for automatically with cryptocurrency
437+microtransactions. On Mars, this task will be trivial, and is merely a stone's
438+throw away from a vast and undiscovered universe of other possibilities unlocked
439+by SSI networks.
440+
441+[^0]:
442+ Of course, all moon names have four words, not three. What the fourth word
443+ needs to be for only three words to display is a matter of Urbit lore that
444+ is more fun to discover yourself than have it told to you, so we won't spoil
445+ it here.
content/blog/landscape-a-portrait.mdnew file+89
@@ -0,0 +1,89 @@
1++++
2+title = "Landscape: A Portrait"
3+date = "2019-09-02"
4+description = "On the latest Urbit user interface, and the interfaces to come."
5+aliases = [
6+ "/posts/essays/landscape-a-portrait/",
7+ "/posts/landscape-a-portrait"
8+]
9+
10+[extra]
11+author = "Matilde Park"
12+ship = "~haddef-sigwen"
13++++
14+
15+
16+
17+Alongside [the v0.8.0 launch](https://urbit.org/posts/2019-7-25-update/) we released the latest version of Landscape – Urbit's prototype user interface. Codenamed “Modulo,” it's our vision of an Urbit UI designed for everyday use. Most importantly, it’s the beginning of an interface that has access to the entire Arvo OS, rather than just one facet. Previous iterations of Landscape solely made use of the [Hall](https://urbit.org/docs/learn/arvo/hall/) messaging protocol.
18+
19+Served after installation on your ship’s HTTPS port, it allows you to interact with Arvo through a web interface built with [Indigo](https://github.com/urbit/indigo), our new UI design language. It has a home screen, which exposes ‘tiles’ for each Landscape application – each able to integrate and customise information from elsewhere in the system and from the broader internet – and connects them to full-screen, graphical applications.
20+
21+The first set of application includes Chat, a new, streamlined chat client, a basic Weather information tile, an analog clock, and Publish, a place for publishing, subscribing, and commenting on ‘notebooks’ – invite-oriented blogs hosted on your ship.
22+
23+
24+
25+
26+
27+Our unofficial mantra – “it’s not finished yet” – is performed yet again, but we're _close_. We can now talk with the broader community about both our inspirations, our visions for its future and our plan to enact that future.
28+
29+## Entering userspace
30+
31+Urbit has been in “research mode” for most of its history, but the system has now made extensive progress and our kernelspace engineers are the opinionated, confident veterans of the long war you’d expect from an operating system’s early history. The spoils of that war, after rewriting and refactoring all of the system's components several times over, are beginning to really speak for themselves.
32+
33+Urbit’s kernel is graduating from its rebellious period, however its _userspace_ has remained embryonic for most of its history. The project of building an application model has been restarted and rescoped into _aspects_ that could weather the chaotic growth of the kernel, but it would never quite serve as an interface to the entire operating system. Due to one of our latest vane refactors, it’s becoming possible to start that work in earnest.
34+
35+Alongside the latest release of Landscape came the rewrite of the [`%eyre`](https://urbit.org/docs/learn/arvo/eyre/) vane, which serves a ship’s files and applications over HTTP. Among the improvements came the decision to move from serving from one ‘/web’ folder by default to an application-specific endpoint.
36+
37+That is, a Hoon application, upon being started, now tells Eyre it wants to serve _these files_ at _this endpoint_ over HTTP and Eyre facilitates that.
38+
39+Landscape, with this in mind, serves at the root endpoint (you know, at `/`). It pre-authenticates the user and provides an API to your ship for applications (and their tiles) to access and _poke_, _peer_ and _scry_ the ship with.
40+
41+
42+
43+Whereas, before, a ship had a web server that was good at serving text, but was more obscure for complex (or graphical) applications that made use of the Arvo OS and network, now a ship launches with a web-based interface that makes applications much simpler to experiment with and develop.
44+
45+If you want, you can just serve files at any endpoint with [a boilerplate](https://github.com/matildepark/urbit-static-page).
46+
47+What's more? Arvo access and Hoon logic are now, by default, inside their own application on the ship itself rather than served as inline code on the front-end. This allows for better separation of concerns and more complex and performant applications.
48+
49+(If you want to play around, there’s an [experimental tool](https://github.com/urbit/create-landscape-app) you can use to get a full-stack boilerplate running in about 40 seconds.)
50+
51+All of this is fantastic news; and while Landscape-oriented userspace development is now _possible_, it’s still not all the way to being an interface to _an operating system_. For that, we’ve started drawing up specifications and proposals.
52+
53+## Rethinking interfaces
54+
55+Among the inspirations for our team are [the tales of Andy Hertzfeld](https://www.folklore.org/StoryView.py?project=Macintosh&story=Were_Not_Hackers!.txt), working on the Macintosh, and ongoing [discussions](http://doc.cat-v.org/plan_9/4th_edition/papers/812/) and [decisions](https://research.swtch.com/help.pdf) that went into Plan 9 from Bell Labs. (Sometimes, for fun, we also watch videos about [the Xerox Alto](https://www.youtube.com/watch?v=tngrLvyiNEI).)
56+
57+These inspirations share that their creators were dealing with really primordial stuff – the font of human-computer interface had really just sprung and they were _seeing things no one had seen before_ because they _had to_.
58+
59+Doing that now, after a lifetime of reflexive familiarity with the dominant solutions – from Apple’s macOS to Google’s Material Design – we have to do the work of _unseeing_. By engaging with what it was like to see for the first time, we get closer to seeing with fresh eyes. We work to avoid implicitly categorising the new territory as simply, well, comparative to the old one.
60+
61+So, while it’s not the same to simply _read_ these dialogues, it can get us pretty close.
62+
63+One reason this iteration of Landscape isn’t the last is because – we must emphasise – this is not the only interface Urbit will have. We aren’t creating a web platform. It should be possible to use _just_ the command-line, and ideally it should be possible to serve windowed interfaces from Arvo itself. It should be possible to SSH into _and_ SMS with your ship, should you want to.
64+
65+After all, we’re creating a decentralised platform of personal servers with an entirely new stack from the bytecode up. Most of the world’s computers descend from Unix, and Unix was based on [timesharing](https://en.wikipedia.org/wiki/Time-sharing) — multiple users in one computer, all pretending it was theirs. Everything since hasn’t left that mindset.
66+
67+So what do we think that new platform needs from its interface?
68+
69+- **Landscape, and all of Urbit’s future interfaces, need a standardised way to view and edit the filesystem.** We had circumnavigated this by mounting to Unix, but it’s now time to confront that issue.
70+
71+- **Landscape, and all of Urbit’s future interfaces, need a way to easily organise around _cohorts_ of ships, or _groups_,** with shared applications or files and a socially-oriented computing experience in turn — [something always in the vision](https://urbit.org/posts/azimuth-is-on-chain/#aegean), but not quite implemented yet.
72+
73+- Lastly, **Landscape, and all of Urbit’s future interfaces, need a userspace-specific, software design pattern** to integrate all of this: access to the file system, permissioning shared sets of files, and tying it together, an underlying representation of both data and interface amongst many computers.
74+
75+No more siloed input/output in applications on a ‘timeshared computer’ with your redundant data always belonging to someone else.
76+
77+## Into the future
78+
79+Right now, Landscape applications are still _monolithic_ and geared exclusively toward _single-person computing_. We hope to change that, and keep communication open with developers so it’s easy for their own development to keep pace with ours.
80+
81+It should be easy to share whatever data with your friends as you like; to permission files programmatically on a server that is permanently, irrevocably _yours_.
82+
83+It should also be easy to read, annotate and discuss a shared book with a specific set of friends; or only allow another set of people to see files in a specific directory if they meet specified requirements.
84+
85+We will backport these exploratory developments into Landscape as they continue and evolve. This, of course, includes kernel work, as we refactor [Gall](https://urbit.org/docs/learn/arvo/gall/), the userspace handler vane, and in the process, standardise streamlined practices for writing Hoon in user applications. Take, for example, the [async monad](https://groups.google.com/a/urbit.org/forum/#!topic/dev/DDG6gHSG1Lc), which allows you to avoid dealing with moves or handling each response in separate parts of the application. User applications and Hoon should be both laconic and accessible, and we’re reifying that.
86+
87+Most importantly, we’ll continue to iterate on how we onboard new developers. [Hoon School](https://urbit.org/hoonschool) continues to evolve; its first cohort is thriving and friendly. We have a dedicated cast of teachers and ongoing access to much of the Urbit team through this stream.
88+
89+If you’d like to join us here, you’ll discover a computer that you can learn and master from the bottom up. Right now, it is a labyrinth for the intrepid; but for the future, and forever, it is _mappable_. A landscape, after all, doesn’t show a single leaf, but the earth and the horizon ahead.
content/blog/layer-2-faq.mdnew file+155
@@ -0,0 +1,155 @@
1++++
2+title = "Layer 2 FAQ"
3+date = "2022-03-01"
4+description = "Answers to all your lingering L2 questions."
5+[extra]
6+image = "https://media.urbit.org/site/posts/essays/l2-faq-artwork.jpg"
7++++
8+
9+The launch of our [Layer 2](https://urbit.org/blog/layer-2-guides) was met with
10+a lot of excitement and a few questions. Don’t fret, we have answers. Below is a
11+selection of the most frequently asked questions and our responses.
12+
13+If you're still stumped, head to `~bitbet-bolbel/urbit-community` or give us a
14+shout online.
15+
16+### Questions:
17+
18+#### Planet Booting, Buying, Custody
19+
20+1. [Do I need ETH to boot my planet?](#1-do-i-need-eth-to-boot-my-planet)
21+2. [Do I have full custody of my L2 planet?](#2-is-there-anything-i-need-to-do-to-ensure-full-custody-of-my-planet)
22+3. [Where can I buy a planet?](#3-are-there-any-platforms-where-i-can-buy-a-planet-for-btc-or-usd)
23+4. [How do I get a hosted planet?](#4-how-do-i-get-a-cloud-hosted-planet)
24+
25+#### Layer 2 Architecture & Migration
26+
27+5. [Why did you decide to build your own Layer 2 rollup?](#5-there-are-plenty-of-organizations-dedicated-to-customizable-rollup-solutions-why-did-you-decide-to-build-your-own)
28+6. [Should I migrate my L1 planet to L2?](#6-if-i-currently-have-an-l1-planet-are-there-any-advantages-to-migrating)
29+7. [Where did the old Bridge go? Can I still use it?](#7-is-it-possible-to-use-the-old-bridge-for-l1-operations)
30+8. [Why is the cost reduction so significant?](#8-why-is-the-cost-reduction-so-significant)
31+9. [What exactly is the mechanism for the “naive” consensus?](#9-what-exactly-is-the-mechanism-for-the-naive-consensus)
32+10. [When I spawn L2 planets via Metamask, I'm prompted to sign every transaction. Do you have plans to remedy this?](#10-when-i-spawn-l2-planets-via-metamask-im-prompted-to-sign-every-transaction-do-you-have-plans-to-remedy-this)
33+
34+#### 1. Do I need ETH to boot my planet?
35+
36+If you were invited to claim a L2 planet, you **do not** need ETH to claim
37+that Urbit ID. Anyone can get on Urbit without ETH or a crypto wallet via L2.
38+Inviting your mom to Urbit just got a lot easier.
39+
40+If you have a L1 planet, you **do** need ETH to claim that Urbit ID.
41+
42+Once you have claimed your Urbit ID and have recorded your master ticket,
43+you **do not** need ETH to boot Urbit. That Urbit ID is now yours, forever.
44+
45+Unsure whether you have been invited to claim a L2 or L1 planet? The quickest
46+way to identify a L2 planet is if you used the below flow to claim.
47+
48+
49+
50+For those with L1 planets, you can avoid future transaction fees by migrating
51+your L1 planet to L2. Read the migration instructions
52+[here](https://urbit.org/getting-started/layer-2-for-planets).
53+
54+#### 2. Is there anything I need to do to ensure full custody of my planet?
55+
56+If you were sent a direct link to claim an L2 planet (see above), it’s
57+in your full custody by design. Bridge generates your master ticket, which you
58+downloaded during the claiming process.
59+
60+#### 3. Are there any platforms where I can buy a planet for BTC or USD?
61+
62+There are a few ways to procure a planet, including some platforms that offer
63+BTC and USD payment options.
64+
65+To purchase a L2 planet, we direct you to:
66+
67+- [Networked Subject](https://subject.network/buy/) for payment in BTC.
68+ Brought to you by `~sitful-hatred`.
69+- [planets.lanlyd.net](https://planets.lanlyd.net) and
70+ [tomdys.gumroad.com](https://tomdys.gumroad.com) for payment in USD.
71+
72+To purchase a L1 planet with ETH, there are a number of platforms dedicated
73+exclusively to Urbit ID. These include:
74+
75+- [urbit.live](https://urbit.live/buy)
76+- [urbitex.io](https://urbitex.io)
77+- [urbit.me](https://urbit.me)
78+
79+You can also acquire L1 Urbit IDs with ETH on [OpenSea](https://opensea.io/collection/urbit-id).
80+
81+Once you purchase a planet, the easiest way to manage your cryptographic asset
82+is through [Bridge](https://bridge.urbit.org/), which is our Urbit ID management
83+interface, wallet navigator, and governance portal.
84+
85+You can use Bridge to perform any desired
86+[Azimuth](https://urbit.org/docs/glossary/azimuth) interactions or download your
87+planet’s keyfile. As an alternative, [Metamask](https://metamask.io) is an
88+easy-to-use Ethereum wallet with a browser extension that integrates easily with
89+Bridge.
90+
91+#### 4. How do I get a cloud-hosted planet?
92+
93+There are a number of ways to host a planet in the cloud. Your options:
94+
95+- DIY:
96+ The most cost-effective method is [setting it up
97+ yourself](https://urbit.org/using/running/hosting), though this route requires
98+ some system administration, and troubleshooting if any issues arise.
99+
100+- Via a Hosting Provider:
101+ The more “headache-free” option is paying for a
102+ hosting provider to take care of all these processes for you, plus support. The
103+ following service providers offer hosting (some include a free planet):
104+ [Tlon](https://urbit.typeform.com/to/zQ9QOV3Z?typeform-source=tlon.io#source=tlon_io),
105+ [UrbitHost](https://urbithost.com/landing), [Get Urbit
106+ ID](https://www.geturbitid.com), [Escape Pod
107+ Store](https://www.escapepod.store), [Nodestead](https://www.nodestead.dev), and
108+ [ThirdEarth](https://third.earth/en/).
109+
110+#### 5. There are plenty of organizations dedicated to customizable rollup solutions. Why did you decide to build your own?
111+
112+Simply put, we designed and engineered our own rollup because we can’t depend
113+on the success or longevity of another organization. As they currently exist,
114+outsourced rollups are too immature and compromised in ways that undermine the
115+integrity of our technical principles. We also can’t restrict the aggregators to
116+a waitlist, another issue which might eventually be resolved, but one that we
117+can’t count on to be resolved soon.
118+
119+#### 6. If I currently have an L1 planet, are there any advantages to migrating?
120+
121+One of the most significant advantages to migrating is the reduced cost of
122+Azimuth-event related transactions. On L2, you can change sponsors or reset your
123+network keys for free with our roller. An important note: migration is currently
124+one-way. If you want to hold onto your L1 planet as a novelty, migration isn't
125+recommended.
126+
127+#### 7. Is it possible to use the old Bridge for L1 operations?
128+
129+The old version of Bridge will remain live, but unmaintained and eventually
130+decommissioned. You can access it at
131+[bridge-sunset.urbit.org](https://bridge-sunset.urbit.org). If you run into
132+something you can only do with the older version of Bridge,
133+[let us know on Github](https://github.com/urbit/bridge/issues/new?assignees=&labels=bridge&template=bridge-bug-report.md&title=).
134+
135+#### 8. Why is the cost reduction so significant?
136+
137+On L1, every operation is an Ethereum transaction, with logic and state, etc.
138+On L2, these operations are reduced and simplified into a
139+no-logic-involved Ethereum transaction. This is what makes L2 transactions
140+cost-efficient: multiple transactions happen simultaneously to share the cost of
141+just one L1 transaction.
142+
143+#### 9. What exactly is the mechanism for the “naive” consensus?
144+
145+Our engineering team has written extensively about the technical features of
146+our L2 rollup. To learn about its intricacies, we encourage you to read
147+`~datnut-pollen`’s comprehensive
148+[overview](https://urbit.org/blog/rollups#technical) and `~wicdev-wisryt`’s
149+original
150+[proposal](https://groups.google.com/a/urbit.org/g/dev/c/p6rP_WsxLS0/m/hQBX0modAwAJ?pli=1)
151+on the Urbit developer mailing list.
152+
153+#### 10. When I spawn L2 planets via Metamask, I'm prompted to sign every transaction. Do you have plans to remedy this?
154+
155+We realize this UX headache and are taking active steps to devise a more efficient transaction scheme. The new method will reduce the number of manual signatures needed for each spawned L2 planet. At the time of this FAQ's publication, we haven't publicized the release timing for the improvement. A provisional solution: set the star's spawn proxy to a custodied L2 planet secured via Master ticket and log in to Bridge as that planet to spawn invites.
content/blog/magic.mdnew file+205
@@ -0,0 +1,205 @@
1++++
2+title = "Magic"
3+date = "2016-05-15"
4+description = "A thought-experiment to explain the Urbit user experience."
5+aliases = [ "/posts/essays/magic", "/posts/magic" ]
6+
7+[extra]
8+author = "Curtis Yarvin"
9+ship = "~sorreg-namtyv"
10+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/magic.jpg"
11++++
12+
13+
14+
15+It's easy to get too obsessed with Urbit's alien technology. We
16+didn't build Urbit for its tech. We built it for people to use.
17+
18+It's also hard to understand the power of Urbit, because it's
19+still quite immature. Unless you understand it already, it's
20+just a weird OS that doesn't work all that well.
21+
22+And this OS is supposedly designed as a new kind of product: a
23+personal server. What is a personal server? If you had one,
24+you'd know. Since you don't, you don't. So both your problem
25+and our solution are totally unclear.
26+
27+One way to understand Urbit is to forget the technology totally.
28+Instead, let's build the same product out of magic. Technology
29+is hard and imperfect and slow. Magic is easy and perfect and
30+fast. Why not use it? At least for a demo?
31+
32+## Magic step one: total integration.
33+
34+Make a list of all the cloud apps which have your personal data.
35+OK, just imagine making a list. OK, use magic.
36+
37+By magic, we make some giant company buy all these apps. It
38+could be any of them, but let's say it's Facebook. Facebook buys
39+_all the apps_. As of now, _all your cloud computing happens in
40+your Facebook profile_.
41+
42+Your Facebook is now your Dropbox and your Evernote and your
43+Wordpress and your Gmail. And it's not just Web apps; all your
44+servers move to Facebook. Your Nest talks to a Facebook server.
45+Your iPhone talks to Facebook instead of iCloud. Your Fitbit
46+records your heart rate in a Facebook log. Your Facebook
47+manages your finances and pays your bills. Got bitcoin?
48+Facebook is your wallet. Shop online? Check out the Facebook
49+Store -- it sells everything!
50+
51+In short, you can just lock your browser to `facebook.com`. The
52+Web is dead. Or more precisely, it's an obsolete protocol which
53+you use to log in to Facebook.
54+
55+Does this sound creepy? Sure. It's incredibly creepy. But look
56+on the bright side: it's also incredibly convenient. (And
57+incredibly secure, at least with a 2-factor key.)
58+
59+For the first time ever, _all your data is in one place_. For
60+example, the engineers at Facebook, who are awesome, would never
61+leave Dropbox, Instagram and iCloud as three separate things.
62+You don't need an "integration" between them. Your profile is
63+one thing: you. Your entire digital life.
64+
65+(In fact, if you're a geek and have Unix boxes, your Facebook is
66+magically integrated with Unix. You can just open your laptop
67+and type `ls /photos/2016/May/` -- as if your digital life was a
68+chip in a box in your backpack, not redundant servers in multiple
69+secure data centers.)
70+
71+Imagine we all lived in hotels, all the time, even in just one
72+city. Imagine you don't even have one room with a long-term
73+lease. You sleep in one pod Mondays, another on Tuesdays...
74+then, someone offers you a home. Your own house. With your own
75+furniture, your own books in your own bookcases...
76+
77+## Magic step two: free your data.
78+
79+The good news is, you get your own house. The bad news is, it's
80+in North Korea.
81+
82+Having your whole life owned by Facebook is still creepy. Or so
83+most people would think. It's not actually clear that it's more
84+creepy to be owned by one corporation, than nine corporations.
85+But it _feels_ creepier.
86+
87+By magic, Facebook cares. So it decides to free you. Actually,
88+Facebook's business is owning you. So freedom will destroy its
89+business. But magically, Facebook doesn't mind.
90+
91+Right now, the software behind your Facebook experience is a
92+million lines of Facebook goo. It solves your problems and shows
93+your ads and does whatever the heck it wants with your data.
94+(Not that it's "your" data. It's Facebook's data, about you.)
95+
96+Without changing the functionality of your Facebook experience,
97+Facebook replaces every component of this goo with an "agent."
98+(You have about as many agents as you used to have apps.) If you
99+don't care about being free, you won't notice the change. If you
100+do care, everything changes.
101+
102+One, you don't have to run Facebook's agents. You can replace
103+them with anyone else's software, free or paid. Agents upgrade
104+themselves automatically, but you are never locked in; you can
105+always switch agents and/or vendors without damaging your data.
106+
107+Don't like your email UI? Change it. Don't like to see ads?
108+You no longer see any ads -- why would someone use an agent that
109+showed them ads? Ick. Unless it's something ridiculously
110+specialized, an agent is either free software or costs $3.99.
111+
112+Two, agents _act as you_. Facebook is no longer the Panopticon.
113+It is not a giant mainframe where all the code can access all the
114+data. An agent can use as much of your own data as you give it;
115+it cannot use anyone else's data. At least not without asking.
116+
117+When anyone can write an agent, only code can be law. Privacy is
118+no longer enforced by the informal decisions of Facebook product
119+managers. It must be enforced by formal security policies.
120+
121+This might constrict the services Facebook can offer, but only a
122+little. Since privacy is a human universal, apps that don't
123+respect it (for instance, image face tagging) feel weird. A
124+service like this can't be broken up into personal agents; it
125+still requires a Big Data mainframe somewhere. But it's okay;
126+the agents can still talk to it.
127+
128+For the most part, Big Data (everyone's) has become little data
129+(yours). You no longer have a Facebook profile -- a fancy UI
130+backed by a million lines of Facebook goo on one big mainframe.
131+Now what you have is a Facebook _server_: a real computer. Or at
132+least, a virtual computer (which is much more reliable than any
133+one physical computer).
134+
135+Is this computer hard to manage? You have the same basic job as
136+someone who owns an iPhone: deciding what software to run. If
137+you skip this job, your iPhone or your Facebook is still pretty
138+useful. You also need to decide what data to keep. An iPhone
139+has finite, free storage; the cloud has infinite, non-free
140+storage. You still want a warning when your server gets fat.
141+But at least it keeps working.
142+
143+## Magic step three: free your server.
144+
145+This agent-oriented Facebook can't show you ads. But this is not
146+actually a huge business problem. Since Facebook owns everyone's
147+life, it has the mother of all monopoly lockins. It can just
148+bill you $9.99 a month for running your Facebook server. This is
149+a great deal, for you and for Facebook.
150+
151+But you're still a slave, Neo. A Facebook server still isn't a
152+personal server. Monopolies suck.
153+
154+Magic works, so Facebook feels guilty. It goes all the way
155+toward freeing you, and ruins its own business.
156+
157+Now, your server is just a big file whose format is precisely
158+defined. You can move it to any hosting service, or even run it
159+on a home PC. Since hosting is now a commodity, it costs almost
160+nothing and has zero profit margin. It may even come bundled
161+with your Internet service.
162+
163+Every data center is owned by the local government. If you have
164+data to hide from the authorities, compute at home. Most people
165+don't have anything to hide and should run in the cloud, because
166+the cloud works better. But using the _same platform_ as those
167+who do have something to hide creates "herd immunity". You don't
168+have to choose between a secure platform with no network effect,
169+and a non-secure platform that everyone else uses.
170+
171+## Magic step four: free your name.
172+
173+Freeing your server also means freeing your identity. It's no
174+longer true that Facebook decides who you are. Facebook just
175+wrote the algorithm. Your server contains cryptographic secrets
176+that control your identity. If your identity was a bitcoin, your
177+server would be a giant bitcoin wallet.
178+
179+The bad news: lose the file, lose the identity. The good news:
180+your server is genuinely personal now. It's yours in every way.
181+It's so personal that if you destroy it, it's gone.
182+
183+Facebook doesn't even keep its power to create new servers. The
184+"real name" policy has done great things to control spam, because
185+spam always depends on disposable accounts. But it implies a
186+central authority.
187+
188+Instead, Facebook borrows an idea from bitcoin and just limits
189+the number of identities. If you need one, you have to buy one.
190+They don't cost that much; just enough to deter spammers.
191+
192+(Is your real name still linked to your identity? Maybe, maybe
193+not. There's a role for name validation, but not everyone needs
194+to have a real name, and not everyone else needs to know it. A
195+dissident, or anyone who wants to speak out and let the words
196+speak for themselves, might want a second anonymous identity.
197+But sock puppets remain evil -- two names for the same person
198+should not interact in the same place.)
199+
200+## Magic step five: call it Urbit.
201+
202+And, with magic, we've succeeded in turning Facebook into Urbit.
203+Technically, Urbit is pretty close to magic, but there is no way
204+it's going to happen this way. See the [roadmap](/blog/roadmap) for how it
205+actually happens.
content/blog/metaphase.mdnew file+79
@@ -0,0 +1,79 @@
1++++
2+title = "Metaphase"
3+date = "2020-12-08"
4+description = "On the upcoming and foregoing Landscape lifecycles, and other forms of mitosis across the Urbit project."
5+
6+[extra]
7+author = "Matilde Park"
8+ship = "~haddef-sigwen"
9+image = "https://media.urbit.org/site/posts/essays/metaphase.jpg"
10++++
11+
12+
13+
14+_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:_
15+
16+```
17+|ota ~hanruc-nalfus-nidsut-tomdun %kids
18+|merge %home ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
19+|merge %kids ~hanruc-nalfus-nidsut-tomdun %kids, =gem %take-that
20+```
21+
22+_We will surface this option more broadly in a future settings overhaul._
23+
24+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.
25+
26+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.
27+
28+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.
29+
30+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.
31+
32+## Landscapers and lifecycles
33+
34+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.
35+
36+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.
37+
38+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)).
39+
40+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.
41+
42+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.
43+
44+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”).
45+
46+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.
47+
48+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.
49+
50+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.
51+
52+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.
53+
54+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.
55+
56+So now, before we could launch a stable stream, we had some things to do first:
57+
58+- **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.
59+- **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.
60+- **We wanted to release the notification-store**. After the October 2020 groups release, Landscape simply wouldn’t be complete without it.
61+- 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.
62+
63+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**.
64+
65+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.
66+
67+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.
68+
69+## Mitosis
70+
71+Describing our progress so candidly can feel strange — after all, it sounds so _early_. But to me, it’s exciting. It’s mitosis.
72+
73+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.
74+
75+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.
76+
77+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.
78+
79+But this is, after all, how a body forms.
content/blog/on-christopher-alexander.mdnew file+70
@@ -0,0 +1,70 @@
1++++
2+title = "On Christopher Alexander"
3+date = "2021-07-19"
4+description = "An overview of his writing and relevance"
5+
6+[extra]
7+author = "Matt"
8+ship = "~tirwyd-sarmes"
9+image = "https://media.urbit.org/site/posts/essays/timelesswaybridge.png"
10++++
11+
12+
13+
14+_A well-designed house not only fits its context well but also illuminates the problem of just what the context is, and thereby clarifies the life which it accommodates — Notes on the Synthesis of Form_
15+
16+There is an unofficial design canon at Urbit. If you were a fly on the wall, you would hear the name "Christopher Alexander" regularly mentioned around the office. Christopher Alexander is an architect, albeit one who isn't taught at most architecture schools. However, his work encompasses far more than what is usually understood as "architecture". Alexander's work is concerned with the production of functional beauty. What's remarkable about his books is that they are not empty philosophical manifestos—Alexander gives specific, actionable guidance on creative problems. His best books are manuals for how to construct forms that are "alive". Alexander threads the needle between highly specific instruction and generalized abstract concepts—his success at this task can be seen in his influence on fields outside of architecture, from computer science to network theory. In his most recent work, Alexander touches upon subjects ranging from religion to math and connects it all into a theory about how the universe functions. But people read him for less lofty reasons: to build a house that is beautiful, design a comprehensive programming language, or figure out how to approach a complex problem. In this post, I'll give an overview of Alexander's work and hear from some Urbit staff about his relevance to software development.
17+
18+Alexander's first book, _Notes on the Synthesis of Form,_ detailed a new way to approach the design process. Released in 1962, it incorporated networks, set theory, language, and math into a new method for accurately modeling and solving design problems. Although Alexander was an architect, the book was concerned with fundamental issues: how do you solve complex problems with hundreds of interconnected variables? The answer lies in decomposing the problem into subsystems and then "diagramming" those subsystems back into a singular integrated form. The process of decomposing a set into [highly-interconnected subsets](https://en.wikipedia.org/wiki/Community_structure) involves a significant amount of computation—Alexander wrote a computer program for the IBM 7090 mainframe which was described in his 1962 paper _HIDECS 2: A Computer Program for the Hierarchical Decomposition of a Set with an Associated Graph._ But this was only half of his design process; after the creation of subsets which are the fundamental units of the design problem, the subsets must be diagrammed. This second half of the process involves integrating and synthesizing all of the variables within a single subset into a conceptual diagram. These fundamental diagrams are then integrated and combined _themselves_ into a single diagram which is the final result of the process. The diagram below is Alexander's solution to the problem of designing a village in India with a huge number of variables and constraints.
19+
20+
21+
22+_Notes on the Synthesis of Form_ can be seen as embodying many of the tensions in 1960s America. Computers were seen as a suspicious technology which embodied the institutionalized science that created the nuclear bomb and cold war era tensions. These suspicions were understandable: computers were massive esoteric machines housed in entire rooms of university and government buildings. They were physically and mentally inaccessible to the average American citizen, while the elites who did use them were held in contempt by the populace. Student protests against being just another cog in "the machine" or "IBM card" were partly right—at this point in the early 60s, many intellectuals were interested in [cybernetics](https://en.wikipedia.org/wiki/Cybernetics:_Or_Control_and_Communication_in_the_Animal_and_the_Machine) and the [mathematical modeling of "human" problems](https://en.wikipedia.org/wiki/Theory_of_Games_and_Economic_Behavior) and Alexander drew from these fields frequently in his book. However, when _Notes on the Synthesis of Form_ came out in 1964 computer culture was shifting towards an alliance with the counterculture—a cultural and technological process that would culminate with these massive pieces of institutional technology becoming "personal computers". He criticized those who wished to keep math and computers away from human creativity: he saw the possibility of computers yoked to creative human beings. He believed this symbiotic approach to technology was necessary—without a new approach to design, the world would continueto produce the ugliness endemic since the industrial revolution. According to Alexander, a designer could only successfully solve this problem by combining his creativity with the analytic and computational power of machines. Through his books and [presentations](https://www.youtube.com/watch?v=98LdFA-_zfA), Alexander would have a lasting impact on object-oriented programming and [pattern based thinking in software design](https://en.wikipedia.org/wiki/Design_Patterns).
23+
24+In _Notes on_ _the Synthesis of Form_ Alexander applauds the buildings and towns of many primitive societies but he notes that there is no hope of a return to this "unselfconscious" state. Therefore, modern people must develop a new design process to reach the same end. But what is this end that Alexander is trying to achieve? Alexander states his aim negatively in _Notes on the Synthesis of Form_ as "the absence of misfits between a form and its context". An [apophatic](https://en.wikipedia.org/wiki/Apophasis) statement might be good enough for mystics but, for someone like Alexander who was concerned with precision, a positive statement was necessary. His positive statement wouldn't come until 1979 with the publication of _A Timeless Way of Building_.
25+
26+In 1975, Alexander would begin publishing his most famous book series which included _The Timeless Way of Building_ and _A Pattern Language_. In these works Alexander took a more holistic approach to creative production and placed less emphasis on design models. This new approach cemented the importance of culture as the substrate that supports a people's inherited "pattern language". Just like a spoken language, a pattern language is developed incrementally over time by people who adapt to the same local environment. Alexander wrote that "a pattern language gives each person who uses it, the power to create an infinite variety of new and unique buildings, just as his ordinary language gives him the power to create an infinite variety of sentences". _A Pattern Language_ is an attempt to create a new language from observing the dialects of buildings around the world. Alexander recognized that there were large-scale patterns between people and the buildings they found beautiful—a productive tension between specificity and more general patterns common to all human beings. Alexander's pattern language is therefore more general than historically generated languages. The "pattern language" approach is now native to many software developers: seeing solutions as complexes of layered and interconnected systems.
27+
28+_A Pattern Language_ is the book that is closest to an instruction manual. It is meant to take the prospective builder all the way through the process of designing and constructing a building, neighborhood, or city. Alexander writes about the macro-patterns of cities and the micro-patterns of buildings, from road design to doorknobs. Alexander wanted to enumerate patterns that interlock and produce beauty at different scales while still being as precise and actionable as possible. In _Notes on the Synthesis of Form_, Alexander was concerned with how to best model reality in order to solve a problem, while _A Pattern Language_ focused on the production of a vernacular that would allow people to produce beautiful buildings.
29+
30+
31+
32+Underlying these different pattern languages is a deep, precise, and objective appreciation of an important quality of human existence—what Alexander calls "the quality without a name". This "quality" is the ultimate goal of Alexander's work. Greater efficiency and instrumentality cannot be ends in themselves. For Alexander, it is a moral imperative to save the world from ugliness and to make human culture match the natural world in beauty, complexity, and aliveness. It is described in _The Timeless Way of Building_ as "the root criterion of life and spirit in a man, a town, a building, or a wilderness. This quality is objective and precise, but it cannot be named". The "quality" cannot be named not because it is a vague or airy concept, but because "the quality is too particular, and words too broad". Nevertheless, Alexander makes an attempt to circumscribe the concept with the words alive, whole, comfortable, free, exact, egoless, eternal.
33+
34+Alexander would say that a Japanese temple and a German church are both approaching the "quality" from different histories and cultures. They are examples of two vernacular languages developing in parallel. The similarity between two modern cities is an example of how we've been severed from our pattern languages and therefore the "quality"; we are forced to design from barren earth. Global homogeneity is a symptom of disconnect from both temporal and spatial order—it is the death of our inherited languages.
35+
36+
37+
38+_The Nature of Order_ is Alexander's most recent book series and explores the metaphysical implications of Alexander's thought. According to Alexander, the failure of the modern built world is because we have learned to view the world as fundamentally dead. Alexander makes an argument that is close to [hylozoism](https://en.wikipedia.org/wiki/Hylozoism) or [IIT](https://en.wikipedia.org/wiki/Integrated_information_theory): all structures have varying amounts of aliveness (an aspect of the "quality"). Because of the modern worldview that sees all structure as dead we have become blind to this deeper aspect. The basic component which makes structures alive are strong and varied centers. Furthermore there are fifteen fundamental attributes of centers which allow them to network and become alive. These fifteen abstract units are what patterns are composed of—patterns that are then woven into languages (this process of formalizing implementations as higher-level abstractions should be familiar to any computer scientist). _The Nature of Order_ is the most philosophical and [spiritual](https://www.firstthings.com/article/2016/02/making-the-garden) of Alexander's work and ties together his overarching preoccupations: how to solve complex human problems and why the task of making the world beautiful is important.
39+
40+You might be wondering how Christopher Alexander is relevant to Urbit?
41+
42+That depends on who you ask.
43+
44+**Galen (~ravmel-ropdyl)**
45+
46+> I suppose the main thing is that most designers tend to become fixated on the mechanics of what they're building. Most design theory is about how things are made, not what it's like to live inside of them or actually rely on them on a daily basis. Alexander is much more concerned with the first-person experience of inhabiting a place or a building. I guess his approach is just much more empathetic which means it's also more practical. He's concerned with _how people actually live_ and how their environment evolves alongside them.
47+>
48+> We live, work, and develop on Urbit. We're often the first people to notice bugs because we are the end users ourselves. Alexander makes the point that old buildings were responsive to feedback because the architect was also the inhabitant. This tight feedback means that the system as a whole is dynamic and alive. We want Urbit to be a house that you live in and make yours, because unlike all the other software you use, your Urbit is actually _yours_.
49+
50+**Josh (~wolref-podlex)**
51+
52+> _The Nature of Order_ has had a big influence on my thinking. At first, the idea of all physical structures being alive sounded like something out of a new age bookstore. But not only do I think that Alexander justifies this claim; it started to make intuitive sense when I looked closely at my experience.
53+>
54+> When I first read _The Nature of Order_ I was living in an industrial neighborhood of San Francisco—the scale of the buildings and streets felt inhuman and everything was made of metal, glass, and concrete. I chose to leave. I moved into a 100+ year-old flat and the difference was immediate and visceral. The space felt like it was designed from experience rather than _ex nihilo_. The apartment was meant to be lived in, surrounded by public spaces where strangers could safely spend time outdoors together.
55+>
56+> If physical objects can have the quality of "aliveness" so too can information objects. Alexander's book is alive. Many of the software projects I've worked on have been cold fish. Keeping this quality in mind is an important part of my decision making. I want Urbit to be a living structure.
57+
58+**Édouard (~fabled-faster)**
59+
60+> I enjoy telling people unfamiliar with Urbit and interface design with respect to Urbit, that the object of our work is essentially that of designing an environment "like a piece of paper".
61+>
62+> Consider how paper as a constrained environment is one that yet can bear nearly any visual expression imaginable—apart from containing drawings or human-made marks, paper can be used to display photographs, paper can be multiplexed to form lenticular holograms, paper can be folded into a crane, etc.
63+>
64+> The "sheet of paper and its resulting forms" I manifest as a design ideal here is what Alexander might refer to as a "semilattice". A mathematical term he co-opted to describe an ideal structural relationship between elements in a system, as opposed to a "tree", which is a top-down structural system that forces elements into rigid categorical constraints. [In his own words](https://www.patternlanguage.com/archive/cityisnotatree.html):
65+>
66+> > _For the human mind, the tree is the easiest vehicle for complex thoughts. But the city is not, cannot and must not be a tree. The city is a receptacle for life. If the receptacle severs the overlap of the strands of life within it, because it is a tree, it will be like a bowl full of razor blades on edge, ready to cut up whatever is entrusted to it. In such a receptacle life will be cut to pieces. If we make cities which are trees, they will cut our life within to pieces._
67+>
68+> A city is a good ideal to maintain for the construction of a new internet and notion of personal computing, but I've tended towards my own interpretation of a piece of paper as a semilattice-embodying object due to its accessibility and ability to be imagined by anyone, designer or not. Our object of design is that of a receptacle of life, of deep expression, of multiplexed possibilities. When I imagine an Urbit in the not-so-distant future, I imagine it as a _method_ (to contrast against those who pin software's expression down to "tools" or "functions") by which I can become "whole" again in a digital context, in all my complexity.
69+
70+Christopher Alexander wanted to collapse the distinction between those who live in buildings and those who design them. Urbit wants to do the same thing with software—in order to not produce ugliness, we should live in what we build. Although we have personal computers now, all of our data is housed in enormous warehouses that make the industrial computers of the 1950s look tiny. What we think of as “our information” actually belongs to someone else and, more often than not, is weaponized against us. Alexander’s moral imperative can be taken and applied to our digital structures. We need to become close with our software again.
content/blog/pin-the-face-that-launches-a-thousand-ships.mdnew file+146
@@ -0,0 +1,146 @@
1++++
2+title = "Pin the Face that Launches a Thousand Ships"
3+date = "2023-04-07"
4+description = "A guest post by ~nospex-larsut"
5+[extra]
6+image = "https://storage.googleapis.com/media.urbit.org/blog/6a0120a85dcdae970b016766c94c14970b-800wi.jpg"
7+author = ""
8+ship = "~nospex-larsut"
9++++
10+_The original article can be found [here](https://nospex-larsut.arvo.network/blog/whyhoon) using [%blog](https://urbit.org/applications/~hanrut-sillet-dachus-tiprel/blog)._
11+
12+
13+
14+## Pin the Face that Launches a Thousand Ships[^1] ##
15+_A short piece addressing some of the standard hesitations to learning Hoon, considered in light of all of the recent exciting network activity._
16+
17+### Setting The Table ###
18+One can draw many distinctions between the Urbit apps that were available this time last year and those released thus far in 2023, but the most important of these may be that the former were apps noticed and used almost exclusively by users already on Urbit, where the latter - notably Pongo, Realm, Tirell Studio, Groups 2, Portal, etc - are apps that are _creating Urbit users_.
19+
20+Prior to the start of 2023, the superficial, yet incomplete, take was something to the effect that much of Urbit’s appeal was largely an affinity with the ideas and principles surrounding the project.
21+
22+People who found their way to Urbit latched on to philosophical entry points, among them values such as calm computing, decentralized/privacy/data-ownership maximalism, or aspirations of replacing a generations-deep legacy computing system that entrenched an ethos of doing things fundamentally inefficiently & incorrectly, in ways that not only hobbled the potential of the internet, but resulted in outright harm to its users through establishing platform models and incentives that consciously sought to manipulate the behavior of those users in countless subtle and not-so-subtle ways.
23+
24+Urbit was a nexus, collecting people from disparate backgrounds & disciplines to something like a spiritual oasis, yes, though one seemingly situated a million miles from anywhere familiar to the outside world; its appeal was more a function of the shared ethos of the community and a shared sense of its potential rather than the existence of new & immediately useful alternatives for day-to-day compute tasks.
25+
26+The energy of Assembly '22 was palpaple; it almost seemed that widespread adoption was around the corner. Inevitably, some of the post-Assembly ‘22 buzz seemed to fizzle as the ensuing months went by; many ships launched during that time went dormant, wondering if the potential hinted at would materialize; the shallow criticisn/meme for getting on to Urbit became, “I’m here… um, now what.”
27+
28+This whole time though, the project was simultaneously also an incredibly busy construction site.
29+
30+Remarkably short-lived, “I’m here… um, now what?’ is unraveling with the realization that this universe has always been accelerating, and this new wave of apps establishes a very visible & powerful reference point for truly appreciating that acceleration and the distance traveled; after what seemed like a brief post-Assembly fizzle, the network is again kinetic and crackling with energy, but in reality it was never slowing down.
31+
32+The latest generation of apps marks an important shift in the trajectory of Urbit adoption. Much of this is possible thanks to the proliferation of hosting options - whether [Native Planet’s](https://nativeplanet.io/) self-hosted solutions or through turnkey models - which collectively have vastly streamlined the Urbit onboarding process such that getting on the network is no longer the equivalent of scaling a forbidding & remote mountain peak, arriving at the threshold of a silent monastery, heaving its heavy door ajar to find it seemingly abandoned only a thin sliver of light to illuminate your path, nobody there to acknowledge your arrival much less offer a tour. The thrill of having finally gotten there dampened by the increasing sense that all of its life is subterranean and the real journey is just beginning.[^2]
33+
34+Single-click onboarding and preloaded apps & groups may not seem like a lot for newcomers, but these things have increased tremendously the ability to get on Urbit compared to just six months ago.
35+
36+And just as a selection of competing hosting providers expanded the number of possible onramps, this new crop of Urbit apps likewise provides a complimentary function as entry points - hidden doors to Urbit embedded in the Apple/Android app stores - in ways that Urbit apps never enjoyed previously, all helping to further reduce the friction of onboarding by orders of magnitude. A user searching for a Telegram alternative stumbles across Pongo; new eyes find Urbit without ever intentionally seeking it out.
37+
38+The animating ideas behind the project, I think, remain as alive as ever - Urbit does not need to jockey to become the ‘current thing’ if it can much more efficiently become the undercurrent thing; without having to waste a single breath converting users at the margin on the necessity or virtue of recreating the web in a decentralized & privacy-oriented manner, new users are able to become advocates for apps that provide practical utility for day-to-day compute, creative, and communication needs - but that also happen to be built on such infrastructure. The yew tree doesn’t propagate itself by trying to convince the bird that it is desirable that there be more yew trees in the world, it just wraps its seed in a tasty & nutritious berry and lets the bird carry it off.
39+
40+Compelling apps, built on continually-improving and innovative infrastructure & development tooling is one piece of the adoption curve. These things bring users, who bring perspectives, feedback, ideas, wants, and needs. It brings their attention to earn it. If they are spending time on Urbit apps, they will also be exposed to whatever else is being shared on Urbit through those apps – what will catch their attention that maybe they are not seeing elsewhere? Suffice to say this is all basically network effects 101, so on to the question of learning Hoon.
41+
42+### Some Grains of Salt ###
43+Perhaps that was a lot of table-setting to get to the original inspiration of this piece, in which I wish to present some arguments to the standard objections or concerns that seem to arise for people thinking of learning Hoon. My aim is not to twist any arms or legs, but only to offer some considerations for those on the fence. Hopefully the preceding bit of history at least reveals some shred of the potential opportunities for Hooners (and other creatives - we absolutely need those as well).
44+
45+But first the grain of salt with which you should take the following:
46+I currently Hoon at something approximating a tenth-grade level. I am by no means a natural born developer, nor am I moving towards a dynamic career switch to full-time Urbit dev. Not by any stretch of the imagination. While I am interested in continuing to learn Hoon for a variety of reasons, none are likely to reverberate very far beyond my own ship.
47+
48+My Hoon education began in the summer/fall ’22 cohort of Hoon School Live. In my early 40’s, I walked into it slightly intimidated by its reputation, and with a personal technical background not much deeper than writing Excel formulas, a little Python, and building simple websites (like, 20 years ago). At the moment, I am much better at reading it than writing it, but thanks to HSL & ASL (and everyone involved with those efforts), it does make sense to me.
49+
50+So despite not exactly practicing what all I am about to preach, the foregoing, combined with having talked to enough people on the fence about learning Hoon, I feel somewhat qualified to at least offer some perspective for those considering the question.
51+
52+### The Standard Hesitations ###
53+The following hesitancies seem to be the recurring ones, and we’ll take them one at a time, although they share a significant degree of overlap.
54+<ol>
55+<li> But I already know languages x, y, z, etc and can build things with them now.</li>
56+<li> I hear Hoon is very difficult / weird / etc.</li>
57+<li> Urbit’s future is uncertain; investing in learning Hoon seems risky.</li>
58+<li> I don’t see many immediate jobs for Hoon devs.</li>
59+</ol>
60+
61+__Hesitancy 1: But I _already know_ languages x, y, z, etc and can build things with them _now_.__
62+
63+A valid contention in that one has invested in skills they are eager to put to use or continue to use. But can you build what you want to build - and where you want to build it? And what is the cost in terms of personal satisfaction to working on something which doesn’t truly excite you?
64+
65+There is something of the sunk-cost fallacy is at work here. It is not always a bad impulse, and opportunity costs are very real. But if there is something compelling about Urbit - and the fact that one is at least seriously considering learning Hoon suggests this is the case - and one is willing to view their existing proficiency in some other language as a demonstration of their capability to learn any programming language, then existing knowledge should not act as a barrier to pursuing new knowledge, particularly if there is a suspicion that working on Urbit may afford more intellectually stimulating and enjoyable opportunities.
66+
67+Consider also that a person working on things that truly animate them, despite maybe being relatively less experienced in the language, nonetheless has much more room to grow in a smaller pool where they may create closer connections, have more access to the perspectives of experienced devs, and get noticed for their contributions faster than those that may exist for a person working on things they are decidedly less passionate about amidst a pool of thousands.
68+
69+Yet another upside of working in Urbit is the sheer amount of projects yet to be built (not all require Hoon, btw); projects that may be intriguing to a developer but which already exist in some other language/product have yet to be built on here, and there is a need for them. The amount of still low-hanging fruit and infrastructure work remaining to be done, let alone potential app and utilities, is substantial, and this is a community that generally speaking, respects anybody who can come in and start contributing with minimal direction or permission.
70+
71+And is time spent learning Hoon really time spent not building things? Are you not building skills, reputation, friendships, problem-solving skills, camaraderie - building a better self - throughout the learning process? One can easily present the argument that the cost in this regard is much less than it may seem at first glance.
72+
73+Since one can only try to subjectively weigh the opportunities open to them with their current skills against the nebulous costs of _not_ pursuing something that has piqued their interest, the dilemma often cannot but remain unanswered until one takes the steps to find out; until then, it remains a persistent, nagging 'what if'?. It may take several months to feel really comfortable writing Hoon, but there is a relatively low cost to spending a few weeks to dive in and see if one has an aptitude or affinity for it.
74+
75+__Hesitancy 2: Hoon is difficult and/or weird.__
76+
77+Recognizing that there are a lot of runes, and that Hoon is odd compared to other languages,
78+
79+- learning just a handful[^3] of them along with the basic families (create cores with | runes, call functions with % runes, conditionals statements are built with ? runes, etc) will get one well on their way. </li>
80+- if Hoon is not your first language, you have already demonstrated a capacity for becoming comfortable working within a framework of structure and syntax that was, relative to your previous inexperience, alien and weird. And while there are additional wrinkles in dealing with a functional language, the majority of CS concepts remain relevant and are transferable.
81+
82+And if Hoon is your first language, it is all uncharted territory anyway and not having anything to compare it to means one is essentially in the same situation as in learning any new language, and in that respect it mirrors almost any endeavor to grasp new modes of problem-solving under a unique set of conditions and constraints. Even if you do not stick with Hoon, the new perspectives in problem-solving experience are valuable, and most of the fundamental concepts will be transferable to other languages.
83+
84+You might also consider how to use Hoon’s reputation for difficulty to your advantage from the standpoint that, if you are firmly convinced that it is or will be unduly difficult, then that should yield a much deeper satisfaction after proving you are in fact capable of learning it.
85+
86+And from a more opportunistic standpoint, realize that others who allow this reputation to dissuade them create outsized opportunities for those who are willing to learn it. One can very usefully calibrate expectations here to use the reputation to provide some cover - if it really is that hard, iit is ok to not get it at first, and you can succeed where others gave up or failed to even try.
87+
88+Speaking from my own experience, the sheer amount of terminology was somewhat overwhelming at first, and this was true of both HSL & ASL (more so the latter, IMO). Many of the names seem arbitrary, but like anything, making it familiar is largely a function of effort.
89+
90+Recognize that Hoon's unique syntax and functional paradigm are integral to its design and purpose. Instead of trying to force parallels between Hoon and other languages or concepts you already know, just immerse yourself in it with an open mind and willingness to grasp its distinct features and the reasoning behind them.
91+
92+<div class="polaroid">
93+ <img src="https://storage.googleapis.com/media.urbit.org/docs/userspace/hoon-school/binary-tree-bottom-row-full.png" alt="Tree">
94+ <div class="container">
95+
96+ <p>See - it's easy!</p>
97+ </div>
98+</div>
99+
100+__Hesitancy 3: Urbit’s future is uncertain; investing in learning Hoon seems risky.__
101+
102+Much of the table-setting for this piece was an attempt to frame the potential opportunity for devs of any level. Keeping things in perspective, Urbit is just about to hit [3,000 active ships](https://twitter.com/urbitfoundation/status/1637931937351491584). There are several reasons why recent activity may be much more indicative of even greater future growth than one might assume from looking at the chart:
103+<ul>
104+<li>a. Maybe very obviously, the growth of the last three months is not simply a 1:1 reflection of the work of the last three months, but of the many preceding years of core development that made a significant increase in percentage terms within a very short interval possible. The stage is set for much faster growth.</li>
105+<li>b. Previously mentioned, but all these threads are interconnected in that, the more eyes on Urbit, the more ideas, talent and additional users will be introduced to, and recognize the depth, of the opportunity here. A steadily stabilizing building environment (thanks to a)) that attracts and can support more users should continue to build momentum. </li>
106+</ul>
107+
108+Remaining sober about reality, 3,000 users is not exactly a ton in web 2 terms; for Urbit, it is simultaneously very many and very little. But with better apps providing more reasons to be on Urbit, working in unison with better UX and onboarding, those users have more reason to stay engaged with Urbit once they are on, which means anything an aspiring Hooner or creator can think of to give them compelling reasons to make them even more engaged is an opportunity.
109+
110+Deliberately twisting the fomo screws a little, it is as true for learning Hoon as it is of anything else that the more widely adopted a platform or language becomes, the safer a bet it will be in terms of stability and longevity. With the accretion of that stability however, the window for realizing the benefits of gaining early experience and exposure in a less-crowded space diminishes accordingly as the sense of perceived riskiness in staking ground there decreases. Like any investment, uncertaintly about the future carries the gift of a difficult to quantity but very real species of camaraderie, credibility, and respect that is only available to those willing to get involved at early stages, and which is lost as the project starts to look increasingly like a 'sure thing.' Hard to value, but weigh that aspect when considering if one should begin learning now or wait until things look ‘slightly more certain’ - what is the bar for this certainty? What is ‘certain enough’?
111+
112+Urbit, by (beautiful) design, is a very low-time preference project in some respects, but it is growing quickly. And the longer you’ve been watching Urbit grow, the more perspective you have of how much can happen in a very short time.
113+
114+When there are 10,000, 100,000 active ships it will be a trip in itself to remember that you started learning Hoon back when there were "only" 3,000, and contributed in maybe some non-trivial way to attract some quantity of new ones by building something you were excited about building.
115+
116+__Hesitancy 4: I don’t see many immediate jobs for Hoon devs.__
117+
118+_Not yet you don’t_. Much of the response to Objection 3 is also relevant here.
119+
120+The pool of Urbit companies is not fixed. It is not an insurmountable obstacle to start up a small-scale dev shop with a handful of talented devs.
121+Money flowing into Urbit is being reported with increasing frequency, and this is only the incoming money that you _hear about_. As Urbit grows, money will chase money, bringing more jobs and more opportunities. For better, or worse, of course, money changes things - more money will necessarily mean more discipline, more focus on shipping product, etc. But not having money changes things too. Money comes here in no small part because it sees the energy and intensity with which this community has been building out Urbit - regardless of whether money was flowing in or out of it - it attracted devs because the project itself was an ambitious worthwhile good in itself.
122+
123+There is much opportunity here for bright, motivated developers willing to make the effort to learn. One only has to bump the total current dev headcounts up against the growing momentum of the project to see the opportunity, whether it be in core projects, apps, or novel pairings with creators to determine ways to distribute and produce content on Urbit. The speed of deployment on Urbit compared to other projects and relative exposure to other platforms affords a significant advantage to motivated, talented people in terms of visibility - when an app gets published on Urbit, everyone sees it.
124+
125+### Wrapping Up ###
126+Hopefully the above provides some perspetive on reframing some of the standard hesitancies. None of them are irrational. However, if none of the above sways you, ask what projects or features might materialize on Urbit that would make you wish you started learning Hoon a year ago (which, in the grand scheme, would make you a reasonably well-experienced Hooner) and then consider that you could wait for that thing to materialize, or play an active part in making it a reality that will attract many other users to the network, along with making others feel like they should have started learning Hoon a year ago.
127+
128+And if the Hoon question is indeed a recurrent & nagging one, attempt to replace it with the question, “two months from now (approximately the duration of an HSL cohort), would I rather have tried learning Hoon and discovered that I don’t like it and be done with the question, or still be sitting here wondering if I should learn Hoon?”
129+
130+The resources for learning Hoon are growing:<br>
131+● [Hoon School Live](https://developers.urbit.org/courses/hsl)<br>
132+● [App School Live](https://developers.urbit.org/courses/asl) <br>
133+● [App Workshop Live](https://developers.urbit.org/courses/awl) <br>
134+● An upcoming [Core Dev course](https://developers.urbit.org/courses/csl)<br>
135+● The growing corpus of [documentation](https://developers.urbit.org/reference/hoon/overview)<br>
136+● And of course the most valuable resource of all is all the people on the network who are willing to answer questions and help one learn. Find them in the Hacker House.
137+<p>
138+
139+If something about Urbit is drawing you toward it, if the project resonates with you in a way that other things in tech do not - if you are truly intrigued by it and want to be here - it is reasonable to assert that the process of learning Hoon is not simply a tax with questionable upside, but a productive process in and of itself; that the very process of learning it will embed you deeper into a space you want to be in.
140+
141+So learn Hoon. Not only is it fun, but as an Urbiter, it is something of a cultural heritage, and the conduit between reality and whatever your endless imagination conceives Urbit’s potential to be - space here is wide open, and any of today’s aspiring Hooners has the potential to pin the face that launches a thousand ships.
142+
143+----------------
144+[^1]: To 'pin a face' is to declare a variable in Hoon.
145+[^2]: Maybe some slight dramatization; this aspect also made it fun for those not in need of immediate gratification.
146+[^3]: [See 'Rune Utilization in Hoon'](https://developers.urbit.org/blog/rune-frequency-202212)
content/blog/pki-maze.mdnew file+70
@@ -0,0 +1,70 @@
1++++
2+title = "Designing a Permanent Personal Identity"
3+date = "2019-11-26"
4+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."
5+
6+[extra]
7+author = "Philip Monk"
8+ship = "~wicdev-wisryt"
9+image = "https://media.urbit.org/site/posts/essays/pki-maze.png"
10++++
11+
12+
13+
14+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.
15+
16+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.
17+
18+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.
19+
20+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.
21+
22+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.
23+
24+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.
25+
26+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.
27+
28+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.
29+
30+To change keys, you must sign a message with the old keys revoking them and supplying the new ones[^1]. 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.
31+
32+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.
33+
34+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.
35+
36+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.
37+
38+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.
39+
40+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.[^2]
41+
42+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.
43+
44+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.[^3] 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.
45+
46+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^32^, 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[^4].
47+
48+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.
49+
50+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.
51+
52+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.
53+
54+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.
55+
56+To create a sane network, we require global consistency for all our names. There are three other properties; pick any two:
57+
58+- Comets are impermanent, self sovereign, and plentiful.
59+
60+- Planets are permanent, self sovereign, and not plentiful.
61+
62+- Moons are permanent, not self sovereign, and plentiful.
63+
64+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.[^5]
65+
66+[^1]: 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.
67+[^2]: 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.
68+[^3]: 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.
69+[^4]: 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+[^5]: 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/blog/platform-decay.mdnew file+50
@@ -0,0 +1,50 @@
1++++
2+title = "Platform Decay, Decentralized Marketplaces, and Urbit"
3+date = "2020-05-07"
4+description = "Urbit is calm computing. Calm commerce follows naturally. "
5+
6+[extra]
7+author = "Nicholas Simmons"
8+ship = "~simfur-ritwed"
9+image = "https://media.urbit.org/site/posts/essays/platform-decay-preview.png"
10++++
11+
12+
13+
14+## Platform decay, decentralized marketplaces, and Urbit
15+
16+The current model followed by almost all social media services is one of easy and free participation in exchange for advertising and data collection. If you’re a fan of decentralized projects like Urbit, or just someone who pays attention to the ongoing debate over social media incentives, you’re likely to be familiar by now with a central critique of this model. There are historical reasons for why we ended up here: ad-serving and user-tracking technology outpaced subscription and micro-payment models because of recalcitrance by banks and regulatory hassles that prevented ‘real money’ from easily integrating into websites. Instead, we pay in eyeballs and analytical data.
17+
18+When we take a moment to think about possible alternatives, we usually fixate on that original bad bargain—’free’ in exchange for ads—before lamenting that first-mover advantage, critical masses of users, and sophisticated algorithms have made it very hard to see successful challenges to the reign of sites like Facebook and Twitter. We’d be happy to pay a few pennies to have an ad-free, data-secure alternative. But this critique misses something larger. There are, in fact, plenty of colossal Internet businesses that actually do charge people money to participate: e-commerce platforms. Some of these enable the sale of virtual goods and content (Steam, Patreon, Spotify), some physical goods (eBay, Etsy), and some both (Amazon, Kickstarter). Because these commercial platforms had to figure out how to make online payments easy and secure for mass audiences for their core business to work, they avoided the total dependency on ad revenue that social media sites have always had. Unfortunately, several factors have conspired to push e-commerce platforms closer and closer to a social media–style business model—by manipulating user behavior and prioritizing ad revenue and branding deals over providing a fair marketplace for ordinary buyers and sellers.
19+
20+E-commerce platforms, as generally perceived by the public, operate on a simple ‘deal’: users (small or large, individual or corporate) can buy and sell goods and services on the platform, facilitated by search engines and payment processors, and augmented by reputation systems and safeguards for buyers and sellers. In exchange, the platform takes a small cut of the revenue that passes through. E-commerce platforms were a key part of the genuinely revolutionary effects of ‘Web 2.0’. As software ate the world, it uncovered siloed value that had been previously inaccessible. This was particularly true for items with a high potential value, but a small market-base. Just as social connection technologies—from Usenet to Facebook—enabled people with niche interests to find each other, mass-platform e-commerce sites allowed buyers and sellers of niche goods—physical or virtual—to find each other and transact, thus granting those goods actual value, and their owners revenue.
21+
22+The ‘deal’ that eBay, Amazon, and the others made with millions of buyers and sellers was a great business proposition for over twenty years. They could take advantage of centuries worth of asymmetrically siloed value, now searchable worldwide, and take a ~10% cut. Their moat was in sophisticated search algorithms, network effects, and, as time went on, finding ways to make online payments as easy and secure as possible—the road not taken by early social media companies like Myspace that decided in favor of reliance on ad revenues. Crowdfunding sites like GoFundMe and Kickstarter reduced friction in online fundraising in exchange for a cut. Patreon applied a similar approach to regular support of individual content creators; Spotify, Soundcloud, and Pandora made it easier to legally stream music. All took advantage of the same ability to extract value from widely distributed niche products. All offered their vendor-users a version of the same deal: facilitation of niche broadcasting in exchange for a visibility and transaction fee.
23+
24+The problem is that the deal is now decaying rapidly, without any prospect of recovery. The behavior of every mature e-commerce vendor platform clearly shows an accelerating trend towards exploiting user data, serving ads, pushing exploitative auxiliary services like high-interest loans, and taking advantage of vendor lock-in and near monopolies on customer attention to warp marketplaces for the benefit of large brands. In other words, they’re all double-dipping.
25+
26+Clicking through normal transactions on PayPal, for example, invariably produces ads for subprime credit cards; similarly, Patreon users can now borrow against their (expected) future earnings. Spotify has reinvented pay-to-play for artists and labels; eBay has leaned hard on promoted listings, with extra fees, in order for vendor offerings to show up in search results. Amazon has increasingly ‘gated’ third-party offerings in categories and brands in which not only their own ‘store brand’ products, but those of large brands with which they have struck external deals, compete. A growing number of consumer products have essentially been prevented from being resold on Amazon or eBay by the threat of spurious, but expensive, anti-counterfeiting lawsuits by major brands, thus buoying new sales by effectively eliminating resale value.
27+
28+There are several key reasons for this. One is simply that as the initial burst of siloed value being accessed, revalued, and bought and sold subsides, the number of transactions plateaus and e-commerce platform revenue with it. The traditional model of venture capital funding for platform businesses, however, demands an exponential growth in profits; the exploitation of customers and vendors becomes irresistible in order to maintain these profit trajectories. Another reason is that as e-commerce platforms accrued large userbases of both buyers and sellers, they began to act like other online platform businesses—distorting marketplaces and shaping user behavior to maximize retention and profit, rather than offering a straightforward service.
29+
30+Platforms exploit user data because they can. Their ownership of your data is baked into the client–server architecture on which their businesses run, and the system cannot correct itself. Chris Dixon, in his prescient [essay](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) about the future of decentralized commercial protocols, presents an S-curve whereby a platform business transitions between serving its users in order to grow and achieve market dominance, and eventually exploiting those users once it has achieved that dominance. In particular, early-stage e-commerce platforms do anything they can to benefit vendors willing to sell on their platform. Vendor presence is vital to attracting customers, but once those customers have been captured, the vendors become the [competition](https://www.wsj.com/articles/amazon-scooped-up-data-from-its-own-sellers-to-launch-competing-products-11587650015?mod=searchresults&page=1&pos=1). Customer eyeballs and dollars are a finite resource, and platforms carefully calculate the potential profit to be made from showing customers one product or another. The lack of platform-agnostic reputation systems also aids vendor capture by platforms. Rather than optimize for a system in which any buyer or seller with good external credibility (measured by, for example, credit scores or relevant business licenses) can use their platforms as a commercial intermediary, eBay and Amazon use seniority and internal transaction records to determine vendor permissions. Since sui generis internal reputation scores can’t be taken to other platforms, these policies create a sunk cost of effort and reputation which traps vendors within specific marketplaces, without an easy exit.
31+
32+Market consolidation and bureaucratic pressures for legibility also work against maintaining a square deal with vendors and users. The midpoint on Dixon’s S-curve, when exploitation of vendors begins to occur, can also be seen as the point where a customer base is solid enough to be marketed to advertisers and major brands who can pay for favorable search placement. Such large, legible deals are easier to negotiate, easier for individual executives to take credit for, and are useful in meeting arbitrary investor benchmarks and buoying quarterly revenue statistics; but they privilege larger brands with larger ad budgets over ordinary sellers in a niche. Another major downside of large, centralized e-commerce platforms is that, like any large bureaucracy, they have PR and regulatory concerns that provide an attack surface for regulators, activists, litigious brands, and monopolists seeking to crush competition—almost invariably at the expense of vendors and customers.
33+
34+Even more subtle and worrying effects come when e-commerce platforms realize that the actual products being shown do not have equal chances of being purchased, therefore delivering revenue to the platform itself. This applies even when the products being compared have nothing in common: apples to oranges; cat food to hiking boots. Accuracy of internal search engine results, and a comprehensive spread of offerings, are regularly sacrificed to the aim of placing a ‘sticky,’ lowest-common-denominator product in front of the customer. I recently ordered vegetable seeds on Amazon; after a few searches for different kinds of seeds, I started having to wade through ‘premium placement’ ads for farmer-themed romance novels before I could view, and choose from, the actual seeds on offer. This deprecation of niche products is ongoing and makes the interface of such platforms less and less navigable. It’s also worth mentioning that, frequently, such deprecation has very little to do with durable consumer interest or a free-market determination of product value. Rather, they come from a ‘thumb on the scale’ of large advertising campaigns that seek to convert a wide range of consumer curiosity into sales for a particular product at a particular time.
35+
36+The manufacturing of consumer desire in this way feels creepy. It’s frustrating to have your tastes dictated to you by whoever has the biggest ad spend. It also spells the end of small business on the Internet—you can spend years mastering knowledge of a profitable niche, but if Amazon profiles your customers and decides they’re more likely to spend their money on the latest Pixar DVD, your listings will be shoved below the fold. Pixar paid for placement and you didn’t; the Pixar ad placement deal made a splash in the quarterly report, your fees didn’t. In cultural terms, this threatens to create a winner-take-all situation that will prevent new and niche artists and thinkers from gaining attention at the expense of explicitly placed, ‘premium’ content.
37+
38+Again, this is all accelerated by the way that ad sales function; platforms like broadly popular content and products because the larger number of customers searching for and purchasing them creates more granular data and increased opportunities for micro-targeting ads. This incentive leads to the increasing invisibility of long-tail, niche content or products whose appeal has less to do with lowest-common-denominator addictive virality, whether it’s the repair manual for your ‘85 Toyota or a copy of Plato’s _Republic_. It also accelerates the stampede toward a ‘sharing’ and ‘renting’ economy; when ad impressions are a sizable part of company revenue, forcing customers to return to ad-infested platforms to continue renting objects or content, rather than making one-time purchases, is a no-brainer.
39+
40+There’s a nightmare scenario here, a kind of hybrid, zombie brainchild of Jean Baudrillard’s concerns about the simulation of common meaning and Peter Thiel’s arguments about the stealthy hollowing-out of industrial capacity. In this nightmare future, financial and legal regulation strangle the viability of anything like a real industry, and we’re left with a handful of incumbent platforms which have concluded that the smartest move is to just sell vaporware ‘content,’ collectible bobbleheads, and sugar water. The supposed niche of any platform business is academic at this level; Amazon, Spotify, and Patreon are simply machines for converting user attention into the highest-margin purchases possible. The ‘high-velocity trash economy’ (h/t Pierre Rochard) increasingly shows itself as a network of funnels by which insider prognostications about government and central bank policy are turned into profits, with the illusion of productive activity serving only as window dressing. This deforming process extends all the way down to the vagaries of the consumer economy. If there is no financial reason for available consumer offerings to be anything we actually need, they can and will be deprecated and displaced; useful goods and services will be sidelined by literal trash that has the ‘financial’ logic of maintaining an unbroken, upward metric by virtue of direct parasitism upon the human brainstem.
41+
42+The implications are obvious: if we can’t make markets obey a representation of factual reality, we won’t be able to build stuff we need in the factual world. The damage which has been done by our replacement of infrastructural capacity with nebulous thematic concerns that happen to feed our dopamine receptors is becoming rapidly apparent to anyone paying attention. If our search results for ‘hammer’ algorithmically default to pro wrestling merchandise, that changes our real, physical lives. Our ability to go out and build things with a hammer is diminished, and so is, implicitly, the importance placed on that act of building by the culture that surrounds us. The physical world of technology, no less than the informational, is a slippery pile of patches and detours. When JPL scientists reestablished contact with an early satellite after decades of inactivity, they relied on vintage computer parts from eBay to communicate with it. In some areas (cars, hand tools, some analog electronics) the present consumer offerings have generally declined, in terms of reliability and user serviceability, from a zenith some twenty or forty years ago. Forty-year-old Toyota trucks often fetch more, in equivalent value, than they did when new, because regulations and planned obsolescence have prevented the ongoing production of trucks that meet the same standards of reliability and fuel economy. The failings of our just-in-time supply chain have likewise been made blatantly obvious by the disruptions of COVID-19. Both argue in the strongest terms against allowing consumer-facing e-commerce to be captured by what are rapidly becoming payola-driven entertainment platforms rather than marketplaces for essential goods, whether car parts, beef jerky, or N95 masks.
43+
44+So what’s the solution? Many prescient observers envision decentralized protocols to safeguard the data of vendors and buyers, and algorithmic representation of their offerings. Any new ‘deal’ between vendors, buyers, and platforms must be rooted in data ownership and neutral code if it is to avoid a repeat of the current paradigm. Personal ownership of browsing, buying, and selling data is necessary so that search results and boosted listings aren’t distorted for each customer in order to ‘nudge’ them into consumptive patterns, and so that value is retained in useful, niche items which don’t lend themselves to dopamine addiction and manipulative marketing campaigns. The hope is that widespread personal control of data would lead to the emergence of protocols and marketplaces which have realistic economic models based on fees; the ‘square deal’ originally promised by ‘Web 2.0’ platforms. Such marketplace businesses wouldn’t be exponential unicorns; they’d be steady, stable infrastructure companies like those that built the foundational technologies of the 20th century and made a secure, middle-class lifestyle possible for millions of people. Data ownership wouldn’t prevent platforms from incorporating advertising, but it would shift the balance of power to an opt-in basis. By reducing the ability to target such ads, it would prevent the lopsided reliance on ad revenue which leads to smaller vendors being neglected. Big companies wouldn’t go away; they’d make their margins by focusing on economies of scale in the real world: logistics, fulfillment, and redundant inventory for commodity goods.
45+
46+We need decentralized, robust reputation systems to combat monopolistic platform lock-in and its attendant abuses, but also so that smaller, more private marketplaces can create their own rules, and still be functional and secure. Right now, reputation data is siloed by the same companies that built large marketplace platforms, which means that anyone who moves outside of their walls loses access to it, and thus loses protection from bad actors. The ability of users to run their own reputation scans, or to pay for a separate layer of reputation data which is marketplace-agnostic, is essential to breaking the hold that large marketplaces currently have on e-commerce. If a local community wanted to trade in homegrown food, for example, they could restrict access, while also making sure that their members didn’t have a previous, external track record of fraud in other markets.
47+
48+Where does Urbit fit into this? We think that the basic infrastructure and alignment of the Urbit system has two major advantages to offer those who will build these new protocols. The first is the simplicity of running one’s personal server of data and locally hosted processes. Any attempt to reimagine privacy-focused e-commerce under current client–server models quickly runs into complexity problems—Web 2.0 platforms require reams of legacy code and armies of SREs to keep them running. The second is the ability to maintain a semi-private but reliable digital identity among different platforms and communities, including commercial ones. Most current conceptions of autonomous marketplaces rightly focus on the potential of cryptocurrency as a decentralized payment system. But wallet and exchange problems, the work-in-progress state of micropayment infrastructure, and price fluctuations among different currencies (crypto or fiat) clearly show the need for a decentralized reputation system which is not simply a crypto wallet address, but is likewise more secure than a PHP forum profile. We think that Urbit ID can provide such a holistic, yet pseudonymous, reputation system without being tied to a particular currency, wallet, or commerce platform.
49+
50+Right now, Urbit is a communication system for communities and individuals. We aim to create spaces where human conversations can take place with a minimum of distractions. We believe that commerce, too, is best achieved in such a space; think of your local hardware store rather than a carnival with barkers at every turn. We also see this as a priority deeply in keeping with the underlying ethos of Urbit. We frequently speak of Urbit as a tool, and reference classic principles of tool design when considering how to expand it. The test of any tool is in its ability to shape the world; if that function isn’t well matched to both the actual world, and the hands and desires of those who will wield it, usability will suffer. Open marketplaces should function as magnifying glasses, to hand buyers and sellers a tool to see the shape of supply and demand, rather than distorting the actual terrain of the marketplace in order to create its own desires. Soon we’ll have BTC integration tied to Urbit ID, and independent security audits of the Urbit system. We want Urbit to become the foundation on which users can build simple, decentralized protocols that enable us to safely and easily buy and sell goods and content that we actually want and need. Urbit is calm computing. Calm commerce follows naturally.
content/blog/precepts-discussion.mdnew file+756
@@ -0,0 +1,756 @@
1++++
2+title = "Precepts: Discussion"
3+date = "2020-03-17"
4+description = "The precepts aren’t arguments. We discuss and justify them here."
5+
6+[extra]
7+author = "Philip Monk"
8+ship = "~wicdev-wisryt"
9+image = "https://media.urbit.org/site/posts/essays/discuss-01.jpg"
10++++
11+
12+
13+
14+The precepts aren’t arguments. We will discuss and justify them here. We don't expect to convince you this is exactly the right set of precepts, but we hope to convince you that this is a coherent set of precepts that might lead to something very interesting.
15+
16+We will address these in the same categories presented above:
17+
18+- A: General Design. Principles of engineering that apply in a great
19+ many situations. Any piece of code will exhibit at least a few of
20+ these.
21+
22+- B: Specific Design. principles of engineering that apply in a few
23+ specific situations. What these lack in general applicability they
24+ make up in specific guidance.
25+
26+- C: Attitude. Good code is the result of people approaching the act of
27+ engineering with the right attitude.
28+
29+- D: Theory. The eternal tension between theory and practice must not
30+ simply be acknowledged but dealt with.
31+
32+- E: Text Style. Code form matters.
33+
34+- F: Real Software. Not all software matters. Any software which
35+ wouldn't exist on Mars isn't real.
36+
37+
38+
39+### A: General Design
40+
41+These are principles of engineering that apply in a great many
42+situations. Any significant piece of code will exhibit at least a few
43+of these.
44+
45+### Simplicity
46+
47+> A20: One hundred lines of simplicity is better than twenty lines of
48+> complexity.
49+
50+> A21: Prefer mechanical simplicity to mathematical simplicity.
51+
52+At Urbit's root is a strong opinion on what constitutes simplicity. We take a semi-subjective view of simplicity. Specifically, we say that the sort of simplicity that matters is the sort that makes it easy to reason about stuff. We call this "mechanical simplicity".
53+
54+A competing view of simplicity says that it can be measured objectively by metrics such as the number of moving parts, the number of kinds of moving parts, the orthogonality of concepts, or cyclomatic complexity. We believe these are important metrics because they are good approximations of mechanical simplicity, but they don't tell the whole story.
55+
56+In acoustics, we use decibels of sound pressure to measure objective volume of sound. However, the Fletcher-Munson curves (equal-loudness contours) describe how loud sounds are perceived to be relative to their frequency. For example, a 75 dB sound at 4kHz sounds equally loud to a 90 dB sound at 10 kHz, even though the latter is over 20 times the sound pressure.
57+
58+Similarly, some sorts of complexity are much easier for humans to deal with than others. For example, humans are much better at learning languages compared to even simple mathematics. Even those who are "good at math" are objectively much better at languages, in terms of how much complexity they can absorb. Humans are also built to understand some
59+social dynamics and structures, even very complex and nuanced ones, without even consciously knowing the rules to them.
60+
61+Some examples of things that are objectively quite simple but subjectively hard for people to learn:
62+
63+- Pointers. Once you've properly learned them, it becomes hard to
64+ sympathize with your past self that found them difficult, but in
65+ practice these are a stumbling block for many people. Some think
66+ they're a "weed-out" concept, meaning they're just a good litmus test
67+ to see if you're the type of person who can learn how to program.
68+ Even if that's the case, it's still meaningful that they're effective
69+ in that.
70+
71+- Recursion. Same as above. Notably, `while` loops do not evoke the
72+ same reactions in people.
73+
74+- Monads. A little more complicated than the above, but objectively not
75+ that complicated. Certainly much less complicated than the C++
76+ standard library, but for some reason many people fail to learn monads
77+ after giving it an honest attempt, while that's rarely the case for
78+ the C++ standard library.
79+
80+- Math in general. The ideas in mathematics are generally pretty clean
81+ and small, which is why once you've learned a concept, it seems
82+ obvious in retrospect. The C++ standard library doesn't look much
83+ more obvious in retrospect than it does on first glance.
84+
85+- Any language that induces a moment where you exclaim to yourself,
86+ "This is true programming! Everyone should program this way, it's so
87+ obviously better!". People say that often about Lisp, Haskell,
88+ Prolog, and Smalltalk. Nobody ever said that about C, Java,
89+ Javascript, or Python. And yet, which ones are easier to learn?
90+ Which ones are used in real life?
91+
92+I've emphasized learning here, but the same principles apply to using a
93+tool after you've learned it.
94+
95+When evaluating simplicity, presumption should be on the side of "what
96+everybody does when they have a choice" instead of "what's
97+mathematically simpler". Being mathematically simple is a point in your
98+favor, but the burden of proof still falls on you to argue that it will
99+be simpler to learn and use.
100+
101+Adherence to this precept is difficult because you have to decide
102+whether an objectively simpler construction is in fact better. This
103+gives a framework for deciding the question.
104+
105+> A19: Dualities must be faced head-on and analyzed differently at
106+> different layers.
107+
108+A crucial point is that the question of simplicity depends on the facts
109+and circumstances of the case. In deeper layers of the system,
110+mathematical simplicity tends to pay greater dividends. If the features
111+of the base layer are not orthogonal, the interactions between them will
112+only grow more complex as you rise in the stack. If the base layer has
113+many moving parts, the number of moving parts can only increase as you
114+rise in the stack.
115+
116+This isn't the only duality that depends on the layer of the stack.
117+The most important layering of the stack is between "systems" and
118+"applications", where "applications" are those pieces of code on which
119+no other application depends. Many answers that are correct in system
120+code are incorrect in application code, and vice versa. These precepts
121+are an attempt to describe principles that apply at all areas of code,
122+but they're much more important to follow in system code.
123+
124+> A22: The Law of Leaky Abstractions is a lie; abstract airtightly.
125+
126+The Law of Leaky Abstractions says that all non-trivial abstractions are
127+leaky. This is the sort of statement that most engineers will accept
128+immediately and most mathematicians would dismiss out-of-hand. In
129+mathematics, if an abstraction leaks, it's not simply an imperfect
130+abstraction, it's completely wrong and should be thrown away. So they
131+manage to create perfect abstractions. They don't always abstract what
132+you wanted to abstract, but at least they're perfect.
133+
134+If mathematicians can do that, there's no reason programmers shouldn't
135+be able to do it as well. Sure, programmers have to deal with some
136+performance considerations that mathematicians can elide, but that's
137+rarely the reason abstractions leak. They leak most often because the
138+creators are lazy or sloppy. If your abstraction leaks, find a way to
139+either plug the leak or reframe the abstraction to incorporate the
140+"leak" in a coherent way. It's not a leak if it's part of the spec. I
141+call this "turning leaks into decorative fountains".
142+
143+### Conceptual clarity
144+
145+> A6: Represent your data as closely as possible to the essential
146+> structure of the problem.
147+
148+There are times when you need to represent your data in an unnatural
149+format for performance reasons, but this is rare. When possible, keep
150+the structure and location of your data in as natural of a manner as
151+possible. For example, if a function can produce an integer or an
152+error, don't produce a negative number to indicate an error — use an
153+explicit tagged union.
154+
155+An important part of this is to fit your data types to your data
156+skin-tightly. If your data types permit states that you intend to be
157+impossible, this is suboptimal. There are degrees of this (if you need
158+a number between 0 and 1000, a uint32 is probably fine even though it's
159+suboptimal), but it's important to strive for it.
160+
161+As an example, if your program can't respond to requests until it
162+completes an initialization process to fill in some of its state, it's
163+tempting to make nullable all the parts of its state that are filled in
164+during the initialization process, then just check whether they're
165+nullable when you use them. This creates a complex set of representable
166+states of partial initialization, and any bugs in that area will be
167+difficult to track down. A better option is to create a "larval" stage
168+of your program that performs the initialization. If requests come in
169+during this larval stage, queue them up until it's done. When it finishes
170+initialization, it metamorphizes into the full program, where all the
171+fields in its state are not nullable. Then run through its queue of
172+pending requests. This more closely resembles the essential structure
173+of the problem.
174+
175+> A8: When mating different paradigms, build one cleanly on top of the
176+> other.
177+>
178+> A9: Never misuse an abstraction.
179+
180+An abstraction provides a set of tools to solve a problem. Use them in
181+the intended way. If this is awkward, consider that this may be the
182+wrong abstraction to use. If the impedance mismatch is large between the
183+paradigm that your program uses and the paradigm that you're mating it
184+with, consider building an explicit layer whose sole purpose is to
185+convert between the paradigms (see B5).
186+
187+### Correctness
188+
189+> A10: Correctness is more important than performance.
190+>
191+> A12: Correctness is more important than optimality.
192+
193+Sometimes you devise a solution which is fast but slightly incorrect.
194+This is rarely a good idea. Especially at lower layers of the system,
195+incorrectness expands as it bubbles up.
196+
197+Other times, you devise a solution which is correct, but you could
198+probably make it cheaper without sacrificing correctness. Sometimes
199+that's worth doing, other times it's not.
200+
201+Finally, in some cases you find a solution that's "optimal"
202+performance-wise or simplicity-wise, but it doesn't quite handle every
203+situation correctly. Maybe in the real world there are genuine
204+exceptions, and the code is much faster or simpler if you don't handle
205+those exceptions. In these cases, it's more important to handle every
206+case correctly than to "snap" to the nearest elegant formulation.
207+
208+> A11: Be simple and uncompromising in defining what's correct; go crazy
209+> with optimizations.
210+
211+Nock is a great example of this. It contains the character of the
212+virtual machine, but its asymptotics are bad. Add jets to fix the
213+asymptotics.
214+
215+Another example is the ACID nature of Arvo. Arvo is a pure
216+function f(logs) of its event log, so formally Arvo is just a
217+function run against an event log. A naive implementation has
218+very bad asymptotics; processing each new event is O(n) in the
219+number of historical events. Choose the function g(state,log)
220+such that f(logs ++ log) = g(f(logs),log). Then, as long as you
221+keep the state in memory, processing each new event is constant in
222+the number of previous events. This still requires O(n) restart
223+from disk, but you can also periodically (and non-blockingly)
224+write a checkpoint of the state to disk, so that restart from disk
225+is only linear in the number of events since the last checkpoint.
226+
227+This pretty much says it all. Define what's correct in as simple of
228+terms as possible — this will make it easier to implement and reason
229+about. Then don't compromise on it.
230+
231+> A13: If you don't completely understand your code and the semantics of
232+> all the code it depends on, your code is wrong.
233+
234+It's impossible to build correct code on a foundation that you're unsure
235+of. This is different than the problem of building something with
236+strong guarantees on top of something with weak guarantees — for
237+example, delivery guarantees on top of an unreliable transport protocol.
238+In that case, you are sure of the underlying system, it's just that what
239+you're sure of is that you can't rely on it delivering packets in order
240+or at all. So, you formalize what you _are_ sure of, which is that it
241+will eventually get your packets through if you keep sending them
242+forever. And that's something you can build on.
243+
244+This is another reason it's important to have simple and accurate
245+correctness claims. When somebody else relies on your code, they
246+will need to know what exactly you claim to provide. If you're
247+accurate, then they don't have to understand your code, only your
248+guarantees.
249+
250+> A14: Deterministic beats heuristic.
251+
252+Heuristics make it hard to give precise safety guarantees, so you should
253+only use them when you don't guarantee much.
254+
255+> A17: Referential transparency is honesty and stability.
256+
257+A claim of referential transparency is a very strong guarantee, so it's
258+very useful for any code built on top of it. That code doesn't need to
259+know anything about how you produce the value because it can't
260+negatively affect the rest of the system, and it's free to cache
261+indefinitely.
262+
263+> A18: Responsibilities should be clearly separated.
264+
265+A program should be responsible for its own guarantees, though it must
266+rely on other programs to maintain their guarantees. You should avoid
267+guarantees that unduly couple separate programs. Any guarantee that
268+references state in more than one program is suspect.
269+
270+### State management
271+
272+> A1: Data is better than code
273+>
274+> A15: Stateless is better than stateful.
275+>
276+> A16: Explicit state is better than implicit state.
277+
278+Data is better than code, but code is better than state. If you must have state, state that is data is better than state that is code.
279+
280+There are many reasons for this. The most basic one is that humans are better at dealing with nouns than verbs. This is true to such an extent that we subconsciously convert statements of the form "so-and-so does such-and-such" to "so-and-so is a such-and-such-er". It's more challenging to view someone as a composition of their internal motivations such that they'll act in a particular way. It's much easier to see them as simply "friend" or "enemy" or "socialist" or "evil capitalist".
281+
282+Socially, the verb -> noun simplification is often problematic because it doesn't communicate the whole picture as accurately. It's an approximation that fails to capture important nuances. And that's because any nontrivial verb can't be understood in terms of a simple noun.
283+
284+However, the practical implications of this insight are different in code. Socially, people are who they are, so the best we can do is learn to understand them better. In code, though, we have a
285+powerful tool: convert the verbs to actual nouns. We can take advantage of our innate ability to reason about nouns and use that to make code that can more easily be reasoned about.
286+
287+Another way of looking at this is that data is easy to reason about. Code is hard to reason about, because it's much larger. Function types are known as "exponential types" because the number of possible functions between sets of size `m` and `n` is `n^m`. If there's global state of size `s`, this is even worse: `n^(m*s)`. The halting problem says that it's impossible in general to even determine if a piece of code will finish without running it.
288+
289+A final way of seeing this is that it's easier to reason about things that don't change. Data doesn't change, so it's a stable foundation. Pure code changes based on its arguments. Impure code changes based on its arguments and state. Impure code that uses code stored in its state
290+nests this whole complexity within itself.
291+
292+You can't, in general, update code in any way other than replacing it wholesale. This is not true of data, where to upgrade you just need a function from the old data type to the new data type.
293+
294+Sending code over the wire is problematic, because it's either very large or depends directly on what the other person has on their local ship. If you depend on what's on their ship and you're wrong, you may get the wrong result. So you explicitly require certain dependencies, at certain versions, ... this way lies dependency hell. There are ways to tame this, but if you just used data in the first place, those problems wouldn't exist.
295+
296+Of course, we can't always use data, precisely because it's smaller than code. And there are occasionally times when we could use either, but the code is actually easier to reason about than the data. All else equal, data > code > state of data > state of code.
297+
298+A note on laziness: lazily defined data occupies a middle ground. It's harder to reason about than strict data, but you get a lot more guarantees with it. It's probably not worth using as your basic substrate, but it makes some things easy to reason about.
299+
300+### CQRS/pubsub
301+
302+> A2: Everything should be CQRS.
303+>
304+> A3: (Almost) Everything should be pubsub.
305+>
306+> A4: A subscriber shouldn't affect a publisher.
307+>
308+> A5: Communication between nodes should be communication between
309+> independent actors.
310+
311+Fred Brooks pointed out that when you add people to an organization with `n` people, the number of interpersonal connections goes up with `n^2`. This is true of binary interpersonal connections, but if you allow groups of any subset of the people, then the number of total groups goes up with `2^n`.
312+
313+The same is true of entities in a program. A program must speak to many other programs about many things. Occasionally it can treat all others the same, so that the number of things it needs to say is constant in `n`. Sometimes it needs to say something different to each person, making it linear in `n`. Other times, it has a set of things it can speak about, say `m`. Pubsub lets the complexity grow with `m` instead of `n`. This lets the total communications grow with `m * n` instead of `n^2`.
314+
315+It's generally good to have more structure in how you communicate with other entities. If all you have is `send-message`, then you force each entity to define their norms around when messages are to be sent, and how to associate one message with another (eg a request to a response). This also gives the underlying system no visibility into the conversations.
316+
317+In CQRS+pubsub, we get a number of useful guarantees to help us structure our conversations. We know that a command will have no response other than exactly one positive or negative acknowledgment. We know that to request any data, we must have an active subscription, and
318+we know that a subscription may be canceled at any time. We know that a subscriber's failure to process a subscription update can't break the publisher. We know that after the initial subscription update, any subscriber to a path will get the same updates as anyone else on that
319+path.
320+
321+The underlying system can keep track of subscriptions, and can even cancel them automatically in certain circumstances (eg if the subscriber is on another ship and has stopped responding). This is like the nouns and verbs discussion above. Subscriptions are nouns, so we can reason about them better, and so can the underlying system. "Send a message" is a verb, so we have few guarantees about it.
322+
323+From Dijkstra's "Go To Statement Considered Harmful", which may as well have been written about unstructured event passing:
324+
325+> My second remark is that our intellectual powers are rather geared to
326+> master static relations and that our powers to visualize processes
327+> evolving in time are relatively poorly developed. For that reason we
328+> should do (as wise programmers aware of our limitations) our utmost to
329+> shorten the conceptual gap between the static program and the dynamic
330+> process, to make the correspondence between the program (spread out in
331+> text space) and the process (spread out in time) as trivial as
332+> possible.
333+
334+In our case, we make the programs of both the publisher and subscriber simpler by writing in terms of well-known constructs like "subscribe" and "push subscription update". You need to know much less about your counterparty.
335+
336+> A7: A client's representation of data should be as close as possible
337+> to that of the server.
338+
339+This is a natural architecture given pubsub, but it's also worth pursuing in its own right. This blurs the distinction between client and server, which makes the client more full-featured.
340+
341+It reduces communication to syncing, which means offline-mode is just a special case of sync latency, and all the local features are still usable.
342+
343+It also tends to reduce centralization, since you're already used to operating on your own, and you have all the data required to do so. The "server" becomes a commodity, easily moved when desired. Git is a good example of this — central git servers are common, but they're also a commodity, so you're never locked into a particular hosting provider. This is possible because the data structures are exactly the same on the client as on the server.
344+
345+> A23: Some cliches are repeated because they are true; others must be
346+> repeated because they are not.
347+
348+Computer security is an industry built on cliches. An example of the first is "your security is only as strong as your weakest link."
349+
350+An example of the second is "security through obscurity is ineffective". Security through obscurity is in fact the most effective form of security — if nobody cares about you, you will never be hacked. The problem is that you must remain obscure for it to work, and that's hard to explain to people in a precise way. It's effective at protecting precisely when there is nothing worth protecting. So, it's better (for them, their companies, and their users) to tell them a lie.
351+
352+However, it's important for whoever's coming up with the cliches to understand the specifics of how they're untruthful. Some of these very precepts may fall under the category of "literally untrue but more useful than the truth".
353+
354+
355+
356+## B: Specific Design
357+
358+There are some principles that aren't obviously better than the alternatives, but if you use them consistently you avoid a lot of issues. These are all examples of this.
359+
360+> B1: Always ack a dupe; never ack an ack.
361+>
362+> It's okay to ack a nack as long as you never nack a nack.
363+
364+This is a simple rule, and if you follow it you get various guarantees for free. For example, sending a message will always cause up to a constant number of additional messages to be sent by direct or indirect causality (other than application-level code), so you never have to worry about accidentally causing a loop.
365+
366+Additionally, acking an ack can never take you from imperfect to perfect reliability. Urbit isn't big on heuristics for stuff that's visible to userspace (A14), so don't even go down that road.
367+
368+Following this rule greatly reduces the architecture space for networks. This is very helpful in finding a good architecture.
369+
370+> B2: Never construct or deconstruct a duct.
371+
372+A duct is akin to a first-class call stack. Don't deconstruct that for the same reasons you shouldn't read your own call stack. If you read your own call stack, and do different things based on that, it breaks a lot of assumptions we have about messages. For example, we assume that a vane will handle a task the same way regardless if the initial IO event was a keystroke or a timer. Don't break that.
373+
374+Similarly, don't construct these by hand. This would be like inserting other functions into your own call stack and then returning to them. Powerful, yes, but pretty much always a bad idea because it breaks our assumptions.
375+
376+> B3: Route on wire before sign, never sign before wire.
377+
378+When we send a message to another vane or app, we send it on a wire. When we get a response to that message, we should care first about the wire it was sent on.
379+
380+It's tempting to shortcut that and route based on the type of response. Maybe you only call to `%iris` once in your app, so you feel like you can just route directly on that. But it doesn't scale, because that dimension is orthogonal to the true dimension you care about — which request this response corresponds to. This is essentially a violation of A6.
381+
382+> B4: Only go from statically typed to dynamically typed if you must.
383+
384+Consider the set `U` of all possible programs. Then consider "the program you want to write" to be a set `S` of programs that differ only in aspects you don't care about. For example, maybe one takes a little more time and one takes a little more memory, and maybe you don't care about that. This set has a generating "specification" — any program that meets that specification is in the set.
385+
386+A type system or testing suite can guarantee that a program is in another set `T`. Obviously, both `S` and `T` are in `U`. Hopefully the intersection of `S` and `T` is non-empty — that is the set of programs which typecheck and meet your spec.
387+
388+A perfect static type system can guarantee `T` is a subset of `S` — if it typechecks, then it works. Obviously, if you let `T := {}` (ie no program typechecks), then this is vacuously true. So you want `T` to be as large as possible while still being a subset of `S` — as many programs as possible typecheck without them being incorrect. But it can't make `T == S` — there will always be some programs that do the correct thing in practice, but the type checker can't prove that.
389+
390+Dually, a perfect testing suite can guarantee that `S` is a subset of `T` — no correct program fails the tests. This is vacuously true if you have no tests, for then `T = U`. So you want `T` to be as small as possible while still being a superset of `S` — you don't want to reject valid programs if you can help it. But you can't make `T == S` — there will always be some programs that are invalid but pass your typechecks (at least, if your program requires a Turing machine).
391+
392+(It is possible to create a static type system that has `S` subset `T` property described above for a testing suite — see Erlang's Dialyzerand [related work](http://user.it.uu.se/~tobiasl/publications/contracts.pdf).)
393+
394+A dynamic type system tells you neither of these ahead of time. Instead, you end up with type errors at runtime. Errors at runtime must be handled at runtime, when the programmer is not present. Errors at compile time are handled at compile time, when the programmer is present.
395+
396+There's a hybrid, which is "static type checks at run time". In other words, you load the code and run the type checks at run time. This is better than pure dynamic checking because as long as the code compiles, you get the guarantees of a static type system. But the later in the process that the code is compiled, or the more it's changed before compiling, the less guarantee you have that the type checker will pass. If a static type checker gives an error at a time when the programmer is not present (because it's run at runtime), that's worse than a dynamic type system — at least that would give it a chance of executing correctly!
397+
398+> B5: Anything with business logic speaks one paradigm; anything that
399+> translates paradigms has no business logic.
400+
401+Translating between paradigms with significant impedance mismatch is usually convoluted code. The state machines are often hard to see, and it tends to be quite cluttered.
402+
403+You want your business logic to be as clean and short as possible. This way the interesting algorithms are laid bare.
404+
405+> B6: Functionally enforced semantic rules are better security primitives
406+> than memory access restrictions.
407+
408+Memory access restrictions are blunt tools. Blunt tools are nice in simple systems, and if all you have is nails, then a hammer is perfect. But in practice you punch all sorts of holes in these restrictions, because you need more granularity and flexibility.
409+
410+Better to define rules in a more powerful language. This allows you to follow A6 and A8. It also lets you use all the correctness tools, like type systems, that you've developed for the rest of your code.
411+
412+
413+
414+### C: Attitude
415+
416+Good code is the result of people approaching the act of engineering with the right attitude.
417+
418+> C1: Code courageously.
419+
420+If you avoid changing a section of code for fear of awakening the
421+demons therein, you are living in fear. If you stay in the
422+comfortable confines of the small section of the code you wrote or
423+know well, you will never write legendary code. All code was
424+written by humans and can be mastered by humans.
425+
426+It's natural to feel fear of code; however, you must act as though
427+you are able to master and change any part of it. To code
428+courageously is to walk into any abyss, bring light, and make it
429+right.
430+
431+The unix/internet stack is a giant ball of mud. It's so big that when you're standing on it, it looks like a bog, and it's not clear that there is a bottom to it. You know there must be, but it doesn't matter because you learned long ago that the best solution is to not dig too deep. Build a strong structure by spreading out your weight and using strong construction materials. If there's something useful deep in the mud, it's probably not worth diving in to pull it out. That's dangerous and prone to failure, and you know many people who have gotten stuck down there.
432+
433+This is an appropriate reaction to the unix/internet stack. It's also self-perpetuating. The bog is filled — even _composed_ of — countless predecessors who did that same thing. If you ever find yourself on solid ground, protect that with your life. Learn how it works and how to use it well. Then build a strong structure on top of that. Don't let it decompose into a layer of mud.
434+
435+Urbit is small enough that, while there's definitely some construction-related dirt and muck covering it, the solid metallic core is not very deep — not more than waist deep in most places. The feeling of always being in contact with the bottom is very different than flailing about in a bog.
436+
437+This property is worth fighting for. It's the whole reason Urbit was written. New Urbit programmers are instinctively distrustful of anything below them and code defensively and fearfully. They must learn that it's all drastically simpler and more legible than they're used to. It's still hard, but you can actually make progress. To do so, you have to stand up straight, so you can get a firm footing on the ground. Keep your chin up and your shoulders back, and adopt the posture of a conqueror. When something doesn't work right, don't retreat into your shell of safety and control — fix it. The forces of chaos are always lurking, but their victory isn't inevitable. It's all on the line, so code with abandon.
438+
439+> C2: No time for lazy people.
440+
441+If there's clearly a right way to do something and a wrong way, do
442+it the right way. Coding requires incredible discipline. Always
443+follow conventions, and fire anyone who won't. Anything that can
444+be solved by discipline is not a real problem.
445+
446+> "To him who knows to do good and does not do it, to him it is
447+> sin."
448+
449+Preserving the property of solid ground requires perpetual discipline. Once lost, it's often impossible to reacquire. Don't compromise your standards.
450+
451+Call people out when they're being lazy. And when someone calls you out, recognize it and fix it. Sometimes it's just a question on a code review — "why did you do it this way?" Upon reflection, you determine that you did it that way because you couldn't be bothered to do it right. Maybe that was a reasonable choice at the time you were coding so you wouldn't be distracted, but if it's been called out in a code review, now's the time to fix it, not make excuses.
452+
453+> C3: When a smart person makes an obviously stupid suggestion, before
454+> responding take a full 60 seconds to envision how you would implement
455+> it and what the effects would be.
456+
457+Once you've determined that someone understands a situation well, if they earnestly make a suggestion that you haven't thought of, or that you immediately dismissed as impractical, stop and consciously consider it. This is one of the best ways of countering the natural echo chamber
458+of your own mind.
459+
460+This is also one of the best ways to build stuff correctly. Very often, you will be tempted to cut a corner, and someone will point out that it should be done correctly. You should consider why you immediately rejected it. Was it because you were afraid of the relevant piece of code? If so, you should learn more about that code to determine if it's actually a good idea. Did you reject it because you felt it would distract you from working on what you thought was more important?
461+Consider carefully whether this particular piece of technical debt is worth taking on. It's worth 60 seconds of thinking about how you could solve it correctly right now — often it would be quite easy to do correctly and you'd be paying interest on the incorrectness for a long time.
462+
463+
464+
465+### D: Theory
466+
467+The eternal tension between theory and practice must not simply be acknowledged, but dealt with.
468+
469+> D1: Academia is a succubus.
470+
471+The results from academia are useful to take advantage of, but the process of academia is a deadly sin for a project as ambitious as Urbit.
472+
473+Academia usually gets the right answer, but it's slow, and it often cycles through a large number of wrong answers before it gets to the right one. It's also unconcerned with many things that a real project must consider. For example, it's generally more concerned with mathematical simplicity than mechanical simplicity, contradicting A21.
474+
475+> D3: Not being qualified to solve a problem is no reason not to solve it.
476+>
477+> D4: The best way to get the right answer is to try it the wrong way.
478+>
479+> D6: Everyone must regularly alternate between theory and practice.
480+
481+One common failure mode for academia is to get bogged down in optimally solving a particular part of a problem such that it fails to solve the whole problem.
482+
483+There's a sense of "if I don't know how to do it, I must discover the correct answer before I can do it". This will get you the right answer if it terminates, which is the sort of algorithm mathematicians like. Engineers like algorithms that do in fact terminate.
484+
485+The fastest way to build a good system is to build it as well as you know how, then iterate on it. You have to be disciplined about actually iterating over time as you learn about the problem, but often the way to learn more about the problem is to move beyond it and work on adjacent
486+problems. Hindsight is 20/20, so get the problem in your rearview mirror as fast as possible. Then while you're driving somewhere else, you'll see what you should have done. Then turn around and go do it. This only works if you or someone else is willing to go back and fix it
487+(C2).
488+
489+> D2: Never fear math.
490+
491+You can spend years working on a problem that you're able to solve in a few days with the right theoretical grounding. There's no excuse for being ignorant of theory; or rather, being ignorant of theory is an excuse to learn it.
492+
493+Many engineers fear theory the same way they fear a complex piece of code deep in the stack (C1). But they shouldn't, because theory is rarely muddy. The same characteristics that make theory impractical also make it clean and learnable. It's also pretty permanent, so a one-time investment will pay dividends for a long time.
494+
495+Of course, if you look deep down, you may find laziness is what's keeping you from learning theory. If that's the case, you need to decide how much you want to design good software. Because there's no room for laziness (C2).
496+
497+> D5: Practice tells you that things are good or bad; theory tells you why.
498+
499+You can never tell whether a system is good or bad without using it (see discussion on A21). Theory has great explanatory power, but only limited exploratory power. The best it can do is point out areas of the idea maze you haven't explored and suggest correlations between
500+objective properties and your subjective judgment of the quality of the system.
501+
502+However, that explanatory power is indeed powerful, and the exploratory suggestions are often able to break you out of a rut (attractor basin). Respect the tension.
503+
504+
505+
506+### E: Text Style
507+
508+Code form matters. Code that is hard to read is hard to maintain. Code that is inconsistently formatted is hard to read, but consistency isn't the end of the story. Some formats are simply hard to read.
509+
510+Formatting also isn't the end of the story. Naming and commenting conventions are even more important to clarity. The human brain is quite good at taking stuff that's in an unexpected form and interpreting it.
511+
512+This is why the diversity of accents and handwriting rarely causes issues, while the diversity of languages requires specialized translators. For someone used to typing on a QWERTY keyboard, it takes some time to get used to typing on a Dvorak keyboard because you have to rewrite your muscle memory. But it's nothing like how hard it is to learn another language. Russian script is roughly as different from English script as Russian grammar is from English's, but it's drastically easier to learn to read, handwrite, and type Cyrillic than it is to learn Russian grammar.
513+
514+So, uniformity of style is good, but it's not sufficient. The style must be readily readable and writable.
515+
516+### Formatting
517+
518+> E1: No code should extend beyond 80 characters, most within 55.
519+
520+Very wide code is unreadable. Even before you get to the readability threshold, it's useful to keep your code relatively narrow. Too narrow of code, on the other hand, results in too tall of code. What these two have in common is that they make it hard to navigate the code.
521+
522+Code navigability is the ability to find the part of the code you're looking for. This has several inputs:
523+
524+- how far away is what you're looking for?
525+- how many distinct places in the code can you have on screen?
526+- how much code can you have on screen?
527+- how fast can you recognize that you're in the correct place?
528+
529+Some of these are strongly affected by workflows. We can't force a developer to have an effective workflow, but we can support those who do. If your workflow is deficient in one of these areas, consider improving it.
530+
531+One of the primary inputs to code navigability is how much of it you can have on your screen. Code that is too wide limits the number of columns of code. Some people keep only one column on their screen, so they don't see a problem with long lines of code. The most efficient navigation is to already be there (i.e. to only have to move your eyes). If you only have one column of code open, you can only be in one place, which eliminates the best form of navigation.
532+
533+Dually, code that is too narrow limits the number of lines you can have on a screen (this isn't a separate precept simply because we've never had to tell someone to write _wider_ code). This suggests there is some happy medium. This is dependent on the language, but in Hoon we've
534+found that up to 55 columns is a pretty good number for most code. However, there are plenty of legitimate reasons to go a bit longer than that. 70 columns is rare, but not surprising. There is essentially never a reason to extend beyond 80 columns.
535+
536+> E2: Tabs aren't real.
537+
538+Code is a text file, and text files are WYSIWYG. The reader should view the file exactly the same as the author wrote it. This is a low-overhead way of avoiding editor-dependence in code, which is as bad as browser-dependence in javascript. Sure, tabs aren't as big a deal as the hell that front-end devs have to deal with, but there's no reason to give an inch to the forces of platform-dependence.
539+
540+Some argue in favor of "customization". Customization is inconsistency.
541+There can be good reason for inconsistency in some areas, but not in
542+code formatting, which is such an intensely communicative action.
543+
544+> E3: A text file is a series of lines, each ending with a newline
545+
546+ character.
547+
548+There are several competing definitions of text files, but most commonly-used software uses this one. It's simple and consistent.
549+
550+Its disadvantage relative to "a text files is a series of characters, possibly including newlines" is that there are some arrangements of characters that are not valid text files (ie non-empty and not ending in a newline). However, some series of characters were already not valid
551+in a text file — eg those including control characters or other nonrepresentable characters.
552+
553+In return, we get the advantage that we can treat a text file as having a more complex and useful structure — a list of lists of characters, rather than simply a list of characters.
554+
555+These are theoretical concerns — the real answer is that it's the way it's always been done, and deviating from that without a good reason is asking for trouble.
556+
557+### Names and comments
558+
559+> E4: One block comment is better than interleaved comments on every line.
560+
561+Interleaved comments are easy to write because you can just paraphrase the code. This is also why they're generally useless. In the micro, code should always be immediately understandable. In the macro, it's often helpful to give context as to the purpose or constraints of the function. Sometimes it's good to even give the algorithm line-by-line in pseudocode, but mixing the pseudocode with the real code obfuscates both.
562+
563+> E5: Don't name anything you don't have to.
564+
565+> E6: If it's the same thing, give it the same name.
566+
567+It is often said that there are two hard things in computer science: cache invalidation and naming things. This is a good aphorism. As often, someone will respond with "There are two hard things in CS: cache invalidation, naming things, and off-by-one errors". This is a weak
568+joke because off-by-one errors are not hard at all. They're mostly a matter of discipline, and there's a couple of conventions that help. If you're looping on a zero-indexed variable, use `i < num_loops`. If you're looping on a one-indexed variable, use `i <= num_loops`.
569+
570+However, cache invalidation and naming things are genuinely hard because they must be solved ad hoc. There is no one-size-fits-all cache invalidation strategy, and possibly there never will be. Similar for naming. So you must actually comprehend and work within each individual
571+context.
572+
573+You shouldn't solve hard problems if you don't need to, so don't name anything you don't have to. Giving unique names to things is tiring, and it reduces readability. A consistent pattern for naming things makes it easy to keep track of what is what and reduces the number of
574+decisions you must make.
575+
576+Examples:
577+
578+- If the only difference between three things is that they're not the
579+ same, consider naming them `thing-1`, `thing-2`, and `thing-3`.
580+
581+- Use agglutinative morphology. If `a` is to `b` as `c` is to `d`, then
582+ find an affix which describes this distinction (say `-suf`) and rename
583+ them to `a`, `a-suf`, `c`, and `c-suf`.
584+
585+- A corollary of the above is that if one variable represents the "same"
586+ thing with a different type, that type should be the morpheme added.
587+ For example, if `a-set` is a set, then `~(tap in a)` should be called
588+ `a-list`.
589+
590+- Don't abbreviate (E8) — everyone abbreviates differently, and bits are
591+ cheap. If it takes you a long time to type the name, consider (1)
592+ finding a more succinct name (good any time you can do it), (2)
593+ becoming a faster typer, or (3) learning autocomplete tools, such as
594+ snippets.
595+
596+- Especially don't abbreviate or otherwise change the word when adding
597+ affixes. Inflectional morphology is bad in such an ad hoc context as
598+ code.
599+
600+> E7: Humans are good at memorizing.
601+
602+We're really good at memorizing sets of things, like runes. We're also good at inferring structure from patterns. We're bad at memorizing structure in apparently unrelated names, though, and once we see a pattern, we assume it's densely populated.
603+
604+So don't be afraid to use new names for new concepts. If concepts are siblings, they needn't necessarily have a direct connection in their name, but if they're hierarchical, then something should suggest that. This can be syntactic or semantic.
605+
606+
607+
608+### F: Real Software
609+
610+Not all software matters. Or at least, not all software comes within
611+the scope of "Urbit". Urbit cares about "Martian software".
612+
613+> F9: Timeless software is good software.
614+
615+There's different sorts of software. A lot of software is inherently ephemeral, and can really only be run in one place. A SAAS company runs bespoke software on a particular set of servers, and that software has no future. It will never be run on anyone else's servers, and it will eventually stop being run even there. It won't even have any direct descendents. It's a genetic dead end.
616+
617+However, not all software is this way. Urbit is interested in software that can live forever. This is what we call "real" software.
618+
619+This is the most important passage in all that has ever been written
620+about Urbit:
621+
622+> What is Martian code actually like? There are two possibilities.
623+>
624+> One: since Earth code is fifty years old, and Martian code is fifty
625+> million years old, Martian code has been evolving into a big ball of mud
626+> for a million times longer than Earth software. (And two million times
627+> longer than Windows.)
628+>
629+> This hypothesis strikes me as possible, but implausible. Since the _big
630+> ball of mud_ expands indefinitely, Martian code would therefore be so
631+> large and horrible that, despite its underground installed base, the
632+> server room bulged into space like a termite mound, intercepting
633+> low-flying asteroids and stinking up the solar system all the way to
634+> Pluto. Our latest space telescopes would surely have detected this
635+> abominable structure - if not, in fact, collided with it.
636+>
637+> Two: therefore, at some point in Martian history, some abject fsck of a
638+> Martian code-monkey must have said: _fsck_ this entire fscking ball of
639+> mud. For _lo_, its defects cannot be summarized; for they exceed the
640+> global supply of bullet points; for numerous as the fishes in the sea,
641+> like the fishes in the sea they fsck, making more little fscking fishes.
642+> For lo, it is _fscked_, and a big ball of mud. And there is only one thing
643+> to do with it: _obliterate_ the trunk, _fire_ the developers, and hire a
644+> whole new fscking _army_ of Martian code-monkeys to rewrite the _entire
645+> fscking thing_.
646+>
647+> This is such an obvious and essential response to the _big ball of mud_
648+> pattern that, despite the fact that we know nothing about Mars, we can
649+> deduce that it must have happened on Mars. Probably several times.
650+> Probably several hundred. For each of these attempts but the last, of
651+> course, the result was either (a) abject failure, (b) another _big ball
652+> of mud_, or (c) both.
653+>
654+> But the last, by definition, succeeded. This is the crucial inference we
655+> can draw about Mars: since the Martians had 50 million years to try, in
656+> the end they must have succeeded. The result: Martian code, as we know
657+> it today. Not enormous and horrible — _tiny and diamond-perfect_.
658+> Moreover, because it is tiny and diamond-perfect, it is perfectly stable
659+> and never changes or decays. It neither is a _big ball of mud_, nor tends
660+> to become one. It has achieved its final, permanent and excellent state.
661+
662+We don't know that Urbit will achieve this final form, but Urbit is an attempt to make progress in that direction. Any software that isn't a candidate for "tiny and diamond-perfect" is either a prototype or scaffolding.
663+
664+Here's some characteristics of real software:
665+
666+> F1: If it's not deterministic, it isn't real.
667+
668+If you do the same thing twice, your computer should react the same way. This is comforting. This is also what makes it easy to reason about and use effectively. If you're not sure what your computer will do, you'll be afraid of it and act defensively toward it. This inevitably leads to a big ball of mud.
669+
670+Diamonds are extremely hard, and they wear very slowly. A diamond surface will support you every time; a mud surface will shift out from under you exactly when you put weight on it.
671+
672+> F2: If it's centralized, it isn't real.
673+
674+Code that depends on a central authority or has a single point of failure is fundamentally brittle. No authority lasts forever, no company lasts forever, no server lasts forever. Under certain
675+circumstances, bones and the like can be preserved for a long time — but not alive. The remains of buildings sometimes last for thousands of years, but the cities are gone.
676+
677+The only things that last forever in their useful form are big hunks of rock (like the pyramids at Giza) and ideas, through writing and transcription. So, if you depend on the sun existing, this is
678+acceptable. If you depend on a piece of source code to be kept forever, copied and re-copied, you're fine. If you depend on a 20-year-old company existing and being easily accessible, this is brittle.
679+
680+Another way to look at this is to say that anything that wouldn't work on a spaceship is architecturally flawed. Maybe it requires many sequential round-trips to a central server because it doesn't have all the relevant information. See discussion of A7.
681+
682+> F3: If it's owned by someone else, it isn't yours.
683+>
684+> F4: If it's managed by someone else and you can't change who that is, it
685+> isn't yours.
686+>
687+> F5: If it's not yours, it isn't permanent.
688+>
689+> F6: If it's not permanent, it isn't real.
690+
691+Nobody is as aligned with your values as you are. If you don't control the software, then you can't guarantee you'll always have access to it. Whoever does control the software may destroy it, move away, or simply revoke your access to it.
692+
693+Control has some nuance. If it's physically controlled by a company and you can't get your data and the software that makes it useful, you definitely don't have control. If you have physical control of it, you do have control. But if you're hosting the data and software on a commodity cloud server, you still mostly have control of it. Your privacy has been reduced, sure. However, as long as you keep regular backups of the data and software, if the hosting provider disappears you just need to find another host, or host it yourself. Any particular host is likely to disappear, but the situation where _every_ host disappears and you can't even host it yourself is much less likely. Brands are mortal, commodities are not.
694+
695+Some branded hosts allow you to download a zip file of your data. This gives you a little more control over your data, but it's much closer to "no control" than "total control". This is because your online world is data plus code, and without the code that makes it useful, data is only good for scrapbooking. The scrapbook will remind you of the good old days, but you won't be able to live them again.
696+
697+> F16: Sovereignty necessitates understanding.
698+
699+Not everyone cares to understand the software they're using. But if you want to compute sovereignly, you must understand what your computer is doing. If it regularly surprises you, you're not in control of it. You must tame it. The current paradigm is a wild monster which cannot be tamed by mere humans — only megacorporations even attempt to do so, and it's always temporary. So, your software needs to be simple enough that it can be understood.
700+
701+> F10: System modules should be designed to be frozen permanently;
702+> conversely, Urbit consists of that system software which admits of a
703+> Kelvin version.
704+
705+"Kelvin versioning" is a versioning scheme where your current version is a natural number, and new versions count down. Once you hit version 0, no more changes should be necessary.
706+
707+This is the opposite of the usual way of developing software, where there is no defined endpoint. This paradigm suggests that you're building something specific. Most current software builds higher and higher in a vain attempt to reach the heavens, until all available effort is expended just to keep this tower from falling over. Kelvin versioned software cuts away until you reach a strong bedrock. Not every piece of software should have a Kelvin version, but infrastructure should.
708+
709+> F11: The two procedures for achieving timelessness are distillation and
710+> generalization.
711+
712+When building a timeless system, you start by building whatever you need to make it work. Then as you continue on, you may find some of the features are no longer necessary. Often, they're only needed when you're using them for user-facing work, but you've already moved on to building user-facing stuff somewhere else. You don't need the niceties anymore, so you should remove them.
713+
714+Other times, you find that you want something similar to a feature you already have, but not exactly the same. When this happens often enough with the same feature, you may discover what is the essential nature of the feature and what are simply ornaments of the original use of the feature. Then, you can generalize the feature so that each of the desired use cases is well served.
715+
716+> F13: That which cannot be Kelvin-versioned should update fluidly and
717+> automatically.
718+
719+Not everything should be Kelvin versioned. Much user-facing code is in a continual process of discovery, and it must react to changing userbases and their needs. These should update without user interaction. You should be able to turn off your ship for years at a time, then turn it back on. After a few minutes or hours of catching up, you should be ready to go.
720+
721+This means you need upgrade paths to be permanent, and they must not lose information. Anything that stops being able to upgrade is not permanent, since it will succumb to bit rot.
722+
723+> F14: Humans are interactive and temporal; technology is permanent and
724+> exhaustive.
725+
726+This is why the software humans touch directly should not be Kelvin
727+versioned but the infrastructure that makes it work should be.
728+
729+> F7: The way it is isn't always the way it ought to be.
730+
731+You should presume that there's a good reason for why things are done a certain way because what works best tends to win in a market in the long term, but markets are rarely efficient. Markets become more efficient over time, if they become more liquid, and as they become larger. Software is young, the cost of switching technologies is often large, and the space of software paradigms yet to be explored dwarfs those we've exhausted. So don't be surprised if you find ways to improve the situation drastically.
732+
733+> F8: The way it ought to be isn't always the way it is.
734+
735+On the other hand, sometimes the elegant solution just isn't right. The ultimate test of the quality of software is whether it's useful to humans. Humans don't fit nice equations, so the timeless truths of mathematics are often mismatched with human convenience. Never sacrifice real utility for the sake of making the code more elegant.
736+
737+> F12: Standardization is better than perfection.
738+
739+Coordination problems are some of the most difficult. When given a choice between compatibility and improvement, carefully consider whether the problem solved by the improvement is weightier than the problem caused by the incompatibility.
740+
741+> F15: Communities are autonomous.
742+
743+This is both a positive statement and a normative one. Communities are in fact a thing separate from their platform, but sometimes changes in the platform can kill them. That's bad. It's slightly different from freedom of association, since that's a freedom that applies to individuals, not the communities themselves.
744+
745+Communities are the basic building blocks of society. We are each a member of some number of communities, and most power is held by these communities. Some communities coincide with family ties, some with common goals, beliefs, or interests. Some may be freely joined by just showing up — others are nearly impossible to join without having been born into them.
746+
747+Throughout civilization society has had many forms. Governments have ranged from police states to feudal societies to democracies to informal tribes of people. In each of these, the fundamental unit is the community. Humans don't live on their own, and they don't live in one
748+universal society. They are a part of some communities and not of others.
749+
750+Technology shouldn't force us into a single global community. Discoverability isn't an unmitigated good. Most communities should be closed off from each other — that's what makes them a community. This allows them to develop their own ideas and norms. These bleed into
751+other communities and may spread if they provide some benefit.
752+
753+Many technologies today combine us into a single community, or at least a single set of norms. If many communities are hosted by a single entity, there will be pressure from some of those communities toward the entity to pressure other communities to follow certain of their norms.
754+This crosstalk isn't all bad, but there must be an equilibrium. All too often the lines between the communities are so permeable as to be inconsequential. In this case, the communities will converge in a single large community, at the cost of the memetic diversity of the original communities.
755+
756+Technology should mirror human interaction, and humans interact in communities.
content/blog/precepts.mdnew file+341
@@ -0,0 +1,341 @@
1++++
2+title = "Precepts"
3+date = "2020-03-17"
4+description = "Technical maxims that define Urbit's approach to engineering."
5+
6+[extra]
7+author = "Philip Monk"
8+ship = "~wicdev-wisryt"
9+image = "https://media.urbit.org/site/posts/essays/pre-01.jpg"
10++++
11+
12+
13+
14+Urbit is a principled approach to system design and programming, but it's often not obvious what those principles are. We have many specific terms for the different parts of the project: Arvo is the OS, Hoon is the language, Tlon is the company, Azimuth is the identity system, Ames is the network. But the word most associated with the project is "Urbit", and it's not clear what technically it refers to. It's only a small stretch to say that "Urbit" _is_ this set of principles, and that if anybody follows these principles strictly they will create a system that is isomorphic to the Urbit.
15+
16+Some of these are commonly held among many software projects, and some are not. Some are only debatably better than the alternatives, but Urbit exclusively chooses them.
17+
18+We’ll start with a brief description of many principles, then we’ll go into a long-form justification.
19+
20+
21+
22+### A: General Design
23+
24+1. Data is better than code.
25+
26+ Store data in your state, send data over the wire, dispatch based
27+ on data.
28+
29+2. Everything should be CQRS.
30+
31+3. (Almost) Everything should be pubsub.
32+
33+4. A subscriber shouldn't affect a publisher.
34+
35+5. Communication between nodes should be communication between
36+ independent actors.
37+
38+ Each message should do one complete thing, and there shouldn't
39+ need to be a sequence of coupled messages.
40+
41+6. Represent your data as closely as possible to the essential structure
42+ of the problem.
43+
44+7. A client's representation of data should be as close as possible to
45+ that of the server.
46+
47+ This blurs the distinction between client and server. It allows
48+ offline-mode, reduces communication to syncing, and decentralizes.
49+
50+8. When mating different paradigms, build one cleanly on top of the
51+ other.
52+
53+ Never try to make them work on some of the same primitives. Never
54+ abuse one to make the other work. For example, ducts in
55+ themselves are very general - if you want to do pubsub, that can
56+ easily be built on top of ducts, but don't pretend that pubsub is
57+ a _part_ of the duct system.
58+
59+9. Never misuse an abstraction.
60+
61+ An abstraction provides a certain set of tools; use them and only
62+ them.
63+
64+10. Correctness is more important than performance.
65+
66+11. Be simple and uncompromising in defining what's correct; go crazy
67+ with optimizations.
68+
69+ Nock is a great example of this. It contains the character of the
70+ virtual machine, but its asymptotics are bad. Add jets to fix the
71+ asymptotics.
72+
73+ Another example is the ACID nature of Arvo. Arvo is a pure
74+ function f(logs) of its event log, so formally Arvo is just a
75+ function run against an event log. A naive implementation has
76+ very bad asymptotics; processing each new event is O(n) in the
77+ number of historical events. Choose the function g(state,log)
78+ such that f(logs ++ log) = g(f(logs),log). Then, as long as you
79+ keep the state in memory, processing each new event is constant in
80+ the number of previous events. This still requires O(n) restart
81+ from disk, but you can also periodically (and non-blockingly)
82+ write a checkpoint of the state to disk, so that restart from disk
83+ is only linear in the number of events since the last checkpoint.
84+
85+12. Correctness is more important than optimality.
86+
87+13. If you don't completely understand your code and the semantics of
88+ all the code it depends on, your code is wrong.
89+
90+14. Deterministic beats heuristic.
91+
92+ Heuristics are evil and should only be used where determinism is
93+ infeasible, such as in cache reclamation.
94+
95+15. Stateless is better than stateful.
96+
97+16. Explicit state is better than implicit state.
98+
99+17. Referential transparency is honesty and stability.
100+
101+ Lack of referential transparency and other forms of
102+ disingenuousness are some of the world's big problems. Only
103+ deviate from referential transparency if absolutely necessary.
104+
105+18. Responsibilities should be clearly separated.
106+
107+ This applies from kernel modules through network citizens.
108+
109+19. Dualities must be faced head-on and analyzed differently at
110+ different layers.
111+
112+ Statically typed vs. dynamically typed, imperative vs. functional,
113+ code vs. data, and effectful vs. pure can all be a matter of
114+ perspective, and all relevant perspectives must have coherent
115+ answers.
116+
117+20. One hundred lines of simplicity is better than twenty lines of
118+ complexity.
119+
120+ It's not enough for an abstraction to reduce code duplication; it
121+ must actually make the code simpler.
122+
123+21. Prefer mechanical simplicity to mathematical simplicity.
124+
125+ Often mechanical simplicity and mathematical simplicity go
126+ together.
127+
128+22. The Law of Leaky Abstractions is a lie; abstract airtightly.
129+
130+ If your abstractions are leaking, it's not due to some law of the
131+ universe; you just suck at abstracting. Usually, you didn't
132+ specify the abstraction narrowly enough.
133+
134+23. Some cliches are repeated because they are true; others must be
135+ repeated because they are not.
136+
137+
138+
139+### B: Specific Design
140+
141+1. Always ack a dupe; never ack an ack.
142+
143+ It's okay to ack a nack as long as you never nack a nack.
144+
145+2. Never construct or deconstruct a duct.
146+
147+3. Route on wire before sign, never sign before wire.
148+
149+4. Only go from statically typed to dynamically typed if you must.
150+
151+ Once you go into a dynamically typed world, it's hard to go back.
152+ Statically typed is better than dynamically typed, so if something
153+ can be made static, it should be.
154+
155+ Each timeless data structure is a brick in the foundation of
156+ digital civilization.
157+
158+5. Anything with business logic speaks one paradigm; anything that
159+ translates paradigms has no business logic.
160+
161+6. Functionally enforced semantic rules are better security primitives
162+ than memory access restrictions.
163+
164+ A compiler can use type safety as an effective tool to enforce
165+ some classes of security guarantees.
166+
167+
168+
169+### C: Attitude
170+
171+1. Code courageously.
172+
173+ If you avoid changing a section of code for fear of awakening the
174+ demons therein, you are living in fear. If you stay in the
175+ comfortable confines of the small section of the code you wrote or
176+ know well, you will never write legendary code. All code was
177+ written by humans and can be mastered by humans.
178+
179+ It's natural to feel fear of code; however, you must act as though
180+ you are able to master and change any part of it. To code
181+ courageously is to walk into any abyss, bring light, and make it
182+ right.
183+
184+2. No time for lazy people.
185+
186+ If there's clearly a right way to do something and a wrong way, do
187+ it the right way. Coding requires incredible discipline. Always
188+ follow conventions, and fire anyone who won't. Anything that can
189+ be solved by discipline is not a real problem.
190+
191+ > "To him who knows to do good and does not do it, to him it is
192+ > sin."
193+
194+3. When a smart person makes an obviously stupid suggestion, before
195+ responding take a full 60 seconds to envision how you would implement
196+ it and what the effects would be.
197+
198+
199+
200+### D: Theory
201+
202+1. Academia is a succubus.
203+
204+ Academia has a really high ratio of smart people to useful
205+ products. Academia has many genuinely smart and interesting
206+ ideas, but always remember that pursuing them whole-heartedly will
207+ never result in a useful product.
208+
209+2. Never fear math.
210+
211+ Academia is inefficient, but it's also correct. Those people
212+ wasted a lot of time finding the right answer, but now that
213+ they've done it, you must exploit it. If you don't know the
214+ theory, learn it. No excuse for being "bad at math". Most who
215+ are "bad at math" are simply lazy or fearful. Be strong and of
216+ good courage. If you're truly so bad at math that you cannot
217+ learn it, you should not design systems.
218+
219+3. Not being qualified to solve a problem is no reason not to solve it.
220+
221+ If you don't know how to do it, do it anyway. "We are too young
222+ to realize that certain things are impossible. So, we will do
223+ them anyway."
224+
225+4. The best way to get the right answer is to try it the wrong way.
226+
227+ You cannot design a good system without spending most of your time
228+ in contact with the problem. The bad parts about systems are
229+ rarely obvious in theory, but often in practice.
230+
231+5. Practice tells you that things are good or bad; theory tells you why.
232+
233+ Never use theory to design a good system from scratch; only
234+ practice can tell whether the system is good.
235+
236+6. Everyone must regularly alternate between theory and practice.
237+
238+ There is an eternal wheel of system design. Given a system, use
239+ practice to discover what is bad, missing, or unnecessary. Then,
240+ use theory to fix the bad, add the missing, and remove the
241+ unnecessary. Repeat.
242+
243+
244+
245+### E: Text Style
246+
247+1. No code should extend beyond 80 characters, most within 55.
248+
249+2. Tabs aren't real.
250+
251+3. A text file is a series of lines, each ending with a newline
252+ character.
253+
254+ Corollary: all non-empty text files end with a newline (often
255+ hidden by editors). An empty text file does not end with a
256+ newline.
257+
258+4. One block comment is better than interleaved comments on every line.
259+
260+5. Don't name anything you don't have to.
261+
262+ This includes conventional names for variables of particular
263+ types. For example, the conventional name for a variable of type
264+ `path` is `pax`. You should have a good reason for using any
265+ other name for a `path`.
266+
267+ A more recent convention that follows the same principle is to
268+ give the variable the same name as its type.
269+
270+6. If it's the same thing, give it the same name.
271+
272+7. Humans are good at memorizing.
273+
274+8. Abbreviations aren't worth it.
275+
276+
277+
278+### F: Real Software
279+
280+1. If it's not deterministic, it isn't real.
281+
282+2. If it's centralized, it isn't real.
283+
284+3. If it's owned by someone else, it isn't yours.
285+
286+4. If it's managed by someone else and you can't change who that is, it
287+ isn't yours.
288+
289+5. If it's not yours, it isn't permanent.
290+
291+6. If it's not permanent, it isn't real.
292+
293+7. The way it is isn't always the way it ought to be.
294+
295+ If you can make it the way it ought to be, do so.
296+
297+8. The way it ought to be isn't always the way it is.
298+
299+ Some things can't be made more elegant.
300+
301+ For every ailment under the sun
302+ There is a remedy, or there is none;
303+ If there be one, try to find it;
304+ If there be none, never mind it.
305+
306+9. Timeless software is good software.
307+
308+10. System modules should be designed to be frozen permanently;
309+ conversely, Urbit consists of that system software which admits of a
310+ Kelvin version.
311+
312+11. The two procedures for achieving timelessness are distillation and
313+ generalization.
314+
315+ Every temporary or contingent feature in a system module should
316+ eventually either be removed (distillation) or relaxed into
317+ timelessness (generalization). For an example of the result of
318+ both procedures, consider the abstraction of the core in Nock and
319+ Hoon.
320+
321+12. Standardization is better than perfection.
322+
323+ Kelvin versioning stops when we run out of versions, not when
324+ every defect has been rectified.
325+
326+13. That which cannot be Kelvin-versioned should update fluidly and
327+ automatically.
328+
329+ All incompatible upgrades should provide permanent and automatic
330+ upgrade paths. This is principled permanent backward
331+ compatibility.
332+
333+14. Humans are interactive and temporal; technology is permanent and
334+ exhaustive.
335+
336+15. Communities are autonomous.
337+
338+16. Sovereignty necessitates understanding.
339+
340+ If you don't understand a system you're using, you don't control
341+ it. If nobody understands the system, the system is in control.
content/blog/providers.mdnew file+82
@@ -0,0 +1,82 @@
1++++
2+title = "Providers"
3+date = "2020-08-17"
4+description = "We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works."
5+
6+[extra]
7+author = "Galen Wolfe-Pauly"
8+ship = "~ravmel-ropdyl"
9+image = "https://storage.googleapis.com/media.urbit.org/site/posts/essays/providers.png"
10++++
11+
12+
13+
14+We look forward to a future where your Urbit is an always-on, always-available service. You should be able to pick up any device and conjure up your whole digital life immediately.
15+
16+Sounds good—but how does this actually come to pass? Urbit has to be technically robust and have a nice interface. Assuming we can deliver both of those things, your Urbit node also has to be safe, secure, and running somewhere with a network connection.
17+
18+Urbit has been getting nicer to use and more stable every day. We use it constantly, both as a company (Tlon) and for the broader Urbit community. From what we can tell, people are using Urbit to start communities of their own here and there. The problem is: to use our platform, you’ve got to run it yourself. This limits our audience _a lot_. Setting up a VPS and running an Urbit OS node is pretty easy if you’re comfortable in the command line, which makes it completely impossible for most people.
19+
20+We hear from people regularly who want to be able to sign up for Urbit like it was any cloud service. What they want is what we’ve been calling a _provider_: a service to provide easy onboarding and hosting. Given a good provider, we’d be pretty close to our long-term vision: Urbit would feel like a ubiquitous, easily accessible service.
21+
22+We’ve always assumed that providers would have to come into existence sooner or later. By the look of it, that time is now. Tlon and a few others have provider-like services in the works. We’ll talk about the specifics of what Tlon is planning to do in a future post. In this one, we’ll talk about what a provider is, why anyone would start one, and give a few examples of what they might look like.
23+
24+## What is a provider?
25+
26+A provider is anyone (company, DAO, a group of friends) that provides easy onboarding and hosting.
27+
28+From a user perspective, signing up with a provider should be as simple as picking a planet and hosting plan, paying, and getting connected to a running Urbit OS node. This should be able to be done entirely in a browser or a standalone app and feel more or less like signing up for a conventional service.
29+
30+From a technical perspective, this means a provider needs to create an Ethereum wallet for the user (client-side, of course), deliver an Urbit ID to it, and boot an Urbit OS node for them. And, at some point in the process, collect payment.
31+
32+As a user, your provider is somewhere between your ISP and your WordPress host. Your provider both runs the star that sponsors your planet (and provides peer discovery) as well as potentially providing both access to communities and even provider-specific software. We don’t really expect providers to be terribly generic—quite the opposite. Providers are likely to differentiate themselves on price, available software, and available communities. We’ll get into some examples later.
33+
34+The utility that a provider offers involves quite a lot of trust on behalf of the user. While the provider never actually holds the keys to your Urbit ID, they do run your node and, in turn, can access its contents. Unlike giant cloud services, your data isn’t in an easily searchable database. Inspecting your data should be something explicitly protected by a good provider ToS.
35+
36+If a strongly worded ToS isn’t enough for you, you can always host yourself. And, given the way Urbit works, downloading your Urbit from a provider and running it elsewhere should be both really simple and something a provider will _always_ let you do. It’s perfectly fine to run Urbit in your closet—which means that providers are really competing on ease of use and price.
37+
38+Let’s move on and talk a bit about why starting a provider makes sense to begin with.
39+
40+## Why would anyone start a provider?
41+
42+Our aim is to make Urbit OS so obviously nice to use that it’s well worth paying for. Today, a planet goes for about $10–$20 and, once you buy one, you’ve got to figure out how to really put it to use. Which takes some work.
43+
44+Any large holder of address space should immediately see the opportunity here: the more useful Urbit is, the more value can be captured by starting a provider. Providers make it possible to actually capture the value in address space, both by selling it and by operating nodes.
45+
46+Let’s say the base cost of running an Urbit OS node, in a hosted environment, is $10 / node / month. If you can sell hosting for $200 / year, you’re making back the ‘cost’ of the planet when someone signs up. Given that it’s more desirable to buy a planet when you know the star is online and you can put it to good use, this seems like a pretty good proposition: both for the provider and the customer.
47+
48+Starting a provider doesn’t _have_ to be done by address-space holders. You could start a provider with no address space of your own by custodying the address space of others. Then, you could take a cut of the address space sales and all of the hosting revenue. With a market of people looking to use Urbit, the crux of success with this approach is simply whether you can compete on user experience.
49+
50+Providers are, in a way, like the miners of Urbit. They’re incentivized to run fleets of very specific VMs for profit. The profit motive, in Urbit’s case, is just a bit more conventional than a bitcoin miner. An Urbit provider is just offering a service in exchange for money.
51+
52+## What are some examples of providers?
53+
54+If you think of a provider simply as a business, its most basic incentive is to attract as many customers as possible. You can do that by competing on price or performance, or by competing on aesthetics and community—there are lots of ways that providers can compete.
55+
56+As a roughly similar ecosystem, the world of webhosting is a great comparison. There are lots of small webhosts that all have very specific services: Dreamhost, MediaTemple, prgmr.com, and Linode all come to mind. Then there are the more generic, large-scale, performance-oriented options: AWS, GCP, Azure. It’s not quite time for an AWS-scale Urbit provider, but perhaps the AWS of Urbit will start as something much smaller.
57+
58+Let’s walk through a few examples to get a feel for what’s possible:
59+
60+Communities -
61+
62+A provider could easily curate community content like news, events, and discussion that it only delivers to its customers. Think of it as a bit like the days of sharing a server among friends—only in this case it could be hundreds or thousands of people who form a collective to run infrastructure and share information.
63+
64+Custom software -
65+
66+There are so many ways that providers can offer custom software. Urbit isn’t ready for third party software distribution. When it is, subscribers to a specific provider could get unique modules and applications synced directly to their Urbit nodes along with their membership.
67+
68+Aside from Urbit-specific software, providers could provide custom software services to their subscribers. A straightforward example of this could come in the form of Bitcoin or Ethereum nodes for processing transactions. Sign up with a provider and get the ability to send transactions to the chain quickly and reliably.
69+
70+Security -
71+
72+Let’s say our base cost of $10 / month / planet from above is correct (it’s probably high, but it’s a simple number). Would someone pay $100 / month for a planet hosted in a bunker or in the pylon of an abandoned oil rig? Maybe.
73+
74+## What about Tlon?
75+
76+Before there can be an ecosystem of providers, there has to be _one_ provider. While we’ve heard of a few other people working on things, we expect Tlon to be the first to try to really get into the provider business in earnest.
77+
78+I’ll save the details of what we’re going to do for a future post. Launching Tlon as a separate business will be the beginning of the separation of Tlon and Urbit. I’m really quite excited about it. Tlon is only able to consider becoming a business of its own because Urbit is mature enough that we can actually do it.
79+
80+For now, I’ll just say that Tlon will pick the low-hanging fruit first. Our goal is to make onboarding a group into Urbit incredibly simple. We want people to be able to go from email invite to running Urbit in a few minutes without ever knowing anything about Ethereum, Unix, or what a private key is.
81+
82+Once we’ve laid the groundwork with something that _just works_, we plan to open-source some of our components. Scaling up Urbit isn’t going to be easy. We hope that others will help us, and will help explore what’s possible in supporting Urbit users in the future.
content/blog/pseudonymous-reputation.mdnew file+64
@@ -0,0 +1,64 @@
1++++
2+title = "Building Your DAO with Pseudonymous Reputation on Urbit"
3+date = "2022-07-19"
4+description = "Using Urbit ID’s pseudonymous reputation model, DAO participants know Urbit ID holders’ past behavior before relying on them, and without sacrificing anonymity."
5+
6+[extra]
7+author = "Anthony Arroyo"
8+ship = "~poldec-tonteg"
9+image = "https://storage.googleapis.com/media.urbit.org/blog/2022.7.14..19.19.05-image.jpg"
10++++
11+
12+
13+
14+_This is cross-posted from [The Combine DAO Blog](https://blog.the-combine.org). If you'd like to comment, join the public [Urbit group](https://urbit.org/groups/~famreb-todmec/the-combine-public)._
15+
16+[The Combine DAO](https://blog.the-combine.org/introduction-to-the-combine-dao) is a DAO built on Urbit to invest in promising projects on the network. While building the DAO, we did a survey of the existing identity solutions and found our solution close to home: Urbit ID provided the best balance of trust and anonymity due to the Urbit networks’ pseudonymous reputation. In this post, we’ll discuss the challenges facing DAOs and discuss why Urbit ID presents advantages over current approaches like token gated DAOs.
17+
18+## Trust, Anonymity and Pseudonymous Reputation
19+
20+Anonymity is a core feature of most DAOs. It’s great in theory. No one wants to trust that the humans operating Robinhood will execute trades how and when they say they will (much less know their names.) We’d all prefer if a smart contract handled it for them.
21+
22+The problem is that trust and anonymity don’t mix, and trust is essential to the practical operation of any organization. This is why existing DAOs take shortcuts to establish trust hierarchies—things like delegating multi-sigs to small groups of trusted leaders, or trusted leaders establishing authority via exclusive Discord channels.
23+
24+Put simply, if there’s no human to trust, there’s no human to hold accountable. Lack of accountability is a major hurdle for any organization.
25+
26+We were aware of this fundamental flaw when building Combine DAO on Urbit, and we’ve found a solution in Urbit ID. Urbit ID is the decentralized identity system at the core of the Urbit project. Urbit IDs are the “decentralized IDs” that [DAO builders yearn](https://thmueller.medium.com/decentralized-identity-3-ways-to-build-trust-in-your-dao-4871491903c8) for. They’re endowed with what we call pseudonymous reputations that unlock the ability to run DAOs in ways that more closely resemble successful IRL organizations, while maintaining the automation that makes them so attractive.
27+
28+## What is Urbit ID?
29+
30+Why is your Urbit ID so different from every other online identity you’ve ever had? The substantive answer is simple: it’s a lot more like your IRL identity. It’s permanent and owned by you. And because it’s the same throughout the Urbit network, it can accrue a reputation.
31+
32+You’ve probably seen Urbit IDs like `~ravmel-ropdyl` or `~mogmet-tadnem` in Twitter profiles. Each is a unique NFT that can be transferred and sold like any other cryptographic asset. Your Urbit ID is your username, network address and crypto wallet all in one.
33+
34+Like wallet addresses, Urbit IDs are anonymous. Like Discord, Twitter, or Notion accounts, they are also pseudonymous. Pseudonymity is the kind of anonymity you find in most online communities: a common username that people recognize even if it’s not your “real” name.
35+
36+Your Urbit ID is to your urbit ship what your deed is to your house or your keys to your car. It encrypts all of your ship’s communications and provides access to your online communities, which in this instance are DAOs.
37+
38+Using Urbit ID’s pseudonymous reputation model, DAO participants know Urbit ID holders’ past behavior before relying on them, and without sacrificing anonymity. Why do reputations stick to Urbit IDs? Because, like your physical person, every action you take with your Urbit ID affects your reputation. Urbit maximalists often ask “How high of a ransom would you pay if your Urbit ID were ‘kidnapped?’” That’s because the reputation of your Urbit ID is the result of years of labor. Imagine every social account you’ve ever had in one immutable chain tied to one immutable pseudonym.
39+
40+Thus, unlike an anonymous wallet address, Twitter handles or Discord accounts, there are high incentives for keeping your Urbit ID’s reputation squeaky clean.
41+
42+## Urbit ID for DAOs
43+
44+Many DAOs gate their membership on the ownership of a cryptographic asset like an ERC-721 or an ERC-20 token. Token gating is used to create a flat, anonymous membership. This was initially seen as a good thing. “One member, one voice.” All decisions made anonymously via multi-sigs and voting apps secured via smart contract.
45+
46+Token gating also adds utility to NFTs; it unlocks access to perks like special releases or events apart from the core asset. To get into the Milady Rave you need to buy a Milady NFT. It doesn’t matter who you are, what you’ve done, or how capable you are of participating in the community’s goals, if you buy a Milady, you’re in. You have the same rights and privileges as everyone else.
47+
48+In reality, many DAOs move inexorably back towards a more conventional model of “human trust” simply because organization requires it. That’s why DAO builders have long sought “decentralized IDs” for members. “One member, one voice” doesn’t work for complex, efficient decision making; it risks chaos and endless discussion. It creates the need for offchain governance executed by smaller groups, which is cumbersome, requires a patchwork of Web2 apps (i.e. Google and Notion), and undermines the “trustless” nature of the DAO.
49+
50+To return to a prior example, imagine Robinhood was a DAO of its members. If it was run like DAOs today—e.g. those not built on Urbit—a group of Robinhood “elites” make and execute trade decisions via private Discord channels. DAO members vote to approve, but participation is low. Some DAOs even cold-call members to garner participation. Not only is participation low, it’s also low quality: banter about the issues of the day.
51+
52+Urbit ID mitigates membership participation issues by adding permanent, pseudonymous reputations to the mix. As in: Who are you letting into your DAO? And whose DAO are you joining?
53+
54+As a leader of an organization, you want high quality members. You want to avoid Dumb Money: people passively investing in your DAO because it’s cool, but without the ability to add value. You also want to avoid oversubscription/underparticipation: a dropoff in engagement from most members as they become interested in newer, shinier things.
55+
56+When it came time to recruit members for Combine DAO, we didn’t have to leave Urbit. We only considered those with strong pseudonymous reputations on the network, many of whom were anonymous outside of Urbit. Some of the Urbit IDs in Combine DAO like `~bitmep-faswyn` have been on the network for years. Some like `~timluc-miptev` have created valuable groups and built companies on Urbit. Selection blindness was both unneeded and unnecessary—members were selected not in spite of “who” they were on Urbit, but because of it.
57+
58+Pseudonymous reputations also allow prospective DAO members to better evaluate leaders. Urbit ID reputations subsume the need for patchworks of authority. You know exactly “who” `~mogmet-tadnem` is. You don’t need to google his Twitter handle and figure out, oh maybe he’s also the guy behind this or that DAO or NFT release. Leaders benefit from the past and are held accountable for future actions.
59+
60+Now, the organizing forces behind Combine DAO are `~poldec-tonteg` and `~wolref-podlex`. In this case, their real world identities are known to many, but they needn’t be: their actions on the network speak for themselves. `~poldec-tonteg` is the former CPO of Tlon and `~wolref-podlex` is the Executive Director of the Urbit Foundation. Prospective members of Combine DAO know who they are aligning themselves with.
61+
62+To sum it up, Urbit ID is a solution for the reputational problems faced by DAOs in their current form. While good in theory, the trustless nature of DAOs leads to practical issues around organization, leadership, membership, voting, and participation. This is why DAO builders need ways to give their membership durable reputations that can travel with the members as they participate.
63+
64+Urbit offers just such cryptographic identities with portable reputations in the form of Urbit IDs. We put pseudonymous reputations to the test in building Combine DAO, and discovered they enhanced leadership formation and membership curation, eliminating some of the organizational problems that DAOs struggle with today.
content/blog/rollups.mdnew file+222
This diff is too big to show here.
content/blog/security-and-continuity.mdnew file+60
This diff is too big to show here.
content/blog/security-audit.mdnew file+153
This diff is too big to show here.
content/blog/simple-durable-yours.mdnew file+48
This diff is too big to show here.
content/blog/smart-home-of-the-future.mdnew file+60
This diff is too big to show here.
content/blog/stable-arvo.mdnew file+93
This diff is too big to show here.
content/blog/state-of-urbit.mdnew file+95
This diff is too big to show here.
content/blog/the-100-year-computer.mdnew file+30
This diff is too big to show here.
content/blog/the-dao-as-a-lesson-in-decentralized-governance.mdnew file+327
This diff is too big to show here.
content/blog/the-missing-middle.mdnew file+50
This diff is too big to show here.
content/blog/the-shape-of-dao-governance-to-come.mdnew file+103
This diff is too big to show here.
content/blog/the-state-of-landscape.mdnew file+78
This diff is too big to show here.
content/blog/the-understanding-urbit-podcast.mdnew file+22
This diff is too big to show here.
content/blog/the-urbit-address-space.mdnew file+299
This diff is too big to show here.
content/blog/tools-of-our-own.mdnew file+66
This diff is too big to show here.
content/blog/toward-a-frozen-operating-system.mdnew file+260
This diff is too big to show here.
content/blog/toward-a-new-clay.mdnew file+1012
This diff is too big to show here.
content/blog/urbit-and-bitcoin.mdnew file+21
This diff is too big to show here.
content/blog/urbit-and-the-blockchain.mdnew file+272
This diff is too big to show here.
content/blog/urbit-creator-daos.mdnew file+74
This diff is too big to show here.
content/blog/urbit-for-creators.mdnew file+47
This diff is too big to show here.
content/blog/urbit-for-normies.mdnew file+175
This diff is too big to show here.
content/blog/urbit-grants-and-mid-2019-gifts.mdnew file+49
This diff is too big to show here.
content/blog/urbit-is-for-communities.mdnew file+92
This diff is too big to show here.
content/blog/urbithost-interview.mdnew file+116
This diff is too big to show here.
content/blog/using-urbit-in-2023.mdnew file+55
This diff is too big to show here.
content/blog/value-of-address-space-pt1.mdnew file+144
This diff is too big to show here.
content/blog/value-of-address-space-pt2.mdnew file+141
This diff is too big to show here.
content/blog/value-of-address-space-pt3.mdnew file+117
This diff is too big to show here.
content/blog/what-is-urbit-for.mdnew file+196
This diff is too big to show here.
hoon/overview.md → content/blog/why-hoon.mdrenamed+18−20
This diff is too big to show here.
content/blog/why-urbit-probably-does-not-need-a-blockchain.mdnew file+623
This diff is too big to show here.
content/blog/your-last-computer.mdnew file+36
This diff is too big to show here.
content/bounties.mdnew file+54
This diff is too big to show here.
content/campus/_index.mdnew file+37
This diff is too big to show here.
content/campus/blockchain-enthusiasts.mdnew file+35
This diff is too big to show here.
content/campus/creatives.mdnew file+21
This diff is too big to show here.
content/coinmarketcap.mdnew file+8
This diff is too big to show here.
content/communities/urbit-austin.mdnew file+11
This diff is too big to show here.
content/communities/urbit-berlin.mdnew file+16
This diff is too big to show here.
content/communities/urbit-christchurch.mdnew file+13
This diff is too big to show here.
content/communities/urbit-cph.mdnew file+11
This diff is too big to show here.
content/communities/urbit-dc.mdnew file+19
This diff is too big to show here.
content/communities/urbit-denver.mdnew file+19
This diff is too big to show here.
content/communities/urbit-london.mdnew file+15
This diff is too big to show here.
content/communities/urbit-mst.mdnew file+13
This diff is too big to show here.
content/communities/urbit-ny.mdnew file+11
This diff is too big to show here.
content/communities/urbit-paris.mdnew file+23
This diff is too big to show here.
content/communities/urbit-seattle.mdnew file+14
This diff is too big to show here.
content/communities/urbit-sf.mdnew file+15
This diff is too big to show here.
content/ecosystem/spotlight/2022-august.mdnew file+44
This diff is too big to show here.
content/ecosystem/spotlight/2022-december.mdnew file+40
This diff is too big to show here.
content/ecosystem/spotlight/2022-november.mdnew file+42
This diff is too big to show here.
content/ecosystem/spotlight/2022-october.mdnew file+41
This diff is too big to show here.
content/ecosystem/spotlight/2022-september.mdnew file+45
This diff is too big to show here.
content/ecosystem/spotlight/2023-february.mdnew file+48
This diff is too big to show here.
content/ecosystem/spotlight/2023-june.mdnew file+40
This diff is too big to show here.
content/ecosystem/spotlight/2023-may.mdnew file+50
This diff is too big to show here.
content/events/2017-08-11-after-hours-bootstrapping-urbit-from-the-ethereum-blockchain.mdnew file+21
This diff is too big to show here.
content/events/2017-09-22-after-hours-fun-with-arvo-the-urbit-os.mdnew file+20
This diff is too big to show here.
content/events/2017-10-26-after-hours-designing-robust-human-systems.mdnew file+20
This diff is too big to show here.
content/events/2017-11-16-after-hours-visiting-contributors.mdnew file+17
This diff is too big to show here.
content/events/2018-01-26-urbit-irl-20181.mdnew file+18
This diff is too big to show here.
content/events/2018-02-23-urbit-irl-20182.mdnew file+18
This diff is too big to show here.
content/events/2018-03-11-20183-hoon-school.mdnew file+16
This diff is too big to show here.
content/events/2018-03-23-urbit-irl-20183.mdnew file+18
This diff is too big to show here.
content/events/2018-04-08-20184-hoon-school.mdnew file+16
This diff is too big to show here.
content/events/2018-05-25-urbit-irl-20185.mdnew file+18
This diff is too big to show here.
content/events/2018-08-03-after-hours-decentralized-web-summit.mdnew file+14
This diff is too big to show here.
content/events/2018-08-17-urbit-irl-20188.mdnew file+20
This diff is too big to show here.
content/events/2018-09-21-urbit-irl-20189.mdnew file+18
This diff is too big to show here.
content/events/2018-10-10-urbit-zcash-blockchain-week.mdnew file+24
This diff is too big to show here.
content/events/2018-12-20-after-hours-its-just-a-party-man.mdnew file+18
This diff is too big to show here.
content/events/2019-03-01-after-hours-ask-galen-anything.mdnew file+20
This diff is too big to show here.
content/events/2019-03-08-urbit-irl-austin-tx.mdnew file+16
This diff is too big to show here.
content/events/2019-04-19-urbit-irl-20194.mdnew file+20
This diff is too big to show here.
content/events/2019-05-17-urbit-irl-20195.mdnew file+18
This diff is too big to show here.
content/events/2019-06-21-urbit-irl-20196.mdnew file+18
This diff is too big to show here.
content/events/2019-07-19-urbit-irl-20197.mdnew file+20
This diff is too big to show here.
content/events/2019-08-29-urbit-austin-20198.mdnew file+18
This diff is too big to show here.
content/events/2019-10-04-urbit-irl-201910.mdnew file+20
This diff is too big to show here.
content/events/2019-11-15-urbit-irl-201911.mdnew file+20
This diff is too big to show here.
content/events/2019-12-13-urbit-irl-201912.mdnew file+28
This diff is too big to show here.
content/events/2020-01-24-urbit-irl-20201.mdnew file+24
This diff is too big to show here.
content/events/2020-02-28-urbit-irl-20202.mdnew file+22
This diff is too big to show here.
content/events/2020-04-03-urbit-os1-launch-party.mdnew file+49
This diff is too big to show here.
content/events/2020-10-09-urbit-hosting-launch-event.mdnew file+38
This diff is too big to show here.
content/events/2020-11-05-developer-call-graph-store.mdnew file+24
This diff is too big to show here.
content/events/2020-11-19-developer-call-bittorrent-tracking-on-urbit.mdnew file+22
This diff is too big to show here.
content/events/2020-12-10-developer-call-injecting-external-services-into-urbit.mdnew file+24
This diff is too big to show here.
content/events/2021-02-04-developer-call-architectural-idea-maze.mdnew file+23
This diff is too big to show here.
content/events/2021-03-04-developer-call-scaling-azimuth.mdnew file+25
This diff is too big to show here.
content/events/2021-03-18-developer-call-pressure-and-protolith.mdnew file+25
This diff is too big to show here.
content/events/2021-04-01-developer-call-javascript-apps-on-urbit.mdnew file+25
This diff is too big to show here.
content/events/2021-04-15-developer-call-software-distribution.mdnew file+34
This diff is too big to show here.
content/events/2021-04-27-bitcoin-launch.mdnew file+27
This diff is too big to show here.
content/events/2021-04-29-developer-call-real-time-communications-on-urbit.mdnew file+30
This diff is too big to show here.
content/events/2021-05-13-developer-call-versioned-networking.mdnew file+26
This diff is too big to show here.
content/events/2021-05-27-town-hall.mdnew file+54
This diff is too big to show here.
content/events/2021-07-01-developer-call-runtime-future.mdnew file+25
This diff is too big to show here.
content/events/2021-07-15-developer-call-yakshaving.mdnew file+25
This diff is too big to show here.
content/events/2021-09-02-21q3-dc-meetup.mdnew file+22
This diff is too big to show here.
content/events/2021-09-16-developer-call-azimuth-scaled.mdnew file+46
This diff is too big to show here.
content/events/2021-09-24-urbit-outside.mdnew file+23
This diff is too big to show here.
content/events/2021-10-07-developer-call-visor.mdnew file+38
This diff is too big to show here.
content/events/2021-10-15-assembly.mdnew file+26
This diff is too big to show here.
content/events/2021-10-16-assembly-keynote.mdnew file+14
This diff is too big to show here.
content/events/2021-10-16-assembly-sw-dist-qa.mdnew file+14
This diff is too big to show here.
content/events/2021-10-28-developer-call-hosting.mdnew file+33
This diff is too big to show here.
content/events/2021-11-26-meetup-brisbane.mdnew file+30
This diff is too big to show here.
content/events/2022-01-21-meetup-austin.mdnew file+16
This diff is too big to show here.
content/events/2022-02-17-developer-call-building-developers.mdnew file+27
This diff is too big to show here.
content/events/2022-03-24-developer-call-urbit-three-ways-with-quartus.mdnew file+26
This diff is too big to show here.
content/events/2022-04-05-urbit-meetup-stockholm.mdnew file+30
This diff is too big to show here.
content/events/2022-04-21-developer-call-uqbar-and-urbits-first-blockchain.mdnew file+24
This diff is too big to show here.
content/events/2022-04-26-urbit-foundation-meetup-kingsnight-amsterdam.mdnew file+23
This diff is too big to show here.
content/events/2022-05-06-urbit-weekend-kansas.mdnew file+20
This diff is too big to show here.
content/events/2022-06-16-developer-call-urbits-new-terminal-stack-tlon copy.mdnew file+23
This diff is too big to show here.
content/events/2022-06-16-developer-call-urbits-new-terminal-stack-tlon.mdnew file+24
This diff is too big to show here.
content/events/2022-07-07-hackathon-hackfs.mdnew file+18
This diff is too big to show here.
content/events/2022-07-08-urbit-fireside-chat-1.mdnew file+19
This diff is too big to show here.
content/events/2022-07-21-developer-holium-community-os.mdnew file+25
This diff is too big to show here.
content/events/2022-07-21-ethcc-paris-22-meetup.mdnew file+21
This diff is too big to show here.
content/events/2022-07-22-urbit-outside-alta-plaza.mdnew file+22
This diff is too big to show here.
content/events/2022-07-28-urbit-meetup-milano-22.mdnew file+22
This diff is too big to show here.
content/events/2022-08-04-reassembly.mdnew file+31
This diff is too big to show here.
content/events/2022-08-12-urbit-fireside-chat-2.mdnew file+20
This diff is too big to show here.
content/events/2022-08-27-urbit-outside-alta-plaza.mdnew file+17
This diff is too big to show here.
content/events/2022-09-08-developer-call-future-of-khan.mdnew file+25
This diff is too big to show here.
content/events/2022-09-15-developer-call-IoT.mdnew file+27
This diff is too big to show here.
content/events/2022-09-19-rabbit-hole-talk.mdnew file+19
This diff is too big to show here.
content/events/2022-09-22-assembly.mdnew file+14
This diff is too big to show here.
content/events/2022-10-13-devcon-bogotá-urbit-meetup-22.mdnew file+36
This diff is too big to show here.
content/events/2022-11-01-developer-week.mdnew file+75
This diff is too big to show here.
content/events/2022-11-19-urbit-irl.mdnew file+18
This diff is too big to show here.
content/events/2022-19-10-developer-call-herd-dependency.mdnew file+25
This diff is too big to show here.
content/events/2023-01-28-urbit-meetup-christchurch.mdnew file+21
This diff is too big to show here.
content/events/2023-01-31-urbit-meetup-krakow.mdnew file+26
This diff is too big to show here.
content/events/2023-02-23-urbit-meetup-berlin.mdnew file+27
This diff is too big to show here.
content/events/2023-03-05-meetup-el-salvador.mdnew file+24
This diff is too big to show here.
content/events/2023-03-25-urbit-meetup-christchurch.mdnew file+21
This diff is too big to show here.
content/events/2023-04-18-urbit-lisbon.mdnew file+19
This diff is too big to show here.
content/events/2023-04-27-urbit-meetup-berlin.mdnew file+27
This diff is too big to show here.
content/events/2023-04-27_urbit-austin-meetup-consensus.mdnew file+16
This diff is too big to show here.
content/events/2023-05-10_urbit-meetup-berlin.mdnew file+25
This diff is too big to show here.
content/events/2023-05-14_urbit-meetup-london.mdnew file+23
This diff is too big to show here.
content/events/2023-05-18_urbit-denver-meetup.mdnew file+19
This diff is too big to show here.
content/events/2023-05-18_urbit-miami-meetup.mdnew file+20
This diff is too big to show here.
content/events/2023-05-27_urbit-meetup-london.mdnew file+21
This diff is too big to show here.
content/events/2023-05-27_urbit-meetup-mst.mdnew file+20
This diff is too big to show here.
content/events/2023-06-03-urbit-meetup-christchurch.mdnew file+24
This diff is too big to show here.
content/events/2023-06-08_urbit-meetup-berlin.mdnew file+25
This diff is too big to show here.
content/events/2023-06-08_urbit-meetup-prague.mdnew file+39
This diff is too big to show here.
content/events/2023-06-12-developer-week.mdnew file+95
This diff is too big to show here.
content/events/2023-06-15_urbit-denver-meetup.mdnew file+19
This diff is too big to show here.
content/events/2023-06-24-urbit-meetup-christchurch.mdnew file+24
This diff is too big to show here.
content/events/2023-06-29-Urbit-Paris-Meetup-1.mdnew file+30
This diff is too big to show here.
content/events/2023-07-01_urbit-meetup-mst.mdnew file+23
This diff is too big to show here.
content/events/2023-07-20-Urbit-Paris-Meetup-ethcc.mdnew file+53
This diff is too big to show here.
content/events/2023-08-16_reassembly.mdnew file+22
This diff is too big to show here.
content/events/2023-10-28_urbit-assembly-lisboa.mdnew file+24
This diff is too big to show here.
content/faq.mdnew file+267
This diff is too big to show here.
content/fora.mdnew file+11
This diff is too big to show here.
content/getting-started/_index.mdnew file+28
This diff is too big to show here.
content/getting-started/cli.mdnew file+290
This diff is too big to show here.
content/getting-started/cloud-hosting.mdnew file+468
This diff is too big to show here.
content/getting-started/desktop.mdnew file+11
This diff is too big to show here.
content/getting-started/get-id.mdnew file+113
This diff is too big to show here.
content/getting-started/getting-around.mdnew file+55
This diff is too big to show here.
content/getting-started/home-servers.mdnew file+27
This diff is too big to show here.
content/getting-started/hosted.mdnew file+30
This diff is too big to show here.
content/getting-started/hosting-providers.mdnew file+24
This diff is too big to show here.
content/getting-started/installing-applications.mdnew file+39
This diff is too big to show here.
content/getting-started/interfaces.mdnew file+10
This diff is too big to show here.
content/getting-started/joining-groups.mdnew file+54
This diff is too big to show here.
content/getting-started/self-host.mdnew file+33
This diff is too big to show here.
content/gifts/sample.mdnew file+6
This diff is too big to show here.
content/grants/2019/bitcoin-node-json-rpc-api-part-1.mdnew file+54
This diff is too big to show here.
content/grants/2019/bitcoin-node-json-rpc-api-part-2.mdnew file+54
This diff is too big to show here.
content/grants/2019/bitcoin-node-json-rpc-api-part-3.mdnew file+54
This diff is too big to show here.
content/grants/2019/bitcoin-node-json-rpc-api-part-4.mdnew file+54
This diff is too big to show here.
content/grants/2019/bitcoin-wallet-on-bridge.mdnew file+62
This diff is too big to show here.
content/grants/2019/escape.mdnew file+46
This diff is too big to show here.
content/grants/2019/gall-api-documentation.mdnew file+53
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-1.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-10.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-2.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-3.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-4.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-5.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-6.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-7.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-8.mdnew file+62
This diff is too big to show here.
content/grants/2019/host-two-urbit-meetups-9.mdnew file+62
This diff is too big to show here.
content/grants/2019/ragnarok-online-on-urbit.mdnew file+53
This diff is too big to show here.
content/grants/2019/udon-syntax-highlighter.mdnew file+43
This diff is too big to show here.
content/grants/2019/unit-tests-for-json-parsing.mdnew file+49
This diff is too big to show here.
content/grants/2019/unit-tests-for-pure-algorithms.mdnew file+60
This diff is too big to show here.
content/grants/2019/unit-tests-for-sha-functions.mdnew file+50
This diff is too big to show here.
content/grants/2019/unit-tests-for-zuse-cryptographic-functions.mdnew file+52
This diff is too big to show here.
content/grants/2020/a-book-about-urbit.mdnew file+84
This diff is too big to show here.
content/grants/2020/a-network-enabled-spatial-database-and-demonstration-app.mdnew file+94
This diff is too big to show here.
content/grants/2020/antechamber.mdnew file+106
This diff is too big to show here.
content/grants/2020/art-by-urbit.mdnew file+31
This diff is too big to show here.
content/grants/2020/bart-train-tracker-landscape-tile.mdnew file+50
This diff is too big to show here.
content/grants/2020/bitcoin-full-node-provider-and-wallet.mdnew file+102
This diff is too big to show here.
content/grants/2020/bitcoin-key-derivation.mdnew file+66
This diff is too big to show here.
content/grants/2020/boston-t-train-tracker-landscape-tile.mdnew file+53
This diff is too big to show here.
content/grants/2020/calendar-ui.mdnew file+55
This diff is too big to show here.
content/grants/2020/calendar.mdnew file+115
This diff is too big to show here.
content/grants/2020/content-saver.mdnew file+44
This diff is too big to show here.
content/grants/2020/cta-train-tracker-landscape-tile.mdnew file+52
This diff is too big to show here.
content/grants/2020/display-eth-data.mdnew file+55
This diff is too big to show here.
content/grants/2020/docker-image-for-cloud-container-orchestration.mdnew file+49
This diff is too big to show here.
content/grants/2020/ethereum-abi-parser.mdnew file+56
This diff is too big to show here.
content/grants/2020/go-airlock-library.mdnew file+44
This diff is too big to show here.
content/grants/2020/haskell-airlock-library.mdnew file+43
This diff is too big to show here.
content/grants/2020/hoon-001-learner-efficiency-and-early-learner-resources.mdnew file+78
This diff is too big to show here.
content/grants/2020/host-three-college-university-urbit-meetups-1.mdnew file+67
This diff is too big to show here.
content/grants/2020/host-three-college-university-urbit-meetups-2.mdnew file+67
This diff is too big to show here.
content/grants/2020/host-three-college-university-urbit-meetups-3.mdnew file+67
This diff is too big to show here.
content/grants/2020/host-three-virtual-urbit-meetups.mdnew file+52
This diff is too big to show here.
content/grants/2020/links-in-urbit-reference-docs.mdnew file+31
This diff is too big to show here.
content/grants/2020/llelogram.mdnew file+55
This diff is too big to show here.
content/grants/2020/matrices-in-hoon.mdnew file+58
This diff is too big to show here.
content/grants/2020/matrixriotim-bridge-bot.mdnew file+42
This diff is too big to show here.
content/grants/2020/open-street-maps-data-importation.mdnew file+52
This diff is too big to show here.
content/grants/2020/staff-the-urbit-help-desk-1.mdnew file+64
This diff is too big to show here.
content/grants/2020/staff-the-urbit-help-desk-2.mdnew file+64
This diff is too big to show here.
content/grants/2020/staff-the-urbit-helpdesk-west.mdnew file+58
This diff is too big to show here.
content/grants/2020/the-complete-guide-to-gall-and-landscape.mdnew file+85
This diff is too big to show here.
content/grants/2020/tor-nodes-relay-search-tile.mdnew file+45
This diff is too big to show here.
content/grants/2020/typescript-airlock-library.mdnew file+43
This diff is too big to show here.
content/grants/2020/up-to-date-hoon-reference-card.mdnew file+30
This diff is too big to show here.
content/grants/2020/urbian-a-customized-linux-distribution-for-urbit-appliances.mdnew file+88
This diff is too big to show here.
content/grants/2020/urbit-event-series.mdnew file+92
This diff is too big to show here.
content/grants/2020/urbit-explainer-video.mdnew file+35
This diff is too big to show here.
content/grants/2020/urbit-http-api-for-kotlin.mdnew file+37
This diff is too big to show here.
content/grants/2020/urbit-http-api-for-rust.mdnew file+55
This diff is too big to show here.
content/grants/2020/urbit-http-interface-java-edition.mdnew file+66
This diff is too big to show here.
content/grants/2020/urbit-http-library-for-ruby.mdnew file+42
This diff is too big to show here.
content/grants/2020/urbit-online-meetup.mdnew file+30
This diff is too big to show here.
content/grants/2020/urbit-ship-and-star-hosting-and-troubleshooting-docs.mdnew file+38
This diff is too big to show here.
content/grants/2020/verifying-urbit-id-on-keybase.mdnew file+76
This diff is too big to show here.
content/grants/2020/web-scraper.mdnew file+45
This diff is too big to show here.
content/grants/2021/analytics-script.mdnew file+54
This diff is too big to show here.
content/grants/2021/authenticate-with-urbit.mdnew file+36
This diff is too big to show here.
content/grants/2021/azimuth-cli.mdnew file+164
This diff is too big to show here.
content/grants/2021/bitcoin-wallet-maintenance.mdnew file+65
This diff is too big to show here.
content/grants/2021/bridge-l2-revamp.mdnew file+57
This diff is too big to show here.
content/grants/2021/clojure-urbit-client.mdnew file+113
This diff is too big to show here.
content/grants/2021/comprehensive-local-server-and-mum-explanation-video.mdnew file+45
This diff is too big to show here.
content/grants/2021/contacts.mdnew file+37
This diff is too big to show here.
content/grants/2021/content-producer.mdnew file+40
This diff is too big to show here.
content/grants/2021/cross-platform-desktop-urbit-app.mdnew file+96
This diff is too big to show here.
content/grants/2021/cypherscope-bot.mdnew file+80
This diff is too big to show here.
content/grants/2021/educational-guide-todomvc-urbit-edition.mdnew file+332
This diff is too big to show here.
content/grants/2021/feed-aggregator.mdnew file+103
This diff is too big to show here.
content/grants/2021/graph-store-documentation-guide.mdnew file+115
This diff is too big to show here.
content/grants/2021/guide-to-s3.mdnew file+35
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-11.mdnew file+62
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-12.mdnew file+58
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-13.mdnew file+59
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-14.mdnew file+59
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-15.mdnew file+59
This diff is too big to show here.
content/grants/2021/host-two-urbit-meetups-16.mdnew file+59
This diff is too big to show here.
content/grants/2021/json-jet.mdnew file+51
This diff is too big to show here.
content/grants/2021/login-with-urbit.mdnew file+84
This diff is too big to show here.
content/grants/2021/machine-learning.mdnew file+122
This diff is too big to show here.
content/grants/2021/market-interface.mdnew file+62
This diff is too big to show here.
content/grants/2021/meetup-bom.mdnew file+118
This diff is too big to show here.
content/grants/2021/minimal-urbit-os.mdnew file+58
This diff is too big to show here.
content/grants/2021/native-urbit.mdnew file+30
This diff is too big to show here.
content/grants/2021/network-explorer-data-pipeline-http-api.mdnew file+234
This diff is too big to show here.
content/grants/2021/nuck-jet.mdnew file+59
This diff is too big to show here.
content/grants/2021/overhaul-the-urbitorg-website.mdnew file+74
This diff is too big to show here.
content/grants/2021/planet-sales.mdnew file+66
This diff is too big to show here.
content/grants/2021/pokur.mdnew file+90
This diff is too big to show here.
content/grants/2021/ra-debugging-tools.mdnew file+26
This diff is too big to show here.
content/grants/2021/ra-page-tracking.mdnew file+34
This diff is too big to show here.
content/grants/2021/ra-segfaults.mdnew file+32
This diff is too big to show here.
content/grants/2021/ra-stack-overflow.mdnew file+32
This diff is too big to show here.
content/grants/2021/search-in-groups.mdnew file+42
This diff is too big to show here.
content/grants/2021/send-emails-to-a-mailing-list.mdnew file+78
This diff is too big to show here.
content/grants/2021/smol-future-sustained-knowledge-sharing-and-marketing.mdnew file+97
This diff is too big to show here.
content/grants/2021/speech-recognition.mdnew file+78
This diff is too big to show here.
content/grants/2021/staff-the-urbit-helpdesk-east.mdnew file+58
This diff is too big to show here.
content/grants/2021/static-site-generation.mdnew file+80
This diff is too big to show here.
content/grants/2021/thread-documentation.mdnew file+85
This diff is too big to show here.
content/grants/2021/translate-key-parts-of-urbitorg-into-german.mdnew file+31
This diff is too big to show here.
content/grants/2021/translate-key-parts-of-urbitorg-into-korean.mdnew file+31
This diff is too big to show here.
content/grants/2021/translate-key-parts-of-urbitorg-into-norwegian.mdnew file+32
This diff is too big to show here.
content/grants/2021/translate-key-parts-of-urbitorg-into-spanish.mdnew file+31
This diff is too big to show here.
content/grants/2021/try-urbit-website.mdnew file+33
This diff is too big to show here.
content/grants/2021/twitter-uv-extension.mdnew file+67
This diff is too big to show here.
content/grants/2021/ua-collaborative-text-editor.mdnew file+31
This diff is too big to show here.
content/grants/2021/ua-filesharer.mdnew file+30
This diff is too big to show here.
content/grants/2021/ua-heads-up-poker.mdnew file+35
This diff is too big to show here.
content/grants/2021/ua-invoice-system.mdnew file+35
This diff is too big to show here.
content/grants/2021/ua-marketplace.mdnew file+36
This diff is too big to show here.
content/grants/2021/ucal-google-and-outlook-integration.mdnew file+85
This diff is too big to show here.
content/grants/2021/urbit-api-for-elixir.mdnew file+38
This diff is too big to show here.
content/grants/2021/urbit-community-concierge-east-coast-2q2021.mdnew file+36
This diff is too big to show here.
content/grants/2021/urbit-community-concierge-east-coast.mdnew file+36
This diff is too big to show here.
content/grants/2021/urbit-community-concierge-west-coast-2q2021.mdnew file+36
This diff is too big to show here.
content/grants/2021/urbit-community-concierge-west-coast.mdnew file+36
This diff is too big to show here.
content/grants/2021/urbit-http-api-for-emacs-elisp.mdnew file+39
This diff is too big to show here.
content/grants/2021/urbit-http-api-for-python.mdnew file+46
This diff is too big to show here.
content/grants/2021/urbit-irc-bridge.mdnew file+49
This diff is too big to show here.
content/grants/2021/urbit-lfs-filehosting.mdnew file+68
This diff is too big to show here.
content/grants/2021/urbit-notes.mdnew file+102
This diff is too big to show here.
content/grants/2021/urbit-react-cookbook.mdnew file+47
This diff is too big to show here.
content/grants/2021/uturn.mdnew file+38
This diff is too big to show here.
content/grants/2021/uv-extension-library.mdnew file+44
This diff is too big to show here.
content/grants/2021/video-content-manager.mdnew file+61
This diff is too big to show here.
content/grants/2021/volt-lightning-on-urbit.mdnew file+313
This diff is too big to show here.
content/grants/2021/webrtc-gall-agent-and-external-app.mdnew file+81
This diff is too big to show here.
content/grants/2021/~home-urbit.mdnew file+119
This diff is too big to show here.
content/grants/2022/abacus.mdnew file+56
This diff is too big to show here.
content/grants/2022/app-engram.mdnew file+117
This diff is too big to show here.
content/grants/2022/app-openbsd.mdnew file+53
This diff is too big to show here.
content/grants/2022/app-store.mdnew file+159
This diff is too big to show here.
content/grants/2022/app-urvault.mdnew file+41
This diff is too big to show here.
content/grants/2022/app-uv-native-notificatons.mdnew file+42
This diff is too big to show here.
content/grants/2022/apprenticeship-extending-bitcoin.mdnew file+76
This diff is too big to show here.
content/grants/2022/apprenticeship-studio-collections.mdnew file+55
This diff is too big to show here.
content/grants/2022/apprenticeship-studio-email.mdnew file+40
This diff is too big to show here.
content/grants/2022/astrolabe.mdnew file+165
This diff is too big to show here.
content/grants/2022/books-development.mdnew file+44
This diff is too big to show here.
content/grants/2022/books.mdnew file+116
This diff is too big to show here.
content/grants/2022/calendar-holium.mdnew file+53
This diff is too big to show here.
content/grants/2022/chess-bounty.mdnew file+54
This diff is too big to show here.
content/grants/2022/chronicle.mdnew file+63
This diff is too big to show here.
content/grants/2022/communal-computing.mdnew file+130
This diff is too big to show here.
content/grants/2022/cue.mdnew file+60
This diff is too big to show here.
content/grants/2022/desk-import-export.mdnew file+102
This diff is too big to show here.
content/grants/2022/digital-editor-MROB.mdnew file+50
This diff is too big to show here.
content/grants/2022/digital-storefront.mdnew file+73
This diff is too big to show here.
content/grants/2022/dusko-valve.mdnew file+81
This diff is too big to show here.
content/grants/2022/eth-provider.mdnew file+65
This diff is too big to show here.
content/grants/2022/eth-wallet.mdnew file+49
This diff is too big to show here.
content/grants/2022/eyre-scry.mdnew file+72
This diff is too big to show here.
content/grants/2022/faux.mdnew file+58
This diff is too big to show here.
content/grants/2022/filesharer.mdnew file+100
This diff is too big to show here.
content/grants/2022/full-stop.mdnew file+131
This diff is too big to show here.
content/grants/2022/gather.mdnew file+87
This diff is too big to show here.
content/grants/2022/general-web-permissions.mdnew file+36
This diff is too big to show here.
content/grants/2022/gnosis-safe.mdnew file+56
This diff is too big to show here.
content/grants/2022/go-urbit.mdnew file+64
This diff is too big to show here.
content/grants/2022/gora-apprentice.mdnew file+61
This diff is too big to show here.
content/grants/2022/herd.mdnew file+58
This diff is too big to show here.
content/grants/2022/hoon-eval.mdnew file+56
This diff is too big to show here.
content/grants/2022/hoon-markdown-library.mdnew file+52
This diff is too big to show here.
content/grants/2022/http-server-driver.mdnew file+98
This diff is too big to show here.
content/grants/2022/keep.mdnew file+119
This diff is too big to show here.
content/grants/2022/knox.mdnew file+81
This diff is too big to show here.
content/grants/2022/lexicon.mdnew file+69
This diff is too big to show here.
content/grants/2022/lightning-development.mdnew file+201
This diff is too big to show here.
content/grants/2022/loom-pointer-compression.mdnew file+62
This diff is too big to show here.
content/grants/2022/meld-memory.mdnew file+55
This diff is too big to show here.
content/grants/2022/membrane.mdnew file+98
This diff is too big to show here.
content/grants/2022/middleware-apprentice.mdnew file+55
This diff is too big to show here.
content/grants/2022/minesweeper.mdnew file+48
This diff is too big to show here.
content/grants/2022/native-planet-2.mdnew file+90
This diff is too big to show here.
content/grants/2022/nested-goals.mdnew file+162
This diff is too big to show here.
content/grants/2022/notifications-protocol.mdnew file+64
This diff is too big to show here.
content/grants/2022/olif.mdnew file+97
This diff is too big to show here.
content/grants/2022/peat.mdnew file+66
This diff is too big to show here.
content/grants/2022/persistent-memory.mdnew file+157
This diff is too big to show here.
content/grants/2022/plug.mdnew file+165
This diff is too big to show here.
content/grants/2022/pony-bounty.mdnew file+72
This diff is too big to show here.
content/grants/2022/port-maintenance.mdnew file+72
This diff is too big to show here.
content/grants/2022/port-to-hosting.mdnew file+56
This diff is too big to show here.
content/grants/2022/profiling.mdnew file+74
This diff is too big to show here.
content/grants/2022/qr-login.mdnew file+48
This diff is too big to show here.
content/grants/2022/quorum.mdnew file+106
This diff is too big to show here.
content/grants/2022/regex-library.mdnew file+114
This diff is too big to show here.
content/grants/2022/seguro-phase-2.mdnew file+190
This diff is too big to show here.
content/grants/2022/seguro-prototype.mdnew file+66
This diff is too big to show here.
content/grants/2022/serving-the-people.mdnew file+101
This diff is too big to show here.
content/grants/2022/slam.mdnew file+113
This diff is too big to show here.
content/grants/2022/slaw-scot-jets.mdnew file+72
This diff is too big to show here.
content/grants/2022/smart-lightbulb-controller.mdnew file+104
This diff is too big to show here.
content/grants/2022/symmetric-routing.mdnew file+69
This diff is too big to show here.
content/grants/2022/trail.mdnew file+168
This diff is too big to show here.
content/grants/2022/trill-ufa.mdnew file+67
This diff is too big to show here.
content/grants/2022/trove.mdnew file+94
This diff is too big to show here.
content/grants/2022/urbit-forms.mdnew file+250
This diff is too big to show here.
content/grants/2022/urbit-interface-framework.mdnew file+88
This diff is too big to show here.
content/grants/2022/urbitswap.mdnew file+59
This diff is too big to show here.
content/grants/2022/value-articles.mdnew file+54
This diff is too big to show here.
content/grants/2022/volt-ui.mdnew file+54
This diff is too big to show here.
content/grants/2022/whom.mdnew file+70
This diff is too big to show here.
content/grants/2023/aera.mdnew file+50
This diff is too big to show here.
content/grants/2023/app-metrics.mdnew file+74
This diff is too big to show here.
content/grants/2023/blog-updates.mdnew file+64
This diff is too big to show here.
content/grants/2023/bridge-grab-bag.mdnew file+35
This diff is too big to show here.
content/grants/2023/community-meetups.mdnew file+37
This diff is too big to show here.
content/grants/2023/did-rfp.mdnew file+26
This diff is too big to show here.
content/grants/2023/elm.mdnew file+68
This diff is too big to show here.
content/grants/2023/email-stella-fixa-rfp.mdnew file+29
This diff is too big to show here.
content/grants/2023/eyre-noun-channels.mdnew file+42
This diff is too big to show here.
content/grants/2023/generator-doccords.mdnew file+46
This diff is too big to show here.
content/grants/2023/gh-concierge.mdnew file+42
This diff is too big to show here.
content/grants/2023/git-on-clay.mdnew file+42
This diff is too big to show here.
content/grants/2023/goals-2.mdnew file+64
This diff is too big to show here.
content/grants/2023/hoon-linter.mdnew file+30
This diff is too big to show here.
content/grants/2023/hoon-replit.mdnew file+45
This diff is too big to show here.
content/grants/2023/issue-grab-bag.mdnew file+36
This diff is too big to show here.
content/grants/2023/json-parser-suite.mdnew file+170
This diff is too big to show here.
content/grants/2023/kNock-property-testing.mdnew file+71
This diff is too big to show here.
content/grants/2023/lick.mdnew file+82
This diff is too big to show here.
content/grants/2023/mapping-ids.mdnew file+106
This diff is too big to show here.
content/grants/2023/network-weather.mdnew file+24
This diff is too big to show here.
content/grants/2023/oauth2-stella-fixa-rfp.mdnew file+31
This diff is too big to show here.
content/grants/2023/osmosis-client.mdnew file+48
This diff is too big to show here.
content/grants/2023/pastebin-RFP.mdnew file+28
This diff is too big to show here.
content/grants/2023/pastebin-proposal.mdnew file+33
This diff is too big to show here.
content/grants/2023/portal-features-1.mdnew file+82
This diff is too big to show here.
content/grants/2023/privacy-msg.mdnew file+89
This diff is too big to show here.
content/grants/2023/quorum-2.mdnew file+84
This diff is too big to show here.
content/grants/2023/replit.mdnew file+52
This diff is too big to show here.
content/grants/2023/school-support-23q1.mdnew file+43
This diff is too big to show here.
content/grants/2023/splitwise-rfp.mdnew file+26
This diff is too big to show here.
content/grants/2023/splitwise.mdnew file+129
This diff is too big to show here.
content/grants/2023/text-search.mdnew file+24
This diff is too big to show here.
content/grants/2023/tinygrad.mdnew file+24
This diff is too big to show here.
content/grants/2023/treesitter.mdnew file+71
This diff is too big to show here.
content/grants/2023/turf.mdnew file+205
This diff is too big to show here.
content/grants/2023/uc-concierge.mdnew file+42
This diff is too big to show here.
content/grants/2023/update-mass.mdnew file+26
This diff is too big to show here.
content/grants/2023/urbit-ninja-strike-team.mdnew file+38
This diff is too big to show here.
content/grants/2023/urbit-react-docs.mdnew file+124
This diff is too big to show here.
content/grants/2023/vere-eyre-cache.mdnew file+38
This diff is too big to show here.
content/grants/2023/wiki-stella-fixa-rfp.mdnew file+26
This diff is too big to show here.
content/groups/_index.mdnew file+3
This diff is too big to show here.
content/groups/~bitbet-bolbel/urbit-community.mdnew file+14
This diff is too big to show here.
content/groups/~bitdeg/assembly22.mdnew file+10
This diff is too big to show here.
content/groups/~dalten/aera.mdnew file+10
This diff is too big to show here.
content/groups/~dibref-labter/arbit.mdnew file+9
This diff is too big to show here.
content/groups/~dister-dozzod-lapdeg/battery-payload.mdnew file+9
This diff is too big to show here.
content/groups/~fabled-faster/new-york.mdnew file+10
This diff is too big to show here.
content/groups/~fabled-faster/structure.mdnew file+10
This diff is too big to show here.
content/groups/~fabled-faster/wind.mdnew file+10
This diff is too big to show here.
content/groups/~famreb-todmec/the-combine-public.mdnew file+13
This diff is too big to show here.
content/groups/~halbex-palheb/uf-public.mdnew file+10
This diff is too big to show here.
content/groups/~hatryx-lastud/other-life.mdnew file+10
This diff is too big to show here.
content/groups/~hiddev-dannut/new-hooniverse.mdnew file+11
This diff is too big to show here.
content/groups/~hocwyn-tipwex/uqbar-event-horizon-forever.mdnew file+11
This diff is too big to show here.
content/groups/~ladtem-filmyr/urbit-ny-week.mdnew file+193
This diff is too big to show here.
content/groups/~lanlyd/terminal.mdnew file+8
This diff is too big to show here.
content/groups/~lodsum-rilner/emil-graphics.mdnew file+10
This diff is too big to show here.
content/groups/~martyr-sarlev-sarsen/assembly-hackers.mdnew file+10
This diff is too big to show here.
content/groups/~matwet/networked-subject.mdnew file+11
This diff is too big to show here.
content/groups/~middev/the-forge.mdnew file+10
This diff is too big to show here.
content/groups/~mister-hilper-dozzod-dalten/quartus.mdnew file+10
This diff is too big to show here.
content/groups/~napmer-rilnut/wet-brain.mdnew file+10
This diff is too big to show here.
content/groups/~natnex-ronret/door-link.mdnew file+10
This diff is too big to show here.
content/groups/~nibset-napwyn/tlon-public.mdnew file+10
This diff is too big to show here.
content/groups/~poldec-tonteg/the-phantom-tollbooth.mdnew file+12
This diff is too big to show here.
content/groups/~sillus-mallus/toki-pona.mdnew file+12
This diff is too big to show here.
content/groups/~sitbus-dapsup/urstralia.mdnew file+9
This diff is too big to show here.
content/groups/~tirrel/the-marketplace.mdnew file+14
This diff is too big to show here.
content/groups/~todset-partug/urmetica.mdnew file+9
This diff is too big to show here.
content/groups/~wacrep-lossul/encyclosphere.mdnew file+9
This diff is too big to show here.
content/groups/~widbep-faltev/asheville.mdnew file+9
This diff is too big to show here.
content/groups/~winder-dapsym/urchan.mdnew file+29
This diff is too big to show here.
content/groups/~witbep-witbep/embark.mdnew file+11
This diff is too big to show here.
content/highlights/highlight-1.mdnew file+6
This diff is too big to show here.
content/highlights/highlight-2.mdnew file+6
This diff is too big to show here.
content/highlights/highlight-3.mdnew file+6
This diff is too big to show here.
content/ids/ballun-dilsup.mdnew file+7
This diff is too big to show here.
content/ids/battus-datsun.mdnew file+10
This diff is too big to show here.
content/ids/binnus.mdnew file+10
This diff is too big to show here.
content/ids/bintud-bitnev.mdnew file+8
This diff is too big to show here.
content/ids/bitbet-bolbel.mdnew file+4
This diff is too big to show here.
content/ids/botbyn-dolrum.mdnew file+7
This diff is too big to show here.
content/ids/datder-sonnet.mdnew file+13
This diff is too big to show here.
content/ids/datnut-pollen.mdnew file+15
This diff is too big to show here.
content/ids/datryn-ribdun.mdnew file+12
This diff is too big to show here.
content/ids/datsyr-radser.mdnew file+12
This diff is too big to show here.
content/ids/dopbet-larped.mdnew file+7
This diff is too big to show here.
content/ids/fallyn-balfus.mdnew file+8
This diff is too big to show here.
content/ids/finmep-lanteb.mdnew file+29
This diff is too big to show here.
content/ids/forryd-ravtyn.mdnew file+6
This diff is too big to show here.
content/ids/haddef-sigwen.mdnew file+12
This diff is too big to show here.
content/ids/haldul-navsyr.mdnew file+7
This diff is too big to show here.
content/ids/hocmed-lidrev.mdnew file+8
This diff is too big to show here.
content/ids/lagrev-nocfep.mdnew file+8
This diff is too big to show here.
content/ids/lanlyd.mdnew file+8
This diff is too big to show here.
content/ids/mallus-fabres.mdnew file+12
This diff is too big to show here.
content/ids/mastyr-bottec.mdnew file+10
This diff is too big to show here.
content/ids/monnys-riphet.mdnew file+7
This diff is too big to show here.
content/ids/nallux-dozryl.mdnew file+12
This diff is too big to show here.
content/ids/nibtud-bidsyt.mdnew file+17
This diff is too big to show here.
content/ids/panleg-padben.mdnew file+6
This diff is too big to show here.
content/ids/pinsyt-nossub.mdnew file+18
This diff is too big to show here.
content/ids/poldec-tonteg.mdnew file+14
This diff is too big to show here.
content/ids/rabsef-bicrym.mdnew file+14
This diff is too big to show here.
content/ids/ravmel-ropdyl.mdnew file+8
This diff is too big to show here.
content/ids/rilfun-lidlen.mdnew file+8
This diff is too big to show here.
content/ids/sarlev-sarsen.mdnew file+8
This diff is too big to show here.
content/ids/sicdev-pilnup.mdnew file+8
This diff is too big to show here.
content/ids/sitful-hatred.mdnew file+8
This diff is too big to show here.
content/ids/sogrum-savluc.mdnew file+11
This diff is too big to show here.
content/ids/tagdyl-ponwyn.mdnew file+10
This diff is too big to show here.
content/ids/tambes-palped.mdnew file+10
This diff is too big to show here.
content/ids/tiplec-lacnyx.mdnew file+6
This diff is too big to show here.
content/ids/tobrun-tomnet.mdnew file+8
This diff is too big to show here.
content/ids/topfet-parmed.mdnew file+6
This diff is too big to show here.
content/ids/wicrum-wicrun.mdnew file+8
This diff is too big to show here.
content/ids/wolref-podlex.mdnew file+8
This diff is too big to show here.
content/marketplaces/azimuth-shop.mdnew file+11
This diff is too big to show here.
content/marketplaces/lanlyd.mdnew file+19
This diff is too big to show here.
content/marketplaces/mocbel-house.mdnew file+19
This diff is too big to show here.
content/marketplaces/networked-subject.mdnew file+14
This diff is too big to show here.
content/marketplaces/opensea.mdnew file+18
This diff is too big to show here.
content/marketplaces/planet-market.mdnew file+26
This diff is too big to show here.
content/marketplaces/urbit-live.mdnew file+13
This diff is too big to show here.
content/marketplaces/urbitex.mdnew file+11
This diff is too big to show here.
content/marketplaces/urbitme.mdnew file+11
This diff is too big to show here.
content/marketplaces/wexpert-systems.mdnew file+13
This diff is too big to show here.
content/organizations/assemblycapital.mdnew file+10
This diff is too big to show here.
content/organizations/dalten.mdnew file+10
This diff is too big to show here.
content/organizations/holium.mdnew file+10
This diff is too big to show here.
content/organizations/labyrinthdao.mdnew file+10
This diff is too big to show here.
content/organizations/mars-review-of-books.mdnew file+19
This diff is too big to show here.
content/organizations/nativeplanet.mdnew file+10
This diff is too big to show here.
content/organizations/quartus.mdnew file+22
This diff is too big to show here.
content/organizations/reciprocal.mdnew file+13
This diff is too big to show here.
content/organizations/sortug.mdnew file+10
This diff is too big to show here.
content/organizations/third-earth.mdnew file+10
This diff is too big to show here.
content/organizations/tirrel.mdnew file+12
This diff is too big to show here.
content/organizations/tlon.mdnew file+12
This diff is too big to show here.
content/organizations/uqbar.mdnew file+10
This diff is too big to show here.
content/organizations/urbit-foundation.mdnew file+12
This diff is too big to show here.
content/organizations/zorp.mdnew file+10
This diff is too big to show here.
content/overview/_index.mdnew file+64
This diff is too big to show here.
content/overview/interface.mdnew file+42
This diff is too big to show here.
content/overview/people-history.mdnew file+73
This diff is too big to show here.
content/overview/urbit-id.mdnew file+63
This diff is too big to show here.
content/overview/urbit-os.mdnew file+45
This diff is too big to show here.
content/podcasts/2018-11-18_a-digital-republic.mdnew file+19
This diff is too big to show here.
content/podcasts/2019-11-11_urbit.mdnew file+9
This diff is too big to show here.
content/podcasts/2020-03-23_a-new-computing-platform.mdnew file+17
This diff is too big to show here.
content/podcasts/2020-03-23_technology-and-freedom.mdnew file+18
This diff is too big to show here.
content/podcasts/2020-03-23_under-the-hood.mdnew file+15
This diff is too big to show here.
content/podcasts/2020-03-24_urbit-id-and-the-network.mdnew file+13
This diff is too big to show here.
content/podcasts/2020-03-26_built-to-last.mdnew file+21
This diff is too big to show here.
content/podcasts/2020-03-26_urbit-and-bitcoin.mdnew file+15
This diff is too big to show here.
content/podcasts/2020-04-05_tlon-operations.mdnew file+15
This diff is too big to show here.
content/podcasts/2020-11-24_humane-computing.mdnew file+11
This diff is too big to show here.
content/podcasts/2021-02-08_urbit.mdnew file+27
This diff is too big to show here.
content/podcasts/2022-01-21_the-most-beautiful-computer.mdnew file+17
This diff is too big to show here.
content/podcasts/2022-01-26_the-only-dignified-computer.mdnew file+17
This diff is too big to show here.
content/podcasts/2022-02-01_100-year-computer.mdnew file+15
This diff is too big to show here.
content/podcasts/2022-02-15_building-web3-products.mdnew file+20
This diff is too big to show here.
content/podcasts/2022-02-21_most-correct-computer.mdnew file+17
This diff is too big to show here.
content/podcasts/2022-02-27_the-combine.mdnew file+13
This diff is too big to show here.
content/podcasts/2022-03-02_theory-of-the-egirl.mdnew file+17
This diff is too big to show here.
content/podcasts/2022-03-04_nockin.mdnew file+18
This diff is too big to show here.
content/podcasts/2022-03-08_urbit-blockchains.mdnew file+16
This diff is too big to show here.
content/podcasts/2022-03-11_mars-review.mdnew file+12
This diff is too big to show here.
content/podcasts/2022-03-13_alien-invasions.mdnew file+16
This diff is too big to show here.
content/podcasts/2022-03-18_politics-of-urbit-governance.mdnew file+15
This diff is too big to show here.
content/podcasts/2022-03-23_quantum-computing.mdnew file+15
This diff is too big to show here.
content/podcasts/2022-04-07_in-lehmans-terms.mdnew file+12
This diff is too big to show here.
content/podcasts/2022-04-19_robot-opera.mdnew file+11
This diff is too big to show here.
content/podcasts/2022-05-21_diary-of-sam-frank.mdnew file+10
This diff is too big to show here.
content/podcasts/2022-05-22_cincinnati-chili.mdnew file+10
This diff is too big to show here.
content/podcasts/2022-06-04_market-bedshite.mdnew file+10
This diff is too big to show here.
content/podcasts/2022-06-22_software-as-soulcraft.mdnew file+20
This diff is too big to show here.
content/podcasts/2022-06-29_josh-lehman.mdnew file+30
This diff is too big to show here.
content/podcasts/2022-07-04_enable-people-to-run-their-own-servers.mdnew file+116
This diff is too big to show here.
content/podcasts/2022-08-04_middling.mdnew file+10
This diff is too big to show here.
content/podcasts/2022-08-11_probing-questions.mdnew file+14
This diff is too big to show here.
content/podcasts/2022-08-19_the-blind.mdnew file+9
This diff is too big to show here.
content/podcasts/2022-08-26_the-harvard-finance-bro.mdnew file+12
This diff is too big to show here.
content/podcasts/2022-09-14_insanely-bullish-on-urbit.mdnew file+13
This diff is too big to show here.
content/podcasts/2022-09-21_the-worlds-best-crypto-investor.mdnew file+12
This diff is too big to show here.
content/podcasts/2022-09-30-neal-davis-urbit-sentience-daos.mdnew file+33
This diff is too big to show here.
content/podcasts/2022-10-04-reality-maximalism-josh-lehman.mdnew file+9
This diff is too big to show here.
content/podcasts/2022-10-06_urbit-maxi-episode copy.mdnew file+9
This diff is too big to show here.
content/podcasts/2022-12-22_epicenter-ted-blackman-gary-lieberman.mdnew file+11
This diff is too big to show here.
content/podcasts/2023-01-05_lets-get-personal.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-01-19_crypto-metaphysics.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-01-24_reject-triviality.mdnew file+13
This diff is too big to show here.
content/podcasts/2023-01-26_building-future-states-with-nation3.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-01-29_urbit-for-idiots.mdnew file+11
This diff is too big to show here.
content/podcasts/2023-02-09_crypto-narratives-new-and-old.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-02-13_distributed-networked-computing.mdnew file+17
This diff is too big to show here.
content/podcasts/2023-02-23_the-urbit-episode.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-03-09_reclaiming-web-1.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-03-23_how-to-invest-in-web3-like-a-cool-kid.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-03-28_pupusas-volcanoes-and-databases.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-04-03_legacy-internet-new-internet.mdnew file+15
This diff is too big to show here.
content/podcasts/2023-04-06_the-ai-episode.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-04-11_its-urbits-all-the-way-down-with-dachus-tiprel.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-04-14_epicenter-tim-galebach.mdnew file+11
This diff is too big to show here.
content/podcasts/2023-04-20_artificial-qintelligence.mdnew file+9
This diff is too big to show here.
content/podcasts/2023-04-27_hoon-only-legal-ui-with-hastuc-dibtux.mdnew file+11
This diff is too big to show here.
content/podcasts/2023-05-11_full-metal-urbit-with-mopfel-winrux.mdnew file+15
This diff is too big to show here.
content/podcasts/2023-05-18_crypto-takes-flight.mdnew file+11
This diff is too big to show here.
content/privacy.mdnew file+89
This diff is too big to show here.
content/proposals.mdnew file+93
This diff is too big to show here.
content/rfps.mdnew file+40
This diff is too big to show here.
content/terms-of-service.mdnew file+69
This diff is too big to show here.
content/updates/2016-10-6-update.mdnew file+264
This diff is too big to show here.
content/updates/2016-5-16-roadmap.mdnew file+245
This diff is too big to show here.
content/updates/2016-7-20-update.mdnew file+160
This diff is too big to show here.
content/updates/2016-8-30-update.mdnew file+268
This diff is too big to show here.
content/updates/2017-1-30-update.mdnew file+345
This diff is too big to show here.
content/updates/2017-10-7-update.mdnew file+17
This diff is too big to show here.
content/updates/2017-11-14-update.mdnew file+217
This diff is too big to show here.
content/updates/2017-12-16-update.mdnew file+31
This diff is too big to show here.
content/updates/2017-12-2-update.mdnew file+76
This diff is too big to show here.
content/updates/2017-12-22-update.mdnew file+33
This diff is too big to show here.
content/updates/2017-3-1-update.mdnew file+108
This diff is too big to show here.
content/updates/2017-4-17-update.mdnew file+158
This diff is too big to show here.
content/updates/2017-5-11-roadmap.mdnew file+234
This diff is too big to show here.
content/updates/2017-8-11-update.mdnew file+109
This diff is too big to show here.
content/updates/2017-9-23-update.mdnew file+25
This diff is too big to show here.
content/updates/2017-9-29-update.mdnew file+17
This diff is too big to show here.
content/updates/2018-1-13-update.mdnew file+28
This diff is too big to show here.
content/updates/2018-1-6-update.mdnew file+38
This diff is too big to show here.
content/updates/2018-10-12-update.mdnew file+62
This diff is too big to show here.
content/updates/2018-10-24-update.mdnew file+40
This diff is too big to show here.
content/updates/2018-11-20-update.mdnew file+55
This diff is too big to show here.
content/updates/2018-11-6-update.mdnew file+47
This diff is too big to show here.
content/updates/2018-12-18-update.mdnew file+59
This diff is too big to show here.
content/updates/2018-2-17-update.mdnew file+39
This diff is too big to show here.
content/updates/2018-2-24-update.mdnew file+32
This diff is too big to show here.
content/updates/2018-2-5-update.mdnew file+26
This diff is too big to show here.
content/updates/2018-2-9-update.mdnew file+41
This diff is too big to show here.
content/updates/2018-3-24-update.mdnew file+57
This diff is too big to show here.
content/updates/2018-3-5-update.mdnew file+32
This diff is too big to show here.
content/updates/2018-4-14-update.mdnew file+57
This diff is too big to show here.
content/updates/2018-4-7-update.mdnew file+41
This diff is too big to show here.
content/updates/2018-5-16-update.mdnew file+50
This diff is too big to show here.
content/updates/2018-5-23-update.mdnew file+64
This diff is too big to show here.
content/updates/2018-5-29-update.mdnew file+17
This diff is too big to show here.
content/updates/2018-5-30-update.mdnew file+78
This diff is too big to show here.
content/updates/2018-6-14-update.mdnew file+71
This diff is too big to show here.
content/updates/2018-6-21-update.mdnew file+60
This diff is too big to show here.
content/updates/2018-6-6-update.mdnew file+81
This diff is too big to show here.
content/updates/2018-7-13-update.mdnew file+67
This diff is too big to show here.
content/updates/2018-7-20-update.mdnew file+58
This diff is too big to show here.
content/updates/2018-7-3-update.mdnew file+66
This diff is too big to show here.
content/updates/2018-7-30-update.mdnew file+64
This diff is too big to show here.
content/updates/2018-8-23-update.mdnew file+85
This diff is too big to show here.
content/updates/2018-8-30-update.mdnew file+57
This diff is too big to show here.
content/updates/2018-8-8-update.mdnew file+59
This diff is too big to show here.
content/updates/2018-9-11-update.mdnew file+61
This diff is too big to show here.
content/updates/2019-11-06-update.mdnew file+42
This diff is too big to show here.
content/updates/2019-12-06-update.mdnew file+42
This diff is too big to show here.
content/updates/2019-2-11-update.mdnew file+39
This diff is too big to show here.
content/updates/2019-2-25-update.mdnew file+35
This diff is too big to show here.
content/updates/2019-2-26-network-update.mdnew file+39
This diff is too big to show here.
content/updates/2019-2-4-update.mdnew file+29
This diff is too big to show here.
content/updates/2019-3-11-update.mdnew file+29
This diff is too big to show here.
content/updates/2019-3-27-update.mdnew file+21
This diff is too big to show here.
content/updates/2019-3-4-update.mdnew file+48
This diff is too big to show here.
content/updates/2019-4-11-update.mdnew file+29
This diff is too big to show here.
content/updates/2019-5-10-update.mdnew file+17
This diff is too big to show here.
content/updates/2019-5-17-update.mdnew file+21
This diff is too big to show here.
content/updates/2019-5-31-update.mdnew file+31
This diff is too big to show here.
content/updates/2019-6-14-update.mdnew file+30
This diff is too big to show here.
content/updates/2019-7-25-update.mdnew file+40
This diff is too big to show here.
content/updates/2020-02-06-update.mdnew file+46
This diff is too big to show here.
content/updates/2020-04-04-update.mdnew file+26
This diff is too big to show here.
content/updates/2020-06-15-update.mdnew file+51
This diff is too big to show here.
content/updates/2020-07-27-update.mdnew file+37
This diff is too big to show here.
content/updates/2020-09-30-update.mdnew file+65
This diff is too big to show here.
content/updates/2020-10-29-update.mdnew file+49
This diff is too big to show here.
content/updates/2020-12-01-update.mdnew file+68
This diff is too big to show here.
content/updates/2021-01-15-update.mdnew file+60
This diff is too big to show here.
content/updates/2021-02-19-update.mdnew file+81
This diff is too big to show here.
content/updates/2021-04-01-update.mdnew file+89
This diff is too big to show here.
content/updates/2021-05-05-update.mdnew file+70
This diff is too big to show here.
content/updates/2021-06-16-update.mdnew file+79
This diff is too big to show here.
content/voting-instructions.mdnew file+36
This diff is too big to show here.
development/_index.mddeleted−33
This diff is too big to show here.
development/develop.mddeleted−115
This diff is too big to show here.
development/environment.mddeleted−62
This diff is too big to show here.
development/grants.mddeleted−84
This diff is too big to show here.
development/precepts.mddeleted−336
This diff is too big to show here.
development/project-repositories.mddeleted−49
This diff is too big to show here.
glossary/_index.mddeleted−10
This diff is too big to show here.
glossary/ames.mddeleted−19
This diff is too big to show here.
glossary/aqua.mddeleted−16
This diff is too big to show here.
glossary/arm.mddeleted−14
This diff is too big to show here.
glossary/arvo.mddeleted−40
This diff is too big to show here.
glossary/atom.mddeleted−20
This diff is too big to show here.
glossary/azimuth.mddeleted−18
This diff is too big to show here.
glossary/battery.mddeleted−14
This diff is too big to show here.
glossary/behn.mddeleted−14
This diff is too big to show here.
glossary/breach.mddeleted−28
This diff is too big to show here.
glossary/bridge.mddeleted−32
This diff is too big to show here.
glossary/censure.mddeleted−14
This diff is too big to show here.
glossary/ceremony.mddeleted−8
This diff is too big to show here.
glossary/chat.mddeleted−32
This diff is too big to show here.
glossary/claims.mddeleted−21
This diff is too big to show here.
glossary/clay.mddeleted−18
This diff is too big to show here.
glossary/comet.mddeleted−32
This diff is too big to show here.
glossary/core.mddeleted−14
This diff is too big to show here.
glossary/delegated-sending.mddeleted−9
This diff is too big to show here.
glossary/desk.mddeleted−15
This diff is too big to show here.
glossary/dill.mddeleted−22
This diff is too big to show here.
glossary/docvote.mddeleted−9
This diff is too big to show here.
glossary/dojo.mddeleted−14
This diff is too big to show here.
glossary/door.mddeleted−14
This diff is too big to show here.
glossary/ecliptic.mddeleted−12
This diff is too big to show here.
glossary/eventlog.mddeleted−23
This diff is too big to show here.
glossary/eyre.mddeleted−17
This diff is too big to show here.
glossary/ford.mddeleted−17
This diff is too big to show here.
glossary/galaxy.mddeleted−15
This diff is too big to show here.
glossary/gall.mddeleted−17
This diff is too big to show here.
glossary/gate.mddeleted−14
This diff is too big to show here.
glossary/hdwallet.mddeleted−17
This diff is too big to show here.
glossary/hoon.mddeleted−15
This diff is too big to show here.
glossary/invite-tree.mddeleted−9
This diff is too big to show here.
glossary/iris.mddeleted−11
This diff is too big to show here.
glossary/jael.mddeleted−8
This diff is too big to show here.
glossary/jaque.mddeleted−15
This diff is too big to show here.
glossary/keyfile.mddeleted−15
This diff is too big to show here.
glossary/landscape.mddeleted−11
This diff is too big to show here.
glossary/mark.mddeleted−17
This diff is too big to show here.
glossary/moon.mddeleted−34
This diff is too big to show here.
glossary/nock.mddeleted−17
This diff is too big to show here.
glossary/noun.mddeleted−15
This diff is too big to show here.
glossary/ota-updates.mddeleted−9
This diff is too big to show here.
glossary/payload.mddeleted−14
This diff is too big to show here.
glossary/ph.mddeleted−9
This diff is too big to show here.
glossary/pier.mddeleted−18
This diff is too big to show here.
glossary/pill.mddeleted−14
This diff is too big to show here.
glossary/planet.mddeleted−15
This diff is too big to show here.
glossary/proxies.mddeleted−29
This diff is too big to show here.
glossary/replay.mddeleted−13
This diff is too big to show here.
glossary/sailudon.mddeleted−13
This diff is too big to show here.
glossary/senate.mddeleted−14
This diff is too big to show here.
glossary/ship.mddeleted−26
This diff is too big to show here.
glossary/shiparvonetwork.mddeleted−9
This diff is too big to show here.
glossary/star.mddeleted−17
This diff is too big to show here.
glossary/sync.mddeleted−16
This diff is too big to show here.
glossary/trap.mddeleted−14
This diff is too big to show here.
glossary/upgrade.mddeleted−13
This diff is too big to show here.
glossary/vane.mddeleted−24
This diff is too big to show here.
glossary/vere.mddeleted−18
This diff is too big to show here.
glossary/voting.mddeleted−27
This diff is too big to show here.
glossary/wallet-generator.mddeleted−11
This diff is too big to show here.
gnosis-safe.mdnew file+48
This diff is too big to show here.
hoon/_index.mddeleted−27
This diff is too big to show here.
hoon/guides/_index.mddeleted−13
This diff is too big to show here.
hoon/guides/aqua.mddeleted−80
This diff is too big to show here.
hoon/guides/cli-tutorial.mddeleted−417
This diff is too big to show here.
hoon/guides/parsing.mddeleted−650
This diff is too big to show here.
hoon/hoon-school/_index.mddeleted−42
This diff is too big to show here.
hoon/hoon-school/ackermann.mddeleted−29
This diff is too big to show here.
hoon/hoon-school/arms-and-cores.mddeleted−652
This diff is too big to show here.
hoon/hoon-school/atoms-auras-and-simple-cell-types.mddeleted−779
This diff is too big to show here.
hoon/hoon-school/bank-account.mddeleted−80
This diff is too big to show here.
hoon/hoon-school/behn.mddeleted−110
This diff is too big to show here.
hoon/hoon-school/caesar.mddeleted−394
This diff is too big to show here.
hoon/hoon-school/conditionals.mddeleted−105
This diff is too big to show here.
hoon/hoon-school/doors.mddeleted−516
This diff is too big to show here.
hoon/hoon-school/egg-timer.mddeleted−159
This diff is too big to show here.
hoon/hoon-school/fibonacci.mddeleted−61
This diff is too big to show here.
hoon/hoon-school/gall.mddeleted−129
This diff is too big to show here.
hoon/hoon-school/gates.mddeleted−272
This diff is too big to show here.
hoon/hoon-school/generators.mddeleted−461
This diff is too big to show here.
hoon/hoon-school/hoon-syntax.mddeleted−356
This diff is too big to show here.
hoon/hoon-school/iron-polymorphism.mddeleted−88
This diff is too big to show here.
hoon/hoon-school/lead-polymorphism.mddeleted−155
This diff is too big to show here.
hoon/hoon-school/libraries.mddeleted−191
This diff is too big to show here.
hoon/hoon-school/list-of-numbers.mddeleted−132
This diff is too big to show here.
hoon/hoon-school/lists.mddeleted−497
This diff is too big to show here.
hoon/hoon-school/molds.mddeleted−98
This diff is too big to show here.
hoon/hoon-school/nouns.mddeleted−563
This diff is too big to show here.
hoon/hoon-school/recursion.mddeleted−195
This diff is too big to show here.
hoon/hoon-school/setup.mddeleted−105
This diff is too big to show here.
hoon/hoon-school/structures-and-complex-types.mddeleted−356
This diff is too big to show here.
hoon/hoon-school/the-subject-and-its-legs.mddeleted−726
This diff is too big to show here.
hoon/hoon-school/trees-sets-and-maps.mddeleted−321
This diff is too big to show here.
hoon/hoon-school/type-checking-and-type-inference.mddeleted−643
This diff is too big to show here.
hoon/hoon-school/type-polymorphism.mddeleted−584
This diff is too big to show here.
hoon/reference/_index.mddeleted−50
This diff is too big to show here.
hoon/reference/advanced.mddeleted−206
This diff is too big to show here.
hoon/reference/auras.mddeleted−98
This diff is too big to show here.
hoon/reference/basic.mddeleted−177
This diff is too big to show here.
hoon/reference/cheat-sheet.mddeleted−28
This diff is too big to show here.
hoon/reference/hoon-errors.mddeleted−189
This diff is too big to show here.
hoon/reference/irregular.mddeleted−257
This diff is too big to show here.
hoon/reference/limbs/_index.mddeleted−18
This diff is too big to show here.
hoon/reference/limbs/limb.mddeleted−71
This diff is too big to show here.
hoon/reference/limbs/wing.mddeleted−44
This diff is too big to show here.
hoon/reference/rune/_index.mddeleted−73
This diff is too big to show here.
hoon/reference/rune/bar.mddeleted−708
This diff is too big to show here.
hoon/reference/rune/buc.mddeleted−606
This diff is too big to show here.
hoon/reference/rune/cen.mddeleted−466
This diff is too big to show here.
hoon/reference/rune/col.mddeleted−245
This diff is too big to show here.
hoon/reference/rune/constants.mddeleted−193
This diff is too big to show here.
hoon/reference/rune/dot.mddeleted−223
This diff is too big to show here.
hoon/reference/rune/ket.mddeleted−387
This diff is too big to show here.
hoon/reference/rune/lus.mddeleted−225
This diff is too big to show here.
hoon/reference/rune/mic.mddeleted−462
This diff is too big to show here.
hoon/reference/rune/sig.mddeleted−452
This diff is too big to show here.
hoon/reference/rune/terminators.mddeleted−78
This diff is too big to show here.
hoon/reference/rune/tis.mddeleted−490
This diff is too big to show here.
hoon/reference/rune/wut.mddeleted−551
This diff is too big to show here.
hoon/reference/rune/zap.mddeleted−239
This diff is too big to show here.
hoon/reference/stdlib/1a.mddeleted−680
This diff is too big to show here.
hoon/reference/stdlib/1b.mddeleted−273
This diff is too big to show here.
hoon/reference/stdlib/1c.mddeleted−459
This diff is too big to show here.
hoon/reference/stdlib/2a.mddeleted−449
This diff is too big to show here.
hoon/reference/stdlib/2b.mddeleted−1412
This diff is too big to show here.
hoon/reference/stdlib/2c.mddeleted−1364
This diff is too big to show here.
hoon/reference/stdlib/2d.mddeleted−373
This diff is too big to show here.
hoon/reference/stdlib/2e.mddeleted−268
This diff is too big to show here.
hoon/reference/stdlib/2f.mddeleted−437
This diff is too big to show here.
hoon/reference/stdlib/2g.mddeleted−105
This diff is too big to show here.
hoon/reference/stdlib/2h.mddeleted−826
This diff is too big to show here.
hoon/reference/stdlib/2i.mddeleted−1133
This diff is too big to show here.
hoon/reference/stdlib/2j.mddeleted−269
This diff is too big to show here.
hoon/reference/stdlib/2k.mddeleted−400
This diff is too big to show here.
hoon/reference/stdlib/2l.mddeleted−108
This diff is too big to show here.
hoon/reference/stdlib/2m.mddeleted−308
This diff is too big to show here.
hoon/reference/stdlib/2n.mddeleted−427
This diff is too big to show here.
hoon/reference/stdlib/2o.mddeleted−187
This diff is too big to show here.
hoon/reference/stdlib/2p.mddeleted−242
This diff is too big to show here.
hoon/reference/stdlib/2q.mddeleted−375
This diff is too big to show here.
hoon/reference/stdlib/3a.mddeleted−859
This diff is too big to show here.
hoon/reference/stdlib/3b.mddeleted−5889
This diff is too big to show here.
hoon/reference/stdlib/3c.mddeleted−649
This diff is too big to show here.
hoon/reference/stdlib/3d.mddeleted−821
This diff is too big to show here.
hoon/reference/stdlib/3e.mddeleted−8
This diff is too big to show here.
hoon/reference/stdlib/3f.mddeleted−722
This diff is too big to show here.
hoon/reference/stdlib/3g.mddeleted−384
This diff is too big to show here.
hoon/reference/stdlib/4a.mddeleted−217
This diff is too big to show here.
hoon/reference/stdlib/4b.mddeleted−994
This diff is too big to show here.
hoon/reference/stdlib/4c.mddeleted−364
This diff is too big to show here.
hoon/reference/stdlib/4d.mddeleted−100
This diff is too big to show here.
hoon/reference/stdlib/4e.mddeleted−471
This diff is too big to show here.
hoon/reference/stdlib/4f.mddeleted−1195
This diff is too big to show here.
hoon/reference/stdlib/4g.mddeleted−179
This diff is too big to show here.
hoon/reference/stdlib/4h.mddeleted−962
This diff is too big to show here.
hoon/reference/stdlib/4i.mddeleted−1054
This diff is too big to show here.
hoon/reference/stdlib/4j.mddeleted−1656
This diff is too big to show here.
hoon/reference/stdlib/4k.mddeleted−276
This diff is too big to show here.
hoon/reference/stdlib/4l.mddeleted−608
This diff is too big to show here.
hoon/reference/stdlib/4m.mddeleted−434
This diff is too big to show here.
hoon/reference/stdlib/4n.mddeleted−447
This diff is too big to show here.
hoon/reference/stdlib/4o.mddeleted−782
This diff is too big to show here.
hoon/reference/stdlib/5a.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/5b.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/5c.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/5d.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/5e.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/5f.mddeleted−176
This diff is too big to show here.
hoon/reference/stdlib/5g.mddeleted−7
This diff is too big to show here.
hoon/reference/stdlib/_index.mddeleted−1733
This diff is too big to show here.
hoon/reference/stdlib/table-of-contents.mddeleted−1731
This diff is too big to show here.
hoon/reference/style.mddeleted−476
This diff is too big to show here.
lib/buildGlossary.jsnew file+59
This diff is too big to show here.
lib/buildPageTree.jsnew file+111
This diff is too big to show here.
lib/cache.jsnew file+90
This diff is too big to show here.
lib/constants.jsnew file+129
This diff is too big to show here.
lib/hooks.jsnew file+71
This diff is too big to show here.
lib/lib.jsnew file+251
This diff is too big to show here.
lib/rss.jsnew file+95
This diff is too big to show here.
next.config.jsnew file+26
This diff is too big to show here.
nock/_index.mddeleted−27
This diff is too big to show here.
nock/definition.mddeleted−186
This diff is too big to show here.
nock/example.mddeleted−362
This diff is too big to show here.
nock/explanation.mddeleted−605
This diff is too big to show here.
nock/implementations.mddeleted−2322
This diff is too big to show here.
package-lock.jsonnew file+5276
This diff is too big to show here.
package.jsonnew file+58
This diff is too big to show here.
pages/404.jsnew file+33
This diff is too big to show here.
pages/[slug].jsnew file+48
This diff is too big to show here.
pages/_app.jsnew file+85
This diff is too big to show here.
pages/api/dev-search.jsnew file+8
This diff is too big to show here.
pages/api/ops-search.jsnew file+8
This diff is too big to show here.
pages/api/roadmap-search.jsnew file+8
This diff is too big to show here.
pages/api/search.jsnew file+45
This diff is too big to show here.
pages/api/sigil.jsnew file+60
This diff is too big to show here.
pages/api/urbit-org-search.jsnew file+45
This diff is too big to show here.
pages/applications/[[...application]].jsnew file+206
This diff is too big to show here.
pages/applications/submit.jsnew file+143
This diff is too big to show here.
pages/articles/[slug].jsnew file+84
This diff is too big to show here.
pages/bitcoin.jsnew file+98
This diff is too big to show here.
pages/blog.jsnew file+131
This diff is too big to show here.
pages/blog/[slug].jsnew file+118
This diff is too big to show here.
pages/campus/[[...slug]].jsnew file+312
This diff is too big to show here.
pages/communities/[slug].jsnew file+87
This diff is too big to show here.
pages/decentralized-discord.jsnew file+291
This diff is too big to show here.
pages/ecosystem/index.jsnew file+416
This diff is too big to show here.
pages/ecosystem/spotlight/[slug].jsnew file+69
This diff is too big to show here.
pages/events.jsnew file+181
This diff is too big to show here.
pages/events/[slug].jsnew file+173
This diff is too big to show here.
pages/getinvolved.jsnew file+58
This diff is too big to show here.
pages/getting-started/[[...slug]].jsnew file+314
This diff is too big to show here.
pages/grants.jsnew file+401
This diff is too big to show here.
pages/grants/[slug].jsnew file+270
This diff is too big to show here.
pages/grants/apprenticeships.jsnew file+29
This diff is too big to show here.
pages/grants/bounties.jsnew file+28
This diff is too big to show here.
pages/grants/proposals.jsnew file+29
This diff is too big to show here.
pages/grants/rfps.jsnew file+29
This diff is too big to show here.
pages/groups/[[...group]].jsnew file+136
This diff is too big to show here.
pages/groups/submit.jsnew file+152
This diff is too big to show here.
pages/ids/[id].jsnew file+241
This diff is too big to show here.
pages/ids/submit.jsnew file+170
This diff is too big to show here.
pages/index.jsnew file+430
This diff is too big to show here.
pages/marketplaces/[slug].jsnew file+84
This diff is too big to show here.
pages/organizations/[slug].jsnew file+179
This diff is too big to show here.
pages/overview/[[...slug]].jsnew file+147
This diff is too big to show here.
pages/podcasts/[slug].jsnew file+84
This diff is too big to show here.
pages/trial-over.jsnew file+35
This diff is too big to show here.
pages/trial.jsnew file+129
This diff is too big to show here.
pages/updates.jsnew file+87
This diff is too big to show here.
pages/updates/[slug].jsnew file+126
This diff is too big to show here.
postcss.config.jsnew file+6
This diff is too big to show here.
public/images/android-chrome-192x192.pngnew file
Binary file not shown.
public/images/android-chrome-512x512.pngnew file
Binary file not shown.
public/images/apple-touch-icon.pngnew file
Binary file not shown.
public/images/favicon-16x16.pngnew file
Binary file not shown.
public/images/favicon-32x32.pngnew file
Binary file not shown.
public/images/favicon.iconew file
Binary file not shown.
public/images/planet-l2-claim.gifnew file
Binary file not shown.
public/images/planet-l2-migration.gifnew file
Binary file not shown.
public/images/planet-l2-transactions.pngnew file
Binary file not shown.
public/images/sound.svgnew file+5
This diff is too big to show here.
scripts/date_to_string_upgrade.jsnew file+43
This diff is too big to show here.
scripts/event_date_upgrade.jsnew file+51
This diff is too big to show here.
system-overview/_index.mddeleted−77
This diff is too big to show here.
system-overview/arvo.mddeleted−33
This diff is too big to show here.
system-overview/azimuth.mddeleted−34
This diff is too big to show here.
system-overview/cryptography.mddeleted−116
This diff is too big to show here.
system-overview/hoon.mddeleted−28
This diff is too big to show here.
system-overview/nock.mddeleted−34
This diff is too big to show here.
system-overview/vere.mddeleted−45
This diff is too big to show here.
tailwind.config.jsnew file+19
This diff is too big to show here.
userspace/_index.mddeleted−30
This diff is too big to show here.
userspace/gall/_index.mddeleted−21
This diff is too big to show here.
userspace/gall/gall-api.mddeleted−958
This diff is too big to show here.
userspace/gall/gall.mddeleted−559
This diff is too big to show here.
userspace/gall/tutorial.mddeleted−14
This diff is too big to show here.
userspace/graph-store/_index.mddeleted−23
This diff is too big to show here.
userspace/graph-store/advanced-info.mddeleted−64
This diff is too big to show here.
userspace/graph-store/data-structure-overview.mddeleted−338
This diff is too big to show here.
userspace/graph-store/overview.mddeleted−109
This diff is too big to show here.
userspace/graph-store/validator-walkthrough.mddeleted−487
This diff is too big to show here.
userspace/landscape/_index.mddeleted−18
This diff is too big to show here.
userspace/landscape/overview.mddeleted−195
This diff is too big to show here.
userspace/landscape/reference/_index.mddeleted−11
This diff is too big to show here.
userspace/landscape/reference/graph-store.mddeleted−160
This diff is too big to show here.
userspace/overview.mddeleted−19
This diff is too big to show here.
userspace/threads/_index.mddeleted−27
This diff is too big to show here.
userspace/threads/basics/_index.mddeleted−29
This diff is too big to show here.
userspace/threads/basics/bind.mddeleted−97
This diff is too big to show here.
userspace/threads/basics/fundamentals.mddeleted−169
This diff is too big to show here.
userspace/threads/basics/input.mddeleted−145
This diff is too big to show here.
userspace/threads/basics/output.mddeleted−119
This diff is too big to show here.
userspace/threads/basics/summary.mddeleted−75
This diff is too big to show here.
userspace/threads/examples/_index.mddeleted−33
This diff is too big to show here.
userspace/threads/examples/child-thread.mddeleted−237
This diff is too big to show here.
userspace/threads/examples/get-json.mddeleted−126
This diff is too big to show here.
userspace/threads/examples/main-loop.mddeleted−178
This diff is too big to show here.
userspace/threads/examples/poke-agent.mddeleted−60
This diff is too big to show here.
userspace/threads/examples/scry.mddeleted−70
This diff is too big to show here.
userspace/threads/examples/take-fact.mddeleted−65
This diff is too big to show here.
userspace/threads/gall/_index.mddeleted−29
This diff is too big to show here.
userspace/threads/gall/poke-thread.mddeleted−116
This diff is too big to show here.
userspace/threads/gall/start-thread.mddeleted−145
This diff is too big to show here.
userspace/threads/gall/stop-thread.mddeleted−152
This diff is too big to show here.
userspace/threads/gall/take-facts.mddeleted−184
This diff is too big to show here.
userspace/threads/gall/take-result.mddeleted−132
This diff is too big to show here.
userspace/threads/overview.mddeleted−81
This diff is too big to show here.
userspace/threads/reference.mddeleted−86
This diff is too big to show here.
vercel.jsonnew file+271
This diff is too big to show here.
vere/_index.mddeleted−37
This diff is too big to show here.
vere/api.mddeleted−1040
This diff is too big to show here.
vere/c.mddeleted−114
This diff is too big to show here.
vere/jetting.mddeleted−779
This diff is too big to show here.
vere/nouns.mddeleted−477
This diff is too big to show here.
vere/runtime.mddeleted−44
This diff is too big to show here.
weights.shdeleted−23
This diff is too big to show here.