on master help sign in
adds azimuth glossary
3ec2cecRobert
reference/glossary.md → reference/arvo-glossary.mdrenamed+37−32
@@ -1,14 +1,18 @@
1+++
1+++
2−title = "Glossary"
2+title = "Arvo Glossary"
3weight = 3
3weight = 3
4template = "doc.html"
4template = "doc.html"
5+++
5+++
6+
6Urbit is renowned for its exotic terminology. Here's a simple overview
7Urbit is renowned for its exotic terminology. Here's a simple overview
7from the strange words within.
8from the strange words within.
8
9
9As Dijkstra put it: "The purpose of abstraction is not to be vague, but
10As 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."
11to create a new semantic level in which one can be absolutely precise."
11
12
13+This glossary only covers terms the Arvo side of the project. You can find the
14+Azimuth glossary [here](../azimuth-glossary)
15+
12### application
16### application
13
17
14Also known as an “app,” an _application_ is a Hoon program that can hold state.
18Also known as an “app,” an _application_ is a Hoon program that can hold state.
@@ -23,14 +27,14 @@ enclosing [core](#core) itself as the subject.
23There are two kinds of arms: _dry_ and _wet_. Most arms are
27There are two kinds of arms: _dry_ and _wet_. Most arms are
24dry.
28dry.
25
29
26−##### dry
30+#### dry
27
31
28 normal, `++`, polymorphic by means of _variance_
32 normal, `++`, polymorphic by means of _variance_
29
33
30 For a dry arm, we ask: is the new payload compatible with the old
34 For a dry arm, we ask: is the new payload compatible with the old
31 payload (against which the core was compiled)?
35 payload (against which the core was compiled)?
32
36
33−##### wet
37+#### wet
34
38
35 unusual, `+-`, polymorphic by means of _genericity_
39 unusual, `+-`, polymorphic by means of _genericity_
36
40
@@ -67,7 +71,7 @@ More in-depth information on Arvo can be found
67
71
68Below are Arvo modules, which are called "vanes".
72Below are Arvo modules, which are called "vanes".
69
73
70−##### Ames
74+#### Ames
71
75
72 The networking vane. Ames handles all things UDP. Here live the protocols for
76 The networking vane. Ames handles all things UDP. Here live the protocols for
73 discovering and interacting with other urbits. It’s also the name for the Urbit
77 discovering and interacting with other urbits. It’s also the name for the Urbit
@@ -78,7 +82,7 @@ Below are Arvo modules, which are called "vanes".
78 More in-depth information on Ames can be found
82 More in-depth information on Ames can be found
79 [`here`](@/docs/learn/arvo/ames.md).
83 [`here`](@/docs/learn/arvo/ames.md).
80
84
81−##### Behn
85+#### Behn
82
86
83 The timing vane. Behn allows for applications to schedule events, which are
87 The timing vane. Behn allows for applications to schedule events, which are
84 managed in a simple priority queue. For example, Clay, the Urbit filesystem,
88 managed in a simple priority queue. For example, Clay, the Urbit filesystem,
@@ -87,7 +91,7 @@ Below are Arvo modules, which are called "vanes".
87
91
88 Behn is located in `/home/sys/vane/behn.hoon` within your urbit.
92 Behn is located in `/home/sys/vane/behn.hoon` within your urbit.
89
93
90−##### Clay
94+#### Clay
91
95
92 The filesystem and typed revision-control vane. Think of Clay as a
96 The filesystem and typed revision-control vane. Think of Clay as a
93 continuously synced git. It handles file-change events and maps them from Urbit
97 continuously synced git. It handles file-change events and maps them from Urbit
@@ -103,7 +107,7 @@ Below are Arvo modules, which are called "vanes".
103 of the architecture can be found
107 of the architecture can be found
104 [`here`](@/docs/learn/arvo/clay.md).
108 [`here`](@/docs/learn/arvo/clay.md).
105
109
106−##### Dill
110+#### Dill
107
111
108 The terminal-driver vane. You run your urbit in your Unix terminal, and
112 The terminal-driver vane. You run your urbit in your Unix terminal, and
109 Unix sends every event -- such as a keystroke or a change in the dimensions of
113 Unix sends every event -- such as a keystroke or a change in the dimensions of
@@ -122,7 +126,7 @@ Below are Arvo modules, which are called "vanes".
122 More in-depth information on Dill can be found
126 More in-depth information on Dill can be found
123 [`here`](@/docs/learn/arvo/dill.md).
127 [`here`](@/docs/learn/arvo/dill.md).
124
128
125−##### Eyre
129+#### Eyre
126
130
127 The web-server vane. Anything HTTP-related lives here. Unix sends HTTP messages
131 The web-server vane. Anything HTTP-related lives here. Unix sends HTTP messages
128 though to Eyre, and Eyre produces HTTP messages in response.
132 though to Eyre, and Eyre produces HTTP messages in response.
@@ -136,7 +140,7 @@ Below are Arvo modules, which are called "vanes".
136 More in-depth information on Eyre can be found
140 More in-depth information on Eyre can be found
137 [`here`](@/docs/learn/arvo/eyre.md).
141 [`here`](@/docs/learn/arvo/eyre.md).
138
142
139−##### Ford
143+#### Ford
140
144
141 The build-system vane. Ford is capable of sequencing generic asynchronous
145 The build-system vane. Ford is capable of sequencing generic asynchronous
142 computations. Its uses include linking source files into programs, assembling
146 computations. Its uses include linking source files into programs, assembling
@@ -151,7 +155,7 @@ Below are Arvo modules, which are called "vanes".
151 More in-depth information on Ford can be found
155 More in-depth information on Ford can be found
152 [`here`](@/docs/learn/arvo/ford.md).
156 [`here`](@/docs/learn/arvo/ford.md).
153
157
154−##### Gall
158+#### Gall
155
159
156 The application-management vane. Userspace apps -- daemons, really -- are
160 The application-management vane. Userspace apps -- daemons, really -- are
157 started, stopped, and sandboxed by Gall. Gall provides developers with a
161 started, stopped, and sandboxed by Gall. Gall provides developers with a
@@ -176,11 +180,12 @@ optional constant.
176
180
177An atom type is _warm_ or _cold_ based on whether the constant exists.
181An atom type is _warm_ or _cold_ based on whether the constant exists.
178
182
183+
179−##### warm
184+#### warm
180
185
181 If the constant is `~` (null), any atom is in the type.
186 If the constant is `~` (null), any atom is in the type.
182
187
183−##### cold
188+#### cold
184
189
185 If the constant is `[~ atom]`, its only legal value is `atom`.
190 If the constant is `[~ atom]`, its only legal value is `atom`.
186
191
@@ -296,11 +301,11 @@ code head the _battery_ and the data tail the _payload_. All code-data
296structures in normal languages (functions, objects, modules, etc.)
301structures in normal languages (functions, objects, modules, etc.)
297translate to cores in Hoon.
302translate to cores in Hoon.
298
303
299−##### battery
304+#### battery
300
305
301 The code-containing head of a core.
306 The code-containing head of a core.
302
307
303−##### payload
308+#### payload
304
309
305 The data-containing tail of a core.
310 The data-containing tail of a core.
306
311
@@ -362,11 +367,11 @@ in the core) with the argument, and then compute the arm.
362
367
363The payload of a gate has a shape of `[sample context]`.
368The payload of a gate has a shape of `[sample context]`.
364
369
365−##### sample
370+#### sample
366
371
367 The argument tuple.
372 The argument tuple.
368
373
369−##### context
374+#### context
370
375
371 The subject in which the gate was defined.
376 The subject in which the gate was defined.
372
377
@@ -424,7 +429,7 @@ such app that uses Hall.
424
429
425_More information on Hall can be found [here](@/docs/learn/arvo/hall.md)._
430_More information on Hall can be found [here](@/docs/learn/arvo/hall.md)._
426
431
427−##### circle
432+#### circle
428
433
429 A circle is the “audience” of your messages -- who can receive them. It can be
434 A circle is the “audience” of your messages -- who can receive them. It can be
430 thought of as a chat channel, but this is a little too narrow. More
435 thought of as a chat channel, but this is a little too narrow. More
@@ -447,7 +452,7 @@ The Hoon source file is located in `/home/sys/hoon.hoon` within your urbit.
447
452
448_More information can be found in the [hoon](@/docs/learn/hoon/_index.md) section._
453_More information can be found in the [hoon](@/docs/learn/hoon/_index.md) section._
449
454
450−##### Mint
455+#### Mint
451
456
452 _Mint_ is the Hoon compiler function. Mint takes the subject type and the
457 _Mint_ is the Hoon compiler function. Mint takes the subject type and the
453 expression source (a [hoon](#a-hoon), for example) and produces the product
458 expression source (a [hoon](#a-hoon), for example) and produces the product
@@ -549,12 +554,12 @@ head-first for either a face named "foo" or a core with an arm of
549"foo". If a face is found, the result is a leg, if a core is
554"foo". If a face is found, the result is a leg, if a core is
550found, the result is the product of the arm.
555found, the result is the product of the arm.
551
556
552−##### leg
557+#### leg
553
558
554 a subexpression, or subtree of the
559 a subexpression, or subtree of the
555 [subject](#nock-subject).
560 [subject](#nock-subject).
556
561
557−##### wing
562+#### wing
558
563
559 a search path into the subject, composed of
564 a search path into the subject, composed of
560 limbs. Search occurs from right to left (`a.b` means `b` within `a`).
565 limbs. Search occurs from right to left (`a.b` means `b` within `a`).
@@ -574,28 +579,28 @@ In [Nock](#nock) and [Hoon](#hoon), a _noun_ is an atom or a cell.
574Nock is a Turing-complete, non-lambda combinator interpreter. It's
579Nock is a Turing-complete, non-lambda combinator interpreter. It's
575Urbit's low-level programming language. Nock is functional and typeless.
580Urbit's low-level programming language. Nock is functional and typeless.
576
581
577−##### noun
582+#### noun
578
583
579 an _atom_ or a _cell_.
584 an _atom_ or a _cell_.
580
585
581−##### atom
586+#### atom
582
587
583 any natural number, including zero.
588 any natural number, including zero.
584
589
585−##### cell
590+#### cell
586
591
587 any ordered pair of nouns.
592 any ordered pair of nouns.
588
593
589
594
590−##### subject
595+#### subject
591
596
592 a noun - the data against which a _formula_ is evaluated.
597 a noun - the data against which a _formula_ is evaluated.
593
598
594−##### formula
599+#### formula
595
600
596 a noun - a function at the nock level.
601 a noun - a function at the nock level.
597
602
598−##### product
603+#### product
599
604
600 a noun - the result of evaluating a formula against a subject.
605 a noun - the result of evaluating a formula against a subject.
601
606
@@ -676,7 +681,7 @@ whose number is its bottom half. So the planet `~firbyr-napbes`,
676`48.879`, whose parent is `~mun`, `0xef`, `239`. The galaxy at the address of
681`48.879`, whose parent is `~mun`, `0xef`, `239`. The galaxy at the address of
677`0` is `~zod`.
682`0` is `~zod`.
678
683
679−##### pier
684+#### pier
680
685
681 A ship's _pier_ is its Unix directory. For planets, the name of the pier is
686 A ship's _pier_ is its Unix directory. For planets, the name of the pier is
682 usually the planet name.
687 usually the planet name.
@@ -691,7 +696,7 @@ validate untrusted network data.
691
696
692Here's some common structure terminology:
697Here's some common structure terminology:
693
698
694−##### bunt
699+#### bunt
695
700
696 A bunt is the default value of a [structure](#structure). It's also a verb;
701 A bunt is the default value of a [structure](#structure). It's also a verb;
697 to _bunt_ a structure is to produce the bunt of that structure. For example,
702 to _bunt_ a structure is to produce the bunt of that structure. For example,
@@ -705,7 +710,7 @@ Here's some common structure terminology:
705 ''
710 ''
706 ```
711 ```
707
712
708−##### icon: The type of the mold's range
713+#### icon: The type of the mold's range
709
714
710_See [mold hoons](/docs/reference/hoon-expressions/rune/buc/)._
715_See [mold hoons](/docs/reference/hoon-expressions/rune/buc/)._
711
716
@@ -725,7 +730,7 @@ a [`hoon`](#a-hoon).
725
730
726Runes have two syntactic forms, _tall_ and _flat_:
731Runes have two syntactic forms, _tall_ and _flat_:
727
732
728−##### tall
733+#### tall
729
734
730 multiple lines, no parentheses, two or more spaces between tokens
735 multiple lines, no parentheses, two or more spaces between tokens
731
736
@@ -736,7 +741,7 @@ Runes have two syntactic forms, _tall_ and _flat_:
736 4
741 4
737 ```
742 ```
738
743
739−##### flat
744+#### flat
740
745
741 one line, parentheses, one space between tokens
746 one line, parentheses, one space between tokens
742
747
@@ -797,7 +802,7 @@ All types are assembled out of base types defined in `++type`.
797does type-inference on a program, it assembles complex types out
802does type-inference on a program, it assembles complex types out
798of the simpler built-in types.
803of the simpler built-in types.
799
804
800−##### nest
805+#### nest
801
806
802 `nest` is an internal Hoon function on two types which performs a type
807 `nest` is an internal Hoon function on two types which performs a type
803 compatibility test. `nest` produces yes if the
808 compatibility test. `nest` produces yes if the
reference/azimuth-glossary.mdnew file+117
@@ -0,0 +1,117 @@
1++++
2+title = "Azimuth Glossary"
3+weight = 4
4+template = "doc.html"
5++++
6+
7+
8+Azimuth is a general-purpose public-key infrastructure (PKI) on the Ethereum blockchain, used as a platform for Urbit identities. You need an Azimuth identity to use the Arvo network. All identity-related operations are governed at this layer For more information, see the [Azimuth documentation](https://urbit.org/docs/concepts/azimuth/).
9+
10+This glossary is intended to familiarize you with Azimuth-related terminology. To brush up on terminology related to Arvo, check out the [Arvo glossary](../arvo-glossary).
11+
12+### Azimuth identity
13+
14+An Azimuth identity, previously known as a _point_, is a non-fungible Ethereum token ([ERC-271](https://medium.com/@brenn.a.hill/noobs-guide-to-understanding-erc-20-vs-erc-721-tokens-d7f5657a4ee7)) that represents a digital identity. The ERC-721 standard, having been made specifically to provide a smart-contract interface for non-fungible assets, allows Azimuth identity ownership to be take advantage of existing third-party tools and systems.
15+
16+#### Planet
17+
18+An Azimuth identity to be used as a personal identity. Issued by stars.
19+
20+#### Star
21+
22+An Azimuth identity meant to be used as network infrastructure. Issued by galaxies, issues planets.
23+
24+#### Galaxy
25+
26+An Azimuth identity meant to be used as top-level network infrastructure, with governance powers. Issues stars.
27+
28+### Bridge
29+
30+A tool that's the primary way to interact with Azimuth and manage your identities. It can be accessed at bridge.azimuth.network.
31+
32+### Master Ticket
33+
34+Think of your master ticket as a very high-value password. The master ticket is the secret code from which all of your other secrets 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.
35+
36+### Multipass
37+
38+Multipass is a planned feature of an Azimuth point that can be used as a universal, real-world identity. It will be able to hold money and have packets routed to it. See this [blog post](https://urbit.org/posts/azimuth-as-multipass/) for more information.
39+
40+#### Network Explorer
41+
42+A Bridge-based interface for browsing Azimuth identities. You can do things such as see which ships are on which parties, and much more.
43+
44+### Ownership Address
45+
46+The Ethereum address that owns a point. As the owner, it can perform all possible operations for that point.
47+
48+### Party
49+
50+Also called an _invite tree_. A host starts a party and all individuals invited to this tree have the ability to share remaining, unclaimed invites with others; when an invite is sent to someone, they become a full member of the party and themselves have the ability to invite. So parties grow like a tree.
51+
52+#### Party Host
53+
54+The ship that generates the party. It's most often a star.
55+
56+#### Guest List
57+
58+The names of planets invited to the same party, as viewed by a party host.
59+
60+#### Invite Cohort
61+
62+The names of planets invited to the same party, as viewed by a guest/planet in a party.
63+
64+#### Sending Invites
65+
66+The action of giving someone a planet using Bridge.
67+
68+#### Code
69+
70+Activation code from an email that allows you to claim an invite
71+
72+#### Birth Time
73+
74+When a ship is claimed from an invite
75+
76+### Passport
77+
78+The Passport is a folder of files one downloads that contains the secrets of your point and should be stored securely. As long as you own the passport, you own the point. The master ticket is stored in the Passport.
79+
80+### Proxy Address
81+
82+An Ethereum address that's allowed to perform a specific subset of the operations the owner of the point can perform. Useful for allowing some control over a point while keeping its ownership address in cold storage. Below, the specific kinds of proxy addresses are listed.
83+
84+#### Management Proxy Address
85+
86+An Ethereum address used for managing a point. This means it can only configure public (aka networking) keys, and perform sponsorship-related operations (requesting sponsor changes & approving/rejecting those).
87+Use cases:
88+- Keeping this handy so you can put the ownership/master ticket in a super safe place
89+- Allowing someone to manage your ship (by setting/deriving networking keys, managing sponsorship)
90+- Allowing a smart contract to manage sponsorship ops (ie star service smart contract)
91+
92+#### Network Keys
93+
94+Your public key contains Authentication and Encryption addresses, and also have Revision, Continuity Era, and Crypto Suite versions. Resetting Network Keys increases the revision number on the key. A main use case would be if your Network Keys were compromised, so you can use your Management Address to re-derive your Network Keys to another revision.
95+
96+#### Spawn Proxy Address
97+
98+An Ethereum address used for spawning children of a point. It can only perform the spawn operation (creating child points) and can do nothing else.
99+
100+Use cases:
101+- Keeping this handy so you can put the ownership/master ticket in a super safe place
102+- Allowing a smart contract to spawn on your behalf (delegated sending/invites, planet sale)
103+
104+#### Voting Proxy Address
105+An Ethereum address used for voting as a point.
106+
107+Use cases:
108+- Keeping this handy so you can put the ownership/master ticket in a super safe place
109+- Delegating your voting rights to someone else
110+
111+#### Transfer Proxy Address
112+
113+An Ethereum address that's allowed to transfer ownership of a point. Generally not used outside of transfers-in-progress. Using a transfer proxy allows one to give the recipient the power to take ownership of a point, rather than being given it. This "control check" is a strong safety mechanism commonly used in many (Ethereum-based) cryptographic assets.
114+
115+### Sponsorship
116+
117+Azimuth registers hierarchical dependence of identities on other identities; planets depend on stars, and stars depend on galaxies. Applications that use Azimuth can use this to set up things like network topology. In Arvo's case, the sponsor promises to provide software updates and peer discovery.
reference/cheat-sheet.md+1−1
@@ -1,6 +1,6 @@
1+++
1+++
2title = "Cheat sheet"
2title = "Cheat sheet"
3−weight = 4
3+weight = 5
4template = "doc.html"
4template = "doc.html"
5+++
5+++
6
6
reference/troubleshooting.md+1−1
@@ -1,6 +1,6 @@
1+++
1+++
2title = "Hoon Errors"
2title = "Hoon Errors"
3−weight = 5
3+weight = 6
4template = "doc.html"
4template = "doc.html"
5+++
5+++
6Ideally your Hoon works perfectly the first time. But...
6Ideally your Hoon works perfectly the first time. But...