on master help sign in
fix glossary links
commit9de946fae928eb3a5b012285b3d0674d81d47664 authordrbeefsupreme <drbeefsupreme@discordja.net> dateWed 4 Aug 2021, 13:04 (5 years ago) parent704688d
61 files changed+150−150
content/docs/glossary/ames.md+3−3 content/docs/glossary/aqua.md+2−2 content/docs/glossary/arvo.md+9−9 content/docs/glossary/atom.md+1−1 content/docs/glossary/azimuth.md+3−3 content/docs/glossary/battery.md+1−1 content/docs/glossary/behn.md+2−2 content/docs/glossary/breach.md+3−3 content/docs/glossary/bridge.md+2−2 content/docs/glossary/censure.md+1−1 content/docs/glossary/ceremony.md+1−1 content/docs/glossary/chat.md+3−3 content/docs/glossary/claims.md+1−1 content/docs/glossary/clay.md+1−1 content/docs/glossary/comet.md+6−6 content/docs/glossary/core.md+1−1 content/docs/glossary/delegated-sending.md+1−1 content/docs/glossary/desk.md+1−1 content/docs/glossary/dill.md+2−2 content/docs/glossary/docvote.md+1−1 content/docs/glossary/dojo.md+3−3 content/docs/glossary/door.md+1−1 content/docs/glossary/ecliptic.md+3−3 content/docs/glossary/eventlog.md+4−4 content/docs/glossary/eyre.md+3−3 content/docs/glossary/ford.md+3−3 content/docs/glossary/galaxy.md+3−3 content/docs/glossary/gall.md+1−1 content/docs/glossary/gate.md+2−2 content/docs/glossary/hdwallet.md+2−2 content/docs/glossary/hoon.md+1−1 content/docs/glossary/invite-tree.md+1−1 content/docs/glossary/iris.md+2−2 content/docs/glossary/jael.md+1−1 content/docs/glossary/jaque.md+1−1 content/docs/glossary/keyfile.md+2−2 content/docs/glossary/landscape.md+2−2 content/docs/glossary/mark.md+2−2 content/docs/glossary/moon.md+4−4 content/docs/glossary/nock.md+3−3 content/docs/glossary/noun.md+1−1 content/docs/glossary/ota-updates.md+1−1 content/docs/glossary/payload.md+1−1 content/docs/glossary/ph.md+1−1 content/docs/glossary/pier.md+3−3 content/docs/glossary/pill.md+3−3 content/docs/glossary/planet.md+2−2 content/docs/glossary/proxies.md+4−4 content/docs/glossary/replay.md+1−1 content/docs/glossary/sailudon.md+2−2 content/docs/glossary/senate.md+5−5 content/docs/glossary/ship.md+8−8 content/docs/glossary/shiparvonetwork.md+1−1 content/docs/glossary/star.md+3−3 content/docs/glossary/sync.md+2−2 content/docs/glossary/trap.md+1−1 content/docs/glossary/upgrade.md+4−4 content/docs/glossary/vane.md+10−10 content/docs/glossary/vere.md+3−3 content/docs/glossary/voting.md+4−4 content/docs/glossary/wallet-generator.md+1−1
content/docs/glossary/ames.md+3−3
@@ -5,13 +5,13 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−**Ames** is the name of the Urbit network and the [vane](../vane) that communicates over it. It's an encrypted peer-to-peer network composed of instances of the [Arvo](../arvo) operating system. Each [galaxy](../galaxy), [star](../star), [planet](../planet), [moon](../moon), and [comet](../comet) communicates over the network utilizing the Ames protocol.
8+**Ames** is the name of the Urbit network and the [vane](/docs/glossary/vane) that communicates over it. It's an encrypted peer-to-peer network composed of instances of the [Arvo](/docs/glossary/arvo) operating system. Each [galaxy](/docs/glossary/galaxy), [star](/docs/glossary/star), [planet](/docs/glossary/planet), [moon](/docs/glossary/moon), and [comet](/docs/glossary/comet) communicates over the network utilizing the Ames protocol.
99
10−Your ship upgrades itself with [OTA updates](../ota-updates) via communication over Ames. The web interface, [Landscape](../landscape), of ships can be accessed by typing `sampel-palnet.arvo.network` into a browser, where `sampel-palnet` is the name of your ship.
10+Your ship upgrades itself with [OTA updates](/docs/glossary/ota-updates) via communication over Ames. The web interface, [Landscape](/docs/glossary/landscape), of ships can be accessed by typing `sampel-palnet.arvo.network` into a browser, where `sampel-palnet` is the name of your ship.
1111
1212Network continuity occasionally needs to be broken, either at an individual
1313level to fix networking issues or at a network-wide level to update Arvo beyond
14−what OTA updates are capable of doing. These events are called [breaches](../breach).
14+what OTA updates are capable of doing. These events are called [breaches](/docs/glossary/breach).
1515### Further Reading
1616
1717- [The Ames tutorial](/docs/arvo/ames/ames): An in-depth technical guide to the Ames protocol.
content/docs/glossary/aqua.md+2−2
@@ -7,9 +7,9 @@ category = "arvo"
77
88**Aqua** is something like Docker but for Urbit; it is a virtualization tool whose primary purpose is testing and development.
99
10−Aqua is a [Gall](../gall) app that runs an [Arvo](../arvo) instance or instances in userspace. It pretends to be [Vere](../vere), and as such it loads [Pills](../pill) to boot up a virtual ship or fleet of ships and then manages them from within the parent Arvo instance. Running tests for a virtual fleet of Aqua ships is done using [pH](../ph).
10+Aqua is a [Gall](/docs/glossary/gall) app that runs an [Arvo](/docs/glossary/arvo) instance or instances in userspace. It pretends to be [Vere](/docs/glossary/vere), and as such it loads [Pills](/docs/glossary/pill) to boot up a virtual ship or fleet of ships and then manages them from within the parent Arvo instance. Running tests for a virtual fleet of Aqua ships is done using [pH](/docs/glossary/ph).
1111
12−Aqua is jetted with the usual [Nock](../nock) interpreter and thus virtual ships do not run any slower than the parent ship.
12+Aqua is jetted with the usual [Nock](/docs/glossary/nock) interpreter and thus virtual ships do not run any slower than the parent ship.
1313
1414### Further Reading
1515
content/docs/glossary/arvo.md+9−9
@@ -4,8 +4,8 @@ template = "doc.html"
44+++
55
66**Arvo** is the Urbit operating system and kernel. Arvo's state is a pure
7−function of its [event log](../eventlog), and it serves as the Urbit event
8−manager. It contains [vanes](../vane), which are kernel modules that perform
7+function of its [event log](/docs/glossary/eventlog), and it serves as the Urbit event
8+manager. It contains [vanes](/docs/glossary/vane), which are kernel modules that perform
99essential system operations.
1010
1111Arvo being purely functional means that the state of the operating system at a given moment is completely determined by the sequence of events in the event log. In other words, the state of an Arvo instance is given by a lifecycle function
@@ -18,19 +18,19 @@ Arvo coordinates and reloads vanes. It can be thought of as a traffic-director.
1818```
1919Unix event -> Vere -> Arvo -> vane -> Arvo
2020```
21−Here, [Vere](../vere) is the virtual machine running Urbit.
21+Here, [Vere](/docs/glossary/vere) is the virtual machine running Urbit.
2222
2323Arvo is located in `/home/sys/arvo.hoon` within your urbit.
2424
25−Arvo vanes include [Ames](../ames) for networking, [Behn](../behn) for timing,
26−[Clay](../clay) for filesystem and typed revision control, [Dill](../dill) for
27−terminal driving, [Eyre](../eyre) for web services, [Ford](../ford) for
28−building, and [Gall](../gall) for application management.
25+Arvo vanes include [Ames](/docs/glossary/ames) for networking, [Behn](/docs/glossary/behn) for timing,
26+[Clay](/docs/glossary/clay) for filesystem and typed revision control, [Dill](/docs/glossary/dill) for
27+terminal driving, [Eyre](/docs/glossary/eyre) for web services, [Ford](/docs/glossary/ford) for
28+building, and [Gall](/docs/glossary/gall) for application management.
2929
30−Vanes and other programs for Arvo are written in [Hoon](../hoon).
30+Vanes and other programs for Arvo are written in [Hoon](/docs/glossary/hoon).
3131
3232A ship creates its own copy of Arvo via a bootstrap sequence known as a
33−[Pill](../pill).
33+[Pill](/docs/glossary/pill).
3434
3535### Further Reading
3636
content/docs/glossary/atom.md+1−1
@@ -5,7 +5,7 @@ template = "doc.html"
55category = "hoon-nock"
66+++
77
8−An **atom** is any non-negative integer of any size. The atom is the most basic data type in [Nock](../nock) and [Hoon](../hoon).
8+An **atom** is any non-negative integer of any size. The atom is the most basic data type in [Nock](/docs/glossary/nock) and [Hoon](/docs/glossary/hoon).
99
1010A Hoon atom type consists of a Nock atom with two additional pieces of metadata:
1111an _aura_, which is a soft type that declares if an atom is a date, a ship name, a
content/docs/glossary/azimuth.md+3−3
@@ -3,11 +3,11 @@ title = "Azimuth"
33template = "doc.html"
44+++
55
6−**Azimuth** is Urbit's identity layer, built as a suite of smart contracts on the Ethereum blockchain. It is Urbit's method of securing digital identities that are required to use the [Arvo](../arvo) peer-to-peer network, without the need for a central authority. Azimuth identities exist as non-fungible tokens, which are owned by Ethereum addresses and can be transferred between such addresses. Identities can use the [claims](../claims) contract to make assertions – real-world or otherwise – about their owner.
6+**Azimuth** is Urbit's identity layer, built as a suite of smart contracts on the Ethereum blockchain. It is Urbit's method of securing digital identities that are required to use the [Arvo](/docs/glossary/arvo) peer-to-peer network, without the need for a central authority. Azimuth identities exist as non-fungible tokens, which are owned by Ethereum addresses and can be transferred between such addresses. Identities can use the [claims](/docs/glossary/claims) contract to make assertions – real-world or otherwise – about their owner.
77
8−The primary way to interact with Azimuth and to manage your identities is through our [Bridge](https://bridge.urbit.org) application. Bridge is a front-end for [Ecliptic](../ecliptic), the Azimuth contract that's used to perform actions on the blockchain.
8+The primary way to interact with Azimuth and to manage your identities is through our [Bridge](https://bridge.urbit.org) application. Bridge is a front-end for [Ecliptic](/docs/glossary/ecliptic), the Azimuth contract that's used to perform actions on the blockchain.
99
10−There are a limited number of Azimuth identities which results in identities having value. This allows for identities to function as reputation primitives, since such scarcity creates an economic incentive for identities to remain static and to keep the network friendly. Undesirable behavior – spamming, scamming, and malware-spreading - will generally result in a [censure](../censure) from [galaxies](../galaxy) and [stars](../star), marking the bad actor.
10+There are a limited number of Azimuth identities which results in identities having value. This allows for identities to function as reputation primitives, since such scarcity creates an economic incentive for identities to remain static and to keep the network friendly. Undesirable behavior – spamming, scamming, and malware-spreading - will generally result in a [censure](/docs/glossary/censure) from [galaxies](/docs/glossary/galaxy) and [stars](/docs/glossary/star), marking the bad actor.
1111
1212It should be noted that Azimuth isn't built just for Arvo. It can be used as an identity system for other projects.
1313
content/docs/glossary/battery.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **battery** is a collection of Hoon expressions and the head of a [core](../core).
9+A **battery** is a collection of Hoon expressions and the head of a [core](/docs/glossary/core).
1010
1111### Further Reading
1212
content/docs/glossary/behn.md+2−2
@@ -5,9 +5,9 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−**Behn** is the timing [vane](../filesystem). It allows for applications to schedule events, which are managed in a simple priority queue. For example, [Clay](../clay), the Urbit filesystem, uses Behn to keep track of time-specific file requests. [Eyre](../eyre), the Urbit web vane, uses Behn for timing-out HTTP sessions.
8+**Behn** is the timing [vane](/docs/glossary/filesystem). It allows for applications to schedule events, which are managed in a simple priority queue. For example, [Clay](/docs/glossary/clay), the Urbit filesystem, uses Behn to keep track of time-specific file requests. [Eyre](/docs/glossary/eyre), the Urbit web vane, uses Behn for timing-out HTTP sessions.
99
10−Behn is located in `/home/sys/vane/behn.hoon` within [Arvo](../arvo).
10+Behn is located in `/home/sys/vane/behn.hoon` within [Arvo](/docs/glossary/arvo).
1111
1212### Further Reading
1313
content/docs/glossary/breach.md+3−3
@@ -5,18 +5,18 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−Continuity on the [Ames](../ames) network occasionally needs to be broken
8+Continuity on the [Ames](/docs/glossary/ames) network occasionally needs to be broken
99(though with increasing rarity) in order to correct a networking error. These
1010infrequent events are known as **breaches**, which cause an individual ship to
1111forget its network message history.
1212
1313Breaches are always initiated by the user, frequently in response to a
14−connectivity error. The easiest way to do this is with [Bridge](../bridge).
14+connectivity error. The easiest way to do this is with [Bridge](/docs/glossary/bridge).
1515There are two types of personal breaches: changing networking keys, and changing
1616the Urbit ID ownership address.
1717
1818Historically, there were also "network breaches", which happened when a major
19−Arvo revision that could not be implemented via an [OTA update](../ota-updates)
19+Arvo revision that could not be implemented via an [OTA update](/docs/glossary/ota-updates)
2020occured. Network breaches were effectively breaching every ship on the network
2121at once. The most recent network breach occurred in December 2020, and we expect
2222it to be the final one.
content/docs/glossary/bridge.md+2−2
@@ -5,7 +5,7 @@ template = "doc.html"
55category = "azimuth"
66+++
77
8−**Bridge** is a client made for interacting with [Azimuth](../azimuth). It's the recommended way to receive, send, and manage your Urbit identity, and it's by far the easiest way to generate the [keyfile](../keyfile) required to get your [ship](../ship) onto the [Arvo](../arvo) network. Most Bridge functions are accessed by "logging in" to an identity's ownership address or one of its [proxy addresses](../proxies). It's accessed at [bridge.urbit.org](https://bridge.urbit.org/).
8+**Bridge** is a client made for interacting with [Azimuth](/docs/glossary/azimuth). It's the recommended way to receive, send, and manage your Urbit identity, and it's by far the easiest way to generate the [keyfile](/docs/glossary/keyfile) required to get your [ship](/docs/glossary/ship) onto the [Arvo](/docs/glossary/arvo) network. Most Bridge functions are accessed by "logging in" to an identity's ownership address or one of its [proxy addresses](/docs/glossary/proxies). It's accessed at [bridge.urbit.org](https://bridge.urbit.org/).
99
1010Below are some important functions of Bridge.
1111
@@ -15,7 +15,7 @@ This function allows you to view the public information of any Urbit identity, s
1515
1616#### Actions
1717
18−- **Issue child:** Spawn a child from a [galaxy](../galaxy) or a [star](../star).
18+- **Issue child:** Spawn a child from a [galaxy](/docs/glossary/galaxy) or a [star](/docs/glossary/star).
1919- **Transfer:** Send the Urbit identity to another Ethereum address.
2020- **Accept incoming transfer:** If someone is trying to send you an Urbit identity, you must use this action to receive it.
2121- **Cancel outgoing transfer:** Cancel a transfer that you initiated before the recipient has accepted it.
content/docs/glossary/censure.md+1−1
@@ -5,7 +5,7 @@ template = "doc.html"
55category = "azimuth"
66+++
77
8−The **Censures** [Azimuth](../azimuth) contract allows [stars](../star) and [galaxies](../galaxy) to assign negative reputation information to other points of equal or lower rank. This information is publicly visible and is intended to create an economic deterrent to bad behavior.
8+The **Censures** [Azimuth](/docs/glossary/azimuth) contract allows [stars](/docs/glossary/star) and [galaxies](/docs/glossary/galaxy) to assign negative reputation information to other points of equal or lower rank. This information is publicly visible and is intended to create an economic deterrent to bad behavior.
99
1010Positive reputation information cannot be similarly assigned to Urbit identities but it may be inferred from a lack of censures.
1111
content/docs/glossary/ceremony.md+1−1
@@ -5,4 +5,4 @@ template = "doc.html"
55category = "azimuth"
66+++
77
8−The **ceremony** or **launch ceremony** was the event that transferred custody of [Azimuth](../Azimuth) identities from a centralized ledger to the Ethereum blockchain. Before the ceremony, the Tlon Corporation kept track of ownership in a spreadsheet. The ceremony created Ethereum tokens for those entries and transferred them to the appropriate [HD Wallets](../hdwallet).
8+The **ceremony** or **launch ceremony** was the event that transferred custody of [Azimuth](/docs/glossary/Azimuth) identities from a centralized ledger to the Ethereum blockchain. Before the ceremony, the Tlon Corporation kept track of ownership in a spreadsheet. The ceremony created Ethereum tokens for those entries and transferred them to the appropriate [HD Wallets](/docs/glossary/hdwallet).
content/docs/glossary/chat.md+3−3
@@ -6,8 +6,8 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Chat** is a suite of [Gall](../gall) applications that handle "instant
10−messaging"-style communication between [ships](../ship).
9+**Chat** is a suite of [Gall](/docs/glossary/gall) applications that handle "instant
10+messaging"-style communication between [ships](/docs/glossary/ship).
1111
1212A chat is a named collection of messages created by and hosted in a ship's
1313`chat-store`. Most of Chat revolves around doing things with these chats.
@@ -27,6 +27,6 @@ There are two "kinds" of chats:
2727
2828### Further Reading
2929
30−- [Landscape](../landscape) includes a web interface for using Chat.
30+- [Landscape](/docs/glossary/landscape) includes a web interface for using Chat.
3131- [Messaging guide](/using/os/messaging): A guide to
3232 using Chat from the command line.
content/docs/glossary/claims.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Claims** [Azimuth](../azimuth) contract allows Urbit identities to make publicly visible assertions about their owner. Such assertions are most commonly about the owner's identity, real-world or otherwise. A claim has three fields: the claim itself, the _protocol_, and the _dossier_.
9+The **Claims** [Azimuth](/docs/glossary/azimuth) contract allows Urbit identities to make publicly visible assertions about their owner. Such assertions are most commonly about the owner's identity, real-world or otherwise. A claim has three fields: the claim itself, the _protocol_, and the _dossier_.
1010
1111The claim itself is what you're attempting to assert the identity of, as in `@JohnDoe` for a Twitter account, or `1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa`
1212
content/docs/glossary/clay.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Clay** is the filesystem and typed revision-control [vane](../vane). It can be thought of as a continuously synced git. Clay handles file-change events and maps them from [Arvo](../arvo) to Unix and vice versa.
9+**Clay** is the filesystem and typed revision-control [vane](/docs/glossary/vane). It can be thought of as a continuously synced git. Clay handles file-change events and maps them from [Arvo](/docs/glossary/arvo) to Unix and vice versa.
1010
1111A common way to use Clay is to create a pier, a directory that exists in and is visible in Unix. Changes are automatically recorded from Urbit to the Unix directory and vice versa. Just set it and forget it!
1212
content/docs/glossary/comet.md+6−6
@@ -5,26 +5,26 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−A **comet** is a kind of [ship](../ship) on the [Ames](../ames) network which
8+A **comet** is a kind of [ship](/docs/glossary/ship) on the [Ames](/docs/glossary/ames) network which
99may be quickly generated by anyone and which are virtually unlimited. They have
1010many uses, including but not limited to:
11−- free identities for new users to try things out before deciding to purchase a [planet](../planet).
11+- free identities for new users to try things out before deciding to purchase a [planet](/docs/glossary/planet).
1212- bots
1313- remaining anonymous
1414- testing software
1515
1616Comets have nearly all the same capabilities as a planet. The restrictions they
1717do possess are technical constraints of the system due primarily to the fact that they
18−have no presence on [Azimuth](../azimuth), rather than purposefully placed
18+have no presence on [Azimuth](/docs/glossary/azimuth), rather than purposefully placed
1919blockades.
20− - They may not [change their networking keys](../bridge).
21− - They may not spawn [moons](../moon).
20+ - They may not [change their networking keys](/docs/glossary/bridge).
21+ - They may not spawn [moons](/docs/glossary/moon).
2222 - They must initiate all direct messages with other ships.
2323The last constraint has a workaround slated. If you wish to change your
2424networking keys, we suggest generating a new comet. Moons are impossible for
2525comets due to the structure of the address space.
2626
27−Some groups on [Landscape](../landscape) may not allow comet membership, but this is rare.
27+Some groups on [Landscape](/docs/glossary/landscape) may not allow comet membership, but this is rare.
2828
2929
3030### Further reading
content/docs/glossary/core.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **core** is a cell of a [battery](../battery) and a [payload](../payload). It is a Hoon construct similar in use to Objects in Object Oriented programming languages.
9+A **core** is a cell of a [battery](/docs/glossary/battery) and a [payload](/docs/glossary/payload). It is a Hoon construct similar in use to Objects in Object Oriented programming languages.
1010
1111### Further Reading
1212
content/docs/glossary/delegated-sending.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Delegated Sending** [Azimuth](../azimuth) contract is a way that a [star](../star ) distributes [planets](../planet). After a star configures the Delegated Sending contract as its [spawn proxy](../proxies) it can give invites to planets, and those invitees can subsequently send additional planets from that star to their friends, and pass on this invite power indefinitely. This contract keeps track of those operations in the form of the [Invite Tree](../invite-tree), so the relationship between inviters and invitees is publicly known.
9+The **Delegated Sending** [Azimuth](/docs/glossary/azimuth) contract is a way that a [star](/docs/glossary/star ) distributes [planets](/docs/glossary/planet). After a star configures the Delegated Sending contract as its [spawn proxy](/docs/glossary/proxies) it can give invites to planets, and those invitees can subsequently send additional planets from that star to their friends, and pass on this invite power indefinitely. This contract keeps track of those operations in the form of the [Invite Tree](/docs/glossary/invite-tree), so the relationship between inviters and invitees is publicly known.
content/docs/glossary/desk.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **desk** is an independently revision-controlled branch of a [ship](../ship) that uses the [Clay](../clay) filesystem. Each desk contains its own apps, [mark](../mark) definitions, files, and so forth.
9+A **desk** is an independently revision-controlled branch of a [ship](/docs/glossary/ship) that uses the [Clay](/docs/glossary/clay) filesystem. Each desk contains its own apps, [mark](/docs/glossary/mark) definitions, files, and so forth.
1010
1111Traditionally a ship has at least a base desk and a home desk. The base desk has all the system software from the distribution, and the home desk is a fork of base with all the items specific to the user of the ship. A desk is a series of numbered commits, the most recent of which represents the current state of the desk. A commit is composed of `1` an absolute time when it was created, `2` a list of zero or more parents, and `3` a map from paths to data.
1212
content/docs/glossary/dill.md+2−2
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Dill** is the terminal-driver [vane](../filesystem). You run your urbit in your Unix terminal, and Unix sends every event –⁠
9+**Dill** is the terminal-driver [vane](/docs/glossary/filesystem). You run your urbit in your Unix terminal, and Unix sends every event –⁠
1010such as a keystroke or a change in the dimensions of the terminal window –⁠ to be handled by Dill. Dill acts as an intermediary for anything that uses keyboard events, which results in a slight input lag in Urbit’s command-line interface.
1111
1212A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined as diagrammed below:
@@ -15,7 +15,7 @@ A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined a
1515Keystroke in Unix -> Vere (virtual machine) -> Arvo -> Dill -> the Dojo
1616```
1717
18−Dill is located at `/home/sys/vane/dill.hoon` within [Arvo](../arvo).
18+Dill is located at `/home/sys/vane/dill.hoon` within [Arvo](/docs/glossary/arvo).
1919
2020### Further Reading
2121
content/docs/glossary/docvote.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−A **document proposal** is a type of [vote](../voting) action taken by the [Galactic Senate](../senate) over [Azimuth](../azimuth). By passing a document proposal, [Galaxies](../galaxy) in the Senate agree legitimize a document with arbitrary content. Such a document might make claims about the state of the world; an example document that would be subject to this type of vote might be a file that says, "@urbit_senate is the official Twitter account of the senate, and is to be managed by John Doe until further notice."
9+A **document proposal** is a type of [vote](/docs/glossary/voting) action taken by the [Galactic Senate](/docs/glossary/senate) over [Azimuth](/docs/glossary/azimuth). By passing a document proposal, [Galaxies](/docs/glossary/galaxy) in the Senate agree legitimize a document with arbitrary content. Such a document might make claims about the state of the world; an example document that would be subject to this type of vote might be a file that says, "@urbit_senate is the official Twitter account of the senate, and is to be managed by John Doe until further notice."
content/docs/glossary/dojo.md+3−3
@@ -5,10 +5,10 @@ title = "Dojo"
55category = "arvo"
66+++
77
8−The **Dojo** is Urbit's command-line application that processes system commands and returns output. It also runs [Hoon](../hoon) and [Nock](../nock) code, making it a good place to play around with those languages.
8+The **Dojo** is Urbit's command-line application that processes system commands and returns output. It also runs [Hoon](/docs/glossary/hoon) and [Nock](/docs/glossary/nock) code, making it a good place to play around with those languages.
99
10−The other default command-line app is [Chat](../chat). To switch between Dojo
11−and [Chat](../chat) press Ctrl-X. The Dojo is the first thing you encounter after successfully booting your [ship](../ship).
10+The other default command-line app is [Chat](/docs/glossary/chat). To switch between Dojo
11+and [Chat](/docs/glossary/chat) press Ctrl-X. The Dojo is the first thing you encounter after successfully booting your [ship](/docs/glossary/ship).
1212
1313### Further Reading
1414- [Hoon Tutorial Lesson 1.1: Setup](/docs/hoon/hoon-school/setup): A great way to get started with using Hoon in the Dojo.
content/docs/glossary/door.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **door** is a [core](../core) the payload of which is a cell of sample and context.
9+A **door** is a [core](/docs/glossary/core) the payload of which is a cell of sample and context.
1010
1111### Further Reading
1212
content/docs/glossary/ecliptic.md+3−3
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Ecliptic** contract sets the rules for what is and is not possible on Azimuth. It's the point of entry for interacting with the [Azimuth](../azimuth) ledger data; the Azimuth contract itself is just data, and the Ecliptic contract is the logic for controlling that data. Examples of such logic include verifying permissions of the person asking to access their data, and ensuring a requested change is actually valid.
9+The **Ecliptic** contract sets the rules for what is and is not possible on Azimuth. It's the point of entry for interacting with the [Azimuth](/docs/glossary/azimuth) ledger data; the Azimuth contract itself is just data, and the Ecliptic contract is the logic for controlling that data. Examples of such logic include verifying permissions of the person asking to access their data, and ensuring a requested change is actually valid.
1010
11−The Senate (the voting body of [galaxies](../galaxy)) has the power to replace
12−Ecliptic via an [upgrade proposal](../upgrade).
11+The Senate (the voting body of [galaxies](/docs/glossary/galaxy)) has the power to replace
12+Ecliptic via an [upgrade proposal](/docs/glossary/upgrade).
content/docs/glossary/eventlog.md+4−4
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−The **event log** of a [ship](../ship) is a totally ordered list of every single [Arvo](../arvo) event that ship has undergone. The state of a ship is a pure function of the event log.
9+The **event log** of a [ship](/docs/glossary/ship) is a totally ordered list of every single [Arvo](/docs/glossary/arvo) event that ship has undergone. The state of a ship is a pure function of the event log.
1010
11−The event log is maintained by [Vere](../vere).
11+The event log is maintained by [Vere](/docs/glossary/vere).
1212
1313If the physical machine loses power and your urbit's state is 'lost' from memory, when your urbit restarts it will replay its entire event log and recover its last valid state from scratch.
1414
@@ -16,8 +16,8 @@ In practice, event logs become large and unwieldy over time. Periodically a snap
1616
1717Persistence, in the context of storing data in a computer system, means that data is stored in a non-volatile manner and that input must be recorded before the output result is performed. Thus, every event must be written to disk - or must be _persisted_ - before the event effects actually take place.
1818
19−The initial entries of the event log are created during the bootstrap sequence contained in a [Pill](../pill).
19+The initial entries of the event log are created during the bootstrap sequence contained in a [Pill](/docs/glossary/pill).
2020
2121### Further Reading
2222
23−- [Pier](../pier): The directory on disk which contains the ship's state.
23+- [Pier](/docs/glossary/pier): The directory on disk which contains the ship's state.
content/docs/glossary/eyre.md+3−3
@@ -6,11 +6,11 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Eyre** is the web-server [vane](../vane) that handles client-facing HTTP operations. Unix sends HTTP messages though to Eyre and Eyre produces HTTP messages in response. It is the counterpart to [Iris](../iris), which is the server-facing HTTP vane.
9+**Eyre** is the web-server [vane](/docs/glossary/vane) that handles client-facing HTTP operations. Unix sends HTTP messages though to Eyre and Eyre produces HTTP messages in response. It is the counterpart to [Iris](/docs/glossary/iris), which is the server-facing HTTP vane.
1010
11−In general, apps and vanes do not call Eyre; rather, Eyre calls apps and vanes. Eyre uses [Ford](../ford) and [Gall](../gall) to functionally publish pages and facilitate communication with apps.
11+In general, apps and vanes do not call Eyre; rather, Eyre calls apps and vanes. Eyre uses [Ford](/docs/glossary/ford) and [Gall](/docs/glossary/gall) to functionally publish pages and facilitate communication with apps.
1212
13−Eyre is located at `/home/sys/vane/eyre.hoon` within [Arvo](../arvo).
13+Eyre is located at `/home/sys/vane/eyre.hoon` within [Arvo](/docs/glossary/arvo).
1414
1515### Further Reading
1616
content/docs/glossary/ford.md+3−3
@@ -6,11 +6,11 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Ford** is the build-system [vane](../vane). Ford is capable of sequencing generic asynchronous computations. Its uses include linking source files into programs, assembling live-updating websites, and performing file-type conversions.
9+**Ford** is the build-system [vane](/docs/glossary/vane). Ford is capable of sequencing generic asynchronous computations. Its uses include linking source files into programs, assembling live-updating websites, and performing file-type conversions.
1010
11−Ford neither accepts Unix events nor produces Unix effects. It exists entirely for the benefit of [Arvo](../arvo) applications and other vanes, specifically [Clay](../clay) and [Gall](../gall).
11+Ford neither accepts Unix events nor produces Unix effects. It exists entirely for the benefit of [Arvo](/docs/glossary/arvo) applications and other vanes, specifically [Clay](/docs/glossary/clay) and [Gall](/docs/glossary/gall).
1212
13−Ford is located at `/home/sys/vane/ford.hoon` within [Arvo](../arvo).
13+Ford is located at `/home/sys/vane/ford.hoon` within [Arvo](/docs/glossary/arvo).
1414
1515### Further Reading
1616
content/docs/glossary/galaxy.md+3−3
@@ -8,8 +8,8 @@ category = "arvo"
88
99A **galaxy** can be one of two related things:
1010
11−- A kind of [Azimuth](../azimuth) Urbit identity that sits at the top of the identity hierarchy. Galaxies, in this sense, have the power to issue [stars](../star), meaning that all other kinds of identities ultimate derive from galaxies. Galaxies also form a [Senate](../senate), the governing body of Azimuth. The Senate has the power to update the logic of Azimuth by [majority vote](../voting).
11+- A kind of [Azimuth](/docs/glossary/azimuth) Urbit identity that sits at the top of the identity hierarchy. Galaxies, in this sense, have the power to issue [stars](/docs/glossary/star), meaning that all other kinds of identities ultimate derive from galaxies. Galaxies also form a [Senate](/docs/glossary/senate), the governing body of Azimuth. The Senate has the power to update the logic of Azimuth by [majority vote](/docs/glossary/voting).
1212
13−- A [ship](../ship) on the Arvo network whose identity is a planet in the former definition. In this sense, galaxies act as infrastructure for the [Arvo](../arvo) network, providing [Ames](../ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](../ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
13+- A [ship](/docs/glossary/ship) on the Arvo network whose identity is a planet in the former definition. In this sense, galaxies act as infrastructure for the [Arvo](/docs/glossary/arvo) network, providing [Ames](/docs/glossary/ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](/docs/glossary/ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
1414
15−Galaxies are 8-bit, representable by numbers 0 to 255. This means that there are 256 possible galaxies; each of these galaxies is able to issue 255 [stars](../star). Galaxies have one-syllable names like `~mul` or `~lux`.
15+Galaxies are 8-bit, representable by numbers 0 to 255. This means that there are 256 possible galaxies; each of these galaxies is able to issue 255 [stars](/docs/glossary/star). Galaxies have one-syllable names like `~mul` or `~lux`.
content/docs/glossary/gall.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**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.
9+**Gall** is the application-management [vane](/docs/glossary/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](/docs/glossary/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](/docs/glossary/ship), Gall will route it behind the scenes through [Ames](/docs/glossary/ames) to the other ship.
1010
1111Gall is located at `/home/sys/vane/gall.hoon` within Arvo.
1212
content/docs/glossary/gate.md+2−2
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **gate** is [core](../core) with one [arm](../arm) named $. They are often called Hoon Functions because they have many of the same properties of functions from other programming languages.
9+A **gate** is [core](/docs/glossary/core) with one [arm](/docs/glossary/arm) named $. They are often called Hoon Functions because they have many of the same properties of functions from other programming languages.
1010
1111### Further Reading
1212
1313- [The Hoon Tutorial](/docs/hoon/hoon-school/): Our guide to learning the Hoon programming language.
14−- [Lesson 1.4 Gates](/docs/hoon/hoon-school/gates): A Hoon tutorial lesson about gates.
14+- [Lesson 1.4 Gates](/docs/hoon/hoon-school/gates): A Hoon tutorial lesson about gates.
content/docs/glossary/hdwallet.md+2−2
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Urbit HD Wallet** (_Hierarchical Deterministic_ Wallet) is a system of related Ethereum addresses that's used to store and manage an Urbit identity. Each of these Ethereum addresses have different powers over the same identity, from setting networking keys for communicating in the [Arvo](../arvo) network to transferring ownership of identities. HD Wallets are created with the [Wallet Generator](../wallet-generator) software.
9+The **Urbit HD Wallet** (_Hierarchical Deterministic_ Wallet) is a system of related Ethereum addresses that's used to store and manage an Urbit identity. Each of these Ethereum addresses have different powers over the same identity, from setting networking keys for communicating in the [Arvo](/docs/glossary/arvo) network to transferring ownership of identities. HD Wallets are created with the [Wallet Generator](/docs/glossary/wallet-generator) software.
1010
11−The Ethereum address that has full powers over a given Urbit identity, including the ability to transfer ownership of the identity, is called the ownership address. Ethereum addresses with fewer powers – the ability to transfer ownership being notably absent – are known as [proxies](../proxies). This scheme of compartmentalized powers allows wallet holders to only handle less valuable keys when they want to perform operations on an Urbit identity without risking their entire asset.
11+The Ethereum address that has full powers over a given Urbit identity, including the ability to transfer ownership of the identity, is called the ownership address. Ethereum addresses with fewer powers – the ability to transfer ownership being notably absent – are known as [proxies](/docs/glossary/proxies). This scheme of compartmentalized powers allows wallet holders to only handle less valuable keys when they want to perform operations on an Urbit identity without risking their entire asset.
1212
1313If a proxy or ownership address is compromised or has its keys lost, it can always be rederived using the master ticket, which is the piece of entropy that was initially used to derive the HD wallet.
1414
content/docs/glossary/hoon.md+1−1
@@ -4,7 +4,7 @@ title = "Hoon"
44template = "doc.html"
55+++
66
7−Hoon is a strict, higher-order typed functional programming language that compiles itself to [Nock](../nock). As a result Hoon code is effectively implemented by the interpreter [Vere](../vere). Programs for the Urbit operating system and kernel, [Arvo](../arvo), are written in Hoon.
7+Hoon is a strict, higher-order typed functional programming language that compiles itself to [Nock](/docs/glossary/nock). As a result Hoon code is effectively implemented by the interpreter [Vere](/docs/glossary/vere). Programs for the Urbit operating system and kernel, [Arvo](/docs/glossary/arvo), are written in Hoon.
88
99The Hoon source file is located in `/home/sys/hoon.hoon` within your Urbit.
1010
content/docs/glossary/invite-tree.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Invite Tree** is the state stored by the [Delegated Sending](../delegated-sending) contract on [Azimuth](../azimuth), and is a record of who gave a [planet](../planet) to whom. This allows for community applications, such as a chat channel for all distantly related planets.
9+The **Invite Tree** is the state stored by the [Delegated Sending](/docs/glossary/delegated-sending) contract on [Azimuth](/docs/glossary/azimuth), and is a record of who gave a [planet](/docs/glossary/planet) to whom. This allows for community applications, such as a chat channel for all distantly related planets.
content/docs/glossary/iris.md+2−2
@@ -6,6 +6,6 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Iris** is the web-server [vane](../vane) that handles everything HTTP-related on the server side. It is the counterpart to [Eyre](../eyre), which is the client-facing HTTP vane.
9+**Iris** is the web-server [vane](/docs/glossary/vane) that handles everything HTTP-related on the server side. It is the counterpart to [Eyre](/docs/glossary/eyre), which is the client-facing HTTP vane.
1010
11−Iris is located at `/home/sys/vane/iris.hoon` within [Arvo](../arvo).
11+Iris is located at `/home/sys/vane/iris.hoon` within [Arvo](/docs/glossary/arvo).
content/docs/glossary/jael.md+1−1
@@ -5,4 +5,4 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−**Jael** is the [vane](../vane) that keeps track of [Azimuth](../azimuth) related information. For each [ship](../ship), this consists of its networking keys, its revision number (or _life_), its breach number, and who the sponsor of the ship is.
8+**Jael** is the [vane](/docs/glossary/vane) that keeps track of [Azimuth](/docs/glossary/azimuth) related information. For each [ship](/docs/glossary/ship), this consists of its networking keys, its revision number (or _life_), its breach number, and who the sponsor of the ship is.
content/docs/glossary/jaque.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−**Jaque** is a new [Nock](../nock) interpreter under development that is intended to replace the current worker process for [Vere](../vere).
9+**Jaque** is a new [Nock](/docs/glossary/nock) interpreter under development that is intended to replace the current worker process for [Vere](/docs/glossary/vere).
1010
1111The current worker utilized by Vere is written in C, while Jaque is written using Java. The primary benefits of switching to Java are the ecosystem benefits and the fact that Java is more memory safe than C.
1212
content/docs/glossary/keyfile.md+2−2
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−A **keyfile** is a piece of information used to associate a [ship](../ship) with an Urbit identity so that the ship can use the [Arvo](../arvo) network. A keyfile is dependent upon the [networking keys](../bridge) that have been set for the identity; we recommend using [Bridge](../bridge) to set the networking keys and to generate the corresponding keyfile.
9+A **keyfile** is a piece of information used to associate a [ship](/docs/glossary/ship) with an Urbit identity so that the ship can use the [Arvo](/docs/glossary/arvo) network. A keyfile is dependent upon the [networking keys](/docs/glossary/bridge) that have been set for the identity; we recommend using [Bridge](/docs/glossary/bridge) to set the networking keys and to generate the corresponding keyfile.
1010
11−The keyfile is used as an argument in the command line when booting a ship. During the boot process, [Vere](../vere) passes the keyfile into the Arvo state.
11+The keyfile is used as an argument in the command line when booting a ship. During the boot process, [Vere](/docs/glossary/vere) passes the keyfile into the Arvo state.
1212
1313### Further Reading
1414
content/docs/glossary/landscape.md+2−2
@@ -6,6 +6,6 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Landscape** is a graphical web interface for your [ship](../ship). Right now, Landscape allows for social networking functions, such as to participating in IRC-like chats such as `~/~dopzod/urbit-help`, subscribing to forum-like pages of other ships called Notebooks, and message other ships directly. It also has weather and clock apps. Landscape is an alternative messaging interface to the command-line app [Chat](../chat).
9+**Landscape** is a graphical web interface for your [ship](/docs/glossary/ship). Right now, Landscape allows for social networking functions, such as to participating in IRC-like chats such as `~/~dopzod/urbit-help`, subscribing to forum-like pages of other ships called Notebooks, and message other ships directly. It also has weather and clock apps. Landscape is an alternative messaging interface to the command-line app [Chat](/docs/glossary/chat).
1010
11−Landscape can be accessed with a browser via [ship.arvo.network](../shiparvonetwork) or by `localhost:80`. You'll be greeted with a login prompt; type `+code` into your [Dojo](../dojo), and use the output as your password.
11+Landscape can be accessed with a browser via [ship.arvo.network](/docs/glossary/shiparvonetwork) or by `localhost:80`. You'll be greeted with a login prompt; type `+code` into your [Dojo](/docs/glossary/dojo), and use the output as your password.
content/docs/glossary/mark.md+2−2
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **mark** is a file-type in the [Clay](../clay) filesystem. A mark is a file that defines filesystem information such as type, merge routines, diff routines, and patch algorithms.
9+A **mark** is a file-type in the [Clay](/docs/glossary/clay) filesystem. A mark is a file that defines filesystem information such as type, merge routines, diff routines, and patch algorithms.
1010
11−The [Ford](../ford) [vane](../vane) converts data between marks and validates data into marks.
11+The [Ford](/docs/glossary/ford) [vane](/docs/glossary/vane) converts data between marks and validates data into marks.
1212
1313
1414### Further Reading
content/docs/glossary/moon.md+4−4
@@ -5,9 +5,9 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−A **moon** is a kind of [ship](../ship) on the [Arvo](../arvo) network. Moons
9−are child identities issued by [planets](../planet), [stars](../stars), and
10−[galaxies](../galaxy). A moon is not independent; it is always subordinate to
8+A **moon** is a kind of [ship](/docs/glossary/ship) on the [Arvo](/docs/glossary/arvo) network. Moons
9+are child identities issued by [planets](/docs/glossary/planet), [stars](/docs/glossary/stars), and
10+[galaxies](/docs/glossary/galaxy). A moon is not independent; it is always subordinate to
1111the ship that issued it. By this we mean that the networking keys for the moon
1212are controlled by the parent, and may be altered or revoked at any time by that parent.
1313
@@ -21,7 +21,7 @@ Looking towards the future, we expect moons to also be utilized as identities
2121for devices, such as such as phones, desktops, smart TVs, and digital thermostats
2222
2323Unlike planets, stars, and galaxies, moons have no presence on
24−[Azimuth](../azimuth). Moons are representable with 64 bits and have long names
24+[Azimuth](/docs/glossary/azimuth). Moons are representable with 64 bits and have long names
2525like `~doznec-salfun-naptul-habrys`, the latter half of which is inherited from
2626their parent planet.
2727
content/docs/glossary/nock.md+3−3
@@ -4,13 +4,13 @@ title = "Nock"
44template = "doc.html"
55+++
66
7−**Nock** is a purely functional typeless programming language and acts as Urbit's lowest-level language. To be more precise, it is a Turing complete combinator interpreter not based on the lambda calculus. It could be thought of as the assembly-level language of Urbit, and is implemented by the runtime system [Vere](../vere).
7+**Nock** is a purely functional typeless programming language and acts as Urbit's lowest-level language. To be more precise, it is a Turing complete combinator interpreter not based on the lambda calculus. It could be thought of as the assembly-level language of Urbit, and is implemented by the runtime system [Vere](/docs/glossary/vere).
88
99[comment]: # ("combinator interpreter" is from the old glossary, but I don't know what is meant by this and there only seems to be a few uses of it online according to google, so maybe there is a better term we can use here, or give more of an explanation of what is meant by this? but maybe that is not appropriate for a glossary)
1010
11−The only basic data type in Nock is the [atom](../atom), which is a non-negative integer. Computation in Nock occurs through the use of [nouns](../noun) (e.g. binary trees whose leaves are atoms) utilized in three different manners: formulas, subjects, and products. A _formula_ is a noun utilized as a function that takes in a noun, its _subject_, and returns a noun, its _product_.
11+The only basic data type in Nock is the [atom](/docs/glossary/atom), which is a non-negative integer. Computation in Nock occurs through the use of [nouns](/docs/glossary/noun) (e.g. binary trees whose leaves are atoms) utilized in three different manners: formulas, subjects, and products. A _formula_ is a noun utilized as a function that takes in a noun, its _subject_, and returns a noun, its _product_.
1212
13−Code written in [Hoon](../hoon) is compiled to Nock, though it is unnecessary to learn Nock to write code in Hoon.
13+Code written in [Hoon](/docs/glossary/hoon) is compiled to Nock, though it is unnecessary to learn Nock to write code in Hoon.
1414
1515### Further Reading
1616
content/docs/glossary/noun.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **noun** is an [atom](../atom) or a cell, which is an ordered pair of nouns. This definition is recursive and ultimately means that a noun is a finite size binary tree whose leaves are atoms. A noun is the basic data structure in [Nock](../nock).
9+A **noun** is an [atom](/docs/glossary/atom) or a cell, which is an ordered pair of nouns. This definition is recursive and ultimately means that a noun is a finite size binary tree whose leaves are atoms. A noun is the basic data structure in [Nock](/docs/glossary/nock).
1010
1111### Further Reading
1212
content/docs/glossary/ota-updates.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−[Ships](../ship) have the ability to upgrade themselves **over the air**. They receive updates from a sponsor [star](../star) or [galaxy](../galaxy).
9+[Ships](/docs/glossary/ship) have the ability to upgrade themselves **over the air**. They receive updates from a sponsor [star](/docs/glossary/star) or [galaxy](/docs/glossary/galaxy).
content/docs/glossary/payload.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **payload** is the set of data needed to run computations in a [core](../core)
9+A **payload** is the set of data needed to run computations in a [core](/docs/glossary/core)
1010
1111### Further Reading
1212
content/docs/glossary/ph.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**pH** is a [Gall](../gall) app that is a framework for fleet testing using [Aqua](../aqua). pH comes with a number of default tests, as well as tools for building and executing custom tests.
9+**pH** is a [Gall](/docs/glossary/gall) app that is a framework for fleet testing using [Aqua](/docs/glossary/aqua). pH comes with a number of default tests, as well as tools for building and executing custom tests.
content/docs/glossary/pier.md+3−3
@@ -5,14 +5,14 @@ template = "doc.html"
55category = "arvo"
66+++
77
8−A **pier** is the directory which contains the state of an Urbit [ship](../ship). It is automatically created in the current directory when booting a ship for the first time.
8+A **pier** is the directory which contains the state of an Urbit [ship](/docs/glossary/ship). It is automatically created in the current directory when booting a ship for the first time.
99
10−Your pier should be kept safe - if it's deleted, you will need to perform a [breach](../breach) in order to advise the rest of the network that your ship's state has been lost.
10+Your pier should be kept safe - if it's deleted, you will need to perform a [breach](/docs/glossary/breach) in order to advise the rest of the network that your ship's state has been lost.
1111
1212Note that a backup should usually _not_ be taken of your pier as a means of keeping it safe - once the ship is run on the network, the backup will be outdated and running from it will necessitate a breach. A running ship automatically backs up its own state within the pier directory for recovery purposes, so as long as the pier is preserved, recovery from most problems is possible.
1313
1414### Further Reading
1515
16−- [Event Log](../eventlog): The main important content of the pier directory.
16+- [Event Log](/docs/glossary/eventlog): The main important content of the pier directory.
1717- [A Guide to Breaches](/using/id/guide-to-breaches): Instructions on handling continuity breaches (resets) on the Ames network.
1818- [Ship Troubleshooting](/using/os/ship-troubleshooting): General instructions on getting your ship to work, which includes network connectivity issues.
content/docs/glossary/pill.md+3−3
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **Pill** is a bootstrap sequence to launch an Urbit ship for the first time. The [event log](../eventlog) begins with the bootstrap sequence of a Pill.
9+A **Pill** is a bootstrap sequence to launch an Urbit ship for the first time. The [event log](/docs/glossary/eventlog) begins with the bootstrap sequence of a Pill.
1010
1111A Pill consists of three ordered lists:
12− * A list of events which are interpreted by Nock to create an [Arvo](../arvo) kernel.
12+ * A list of events which are interpreted by Nock to create an [Arvo](/docs/glossary/arvo) kernel.
1313 * A list of Arvo events to run once the Arvo kernel is created.
14− * A list of userspace events to run once the Arvo events have been run. Currently, this consists of setting up the [Clay](../clay) file system.
14+ * A list of userspace events to run once the Arvo events have been run. Currently, this consists of setting up the [Clay](/docs/glossary/clay) file system.
content/docs/glossary/planet.md+2−2
@@ -8,8 +8,8 @@ category = "arvo"
88
99A **planet** is can be one of two related things:
1010
11−- A kind of [Azimuth](../azimuth) Urbit identity that sits at the bottom of the identity hierarchy. Planets act as independent identities for use by individual humans as peers on the [Arvo](../arvo) network. Planets are issued by [stars](../star), and receive services such as peer-to-peer routing and [over-the-air software updates](../ota-updates) from the star that sponsors them.
11+- A kind of [Azimuth](/docs/glossary/azimuth) Urbit identity that sits at the bottom of the identity hierarchy. Planets act as independent identities for use by individual humans as peers on the [Arvo](/docs/glossary/arvo) network. Planets are issued by [stars](/docs/glossary/star), and receive services such as peer-to-peer routing and [over-the-air software updates](/docs/glossary/ota-updates) from the star that sponsors them.
1212
13−- A [ship](../ship) on the Arvo network whose identity is a planet in the former definition. Planets, in the second sense, have the power to issue [moons](../moon). Moons are Arvo ships that are meant for use with devices, are completely subordinated from their parent planet, and have no Azimuth presence.
13+- A [ship](/docs/glossary/ship) on the Arvo network whose identity is a planet in the former definition. Planets, in the second sense, have the power to issue [moons](/docs/glossary/moon). Moons are Arvo ships that are meant for use with devices, are completely subordinated from their parent planet, and have no Azimuth presence.
1414
1515Planets have addresses that are representable by 32 bits. This means that there are nearly 4.3 billion possible planets. Planets have four-syllable names like `~morzod-ballet` or `~rovnys-ricfer`.
content/docs/glossary/proxies.md+4−4
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−**Proxies** are Ethereum addresses in the [Urbit HD Wallet](../hdwallet) system that have limited powers. They are lower-powered "siblings" of the ownership key, which has the sole power to transfer the assigned Urbit identity. Using [Bridge](../bridge), you can change the Ethereum addresses used for your proxies.
9+**Proxies** are Ethereum addresses in the [Urbit HD Wallet](/docs/glossary/hdwallet) system that have limited powers. They are lower-powered "siblings" of the ownership key, which has the sole power to transfer the assigned Urbit identity. Using [Bridge](/docs/glossary/bridge), you can change the Ethereum addresses used for your proxies.
1010
1111There are three types of proxy.
1212
@@ -16,14 +16,14 @@ The management proxy can configure or set Arvo networking keys and conduct spons
1616
1717- **Voting Proxy**
1818
19−The voting proxy can cast votes on behalf of its assigned point on new proposals, including changes to [Ecliptic](../ecliptic). The voting proxy is unique to [galaxies](../galaxy), since only power galaxies have seats in the Senate.
19+The voting proxy can cast votes on behalf of its assigned point on new proposals, including changes to [Ecliptic](/docs/glossary/ecliptic). The voting proxy is unique to [galaxies](/docs/glossary/galaxy), since only power galaxies have seats in the Senate.
2020
2121- **Spawn Proxy**
2222
23−Creates new child points given Ethereum address. For [stars](../stars) and [galaxies](../galaxy) only.
23+Creates new child points given Ethereum address. For [stars](/docs/glossary/stars) and [galaxies](/docs/glossary/galaxy) only.
2424
2525
2626### Further Reading
2727
28−- [Azimuth glossary page](../azimuth): The glossary entry for Azimuth.
28+- [Azimuth glossary page](/docs/glossary/azimuth): The glossary entry for Azimuth.
2929- [The Azimuth concepts page](/docs/azimuth/advanced-azimuth-tools): A more in-depth explanation of Azimuth, including information the storage of Urbit identities.
content/docs/glossary/replay.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**Replay** is how [Vere](../vere) computes the state of a ship's [Arvo](../arvo) instance from the [event log](../eventlog) after a ship reboots. In order to avoid replaying the entire event log, Replay takes a snapshot of the current state of the ship approximately once every ten minutes. Then when a ship reboots, Replay loads the most recent snapshot and replays events from the event log up to the most recent event.
9+**Replay** is how [Vere](/docs/glossary/vere) computes the state of a ship's [Arvo](/docs/glossary/arvo) instance from the [event log](/docs/glossary/eventlog) after a ship reboots. In order to avoid replaying the entire event log, Replay takes a snapshot of the current state of the ship approximately once every ten minutes. Then when a ship reboots, Replay loads the most recent snapshot and replays events from the event log up to the most recent event.
1010
1111### Further Reading
1212
content/docs/glossary/sailudon.md+2−2
@@ -8,6 +8,6 @@ category = "arvo"
88
99**Sail** and **Udon** are domain specific languages for Hoon.
1010
11−Sail is used to express XML data structures, which are used for rendering webpages, such as when browsing [collections](../collection) in [Landscape](../landscape).
11+Sail is used to express XML data structures, which are used for rendering webpages, such as when browsing [collections](/docs/glossary/collection) in [Landscape](/docs/glossary/landscape).
1212
13−Udon is similar to Markdown, a simple language for writing documents. Udon is stored in [Clay](../clay) and rendered using [Ford](../ford).
13+Udon is similar to Markdown, a simple language for writing documents. Udon is stored in [Clay](/docs/glossary/clay) and rendered using [Ford](/docs/glossary/ford).
content/docs/glossary/senate.md+5−5
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Galactic Senate** is the body of all [galaxies](../galaxy) that governs
10−[Azimuth](../azimuth) by [majority vote](../voting). There are two types of
11−votes: an [upgrade proposal](../upgrade), which is a motion to update the logic
12−of Azimuth (i.e. [Ecliptic](../ecliptic)), and a [document
13−proposal](../docvote), which is a motion to legitimize or approve the content of an
9+The **Galactic Senate** is the body of all [galaxies](/docs/glossary/galaxy) that governs
10+[Azimuth](/docs/glossary/azimuth) by [majority vote](/docs/glossary/voting). There are two types of
11+votes: an [upgrade proposal](/docs/glossary/upgrade), which is a motion to update the logic
12+of Azimuth (i.e. [Ecliptic](/docs/glossary/ecliptic)), and a [document
13+proposal](/docs/glossary/docvote), which is a motion to legitimize or approve the content of an
1414arbitrary document.
content/docs/glossary/ship.md+8−8
@@ -6,21 +6,21 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **ship** is an instance of an Urbit computer that is a peer on the [Arvo](../arvo) network.
9+A **ship** is an instance of an Urbit computer that is a peer on the [Arvo](/docs/glossary/arvo) network.
1010
1111A ship can be one of five classes:
1212
13−- [comets](../comet), disposable identities.
14−- [moons](../moon), connected devices subordinated to a ship.
15−- [planets](../planet), individual users.
16−- [stars](../star), network infrastructure nodes.
17−- [galaxy](../galaxy), also network infrastructure nodes.
13+- [comets](/docs/glossary/comet), disposable identities.
14+- [moons](/docs/glossary/moon), connected devices subordinated to a ship.
15+- [planets](/docs/glossary/planet), individual users.
16+- [stars](/docs/glossary/star), network infrastructure nodes.
17+- [galaxy](/docs/glossary/galaxy), also network infrastructure nodes.
1818
19−To be able to use the Arvo network, planets, stars, and galaxies must be combined with an [Azimuth](../azimuth)-based Urbit identity in the form of a [keyfile](../keyfile).
19+To be able to use the Arvo network, planets, stars, and galaxies must be combined with an [Azimuth](/docs/glossary/azimuth)-based Urbit identity in the form of a [keyfile](/docs/glossary/keyfile).
2020
2121### Further Reading
2222
2323- [Using Bridge](/getting-started/): A guide to installing Urbit and booting a ship.
2424- [Ship Troubleshooting](/using/os/ship-troubleshooting): General instructions on getting your ship to work, which includes network connectivity issues.
2525- [Understanding Urbit ID](/understanding-urbit/urbit-id)
26−- [Pier](../pier): The directory containing a ship's state.
26+- [Pier](/docs/glossary/pier): The directory containing a ship's state.
content/docs/glossary/shiparvonetwork.md+1−1
@@ -6,4 +6,4 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**ship.arvo.network** is a way to connect to [ships](../ship) via HTTP utilizing DNS lookup. For example, the address for `~zod` would be `zod.arvo.network`.
9+**ship.arvo.network** is a way to connect to [ships](/docs/glossary/ship) via HTTP utilizing DNS lookup. For example, the address for `~zod` would be `zod.arvo.network`.
content/docs/glossary/star.md+3−3
@@ -6,12 +6,12 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **star** is the kind of Urbit identity that sits between the [galaxy](../galaxy) and [planets](../planet) in the identity hierarchy. Stars act as infrastructure for the [Arvo](../arvo) network, providing planets with [Ames](../ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](../ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
9+A **star** is the kind of Urbit identity that sits between the [galaxy](/docs/glossary/galaxy) and [planets](/docs/glossary/planet) in the identity hierarchy. Stars act as infrastructure for the [Arvo](/docs/glossary/arvo) network, providing planets with [Ames](/docs/glossary/ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](/docs/glossary/ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
1010
1111A **star** can be one of two related things:
1212
13−- A kind of [Azimuth](../azimuth) Urbit identity that sits between the [galaxy](../galaxy) and [planets](../planet) in the identity hierarchy. Stars, in this sense, have the power to issue [planets](../planet), and are themselves are issued by galaxies.
13+- A kind of [Azimuth](/docs/glossary/azimuth) Urbit identity that sits between the [galaxy](/docs/glossary/galaxy) and [planets](/docs/glossary/planet) in the identity hierarchy. Stars, in this sense, have the power to issue [planets](/docs/glossary/planet), and are themselves are issued by galaxies.
1414
15−- A [ship](../ship) on the Arvo network whose identity is a star in the former definition. In this sense, stars act as infrastructure for the [Arvo](../arvo) network, providing planets with [Ames](../ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](../ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
15+- A [ship](/docs/glossary/ship) on the Arvo network whose identity is a star in the former definition. In this sense, stars act as infrastructure for the [Arvo](/docs/glossary/arvo) network, providing planets with [Ames](/docs/glossary/ames)-related services, such as peer-to-peer routing and distributing [over-the-air software updates](/docs/glossary/ota-updates). Stars rely on galaxies for these services in the way that planets rely on stars.
1616
1717Stars have addresses that are representable by 16 bits. This means that there are 65,280 possible stars, and each of these stars is able to issue 65,535 planets. Stars have two-syllable names like `~taglux` or `~hallet`.
content/docs/glossary/sync.md+2−2
@@ -6,9 +6,9 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−**|sync** sets up a sychronization between two [Clay](../clay) [desks](../desk). It is mostly used to distribute kernel updates.
9+**|sync** sets up a sychronization between two [Clay](/docs/glossary/clay) [desks](/docs/glossary/desk). It is mostly used to distribute kernel updates.
1010
11−By default, in the [galaxy](../galaxy)/[star](../star)/[planet](../planet)/[moon](../moon) hierachy, the kids desk of the parent is synchronized with the base desk of the child.
11+By default, in the [galaxy](/docs/glossary/galaxy)/[star](/docs/glossary/star)/[planet](/docs/glossary/planet)/[moon](/docs/glossary/moon) hierachy, the kids desk of the parent is synchronized with the base desk of the child.
1212
1313
1414### Further Reading
content/docs/glossary/trap.md+1−1
@@ -6,7 +6,7 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−A **trap** is a [core](../core) with one arm named $ and no sample. They are often used in similar ways to looping structures in other programming languages.
9+A **trap** is a [core](/docs/glossary/core) with one arm named $ and no sample. They are often used in similar ways to looping structures in other programming languages.
1010
1111### Further Reading
1212
content/docs/glossary/upgrade.md+4−4
@@ -6,8 +6,8 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−An **upgrade proposal** is a type of [vote](../voting) action taken by the
10−[Galactic Senate](../senate) over [Azimuth](../azimuth). By passing an upgrade
11−proposal, [Galaxies](../galaxy) in the Senate agree to change the
12−[Ecliptic](../ecliptic) smart contracts.
9+An **upgrade proposal** is a type of [vote](/docs/glossary/voting) action taken by the
10+[Galactic Senate](/docs/glossary/senate) over [Azimuth](/docs/glossary/azimuth). By passing an upgrade
11+proposal, [Galaxies](/docs/glossary/galaxy) in the Senate agree to change the
12+[Ecliptic](/docs/glossary/ecliptic) smart contracts.
1313
content/docs/glossary/vane.md+10−10
@@ -6,18 +6,18 @@ template = "doc.html"
66category = "arvo"
77+++
88
9−A **vane** is an [Arvo](../arvo) kernel module that performs essential system operations. The vanes are:
9+A **vane** is an [Arvo](/docs/glossary/arvo) kernel module that performs essential system operations. The vanes are:
1010
1111
12−- [Ames](../ames), the peer-to-peer networking vane.
13−- [Behn](../behn), the timer vane.
14−- [Clay](../clay), the filesystem and revision-control vane.
15−- [Dill](../dill), the terminal-driver vane.
16−- [Eyre](../eyre), the HTTP vane.
17−- [Ford](../ford), the build-system vane.
18−- [Gall](../gall), the application vane.
19−- [Iris](../iris), the server HTTP vane.
20−- [Jael](../jael), the security vane.
12+- [Ames](/docs/glossary/ames), the peer-to-peer networking vane.
13+- [Behn](/docs/glossary/behn), the timer vane.
14+- [Clay](/docs/glossary/clay), the filesystem and revision-control vane.
15+- [Dill](/docs/glossary/dill), the terminal-driver vane.
16+- [Eyre](/docs/glossary/eyre), the HTTP vane.
17+- [Ford](/docs/glossary/ford), the build-system vane.
18+- [Gall](/docs/glossary/gall), the application vane.
19+- [Iris](/docs/glossary/iris), the server HTTP vane.
20+- [Jael](/docs/glossary/jael), the security vane.
2121
2222### Further Reading
2323
content/docs/glossary/vere.md+3−3
@@ -6,11 +6,11 @@ template = "doc.html"
66category = "hoon-nock"
77+++
88
9−**Vere**, pronounced "Vair", is the [Nock](../nock) runtime environment and Urbit virtual machine. Vere is written in C, runs on Unix, and is the intermediate layer between your urbit and Unix. Unix system calls are made by Vere, not Arvo; Vere must also encode and deliver relevant external events to [Arvo](../arvo). Vere is also responsible for implementing jets and maintaining the persistent state of each urbit (computed as a pure function of its [event log](../eventlog) with [Replay](../replay)). It also contains the I/O drivers for Urbit’s vanes, which are responsible for generating events from Unix and applying effects to Unix.
9+**Vere**, pronounced "Vair", is the [Nock](/docs/glossary/nock) runtime environment and Urbit virtual machine. Vere is written in C, runs on Unix, and is the intermediate layer between your urbit and Unix. Unix system calls are made by Vere, not Arvo; Vere must also encode and deliver relevant external events to [Arvo](/docs/glossary/arvo). Vere is also responsible for implementing jets and maintaining the persistent state of each urbit (computed as a pure function of its [event log](/docs/glossary/eventlog) with [Replay](/docs/glossary/replay)). It also contains the I/O drivers for Urbit’s vanes, which are responsible for generating events from Unix and applying effects to Unix.
1010
11−When you boot your [ship](../ship), Vere passes your [Azimuth](../azimuth) [keyfile](../keyfile) into the Arvo state, allowing a connection to the [Ames](../ames) network.
11+When you boot your [ship](/docs/glossary/ship), Vere passes your [Azimuth](/docs/glossary/azimuth) [keyfile](/docs/glossary/keyfile) into the Arvo state, allowing a connection to the [Ames](/docs/glossary/ames) network.
1212
13−Vere consists of two processes that communicate via a socket: a daemon process in charge of managing I/O channels, and a worker process that acts as a Nock interpreter that is instructed by the daemon process. Currently the worker is written in C, but a new worker written in Java, called [Jacque](../jacque), is under development.
13+Vere consists of two processes that communicate via a socket: a daemon process in charge of managing I/O channels, and a worker process that acts as a Nock interpreter that is instructed by the daemon process. Currently the worker is written in C, but a new worker written in Java, called [Jacque](/docs/glossary/jacque), is under development.
1414
1515### Further Reading
1616
content/docs/glossary/voting.md+4−4
@@ -6,11 +6,11 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−**Voting** is a power available to [galaxies](../galaxy), in their capacities as
10−members of the [Galactic Senate](../senate), through an [Azimuth](../azimuth)
9+**Voting** is a power available to [galaxies](/docs/glossary/galaxy), in their capacities as
10+members of the [Galactic Senate](/docs/glossary/senate), through an [Azimuth](/docs/glossary/azimuth)
1111smart contract. Galaxies collectively make decisions about the governance of
12−Azimuth and the [Arvo](../arvo) network by voting. There are two types of proposals that can be voted on:
13−an [upgrade proposal](../upgrade) and a [document proposal](../docvote).
12+Azimuth and the [Arvo](/docs/glossary/arvo) network by voting. There are two types of proposals that can be voted on:
13+an [upgrade proposal](/docs/glossary/upgrade) and a [document proposal](/docs/glossary/docvote).
1414
1515A proposal is always a Yes/No vote. The vote concludes at the end of 30 days,
1616or whenever an absolute majority is reached, whichever comes first. Assuming a
content/docs/glossary/wallet-generator.md+1−1
@@ -6,6 +6,6 @@ template = "doc.html"
66category = "azimuth"
77+++
88
9−The **Wallet Generator** is a planned open-source app developed for generating an [Urbit HD Wallet](../hdwallet) to secure your [Azimuth](../Azimuth) identities. Wallet Generator will be part of the [Bridge](../bridge) software, and it's a graphical user interface that handles the entire process of creating a new [Urbit HD Wallet](../hdwallet), starting with the entropy-creation step.
9+The **Wallet Generator** is a planned open-source app developed for generating an [Urbit HD Wallet](/docs/glossary/hdwallet) to secure your [Azimuth](/docs/glossary/Azimuth) identities. Wallet Generator will be part of the [Bridge](/docs/glossary/bridge) software, and it's a graphical user interface that handles the entire process of creating a new [Urbit HD Wallet](/docs/glossary/hdwallet), starting with the entropy-creation step.
1010
1111The Wallet Generator must be used offline for security reasons. If an internet connection is detected at any time, the program will end, forcing the user to start from the beginning. As a final step, Wallet Generator will produce PDF files containing all of the aforementioned seeds, as well as a PDF that contains ownership Ethereum public addresses for receiving ships.