7115a0c · urbit.org · git.iko.soy

git.iko.soy/urbit.org

Merge pull request #761 from urbit/fix-links-2

fix links from zola transition

commit7115a0cf8fb11c0099b49002091b8cb17182318b authorpoprox <51337059+drbeefsupreme@users.noreply.github.com> dateWed 4 Aug 2021, 13:51 (5 years ago) parent0e1157c e2c7629

99 files changed+260−260

compare with master

unifiedsplit

content/Bitcoin-wallet.md+1−1

@@ -18,7 +18,7 @@ If you are interested in [being a provider](https://subject.network/posts/btc-wa

1818

1919### Verify

2020

21−You should verify your version of this Bitcoin wallet. To do so, follow the instructions in the README in our [Github](https://github.com/urbit/urbit/blob/master/pkg/btc-wallet/README.md) repo.

21+You should verify your version of this Bitcoin wallet. To do so, follow the instructions in the README in our [Github](https://github.com/urbit/urbit/blob/master/pkg/btc-wallet/README) repo.

2222

2323Instructions reproduced here:

2424

content/blog/an-urbit-overview.md+5−5

@@ -201,11 +201,11 @@ with a small, fixed-price public presale of Urbit address space. Join

201201us and help make this future actually happen.

202202

203203To keep reading, learn more about [Urbit's address

204−space](../the-urbit-address-space); share our vision of the Urbit user

205−experience, from the [top down](../what-is-urbit-for) or the [bottom

206−up](../magic); check out the [development roadmap](../roadmap);

207−evaluate Urbit's [beliefs and principles](../beliefs-and-principles) or its

208−[interim constitution](../interim-constitution).

204+space](/blog/the-urbit-address-space); share our vision of the Urbit user

205+experience, from the [top down](/blog/what-is-urbit-for) or the [bottom

206+up](/blog/magic); check out the [development roadmap](/blog/roadmap);

207+evaluate Urbit's [beliefs and principles](/blog/beliefs-and-principles) or its

208+[interim constitution](/blog/interim-constitution).

209209

210210(For technical readers, check out our [documentation](https://urbit.org/docs/) or

211211the [whitepaper](https://media.urbit.org/whitepaper.pdf)).

content/blog/first-contract.md+23−23

@@ -15,9 +15,9 @@ image = "https://media.urbit.org/site/posts/essays/land3.jpg"

1515<br>

1616

1717Recently, the [first upgrade](https://github.com/urbit/azimuth/pull/35) to the

18−[Azimuth](@/docs/glossary/azimuth.md) smart contracts which make up Urbit ID was

19−put up to an [upgrade proposal vote](@/docs/glossary/upgrade.md) by the

20−[Galactic Senate](@/docs/glossary/senate.md). This vote is still open and will

18+[Azimuth](/docs/glossary/azimuth) smart contracts which make up Urbit ID was

19+put up to an [upgrade proposal vote](/docs/glossary/upgrade) by the

20+[Galactic Senate](/docs/glossary/senate). This vote is still open and will

2121last for 30 days (June 20th) or until an absolute majority is reached. We’d like

2222to take this opportunity to discuss two things. [First](#changelist), what the

2323proposed changes are, and [second](#senate), a review of how Urbit governance

@@ -25,16 +25,16 @@ works and where we’re at in the decentralization process.

2525

2626Before we dive into what the proposed changes are, let’s review what the Senate

2727is actually capable of changing. Urbit ID is really two sets of smart contracts:

28−Azimuth and [Ecliptic](@/docs/glossary/ecliptic.md). Azimuth is the data of the

28+Azimuth and [Ecliptic](/docs/glossary/ecliptic). Azimuth is the data of the

2929public key infrastructure - roughly, this is the list of

30−[ships](@/docs/glossary/ship.md) and which Ethereum addresses own them, along

30+[ships](/docs/glossary/ship) and which Ethereum addresses own them, along

3131with other data such as networking keys and sponsorship status. The Senate has

3232no ability to touch this data directly. This is in direct contrast to all

3333existing centralized services, where your account is always at risk of being

3434taken away from you. What the Senate can change is Ecliptic, which is the

3535“business logic” that decides how you can interact with the data in Azimuth.

3636These are mechanisms such as what powers various

37−[proxies](@/docs/glossary/proxies.md) have, how stars/planets are released over

37+[proxies](/docs/glossary/proxies) have, how stars/planets are released over

3838time, and how sponsorship works. Put another way, the data and database format

3939must remain the same, but the rules by which we interact with it may change

4040according to the governance rules we [detail below](#senate).

@@ -119,27 +119,27 @@ current position, but still serve as useful historical markers. We hope to

119119revisit and refresh these documents soon.

120120

121121- [2016.5.16 - Interim

122− Constitution](@/blog/interim-constitution.md)

122+ Constitution](/blog/interim-constitution)

123123- [2016.5.16 - The

124− Urbit Address Space](@/blog/the-urbit-address-space.md)

124+ Urbit Address Space](/blog/the-urbit-address-space)

125125- [2016.6.24 - The DAO as a Lesson in Decentralized

126− Governance](@/blog/the-dao-as-a-lesson-in-decentralized-governance.md)

126+ Governance](/blog/the-dao-as-a-lesson-in-decentralized-governance)

127127- [2019.1.11 - Governance of

128− urbit.org](@/blog/governance-of-urbit.md)

128+ urbit.org](/blog/governance-of-urbit)

129129

130130### Galactic Senate

131131

132−The Galactic Senate is composed of all [galaxy](@/docs/glossary/galaxy.md)

132+The Galactic Senate is composed of all [galaxy](/docs/glossary/galaxy)

133133holders, which at present consists of more than 100 individuals and a few

134134organizations, including Tlon and the Urbit Foundation. Using the Azimuth

135135voting contract, the Senate can present and vote on two kinds of proposals:

136−[document proposals](@/docs/glossary/docvote.md) and [upgrade

137−proposals](@/docs/glossary/upgrade.md). Thus far, all matters which the Senate

136+[document proposals](/docs/glossary/docvote) and [upgrade

137+proposals](/docs/glossary/upgrade). Thus far, all matters which the Senate

138138has voted on have been document proposals. The [most recent

139139vote](https://github.com/urbit/azimuth/pull/34) declared the Urbit network as

140140(i) being secure (as confirmed by a [third party

141−audit](@/blog/security-audit.md)) and (ii) having reached continuity (as in, no

142−further [network breaches](@/docs/glossary/breach.md) are expected). Previous votes

141+audit](/blog/security-audit)) and (ii) having reached continuity (as in, no

142+further [network breaches](/docs/glossary/breach) are expected). Previous votes

143143were to declare that [Azimuth is live](https://github.com/urbit/azimuth/pull/25)

144144and that [Arvo is stable](https://github.com/urbit/azimuth/pull/24).

145145

@@ -155,7 +155,7 @@ In the beginning, Urbit’s creator Curtis Yarvin was in possession of the entir

155155address space - all 256 galaxies, and everything underneath it. A network of one

156156is no network at all, and so over the last decade Urbit’s development has been

157157primarily driven by selling or giving away these galaxies. On [June 1,

158−2016](@/blog/the-urbit-address-space.md), the allocation was:

158+2016](/blog/the-urbit-address-space), the allocation was:

159159

160160> 95, to the Tlon Corporation. 50, to urbit.org, the future community

161161> foundation. 40, to Tlon employees and their family members (24 to Curtis, who

@@ -167,9 +167,9 @@ primarily driven by selling or giving away these galaxies. On [June 1,

167167Since then, Tlon has sold a number of

168168its galaxies to fund development and others have changed hands to the point

169169that Tlon and urbit.org no longer possess a majority share of galaxies. In

170−January 2019, [Curtis gave all of his galaxies](@/blog/a-founders-farewell.md) to

170+January 2019, [Curtis gave all of his galaxies](/blog/a-founders-farewell) to

171171Tlon when he left the project. In August 2020 we shared an update on the [known

172−distribution of address space](@/blog/value-of-address-space-pt3.md), where

172+distribution of address space](/blog/value-of-address-space-pt3), where

173173Curtis’ galaxies are marked as Tlon’s “naked galaxies”. Shortly thereafter, Tlon

174174disbursed its naked galaxies among the employees that wanted one who did not

175175already possess one, thus removing Tlon and urbit.org’s controlling share of the

@@ -198,13 +198,13 @@ controlled by the users is now well underway.

198198

199199In the past, nearly all Urbit software was written by Tlon. While Tlon is still

200200the only corporation actively updating Urbit’s MIT-licensed open source

201−software, namely [Vere](@/docs/glossary/vere.md) (the runtime),

202−[Arvo](@/docs/glossary/arvo.md) (the kernel),

203−[Landscape](@/docs/glossary/landscape.md) (the client), and

204−[Bridge](@/docs/glossary/bridge.md) (the ID manager), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).

201+software, namely [Vere](/docs/glossary/vere) (the runtime),

202+[Arvo](/docs/glossary/arvo) (the kernel),

203+[Landscape](/docs/glossary/landscape) (the client), and

204+[Bridge](/docs/glossary/bridge) (the ID manager), unaffiliated individuals have been making enormous contributions to Urbit over the past couple of years via the [grants program](https://grants.urbit.org/history). Recent examples include the [Bitcoin node and wallet integration](https://github.com/urbit/urbit/pull/4940), [WebRTC integration](https://grants.urbit.org/proposals/21131866-webrtc-gall-agent-and-external-app), [Port, an Urbit installer and ship manager](https://github.com/arthyn/port), and [`|fuse`, an important primitive for 3rd party software distribution](https://github.com/urbit/urbit/pull/4820).

205205

206206The only real power Tlon holds over Urbit is the ability to push [OTA

207−updates](@/docs/glossary/ota-updates.md) via `~zod`, and suggest that people

207+updates](/docs/glossary/ota-updates) via `~zod`, and suggest that people

208208download our binaries. To the best of our knowledge, all extant galaxies

209209retrieve their OTA updates from `~zod`, who forward it to their stars, who

210210forward it to their planets. This software distribution route is merely a

content/blog/first-steps-towards-urbit-org.md+1−1

@@ -56,4 +56,4 @@ I look forward to working with you.

5656

5757[^2]: We’re also really into the idea of being the first builder of housing on Mars. Just saying...

5858

59−[^3]: We call this project Airlock. You’ll hear more about it soon.

59+[^3]: We call this project Airlock. You’ll hear more about it soon.

content/blog/interim-constitution.md+1−1

@@ -28,7 +28,7 @@ may not incorporate any or all of the interim structures.

2828

2929## Beliefs and principles

3030

31−See our document of [beliefs and principles](../beliefs-and-principles).

31+See our document of [beliefs and principles](/blog/beliefs-and-principles).

3232

3333## Governance structures

3434

content/blog/magic.md+1−1

@@ -200,5 +200,5 @@ should not interact in the same place.)

200200

201201And, with magic, we've succeeded in turning Facebook into Urbit.

202202Technically, Urbit is pretty close to magic, but there is no way

203−it's going to happen this way. See the [roadmap](../roadmap) for how it

203+it's going to happen this way. See the [roadmap](/blog/roadmap) for how it

204204actually happens.

content/blog/the-urbit-address-space.md+1−1

@@ -201,7 +201,7 @@ own real estate.

201201Urbit was created by Curtis Yarvin, who has distributed the 256

202202galaxies as follows (allocation as of June 1, 2016):

203203

204−95, to the [Tlon Corporation](../company). 50, to urbit.org, the future

204+95, to the [Tlon Corporation](/blog/company). 50, to urbit.org, the future

205205community foundation. 40, to Tlon employees and their family members

206206(24 to Curtis, who started in 2002; 16 to everyone else, who started

207207in 2014). 34, to outside investors in Tlon. 37, to 33 other

content/community/governance.md+1−1

@@ -16,7 +16,7 @@ An owner of a galaxy (or a delegate) can propose a new iteration of the contract

1616

1717In a similar process, document hashes can be proposed. While their off-chain documents can't be "technically enforced", this mechanism is useful for the Senate to record more abstract decisions.

1818

19−For off-chain process around proposals, as suggested by core developers, please see [senate.md](https://github.com/urbit/azimuth/blob/master/senate.md).

19+For off-chain process around proposals, as suggested by core developers, please see [senate.md](https://github.com/urbit/azimuth/blob/master/senate).

2020

2121The group of core developers manages Urbit’s [GitHub repository](https://github.com/urbit/), which controls Arvo, Urbit’s operating system. Changes and upgrades are decided upon by consensus.

2222

content/community/hosting-a-meetup.md+1−1

@@ -8,7 +8,7 @@ hidenext = "true"

88hide_previous_title = "true"

99+++

1010

11−There are already [a few](../meetups) Urbit meetups that take place in cities around the United States. Want to start a meetup in your home town? Consider these best practices.

11+There are already [a few](/community/meetups) Urbit meetups that take place in cities around the United States. Want to start a meetup in your home town? Consider these best practices.

1212

1313### Create the Meetup Group Online

1414

content/community/meetups.md+1−1

@@ -16,7 +16,7 @@ hide_next_title = "true"

1616

1717Turns out that getting Urbit fans together in one room is pretty fun. Here's an incomplete list of community-led Urbit IRL groups. These events are generally informal and very approachable – feel free to dive in.

1818

19−Interested in hosting an Urbit event of your own? Follow our [guide to meetup best-practices](../hosting-a-meetup). Send an email to [support@urbit.org](mailto:support@urbit.org) and we'll list your meetup on this page.

19+Interested in hosting an Urbit event of your own? Follow our [guide to meetup best-practices](/community/hosting-a-meetup). Send an email to [support@urbit.org](mailto:support@urbit.org) and we'll list your meetup on this page.

2020

2121### Asia

2222

content/docs/arvo/ames/ames.md+8−8

@@ -11,7 +11,7 @@ over it. When Unix receives a packet over the correct UDP port, it pipes

1111it straight into Ames for handling. Also, all packets sent over the

1212Ames network are sent by the Ames vane. Apps and vanes may use

1313Ames to directly send messages to other ships. In general, apps use

14−[Gall](@/docs/userspace/gall/gall.md) and [Clay](@/docs/arvo/clay/clay.md)

14+[Gall](/docs/userspace/gall/gall) and [Clay](/docs/arvo/clay/clay)

1515to communicate with other ships rather than using Ames

1616directly, but this isn't a requirement. Of course, Gall and Clay use

1717Ames behind the scenes to communicate across the network. Jael is the only other

@@ -28,7 +28,7 @@ vane or app, is defined in Ames.

2828This section summarizes the design of Ames. Beyond this section are deeper

2929elaborations on the concepts presented here.

3030

31−Ames extends [Arvo's](@/docs/arvo/overview.md) `%pass`/`%give` `move` semantics across the network.

31+Ames extends [Arvo's](/docs/arvo/overview) `%pass`/`%give` `move` semantics across the network.

3232

3333Ames receives packets as Arvo events and emits packets as Arvo

3434effects. The runtime is responsible for transferring the bytes in

@@ -135,7 +135,7 @@ The 32-bit header is given by the following data, presented in order:

135135 - 2 bits: sender address size

136136 - 2 bits: receiver address size

137137 - 20 bits: checksum (truncated insecure hash of the body, done with

138− [`+mug`](@/docs/hoon/reference/stdlib/2e.md#mug)

138+ [`+mug`](/docs/hoon/reference/stdlib/2e#mug)

139139 - 1 bit: is this relayed? (if set, `origin` will be present in the body)

140140

141141 Every packet sent between ships is encrypted except for self-signed attestation packets from 128-bit comets.

@@ -159,15 +159,15 @@ order:

159159

160160 `SIV` is a "synthetic initialization vector" as defined in AES-256 SIV, the encryption

161161 algorithm utilized to encrypt Ames packets (see the page on [Ames

162− cryptography](@/docs/arvo/ames/cryptography.md)). It is formed from the

162+ cryptography](/docs/arvo/ames/cryptography)). It is formed from the

163163 following noun: `~[sender=@p receiver=@p sender-life=@ receiver-life=@]` (see

164− [Life and Rift](@/docs/azimuth/life-and-rift.md) for information on what `life`

164+ [Life and Rift](/docs/azimuth/life-and-rift) for information on what `life`

165165 is). As this data is in Azimuth, it is not explicitly sent over the wire. Thus

166166 the mod 16 sender and receiver life in the first 8 bits are only for quick

167167 filtering of honest packets sent to or from a stale life.

168168

169169 The ciphertext is formed by `+jam`ming a `$shut-packet` and then encrypting

170− using [`+en:sivc:aes:crypto`](@/docs/arvo/reference/cryptography.md#en).

170+ using [`+en:sivc:aes:crypto`](/docs/arvo/reference/cryptography#en).

171171

172172### Packeting

173173

@@ -256,7 +256,7 @@ This means all re-sends of an ack packet will be bitwise identical to each other

256256Each datum in this noun is an atom with the aura `@ud` or an aura that nests

257257under `@ud`.

258258

259−Here, `our-life` refers to the [`life`](@/docs/glossary/breach.md), or revision

259+Here, `our-life` refers to the [`life`](/docs/glossary/breach), or revision

260260number, of the acking ship's networking keys, and `her-life` is the `life` of

261261the ack-receiving ship's networking keys. `bone` is an opaque number identifying

262262the flow. `message-num` denotes the number of the

@@ -428,7 +428,7 @@ message.

428428

429429Urbit's functionality is split between the two binaries `urbit-worker` (sometimes

430430called the Serf) and `urbit-king` (sometimes called the King). This division of

431−labor is currently not well-documented outside of the [Vere documents](@/docs/vere/_index.md), but we summarize it here.

431+labor is currently not well-documented outside of the [Vere documents](/docs/vere/), but we summarize it here.

432432

433433In short, the Serf is the Nock runtime and so keeps track of the current state

434434of Arvo as a Nock noun and updates the state by `%poke`ing it with nouns, and

content/docs/arvo/ames/cryptography.md+6−6

@@ -35,9 +35,9 @@ is used for authentication

3535

3636The encrypted payload of each packet is a `$shut-packet`, which is the `+jam` of

3737a cell with the `bone`, message number, and message fragment or ack (see

38−[Ames](@/docs/arvo/ames/ames.md) for more information on packet structure). The

38+[Ames](/docs/arvo/ames/ames) for more information on packet structure). The

3939message fragment is signed using the authentication key. It is encrypted using

40−[`+en:crub:crypto`](@/docs/arvo/reference/cryptography.md#en) found in

40+[`+en:crub:crypto`](/docs/arvo/reference/cryptography#en) found in

4141`sys/zuse.hoon`, which utilizes the 256-bit AES-SIV algorithm.

4242

4343## Diffie-Hellman key exchange {#key-exchange}

@@ -45,7 +45,7 @@ message fragment is signed using the authentication key. It is encrypted using

4545For each foreign ship a given ship has communicated with, `$ames-state` contains a

4646`$peer-state`, inside which the `$symmetric-key` (an atom which nests under

4747`@uw`) is utilized for encrypting all Ames packets shared between the two ships.

48−The `symmetric-key` is derived using [`+shar:ed:crypto`](@/docs/arvo/reference/cryptography.md#ed) found in `sys/zuse.hoon`,

48+The `symmetric-key` is derived using [`+shar:ed:crypto`](/docs/arvo/reference/cryptography#ed) found in `sys/zuse.hoon`,

4949which is an arm utilized for generating the symmetric key for elliptic curve

5050[Diffie-Hellman key

5151exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange)

@@ -62,7 +62,7 @@ its identity with an "attestation packet". This is an unencrypted packet whose

6262payload is the comet's signature created with its private key. This is the only

6363circumstance under which a ship will send an unencrypted packet. The signature

6464is generated with

65−[`+sign:as:crub`](@/docs/arvo/reference/cryptography.md#sign-as) found in

65+[`+sign:as:crub`](/docs/arvo/reference/cryptography#sign-as) found in

6666`sys/zuse.hoon`.

6767

6868Upon hearing an attestation packet, the receiving ship will generate a symmetric

@@ -77,7 +77,7 @@ with a non-comet. This is a technical limitation with a planned workaround.

7777## `+acru:ames` {#crypto-core}

7878

7979The `+crypto-core` in `$ames-state` is an `+acru:ames` core, a

80−[lead](@/docs/hoon/reference/advanced.md#dry-polymorphism-and-core-nesting-rules)

80+[lead](/docs/hoon/reference/advanced#dry-polymorphism-and-core-nesting-rules)

8181interface core for asymmetric cryptosuites found in `sys/lull.hoon` which

8282handles encryption, decryption, signing, and verifying. In practice, the only

8383cryptosuite in use is [`+crub:crypto`](#crub), which implements [Suite B

@@ -112,7 +112,7 @@ Cryptography](https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography).

112112As the `+acru` core is merely an interface, the details on how it is implemented

113113may vary according to the cryptosuite. We summarize what each

114114core is utilized for here, but see

115−[`crub:crypto`](@/docs/arvo/reference/cryptography.md#crub) for more details on

115+[`crub:crypto`](/docs/arvo/reference/cryptography#crub) for more details on

116116how the specific cryptosuite utilized by Ames is implemented.

117117

118118#### `+as:acru`

content/docs/arvo/gall/overview.md+1−1

@@ -4,7 +4,7 @@ weight = 1

44template = "doc.html"

55+++

7−**Gall** is the application-management [vane](../vane). Userspace apps –⁠ daemons, really –⁠ are started, stopped, and sandboxed by Gall. Gall provides developers with a consistent interface for connecting their app to [Arvo](../arvo). It allows applications and other vanes to send messages to applications and subscribe to data streams. Messages coming into Gall are routed to the intended application, and the response comes back along the same route. If the intended target is on another [ship](../ship), Gall will route it behind the scenes through [Ames](../ames) to the other ship.

7+**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/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](/docs/glossary/ship), Gall will route it behind the scenes through [Ames](/docs/arvo/ames/ames) to the other ship.

99Gall is located at `/home/sys/vane/gall.hoon` within Arvo.

1010

content/docs/arvo/reference/_index.md+1−1

@@ -5,7 +5,7 @@ sort_by = "weight"

55template = "sections/docs/chapters.html"

66+++

8−[Cryptography](@/docs/arvo/reference/cryptography.md)

8+[Cryptography](/docs/arvo/reference/cryptography)

1010An overview of where Arvo uses cryptography, what algorithms are used, and how

1111they are implemented.

content/docs/arvo/reference/cryptography.md+9−9

@@ -6,24 +6,24 @@ template = "doc.html"

77This is a summary of the cryptography functions found in `sys/zuse.hoon`, Arvo's

88standard library. This page currently only documents cryptographic functions

9−directly utilized by [Ames](@/docs/arvo/ames/ames.md). `zuse` also contains

9+directly utilized by [Ames](/docs/arvo/ames/ames). `zuse` also contains

1010cryptographic functions relevant to Ethereum such as the `+keccak:crypto` core,

1111but they are currently undocumented.

1212

13−Documentation for [Insecure Hashing](@/docs/hoon/reference/stdlib/2e.md) and the

14−[SHA Hash Family](@/docs/hoon/reference/stdlib/3d.md) is found in the Hoon standard

13+Documentation for [Insecure Hashing](/docs/hoon/reference/stdlib/2e) and the

14+[SHA Hash Family](/docs/hoon/reference/stdlib/3d) is found in the Hoon standard

1515library reference.

1616

1717## Summary

1818

1919`zuse` contains several cryptosuites. The ones utilized by Ames are

2020[`+ed:crypto`](#ed), [`+aes:crypto`](#aes), and [`+crub:crypto`](#crub), with

21−the latter being the only one which is implemented as an [`+acru:ames`](@/docs/arvo/ames/cryptography.md#crypto-core)-shaped core.

21+the latter being the only one which is implemented as an [`+acru:ames`](/docs/arvo/ames/cryptography#crypto-core)-shaped core.

2222

2323## `+crub:crypto` {#crub}

2424

2525`+crub:crypto` implements an

26−[`+acru:ames`](@/docs/arvo/ames/cryptography.md#crypto-core) core that implements

26+[`+acru:ames`](/docs/arvo/ames/cryptography#crypto-core) core that implements

2727[Suite B Cryptography](https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography).

2828

2929It utilizes AES symmetric key encryption and decryption from [`+aes:crypto`](#aes)

@@ -198,12 +198,12 @@ Diffie-Hellman](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hell

198198key agreements as well as [Elliptic Curve Digital Signature

199199Algorithm](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm).

200200These functionalities are ultimately utilized by [`+crub:crypto`](#crub), the

201−only cryptosuite which [Ames](@/docs/arvo/ames/ames.md) makes use of.

201+only cryptosuite which [Ames](/docs/arvo/ames/ames) makes use of.

202202

203−Most gates in `+ed:crypto` are [jetted](@/docs/vere/jetting.md), meaning that an

203+Most gates in `+ed:crypto` are [jetted](/docs/vere/jetting), meaning that an

204204external reference library is utilized whenever these functions are called,

205205rather than running in Nock natively. See the [Vere

206−documentation](@/docs/vere/cryptography.md#ed) for more information about the

206+documentation](/docs/vere/cryptography#ed) for more information about the

207207library utilized by jets.

208208

209209## `+aes:crypto` {#aes}

@@ -213,7 +213,7 @@ This core contains cryptographic primitives and helper functions for

213213encryption and decryption. As is the case with `ed:crypto`, these

214214functionalities are utilized by [`+crub:crypto`](#crub), and most gates are

215215jetted. See also the Vere documentation on [AES

216−SIV](@/docs/vere/cryptography.md#aes) for more information about the library

216+SIV](/docs/vere/cryptography#aes) for more information about the library

217217utilized by jets.

218218

219219This core contains several doors, each one used for a different variation of AES

content/docs/arvo/reference/filesystem.md+10−10

@@ -7,21 +7,21 @@ template = "doc.html"

77Here we describe what each of the primary folders present in the `%home` `desk`

88are used for. This organization is merely a convention, and the exact location

99of any file does not affect its operation. That being said, some [Ford

10−runes](@/docs/arvo/ford/ford.md) are designed with this structure in mind, and

10+runes](/docs/arvo/ford/ford) are designed with this structure in mind, and

1111applications such as dojo look in specific folders for code to run. Furthermore,

1212this organization is not perfectly adhered to - sometimes you may find structure

1313definitions in `/lib`, for example.

1414

1515- `/app` contains userspace applications, i.e. [Gall

16− agents](@/docs/userspace/gall/gall.md).

16+ agents](/docs/userspace/gall/gall).

1717- `/gen` contains generators. Many applications make use of generators, but

1818 also each generator in this folder may be run from dojo using `+`. For

1919 example, `/gen/foo/hoon` is run with `+foo`.

2020- `/lib` contains libraries that may be shared by multiple agents, threads,

2121 generators, etc. However, this is not the location of the standard libraries

2222 (see `/sys`). Libraries are imported from `/lib` with `/+`.

23−- `/mar` contains [mark](@/docs/arvo/clay/architecture.md#marks) definitions.

24−- `/sur` contains shared [structure](@/docs/hoon/reference/rune/_index.md) definitions.

23+- `/mar` contains [mark](/docs/arvo/clay/architecture#marks) definitions.

24+- `/sur` contains shared [structure](/docs/hoon/reference/rune/) definitions.

2525 Whenever you expect structures to be used by code across multiple files, it

2626 is recommended to place their shared structures in `/sur`. Structures are

2727 imported from `/sur` with `/-`.

@@ -30,7 +30,7 @@ definitions in `/lib`, for example.

3030 the exception to the rule - structures and functions that are central to

3131 Hoon, Arvo, and its vanes, are all located within this folder rather than in

3232 `/lib` and `/sur`. See [below](#sys) for more information on `/sys`.

33−- `/ted` contains [threads](@/docs/userspace/threads/overview.md). These may be

33+- `/ted` contains [threads](/docs/userspace/threads/overview). These may be

3434 run from dojo using `-`. For example, `/ted/foo/hoon` is run with `-foo`.

3535- `/tests` contains unit tests intended to be run using the `test` thread. To

3636 run a particular test `+test-bar` in `/tests/foo.hoon` in dojo, enter `-test %/tests/foo/test-bar ~`. If a file is specified, every test in that file will

@@ -44,13 +44,13 @@ dependencies is `hoon.hoon` -> `arvo.hoon` -> `lull.hoon` -> `zuse.hoon`. We

4444give a brief description of each of them.

4545

4646- `hoon.hoon` contains the Hoon compiler and the [Hoon standard

47− library](@/docs/hoon/reference/stdlib/table-of-contents.md). The Hoon

47+ library](/docs/hoon/reference/stdlib/table-of-contents). The Hoon

4848 compiler is self-hosted. This is the first file loaded by the Nock virtual

49− machine, [Vere](@/docs/vere/runtime.md), in order for it to learn how to

49+ machine, [Vere](/docs/vere/runtime), in order for it to learn how to

5050 interpret Hoon. The kelvin version number is the subject of `hoon.hoon`,

5151 currently at 140. One may see this from dojo by inspecting the subject with

5252 `.` and noting that `%140` is the final entry of the subject.

53−- `arvo.hoon` contains the [Arvo kernel](@/docs/arvo/overview.md) and

53+- `arvo.hoon` contains the [Arvo kernel](/docs/arvo/overview) and

5454 additional structures and functions directly relevant to the kernel. This is

5555 Urbit's "traffic cop", and as such contains the structure definitions for

5656 call stacks such as `duct`s and `bone`s. Once Vere understands Hoon, it loads

@@ -60,10 +60,10 @@ give a brief description of each of them.

6060 vanes, as well as a few functions. In particular, this includes the

6161 definitions of the `card`s utilized by each vane, each of which are

6262 documented in their respective documentation. `lull.hoon` is loaded by the

63− kernel during the [larval stage](@/docs/arvo/overview.md#larval-stage-core)

63+ kernel during the [larval stage](/docs/arvo/overview#larval-stage-core)

6464 in order to prepare to create the vanes. `arvo.hoon` is the subject of `lull.hoon`.

6565- `zuse.hoon` is the Arvo standard library. It consists primarily of functions

6666 shared by the kernel and vanes, such as the ones related to

67− [cryptography](@/docs/arvo/reference/cryptography.md). `zuse.hoon` is loaded

67+ [cryptography](/docs/arvo/reference/cryptography). `zuse.hoon` is loaded

6868 by the larval kernel following `lull.hoon`. `lull.hoon` is the subject of

6969 `zuse.hoon`. Then `zuse` is the subject of the vanes.

content/docs/azimuth/azimuth.md+2−2

@@ -43,7 +43,7 @@ Think of your master ticket like a very high-value password. The master ticket i

4343

4444### Ownership Address

4545

46−An ownership address has all rights over the assets deeded to it. These rights are on-chain actions described and implemented in [Ecliptic](@/docs/glossary/ecliptic.md), Azimuth's suite of governing smart-contracts.

46+An ownership address has all rights over the assets deeded to it. These rights are on-chain actions described and implemented in [Ecliptic](/docs/glossary/ecliptic), Azimuth's suite of governing smart-contracts.

4747

4848### Proxies

4949

@@ -56,7 +56,7 @@ Proxy addresses allow you to execute non-ownership related actions like spawning

5656

5757- **Voting Proxy**

5858

59− Galaxies only. Galaxies are the part of the [Galactic Senate](@/docs/glossary/senate.md), and this means

59+ Galaxies only. Galaxies are the part of the [Galactic Senate](/docs/glossary/senate), and this means

6060 they can cast votes on new proposals including changes to Ecliptic.

6161

6262- **Spawn Proxy**

content/docs/development/develop.md+1−1

@@ -35,7 +35,7 @@ an [interface](https://github.com/urbit/urbit/tree/master/pkg/interface) built

3535with [React](https://reactjs.org).

3636

3737Additionally, you can [contribute to

38−Landscape](https://github.com/urbit/urbit/blob/master/pkg/interface/CONTRIBUTING.md)

38+Landscape](https://github.com/urbit/urbit/blob/master/pkg/interface/CONTRIBUTING)

3939by tackling issues in its [issue

4040tracker](https://github.com/urbit/landscape/issues) and/or running the

4141[development stream](https://groups.google.com/a/urbit.org/g/dev/c/r2hv4ajCLwk).

content/docs/glossary/ames.md+3−3

@@ -5,13 +5,13 @@ template = "doc.html"

55category = "arvo"

66+++

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.

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"

88**Aqua** is something like Docker but for Urbit; it is a virtualization tool whose primary purpose is testing and development.

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/arm.md+1−1

@@ -6,7 +6,7 @@ template = "doc.html"

66category = "hoon-nock"

77+++

9−An **arm** is a Hoon expression encoded as a noun. You can find them as part of a [core](../core)

9+An **arm** is a Hoon expression encoded as a noun. You can find them as part of a [core](/docs/glossary/core)

1010

1111### Further Reading

1212

content/docs/glossary/arvo.md+9−9

@@ -4,8 +4,8 @@ template = "doc.html"

44+++

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+++

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).

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+++

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.

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.

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+++

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+++

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.

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+++

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+++

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/).

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+++

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.

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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.

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+++

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+++

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+++

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+++

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+++

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"

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+++

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+++

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+++

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+++

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.

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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).

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+++

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+++

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+++

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+++

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+++

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.

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+++

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"

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+++

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+++

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"

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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+++

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.

content/docs/hoon/hoon-school/doors.md+1−1

@@ -408,7 +408,7 @@ In the above example we created a door `c` with sample `b=@` and found that the

408408 ++ greater |=(a=@ (gth a b))

409409 --

410410```

411−Here the type of `b` is inferred to be `@` based on the example value `7`, similar to how we've seen casting done by example. You will learn more about how types are inferred in [Lesson 2.2](@docs/hoon/hoon-school/type-checking-and-type-inference.md).

411+Here the type of `b` is inferred to be `@` based on the example value `7`, similar to how we've seen casting done by example. You will learn more about how types are inferred in [Lesson 2.2](@docs/hoon/hoon-school/type-checking-and-type-inference).

412412

413413### Doors in the Hoon Standard Library

414414

content/docs/hoon/hoon-school/list-of-numbers.md+1−1

@@ -129,4 +129,4 @@ Our program works by having each iteration of the list creating a cell. In each

129129 4 ~

130130```

131131

132−If you still don't intuit how this is working, don't worry. We'll take a deeper look into recursion later with our [Recursion Walkthrough](../recursion).

132+If you still don't intuit how this is working, don't worry. We'll take a deeper look into recursion later with our [Recursion Walkthrough](/docs/hoon/hoon-school/recursion).

content/docs/hoon/reference/irregular.md+5−5

@@ -204,7 +204,7 @@ Lets us adjust types without violating type constraints.

204204

205205### `^:` ketcol

206206

207−[docs](@/docs/hoon/reference/rune/ket.md#ketcol) \\,

207+[docs](/docs/hoon/reference/rune/ket#ketcol) \\,

208208

209209`[%ktcl p=spec]`: mold gate for type `p`.

210210

@@ -224,7 +224,7 @@ Irregular: `` `p`q ``

224224

225225### `^*` kettar

226226

227−[docs](@/docs/hoon/reference/rune/ket.md#kettar) \\\*

227+[docs](/docs/hoon/reference/rune/ket#kettar) \\\*

228228

229229`[%kttr p=spec]`: produce bunt value of mold.

230230

@@ -294,14 +294,14 @@ See [%sand](/docs/hoon/reference/rune/constants#warm) for other irregular defini

294294

295295### Wings

296296

297−[docs](content/docs/hoon/reference/limbs/wing.md)

297+[docs](content/docs/hoon/reference/limbs/wing)

298298`[%wing p=(list limb)]`; a limb search path.

299299`a.b` finds limb `a` within limb `b` ("var" `a` within "var" `b`).

300300

301301### Printing stuff

302302

303−- `<a b c>` prints a [tape](../library/2q/#-tape).

304−- `>a b c<` prints a [tank](../library/2q/#-tank).

303+- `<a b c>` prints a [tape](/docs/hoon/reference/stdlib/2q/#-tape).

304+- `>a b c<` prints a [tank](/docs/hoon/reference/stdlib/2q/#-tank).

305305

306306## Commentary

307307

content/docs/hoon/reference/stdlib/3d.md+2−2

@@ -230,7 +230,7 @@ byte-string.

230230128-bit noun hash

231231

232232Produces a 128-bit atom by hashing a noun `yux` with the `shah` function. If

233−that noun is a cell, then it is passed to the [`jam`](../2p) function to produce

233+that noun is a cell, then it is passed to the [`jam`](/docs/hoon/reference/stdlib/2p) function to produce

234234an atom to be hashed.

235235

236236#### Accepts

@@ -818,4 +818,4 @@ Since everything in Hoon is a pure function, we need to use tricks like this to

818818generate separate random values from the same seed. Notice how we jump from

819819one `raws` function call to another in the above example.

820820

821−---

821+---

content/docs/system-overview/cryptography.md+3−3

@@ -119,6 +119,6 @@ Jael and utilized by Ames for end-to-end encrypted communication.

119119The following pages contained more detailed information about the cryptography

120120utilized by each of the system components.

121121

122−- [Ames](@/docs/arvo/ames/cryptography.md)

123−- [Zuse](@/docs/arvo/reference/cryptography.md)

124−- [Vere](@/docs/vere/cryptography.md)

122+- [Ames](/docs/arvo/ames/cryptography)

123+- [Zuse](/docs/arvo/reference/cryptography)

124+- [Vere](/docs/vere/cryptography)

content/docs/userspace/threads/basics/summary.md+2−2

@@ -4,14 +4,14 @@ weight = 5

44template = "doc.html"

55+++

7−That's basically all you need to know to write threads. The best way to get a good handle on them is just to experiment with some `strandio` functions. For information on running threads from gall agents, see [here](../index.md#gall) and for some examples see [here](../index.md#how-tos--examples).

7+That's basically all you need to know to write threads. The best way to get a good handle on them is just to experiment with some `strandio` functions. For information on running threads from gall agents, see [here](/docs/userspace/threads/gall) and for some examples see [here](/docs/userspace/threads/examples).

99Now here's a quick recap of the main points covered:

1010

1111## Spider

1212

1313- is the gall agent that manages threads.

14−- Details of interacting with threads via spider can be seen [here](../reference.md).

14+- Details of interacting with threads via spider can be seen [here](/docs/userspace/threads/reference).

1515

1616## Threads

1717- are like transient gall agents

content/docs/userspace/threads/gall/start-thread.md+1−1

@@ -125,7 +125,7 @@ We can ignore the input logic, here's the important part:

125125

126126You can generate a tid any way you like, just make sure it's unique. Here we just use the hash of some entropy prefixed with `thread_`.

127127

128−Then it's just a poke to `%spider` with the mark `%spider-start` and a vase containing [start-args](../reference.md#start-thread). Spider will then respond with a `%poke-ack` with a `(unit tang)` which will be `~` if it started successfully or else contain an error and a traceback if it failed. Here we test for this and print the result:

128+Then it's just a poke to `%spider` with the mark `%spider-start` and a vase containing [start-args](/docs/userspace/threads/reference#start-thread). Spider will then respond with a `%poke-ack` with a `(unit tang)` which will be `~` if it started successfully or else contain an error and a traceback if it failed. Here we test for this and print the result:

129129

130130```hoon

131131++ on-agent

content/docs/userspace/threads/http-api.md+2−2

@@ -4,7 +4,7 @@ weight = 2

44template = "doc.html"

55+++

7−Spider has an Eyre binding which allows threads to be run externally via [authenticated](@/docs/arvo/eyre/external-api-ref.md#authentication) HTTP POST requests.

7+Spider has an Eyre binding which allows threads to be run externally via [authenticated](/docs/arvo/eyre/external-api-ref#authentication) HTTP POST requests.

99Spider is bound to the `/spider` URL path, and expects the requested URL to look like:

1010

@@ -46,7 +46,7 @@ Here's an extremely simple thread that takes a `vase` of `(unit json)` and just

4646(pure:m !>(json))

4747```

4848

49−First we must obtain a session cookie by [authenticating](@/docs/arvo/eyre/examples.md#authenticating).

49+First we must obtain a session cookie by [authenticating](/docs/arvo/eyre/examples#authenticating).

5050

5151Now we can try and run our thread. Spider is bound to the `/spider` URL path, and expects the rest of the path to be `/{inputMark}/{thread}/{outputMark}`. Our `{thread}` is called `eyre-thread`, and both its `{inputMark}` and `{outputMark}` are `json`, so our URL path will be `/spider/json/eyre-agent/json`. Our request will be an HTTP POST request and the body will be some `json`, in this case `[{"foo": "bar"}]`:

5252

content/docs/vere/_index.md+1−1

@@ -37,6 +37,6 @@ A walkthrough of each of the `u3` modules.

3737

3838A jetting guide by for new Urbit developers.

3939

40−## [Cryptography](@/docs/vere/cryptography.md)

40+## [Cryptography](/docs/vere/cryptography)

4141

4242References on the cryptography libraries utilized by jets.

content/docs/vere/cryptography.md+2−2

@@ -5,7 +5,7 @@ template = "doc.html"

55+++

77All cryptographic primitives utilized by Arvo are

8−[jetted](@/docs/vere/jetting.md). This is done for performance-related reasons

8+[jetted](/docs/vere/jetting). This is done for performance-related reasons

99in other parts of the system, but for cryptography this is also extremely

1010important because it allows us to utilize standard reference implementations for

1111the primitives written in C.

@@ -15,7 +15,7 @@ All jets related to encryption may be found in `pkg/urbit/jets/e/`.

1515In this section we review what specific implementations are utilized. At the

1616moment, only libraries directly related to Ames are documented here, though we

1717note that there are jets for other cryptographic functions such as the [SHA

18−Hash Family](@/docs/hoon/reference/stdlib/3d.md) as well.

18+Hash Family](/docs/hoon/reference/stdlib/3d) as well.

1919

2020### Ed25519 {#ed}

2121

content/faq.md+6−6

@@ -124,15 +124,15 @@ It’s also worth noting that, while there are almost 8B people on Earth, there

124124

125125### How secure is Urbit right now? {#how-secure-is-urbit}

126126

127−We consider some parts of Urbit to be secure, while other parts still need some work and external auditing. For technical details on Urbit's cryptosystems, see the [documentation](@/docs/system-overview/cryptography.md).

127+We consider some parts of Urbit to be secure, while other parts still need some work and external auditing. For technical details on Urbit's cryptosystems, see the [documentation](/docs/system-overview/cryptography).

128128

129129[Urbit ID](#what-is-urbit-id) / [Azimuth](#what-is-azimuth), Urbit's identity layer, is live on the Ethereum blockchain and has been audited by Open Zeppelin, Blockchain at Berkeley, and Bloctrax.

130130

131−In late 2020, Urbit's [Ames](@/docs/glossary/ames.md) networking protocol was audited by [Leviathan Security](https://www.leviathansecurity.com/). You can read about this milestone [here](@/blog/security-and-continuity.md).

131+In late 2020, Urbit's [Ames](/docs/glossary/ames) networking protocol was audited by [Leviathan Security](https://www.leviathansecurity.com/). You can read about this milestone [here](/blog/security-and-continuity).

132132

133−The security of the runtime, [Vere](@/docs/vere/_index.md), has not yet been adequately assessed or systematically hardened.

133+The security of the runtime, [Vere](/docs/vere/), has not yet been adequately assessed or systematically hardened.

134134

135−All communication on Urbit is end-to-end encrypted. However, the [event log](@/docs/glossary/eventlog.md) is not encrypted at rest but we plan to give users that option in the future.

135+All communication on Urbit is end-to-end encrypted. However, the [event log](/docs/glossary/eventlog) is not encrypted at rest but we plan to give users that option in the future.

136136

137137Tlon keeps a quantum computing expert on staff and understands that post-quantum cryptographic methods must be implemented sooner than later, since any data not already encrypted using these methods is at risk of being collected and decrypted once sufficiently powerful quantum computers exist. [NIST](https://www.nist.gov/) anticipates the release of their preliminary findings on [post-quantum cryptography standards](https://csrc.nist.gov/projects/post-quantum-cryptography) around the end of 2021, with full guidelines following in 2024. Tlon will develop a strategy for post-quantum encryption for Urbit following their recommendations.

138138

@@ -142,7 +142,7 @@ Thus, while Urbit is probably more secure and private than most digital communic

142142

143143The [Urbit Hierarchical Deterministic (HD) Wallet](/docs/glossary/hdwallet) is a custom Ethereum wallet based on BIP39 and BIP44 – the same underlying technology used by wallet providers like Ledger, Trezor, Metamask, and MyEtherWallet. You can think of the Urbit HD wallet as a wallet of wallets, which lets you keep a single passphrase for all of your Urbit ID keys. Urbit ID uses multiple keys with different capabilities – a bit like permissions – so that you can keep the more valuable keys in cold storage while keeping less valuable keys, used in day-to-day operation, more easily accessible. If you're only operating a planet, you shouldn't have to worry about this: you can simply think of your "master ticket" as the password to your Urbit ID. If you're operating a star or galaxy, the Urbit HD Wallet allows you to implement a multi-tier key custody scheme.

144144

145−If you're interested, you can read the spec here: [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet.md).

145+If you're interested, you can read the spec here: [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet).

146146

147147### What is a master ticket? {#master-ticket}

148148

@@ -167,7 +167,7 @@ An ownership address is an Ethereum address that owns one or more of your Urbit

167167

168168All Ethereum key-pairs in the Urbit wallet system, including [proxies](/docs/glossary/proxies), are produced by 128-bit cryptographically random values called seeds. These seeds are the equivalent of the BIP39 mnemonic of an Ethereum wallet and are yours alone. An ownership key pair is derived from an ownership seed and, likewise, the various proxy key pairs are generated from their respective proxy seeds.

169169

170−For detailed information see the [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet.md).

170+For detailed information see the [Urbit HD Wallet Spec (UP 8)](https://github.com/urbit/proposals/blob/master/008-urbit-hd-wallet).

171171

172172### What does it mean to “set public keys”? {#set-public-keys}

173173

content/grants/bitcoin-key-derivation.md+1−1

@@ -52,7 +52,7 @@ The worker should have a background that demonstrates proficiency with building

5252

5353### Resources

5454

55−- [Urbit HD Wallet design](https://github.com/urbit/fora-posts/blob/master/proposals/posts/~2018.11.8..19.31.59..ba77~.md)

55+- [Urbit HD Wallet design](https://github.com/urbit/fora-posts/blob/master/proposals/posts/~2018.11.8..19.31.59..ba77~)

5656- [BIP-32 re: extended public keys](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Extended_keys)

5757

5858## Milestones

content/grants/bitcoin-wallet-on-bridge.md+1−1

@@ -39,7 +39,7 @@ A completed wallet should:

3939- [Bitcoin Core SPV wallet reference](https://bitcoin.org/en/operating-modes-guide#simplified-payment-verification-spv)

4040- [JS Library to interact with SPV wallet](https://github.com/bitcoinjs/bitcoinjs-lib)

4141- [The Bridge repository](https://github.com/urbit/bridge)

42−- [Urbit Wallet Reference](https://github.com/urbit/fora-posts/blob/master/proposals/posts/~2018.11.8..19.31.59..ba77~.md)

42+- [Urbit Wallet Reference](https://github.com/urbit/fora-posts/blob/master/proposals/posts/~2018.11.8..19.31.59..ba77~)

4343- [Urbit Wallet Key Generation](https://github.com/urbit/urbit-key-generation]

4444- [BIP 32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki)

4545- [BIP 39](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki)

content/grants/educational-guide-todomvc-urbit-edition.md+1−1

@@ -61,7 +61,7 @@ using it.

6161

6262This section is fairly straightforward, as it has been covered many times

6363before. ~timluc-miptev's gall guide has a [great

64−overview](https://github.com/timlucmiptev/gall-guide/blob/master/workflow.md#three-workflow-options)

64+overview](https://github.com/timlucmiptev/gall-guide/blob/master/workflow#three-workflow-options)

6565of how to work with fake ships efficiently, and the existing documentation has

6666plenty of material material.

6767

content/grants/the-complete-guide-to-gall-and-landscape.md+1−1

@@ -18,7 +18,7 @@ link = ""

1818

1919## PoC and Prior Work

2020

21−The first 5 chapters of the course are complete in late draft form and can be found [here](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview.md)

21+The first 5 chapters of the course are complete in late draft form and can be found [here](https://github.com/timlucmiptev/gall-guide/blob/master/guide-docs/overview)

2222

2323My ["Nock for Everyday Coders" Guide](https://blog.timlucmiptev.space/part1.html) was the result of my exploring Nock on my own, and is probably the most detailed Nock reference available currently.

2424

content/grants/unit-tests-for-zuse-cryptographic-functions.md+1−1

@@ -32,7 +32,7 @@ Save the test files in the `tests/sys/zuse/crypto` directory in Arvo. Use the sa

3232#### Resources

3333

3434- Read the [guide](https://github.com/urbit/urbit/blob/master/pkg/arvo/TESTING.udon) to writing unit tests in Hoon.

35−- Read the guide to [contributing](https://github.com/urbit/urbit/blob/master/CONTRIBUTING.md).

35+- Read the guide to [contributing](https://github.com/urbit/urbit/blob/master/CONTRIBUTING).

3636- [Here](https://github.com/urbit/urbit/blob/alef2/pkg/arvo/tests/sys/zuse/ordered-map.hoon) is an example test file for the new Ames. Your tests should be similar to it.

3737

3838#### Contribution Guidelines

content/grants/volt-lightning-on-urbit.md+2−2

@@ -110,7 +110,7 @@ Private key/hot wallet management inside Urbit. This is needed to sign commitmen

110110### RFCs implemented

111111

112112We implement everything related to channels, HTLCs, and invoices. We leave out all the Lightning networking and routing elements.

113−[RFCs located here](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md)

113+[RFCs located here](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction)

114114

115115- RFC 02: channel opening, closing, HTLCs

116116- RFC 03: commitment transactions

@@ -231,7 +231,7 @@ It is possible to re-balance channel liquidity (shifting more of the balance to

231231

232232- The libraries and full node interface provided by the `btc-wallet` project will be useful for parsing formats like `bech32` and for querying the state of the blockchain to monitor for cheating.

233233- [Urbit Bitcoin Wallet](https://github.com/timlucmiptev/btc-agents)

234−- [Lightning RFC](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md)

234+- [Lightning RFC](https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction)

235235- [lnd RPC API](https://api.lightning.community/)

236236

237237## contributor requirements

content/updates/2016-5-16-roadmap.md+1−1

@@ -241,4 +241,4 @@ ball and run with it.

241241

242242## Governance

243243

244−See the [interim constitution](../interim-constitution).

244+See the [interim constitution](/blog/interim-constitution).

content/using/id/guide-to-breaches.md+1−1

@@ -20,7 +20,7 @@ has forgotten about it.

2020

2121Breaches often fix connectivity issues, but should only be used as a last

2222resort. Before performing a breach, look at alternative fixes in the [Ship

23−Troubleshooting](../ship-troubleshooting) guide. Also reach out for help in the

23+Troubleshooting](/using/os/ship-troubleshooting) guide. Also reach out for help in the

2424Help channel in the Urbit Community group `~bitbet-bolbel/urbit-community`, or,

2525failing that, in the `#ship-starting-support` channel in our [Discord

2626server](https://discord.gg/n9xhMdz) to see if there is another option.