6Urbit is renowned for its exotic terminology. Here's a simple overview
7from the strange words within.
9As Dijkstra put it: "The purpose of abstraction is not to be vague, but
10to create a new semantic level in which one can be absolutely precise."
12<span id="application"></span>
15Also known as an “app,” an _application_ is a Hoon program that can hold state.
20An _arm_ is a named, functionally-computed attribute of a [core](#core).
22The [hoon](#a-hoon) of each arm is compiled to a Nock formula, with the
23enclosing [core](#core) itself as the subject.
25There are two kinds of arms: _dry_ and _wet_. Most arms are
30 normal, `++`, polymorphic by means of _variance_
32 For a dry arm, we ask: is the new payload compatible with the old
33 payload (against which the core was compiled)?
37 unusual, `+-`, polymorphic by means of _genericity_
39 A wet arm uses the hoon as a macro. We create a new type analysis
40 path, which works as if we expanded the callee with the caller's
43_See [advanced types](/docs/reference/hoon-expressions/advanced/)_.
46<span id="arvo"></span>
49The Urbit operating system and kernel. Arvo's state is a pure function of its
50event log, and it serves as the Urbit event manager. It contains vanes, which are
51kernel modules that perform essential system operations. Arvo itself can only
52deal with one file at a time. For more, it relies on Ford, the build-system
55Arvo being purely functional means that the it is a function that is:
57`(state, event) → (state, effects)`
59Arvo coordinates and reloads vanes. It can be thought of as a traffic-director.
60Any vane needs to go through Arvo before reaching another vane. Events and
61their effects happen like so:
63`Unix event → vere (the virtual machine that runs Urbit) → Arvo → vane → Arvo`
65Arvo is located in `/home/sys/arvo.hoon` within your urbit.
67More in-depth information on Arvo can be found
68[`here`](/docs/learn/arvo/arvo-internals).
70Below are Arvo modules, which are called "vanes".
74 The networking vane. Ames handles all things UDP. Here live the protocols for
75 discovering and interacting with other urbits. It’s also the name for the Urbit
76 network itself. All communication is signed and encrypted.
78 Ames is located in `/home/sys/vane/ames.hoon` within your urbit.
80 More in-depth information on Ames can be found
81 [`here`](/docs/learn/arvo/arvo-internals/ames#commentary).
85 The timing vane. Behn allows for applications to schedule events, which are
86 managed in a simple priority queue. For example, Clay, the Urbit filesystem,
87 uses Behn to keep track of time-specific file requests. Eyre, the Urbit web
88 vane, uses Behn for timing-out HTTP sessions.
90 Behn is located in `/home/sys/vane/behn.hoon` within your urbit.
94 The filesystem and typed revision-control vane. Think of Clay as a
95 continuously synced git. It handles file-change events and maps them from Urbit
96 to Unix and vice versa.
98 A common way to use it is to create a pier, a directory that exists in and is
99 visible in Unix. Changes are automatically recorded from Urbit to the Unix
100 directory, and vice versa. Just set it and forget it!
102 Clay is located at `/home/sys/vane/clay.hoon` within your urbit.
104 Basic information on using Clay can be found
105 [`here`](/docs/arvo/arvo-internals/filesystem/). An in-depth explanation
106 of the architecture can be found
107 [`here`](/docs/learn/arvo/arvo-internals/clay#architecture).
111 The terminal-driver vane. You run your urbit in your Unix terminal, and
112 Unix sends every event -- such as a keystroke or a change in the dimensions of
113 the terminal window -- to be handled by Dill. Dill acts as an intermediary for
114 anything that uses keyboard events. This is why there’s some input lag in
115 Urbit’s command-line interface. (Optimization will come later!)
117 A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined
120 Keystroke in Unix -> Vere (virtual machine) -> Arvo -> Dill -> the Dojo
123 Dill is located at `/home/sys/vane/clay.hoon` within your urbit.
125 More in-depth information on Dill can be found
126 [`here`](/docs/learn/arvo/arvo-internals/dill).
130 The web-server vane. Anything HTTP-related lives here. Unix sends HTTP messages
131 though to Eyre, and Eyre produces HTTP messages in response.
133 In general, apps and vanes do not call Eyre; rather, Eyre calls apps and vanes.
134 Eyre uses Ford and Gall to functionally publish pages and facilitate
135 communication with apps.
137 Eyre is located at `/home/sys/vane/eyre.hoon` within your urbit.
139 More in-depth information on Eyre can be found
140 [`here`](https://urbit.org/docs/using/web/).
144 The build-system vane. Ford is capable of sequencing generic asynchronous
145 computations. Its uses include linking source files into programs, assembling
146 live-updating websites, and performing file-type conversions.
148 Ford neither accepts Unix events nor produces Unix effects. It exists
149 entirely for the benefit of Urbit applications and other vanes, in particular
152 Ford is located at `/home/sys/vane/ford.hoon` within your urbit.
154 More in-depth information on Ford can be found
155 [`here`](/docs/learn/arvo/arvo-internals/ford).
159 The application-management vane. Userspace apps -- daemons, really -- are
160 started, stopped, and sandboxed by Gall. Gall provides developers with a
161 consistent interface for hooking their app up to the operating system. It allows
162 applications and other vanes to send messages to applications and subscribe to
163 data streams. Messages coming into Gall are routed to the intended application,
164 and the response comes back along the same route. If the intended target is on
165 another ship, Gall will route it, behind the scenes, through Ames to the other
168 Gall is located at `/home/sys/vane/gall.hoon` within your urbit.
170 More in-depth information on Gall can be found
171 [`here`](/docs/learn/arvo/arvo-internals/gall/).
175An atom is any natural number, including zero. The atom is the most basic data
176type in [Nock](#nock) and [Hoon](#hoon). A Hoon atom type describes a Nock
177atom with two additional pieces of metadata: an [_aura_](#aura), and an
180An atom type is _warm_ or _cold_ based on whether the constant exists.
184 If the constant is `~` (null), any atom is in the type.
188 If the constant is `[~ atom]`, its only legal value is `atom`.
190_See [basic types](/docs/reference/hoon-expressions/basic)_
192<span id="aura"></span>
195An aura is a soft atom type. They appear as strings beginning with `@`. Auras
196represent the structure of an atom, print format, or other semantics. Its
197constraints on the value of an atom aren't enforced in any way.
199You can cast something to an aura, like a decimal, and get back its hexademical.
208Auras are an advisory type system. You can go up or down, but not sideways in
209the hierarchy. `@t` and `@` can each be cast to the other, but @t can’t be cast
210to `@u`, for example, without first being cast to the empty aura `@`.
215 > ^- @ 'c' :: 'c' is of the aura @t
222Here is a non-exhaustive list of auras:
225Aura Meaning Example Literal Syntax
226-------------------------------------------------------------------------
228 @da absolute date ~2018.5.14..22.31.46..1435
230@p phonemic string (ship name) ~sorreg-namtyv
231@r IEEE floating-point
232 @rd double precision (64 bits) .~6.02214085774e23
233 @rh half precision (16 bits) .~~3.14
234@s signed integer, sign-bit low
235 @sb signed binary --0b11.1000
236 @sd signed decimal --1.000.056
237 @sx signed hexadecimal -0x5f5.e138
238@t UTF-8 text (cord) 'howdy'
239 @ta ASCII text (knot) ~.howdy
240 @tas ASCII text symbol (term) %howdy
242 @ub unsigned binary 0b11.1000
243 @ud unsigned decimal 1.000.056
244 @ux unsigned hexadecimal 0x5f5.e138
247You can find the list of all auras [here](/docs/reference/hoon-expressions/rune/constants).
251Blocksize is the power-of-two bitwidth of an atom. So, an atom with a blocksize
252of `3` has a bitwidth of `2^3`, which is 8. A bitwidth of 8, in turn, can
253represent `2^8` values, or 256.
257To cast is to put a Hoon expression through the compiler’s type-checker to test
258whether the expression is guaranteed to evaluate to a product that falls within
259the desired type. If the expression is not guaranteed to behave in this way,
260then the compiler will halt with a nest-fail crash. Proper Hoon code will
261include a cast for the product type of each gate.
263The cast rune is `^-` (pronounced "ket-hep"). So, to cast to a list of atoms,
264we write `^- (list @)`. The irregular form of that expression is ``(list @)``.
268In Nock and Hoon, a _cell_ is an ordered pair of [nouns](#noun).
272Cells orient to the right; for example, the noun [2 6 14 15] is short for
278A clam is the use of a structure as a gate. Usually used to verify marks from
282 > ((list @t) [97 98 ~])
288In Hoon, `cord` is an aura for representing atoms as strings. UTF-8,
289least-significant bit first. Represented as the aura `@t`.
292 > `@t`478.560.413.032
296<span id="core"></span>
299A _core_ is a [cell](#nock-cell) of `[code data]`, where we call the
300code head the _battery_ and the data tail the _payload_. All code-data
301structures in normal languages (functions, objects, modules, etc.)
302translate to cores in Hoon.
306 The code-containing head of a core.
310 The data-containing tail of a core.
312_See [basic types](/docs/reference/hoon-expressions/basic)._
316The Dojo is the Urbit shell; the command line where you run programs,
317expressions, and system commands. It’s a CLI that is encountered right when
318an urbit is started for the first time. It is somewhat analogous to Bash, the
319Unix terminal, and more analogous to a Hoon REPL.
321You’ll notice that many things can’t be written here; this is normal. The Dojo
322enforces syntactical correctness right at the command line. Strings that can’t
323be continued into a valid expression are automatically trimmed back to something
324that can be. Some syntactically invalid expressions can be completed, but the
325Dojo will prevent them from being entered as a command. You can play around
326with this functionality learn what syntax is kosher.
331A duct is an Arvo-level call stack. At the beginning of every duct is a Unix
332event, such as a keystroke, network packet, timer event, or file change.
334A duct is a `list` of `wire`s. A wire is itself a `list` of `knot`s. A `knot`
339A _face_ is the Hoon analog to what is a variable name in most other
340programming languages. Faces are metadata labels for legs, allowing us to
341address parts. Because there is no metadata in Nock, faces cannot exist in Nock.
348In the above example, `a` is the face and `2` is the value.
350Hoon has no scope or symbol-table; there is only the subject. To "declare" a
351"variable" is to construct a new subject: `[name=value old-subject]`.
353_See [advanced types](/docs/reference/hoon-expressions/advanced)_.
358A `flag` is Hoon's version of a boolean. `0` (`%.y`) is _yes_, `1` (`%.n`) is
361Why? It's fresh, it's different, it's new. And it's annoying. And it
362keeps you on your toes. And it's also just intuitively right.
364<span id="gate"></span>
367A _gate_ is a [core](#core) with one [arm](#arm) -- Hoon's closest
368analog to a function. To call a gate on an argument, replace the sample
369(at [tree address](/docs/reference/hoon-expressions/limb/limb) `+6`
370in the core) with the argument, and then compute the arm.
372The payload of a gate has a shape of `[sample context]`.
380 The subject in which the gate was defined.
382_See [basic types](/docs/reference/hoon-expressions/basic),
383[`%-` ("cenhep")](/docs/reference/hoon-expressions/rune/cen#cenhep/) (the
384[rune](#rune) for calling a `gate`)._
388A _generator_ is like a limited Hoon script: it’s a shell command that produces
389a value before disappearing. Generators take an input [noun](#noun) (a value)
390and produce an output `noun` by performing calculations on its arguments,
391prompting for input, or making HTTP requests.
393You need a `bar` rune like `|=` in your generator, because a generator is
394essentially a function that you’re calling.
396Generators, unlike [apps](#application), hold no state. They are pure,
397stateless functions, and they cannot send [moves](#move). Because of this,
398generators are have a more narrow use than apps. Among the non-trivial uses of
399a a generator is moving data into apps -- they’re the backbone of Urbit’s
402Generators are run from the `/gen` directory of your current desk. For example,
403to run a generator named `whatever.hoon`, you would type `> +whatever` in the
404[Dojo](/docs/learn/arvo/arvo-internals/shell).
408A _glyph_ is a single, non-alphanumeric ASCII character. Each glyph has its own
409monosyllabic name, which allows the efficient communication of Hoon-related
410information in speech. [`Runes`](#rune) are composed of two glyphs.
411Below is a complete list of glyphs with their associated pronunciations.
414ace [1 space] gal < pal (
415bar | gap [>1 space, nl] par )
430_Hall_ is the Urbit communication back-end. It’s a messaging bus that can work
431with clients of all sorts. [`:talk`](#talk), the built-in chat client, is one
432such app that uses Hall.
434_More information on Hall can be found [here](/docs/learn/arvo/arvo-internals/hall)._
438 A circle is the “audience” of your messages -- who can receive them. It can be
439 thought of as a chat channel, but this is a little too narrow. More
440 specifically, it’s a named collection of messages created by and hosted on a
441 ship’s Hall, usually represented as `~ship-name/circle-name`. On Talk,
442 Urbit’s built-in chat front-end, the first circle that you will likely
443 encounter is `~dopzod/urbit-help`.
447_Hood_ orchestrates many of the Urbit initialization systems necessary
450<span id="hoon"></span>
453Hoon is a strict, higher-order typed functional language that compiles itself
456The Hoon source file is located in `/home/sys/hoon.hoon` within your urbit.
458_More information can be found in the [hoon](/docs/learn/arvo/hoon) section._
460<span id="mint"></span>
463 _Mint_ is the Hoon compiler function. Mint takes the subject type and the
464 expression source (a [hoon](#a-hoon), for example) and produces the product
465 type and nock formula. So [type hoon] is mapped to [type nock].
469A _hoon_ (lowercase) is the result of parsing a Hoon source expression into an
470AST node. These AST nodes are nouns, like all other Hoon data. Because every
471Hoon program is, in its entirety, a single expression of Hoon, the result of
472parsing the whole thing into an AST is a single `hoon`.
474A hoon is a tagged union of the form `[%tag data]`, where the tag
475is a constant such as `%brts` (from the source [rune](#rune) `|=`,
476i.e. "bartis"), and is matched up with the appropriate type of data
477(often more `hoon`s, from source subexpressions). For example, the
478expression `:-(2 17)`, once parsed into an AST, becomes the following:
481[%clhp p=[%sand p=%ud q=2] q=[%sand p=%ud q=17]]
484The `%clhp` is produced from the rune `:-` (i.e. "colhep"). The 2 and
48517 have each been parsed as `%sand`-tagged hoons, which represent
486atoms (in this case each with an aura of `%ud`, i.e. unsigned
489To parse Hoon source into a hoon AST, use `ream` on a `cord`
490containing Hoon source. Try the following in [Dojo](/docs/learn/arvo/arvo-internals/shell):
499[%clls p=[%sand p=%ud q=12] q=[%sand p=%ud q=7] r=[%rock p=%tas q=97]]
502See [expression reference](/docs/reference/hoon-expressions/rune) for the full list of hoons.
506Irregular forms are alternative ways of writing Hoon expressions, alternatives
507to the digraphic runes such as `:~`. Irregular forms are usually more compact
510_See [irregular forms](/docs/reference/hoon-expressions/irregular)._
514A _jet_ is a piece of C code that have equivalent products to a piece of Hoon or
515Nock code. They are used for performance reasons; jets are meant to be faster
516than the code that they are substituting for.
518Jets are necessary for mathematics, performance-wise, because Nock handles it
519so inefficiently. Nock, for example, can’t decrement (reduce a number by one)
520except by starting building a loop that starts from zero and increments to a
523_See [API overview](/docs/learn/arvo/vere/api)._
527A lark is an expression that returns a [limb](#limb) at the specified
528address in a cell. Using `-` by itself returns the head of the subject, and
529using `+` by itself returns the tail:
532> -:[[4 5] [6 [14 15]]]
535> +:[[4 5] [6 [14 15]]]
539You can combine `+` or `-` with either of `>` or `<` to get a more specific limb
540of the subject. `-<` returns the head of the head; `->` returns the tail of the
541head; `+<` returns the head of the tail; and `+>` returns the tail of the tail.
542By alternating the `+`/`-` symbols with `<`/`>` symbols, you can go as deep as
546> +>-:[[4 5] [6 [14 15]]]
549> +>+:[[4 5] [6 [14 15]]]
553<span id="limb"></span>
556A _limb_ is an attribute or variable reference. A limb is an [arm](#arm) or a
559To resolve a _limb_ named "foo", the subject is searched depth-first,
560head-first for either a face named "foo" or a core with an arm of
561"foo". If a face is found, the result is a leg, if a core is
562found, the result is the product of the arm.
566 a subexpression, or subtree of the
567 [subject](#nock-subject).
571 a search path into the subject, composed of
572 limbs. Search occurs from right to left (`a.b` means `b` within `a`).
574_See [Limbs and wings](/docs/hoon-expressions/limb/)_
577<span id="move"></span>
580A move is the [Arvo](#arvo) equivalent of a syscall.
583<span id="noun"></span>
586In [Nock](#nock) and [Hoon](#hoon), a _noun_ is an atom or a cell.
589<span id="nock"></span>
592Nock is a Turing-complete, non-lambda combinator interpreter. It's
593Urbit's low-level programming language. Nock is functional and typeless.
595<span id="nock-noun"></span>
598 an _atom_ or a _cell_.
600<span id="nock-atom"></span>
603 any natural number, including zero.
605<span id="nock-cell"></span>
608 any ordered pair of nouns.
610<span id="nock-subject"></span>
613 a noun - the data against which a _formula_ is evaluated.
615<span id="nock-formula"></span>
618 a noun - a function at the nock level.
620<span id="nock-product"></span>
623 a noun - the result of evaluating a formula against a subject.
625_See the [Nock definition](/docs/learn/arvo/nock/definition)._
628<span id="mark"></span>
631A _mark_ is Urbit's version of a MIME type, if a MIME type was an
632executable specification. The mark is just a label that's used as a path
633to a local source file in the Arvo filesystem. This source file defines
634a core that can mold untrusted data, diff and patch, convert to other
637If this sounds like magic, it isn't quite magic. There's no way
638for different urbits to make sure they mean the same thing by the
639same mark. However, when incompatibility happens, marks ensure
640that we at least handle the situation in a predictable way.
644Every core has a _metal_ which defines its variance model (ie, the
645properties of the type of a compatible core). The default is `gold`
651- `iron`: _contravariant_
653_See [advanced types](/docs/reference/hoon-expressions/advanced)_.
657An Urbit _ship_ is: a cryptographic title on a _will_ signed by private key; a
658human-memorable name; and a packet-routing address. Ships are classed by the
659number of bits in their address:
662 Size Name Parent Object Example
663 ----- ------ ------ ------ -------
664 2^8 galaxy ~ supernode ~zod
665 2^16 star galaxy supernode ~dozbud
666 2^32 planet star user ~tasfyn-partyv
667 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
668 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
671Any ship can be called an _urbit_. The lowercase "u" distinguishes it from Urbit
672the software stack and Urbit the network.
674_You can find a longer-form summary [here.](https://urbit.org/posts/essays/the-urbit-address-space/)._
676An Urbit identity is a string like `~firbyr-napbes`. It means nothing,
677but it's easy to remember and say out loud. `~firbyr-napbes` is actually
678just a 32-bit number (`3.237.967.392`, to be exact), like an IP address,
679that we turn into a human-memorable string. The full name of this string
680can be viewed by typing `our` in the Dojo, Urbit's shell. This is useful
681when running a ship with a longer name, such as a _moon_ or a _comet_.
683Technically, an urbit is a secure digital identity that you own and
684control with a cryptographic key, like a Bitcoin wallet. As in Bitcoin,
685the supply of urbits is mathematically limited. This keeps the network
686friendly, by making spam and abuse expensive.
688An urbit name is just a number; smaller numbers make shorter names.
689Shorter names are easier to remember, so they're more valuable. So
690urbits are classified by the number of bits in their name. (A ship name
691is just a scrambled base-256 representation of the number.)
693A 32-bit urbit (like `~firbyr-napbes`) is called a _planet._ A 16-bit
694urbit (like `~pollev)` is a _star._ An 8-bit ship (like `~mun`) is a
695_galaxy._ A planet is an identity for an independent, adult human. Stars
696and galaxies are network infrastructure.
698Each planet or star is launched by its _parent,_ the star or galaxy
699whose number is its bottom half. So the planet `~firbyr-napbes`,
700`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
701`48.879`, whose parent is `~mun`, `0xef`, `239`. The galaxy at the address of
707 A ship's _pier_ is its Unix directory. For planets, the name of the pier is
708 usually the planet name.
710<span id="structure"></span>
713A _structure_ is an idempotent [gate](#gate) (function) that constructs and
714validates types in Hoon.
716An example: Arvo [marks](#mark) use Hoon's type system via structures to
717validate untrusted network data.
719Here's some common structure terminology:
723 A bunt is the default value of a [structure](#structure). It's also a verb;
724 to _bunt_ a structure is to produce the bunt of that structure. For example,
725 bunting `@` results in `0`, and bunting `@t` results in `''`. Bunting is
726 performed with `*` followed by the structure in question:
735- ##### icon: The type of the mold's range.
737_See [mold hoons](/docs/reference/hoon-expressions/rune/buc/)._
739<span id="rune"></span>
742A Hoon _rune_ is a pair of ASCII symbols used to begin a
743[Hoon expression](#a-hoon).
745For example, the rune [`?:`](/docs/reference/hoon-expressions/rune/wut#wutcol/) is
746Hoon's most common conditional, a branch on a boolean test. The first
747symbol in a rune represents a family of related runes. For example, the
748[`?` family](/docs/reference/hoon-expressions/rune/wut/) are all conditionals.
750The result of parsing a Hoon source expression—the rune, followed
751by its respective children—into an AST node is simply called
754Runes have two syntactic forms, _tall_ and _flat_:
758 multiple lines, no parentheses, two or more spaces between tokens
769 one line, parentheses, one space between tokens
773 > %+(add 2 2) :: regular flat form
776 > (add 2 2) :: irregular flat form
780Tall hoons can contain flat hoons, but not vice versa. All irregular
783_See [hoon concept](#a-hoon),
784[expressions](/docs/reference/hoon-expressions/rune).
788_Sail_ is the Hoon markup language for XML.
792To _scry_ means to request data from the Arvo namespace and bring it
795_See [.^ (dot-ket)](/docs/reference/hoon-expressions/rune/dot/ket/)._
799`slot` is the name for Hoon's tree-addressing scheme.
801Every cell has a head and a tail, each of which may be either an atom or
802a cell. Therefore every noun is a binary tree. `+1` or `.` resolves to
803the whole cell (technically this would work against an atom as well).
804The head of `+n` is `+2n`, the tail is `+(2n+1)`.
806`+7` is a special address for gates, because the position is defined
807(by convention) as the context of a gate and of all cores.
809<span id="talk"></span>
812_Talk_ is Urbit's built-in chat app. It’s one example of an app that can be
813built on top of Hall, the Urbit back-end messaging system.
815_See [Messaging](/docs/learn/arvo/arvo-internals/messaging). for more information._
819A Hoon _type_ defines a set (finite or infinite) of nouns and ascribes
820some semantics to it. There is no direct syntax for defining
821types; they are always defined by inference (i.e., by
822[`mint`](#mint)), usually using a constructor ([structure](#structure)).
824All types are assembled out of base types defined in `++type`.
825(Look up `++ type` in hoon.hoon for examples.) When the compiler
826does type-inference on a program, it assembles complex types out
827of the simpler built-in types.
831 `nest` is an internal Hoon function on two types which performs a type
832 compatibility test. `nest` produces yes if the
833 set of nouns in the second type is provably a subset of the first.
834 If `nest` produces no, the Hoon programmer will receive a `nest-fail`
835 error. This is one of the most commons errors in Hoon programming.
837 _See [advanced types](/docs/reference/hoon-expressions/advanced/)_.
838 _See [troubleshooting](/docs/reference/troubleshooting)_.
843Hoon's equivalent of a nullable pointer or a Haskell Maybe. If `q` is `~`,
844null, the type is _warm_; any atom is in the type. If `q` is `[~ x]`, where
845`x` is any atom, the type is _cold_; its only legal value is the constant `x`.
849A _vane_ is an [Arvo](#arvo) module. Each Vane is a single file because Arvo
850cannot, on its own, deal with programs that are split between multiple files.
851Some vanes can do this, however.
853### Vere (pronounced “vair”)
855The runtime system, written in C, that implements [Nock](#nock). All
856It’s written in C. Vere-level errors are prepended with as `bail:`.
858Vere is a virtual machine: it pretends to be hardware, and is the single point
859of contact between your Urbit and the rest of your system. But more than that,
860Vere handles the Urbit event log and handles jets. It’s also contains the i/o
861drivers for Urbit’s vanes, responsible for generating events from Unix and
862applying effects to Unix.
866_Zuse_ is a defined interface for vanes. It contains the part of the Hoon
867standard library that is specific to Arvo functionality.
869Arvo is located in `/home/sys/zuse.hoon` within your urbit.
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list