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

git.iko.soy/urbit.org

remove @ for old zola links

commit510732e0feb4a0caa6dae9dfc11ef4b86ca449c8 authordrbeefsupreme <drbeefsupreme@discordja.net> dateWed 4 Aug 2021, 11:50 (5 years ago) parent0e1157c

13 files changed+64−64

compare with master

unifiedsplit

content/blog/first-contract.md+14−14 content/docs/arvo/ames/ames.md+8−8 content/docs/arvo/ames/cryptography.md+6−6 content/docs/arvo/reference/_index.md+1−1 content/docs/arvo/reference/cryptography.md+9−9 content/docs/arvo/reference/filesystem.md+10−10 content/docs/azimuth/azimuth.md+2−2 content/docs/hoon/reference/irregular.md+2−2 content/docs/system-overview/cryptography.md+3−3 content/docs/userspace/threads/http-api.md+2−2 content/docs/vere/_index.md+1−1 content/docs/vere/cryptography.md+2−2 content/faq.md+4−4

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

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

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

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

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

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.md) and [upgrade

137+proposals](/docs/glossary/upgrade.md). 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

141141audit](@/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

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

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

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

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

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

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.md) `%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.md#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.md)). 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.md) 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.md#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.md), 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/_index.md), 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.md) 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.md#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.md#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.md#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.md#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.md#crub) for more details on

116116how the specific cryptosuite utilized by Ames is implemented.

117117

118118#### `+as:acru`

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

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

14+[SHA Hash Family](/docs/hoon/reference/stdlib/3d.md) 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.md#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.md#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.md) 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.md), 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.md#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.md#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.md) 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.md).

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

24+- `/sur` contains shared [structure](/docs/hoon/reference/rune/_index.md) 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.md). 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.md). 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.md), 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.md) 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.md#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.md). `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.md), 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.md), and this means

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

6161

6262- **Spawn Proxy**

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

@@ -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.md#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.md#kettar) \\\*

228228

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

230230

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

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

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

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

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

1919

2020### Ed25519 {#ed}

2121

content/faq.md+4−4

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

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

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/_index.md), 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.md) 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