510732e · urbit.org · git.iko.soy

git.iko.soy/urbit.org

on master help sign in

remove @ for old zola links

510732edrbeefsupreme5 years ago

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

compare with master

unifiedsplit

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

15<br>

17Recently, 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

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

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

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

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

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

23proposed 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.

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

27is 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.md). Azimuth is the data of the

29public 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.md) and which Ethereum addresses own them, along

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

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

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

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

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

36These 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.md) have, how stars/planets are released over

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

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

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

@@ -129,17 +129,17 @@ revisit and refresh these documents soon.

129

130### Galactic Senate

131

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

145

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

198

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

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

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

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

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

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

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

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

205

206The 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.md) via `~zod`, and suggest that people

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

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

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

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

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

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

13Ames 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.md) and [Clay](/docs/arvo/clay/clay.md)

15to communicate with other ships rather than using Ames

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

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

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

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

29elaborations on the concepts presented here.

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

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

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

34effects. 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:

135 - 2 bits: sender address size

136 - 2 bits: receiver address size

137 - 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.md#mug)

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

140

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

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

159

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

161 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.md)). It is formed from the

163 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.md) for information on what `life`

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

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

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

168

169 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.md#en).

171

172### Packeting

173

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

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

257under `@ud`.

258

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.md), or revision

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

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

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

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

428

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

430called 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/_index.md), but we summarize it here.

432

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

434of 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

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

37a 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.md) for more information on packet structure). The

39message 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.md#en) found in

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

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

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

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

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

47`@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.md#ed) found in `sys/zuse.hoon`,

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

50[Diffie-Hellman key

51exchange](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

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

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

64is generated with

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

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

66`sys/zuse.hoon`.

68Upon 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.

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

79The `+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.md#dry-polymorphism-and-core-nesting-rules)

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

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

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

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

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

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

114core 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.md#crub) for more details on

116how the specific cryptosuite utilized by Ames is implemented.

117

118#### `+as:acru`

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

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

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

6+++

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

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

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

11they are implemented.

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

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

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

8standard 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.md). `zuse` also contains

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

11but they are currently undocumented.

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

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

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

15library reference.

17## Summary

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

20[`+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.md#crypto-core)-shaped core.

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

25`+crub:crypto` implements an

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

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

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

29It 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

198key agreements as well as [Elliptic Curve Digital Signature

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

200These 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.md) makes use of.

202

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.md), meaning that an

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

205rather 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.md#ed) for more information about the

207library utilized by jets.

208

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

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

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

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

215jetted. 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.md#aes) for more information about the library

217utilized by jets.

218

219This 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"

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

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

9of 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.md) are designed with this structure in mind, and

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

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

13definitions in `/lib`, for example.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

32 `/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.md). These may be

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

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

36 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

44give a brief description of each of them.

46- `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.md). The Hoon

48 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.md), in order for it to learn how to

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

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

52 `.` 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.md) and

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

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

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

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

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

62 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.md#larval-stage-core)

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

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

66 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.md). `zuse.hoon` is loaded

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

69 `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

44### Ownership Address

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.md), Azimuth's suite of governing smart-contracts.

48### Proxies

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

57- **Voting Proxy**

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.md), and this means

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

62- **Spawn Proxy**

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

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

204

205### `^:` ketcol

206

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

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

208

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

210

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

224

225### `^*` kettar

226

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

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

228

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

230

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

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

119The following pages contained more detailed information about the cryptography

120utilized by each of the system components.

121

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

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

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

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

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

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

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

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

4template = "doc.html"

5+++

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.md#authentication) HTTP POST requests.

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

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

46(pure:m !>(json))

47```

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.md#authenticating).

51Now 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"}]`:

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

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

38A jetting guide by for new Urbit developers.

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

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

42References on the cryptography libraries utilized by jets.

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

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

5+++

7All cryptographic primitives utilized by Arvo are

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

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

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

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

11the primitives written in C.

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

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

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

17note 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.md) as well.

20### Ed25519 {#ed}

content/faq.md+4−4

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

124

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

126

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

128

129[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.

130

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.md) networking protocol was audited by [Leviathan Security](https://www.leviathansecurity.com/). You can read about this milestone [here](@/blog/security-and-continuity.md).

132

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/_index.md), has not yet been adequately assessed or systematically hardened.

134

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.md) is not encrypted at rest but we plan to give users that option in the future.

136

137Tlon 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.

138