update all vane discussion to mention khan

content/guides/core/app-school/1-arvo.md

@@ -47,7 +47,6 @@ Here's a brief summary of each of the vanes:
   source code and relevant files are automatically built and loaded upon
   installation, so your Gall agent itself would not need to interact with Clay
   unless you specifically wanted to read and write files.
-
 - **Dill**: Terminal driver vane. You would not typically interact with Dill
   directly; printing debug messages to the terminal is usually done with hinting runes
   and functions rather than tasks to Dill, and CLI apps are mediated by a
@@ -60,9 +59,7 @@ Here's a brief summary of each of the vanes:
   Guide](/reference/arvo/eyre/guide) for details), but usually you'd just serve a
   front-end [glob](/reference/additional/dist/glob) via the `%docket` agent, so you'd
   not typically have your agent deal with Eyre directly.
-
 - **Gall**: App management vane; this is where your agent lives.
-
 - **Iris**: Web client vane. If you want your agent to query external web APIs and
   the like, it's done via Iris. Oftentimes web API interactions are
   spun out into [threads](/guides/additional/threads/fundamentals) to avoid
@@ -73,15 +70,19 @@ Here's a brief summary of each of the vanes:
   since Gall handles Ames communications for you, you'd not typically deal with
   Jael directly unless your were specifically writing something that made use of
   its data.
+- **Khan**: Control plane vane. The main purpose of Khan is for external
+  application to be able to run threads via a Unix socket and receive their
+  results. Khan's external interface is still experimental, but it's also good
+  for running threads internally.
 
 ## Userspace
 
 Gall agents live in "userspace" as opposed to "kernelspace". Kernelspace is Arvo
-and its eight vanes. Userspace is primarily Gall agents, generators, threads,
+and its nine vanes. Userspace is primarily Gall agents, generators, threads,
 front-ends, and all of their related files in Clay. The distinction looks
 something like this:
 
-[![kernelspace/userspace diagram](https://media.urbit.org/guides/core/app-school/kernelspace-userspace-diagram.svg)](https://media.urbit.org/guides/core/app-school/kernelspace-userspace-diagram.svg)
+[![kernelspace/userspace diagram](https://media.urbit.org/guides/core/app-school/kernelspace-userspace-diagram-v1.svg)](https://media.urbit.org/guides/core/app-school/kernelspace-userspace-diagram-v1.svg)
 
 By and large, Gall _is_ the userspace vane - the majority of userspace is either
 Gall agents, or things used by Gall agents. Apart from the agents themselves,
@@ -212,7 +213,8 @@ sys
 │   ├── eyre.hoon
 │   ├── gall.hoon
 │   ├── iris.hoon
-│   └── jael.hoon
+│   ├── jael.hoon
+│   └── khan.hoon
 └── zuse.hoon
 ```
 

content/guides/core/app-school/5-cards.md

@@ -157,6 +157,7 @@ A `note-arvo` is defined in `lull.hoon` like so:
       [%g task:gall]
       [%i task:iris]
       [%j task:jael]
+      [%k task:khan]
       [%$ %whiz ~]
       [@tas %meta vase]
   ==

content/guides/core/app-school/9-vanes.md

@@ -58,6 +58,7 @@ The `path` will just be the `wire` you want the response to arrive on. The
       [%g task:gall]
       [%i task:iris]
       [%j task:jael]
+      [%k task:khan]
       [%$ %whiz ~]
       [@tas %meta vase]
   ==
@@ -108,6 +109,7 @@ A `sign-arvo` is the following structure, defined in `lull.hoon`:
       [%gall gift:gall]
       [%iris gift:iris]
       [%jael gift:jael]
+      [%khan gift:khan]
   ==
 ```
 

content/guides/core/app-school/intro.md

@@ -12,7 +12,7 @@ equivalent, you should be fine.
 
 ## What are Gall agents?
 
-Gall is one of the eight vanes (kernel modules) of Arvo, Urbit's operating
+Gall is one of the nine vanes (kernel modules) of Arvo, Urbit's operating
 system. Gall's purpose is to manage userspace applications called _agents_.
 
 An agent is a piece of software that is primarily focused on maintaining and

content/overview/arvo.md

@@ -29,3 +29,4 @@ Arvo modules are also called 'vanes'. Arvo's vanes are:
 - [Gall](/reference/arvo/gall/gall): application sandbox and manager.
 - [Iris](/reference/arvo/iris/iris): HTTP client.
 - [Jael](/reference/arvo/jael/jael): Public and private key storage.
+- [Khan](/reference/arvo/khan/khan): Control plane and thread runner.

content/reference/arvo/concepts/scry.md

@@ -19,7 +19,7 @@ Scries are performed exclusively with the dotket rune: `.^`
 
 For details of its usage, see the [dotket](/reference/hoon/rune/dot#-dotket) section of the Nock rune documentation. In addition to the dotket documentation, below is a colour-coded diagram breaking down the structure of a dotket scry expression with some additional notes.
 
-![Scry diagram](https://storage.googleapis.com/media.urbit.org/docs/arvo/scry-diagram-v2.svg)
+![Scry diagram](https://media.urbit.org/docs/arvo/scry-diagram-v3.svg)
 
 One further note on `care`s (which can sometimes be confusing): While `care`s are part of the global namespace, they're most extensively used by Clay in particular. In Clay, `care`s specify Clay submodules with specific behaviour, and are used both in scries as well as `task`s and `gift`s. For example, a `%x` `care` reads the data of a file, a `%p` `care` reads file permissions, and so forth. To see all of Clay's `care`s and what they do, you can refer to Clay's [Scry Reference](/reference/arvo/clay/scry).
 
@@ -31,7 +31,15 @@ There are two places where scry endpoints are defined:
 
 #### Vanes
 
-Each of Arvo's eight vanes (kernel modules) include a `+scry` arm which defines that vane's scry endpoints. The number of endpoints and extent of data available varies between vanes. For example, Clay has a very extensive set of scry endpoints which provide read access to all files in all desks across all revisions, as well as the ability to build files, perform `mark` conversions, and various other functions. Jael provides access to a great deal of PKI data. On the other hand, Dill has only a couple of endpoints which are mostly useful for debugging, and Iris has none at all (apart from standard memory reporting endpoints you'd not typically use in your applications).
+Each of Arvo's nine vanes (kernel modules) include a `+scry` arm which defines
+that vane's scry endpoints. The number of endpoints and extent of data available
+varies between vanes. For example, Clay has a very extensive set of scry
+endpoints which provide read access to all files in all desks across all
+revisions, as well as the ability to build files, perform `mark` conversions,
+and various other functions. Jael provides access to a great deal of PKI data.
+On the other hand, Dill has only a couple of endpoints which are mostly useful
+for debugging, and Iris has none at all (apart from standard memory reporting
+endpoints you'd not typically use in your applications).
 
 To explore what scry endpoints are available for vanes, you can refer to the Scry Reference section of each vane in the [Arvo](/reference/arvo/overview) section of the documents.
 

content/reference/arvo/gall/data-types.md

@@ -241,6 +241,7 @@ vanes, or for sending out updates to subscribers. The three cases are:
         [%g task:gall]
         [%i task:iris]
         [%j task:jael]
+        [%k task:khan]
         [%$ %whiz ~]
         [@tas %meta vase]
     ==
@@ -476,6 +477,7 @@ This arm is called when a vane gives our agent a `gift`. A `sign-arvo` is:
       [%gall gift:gall]
       [%iris gift:iris]
       [%jael gift:jael]
+      [%khan gift:khan]
   ==
 ```
 

content/reference/arvo/overview.md

@@ -530,7 +530,7 @@ As described above, we use Arvo proper to route and control the flow of `move`s.
 However, Arvo proper is rarely directly responsible for processing the event
 data that directly causes the desired outcome of a `move`. This event data is contained within a `card`. Instead, Arvo proper passes the `card` off to one of its vanes, which each present an interface to clients for a particular well-defined, stable, and general-purpose piece of functionality.
 
-As of this writing, we have eight vanes, which each provide the following services:
+As of this writing, we have nine vanes, which each provide the following services:
 
 - [Ames](/reference/arvo/ames/ames): the name of both our network and the vane that communicates over it.
 - [Behn](/reference/arvo/behn/behn): a simple timer.
@@ -540,6 +540,7 @@ As of this writing, we have eight vanes, which each provide the following servic
 - [Gall](/reference/arvo/gall/gall): manages our userspace applications. `%gall` keeps state and manages subscribers.
 - [Iris](/reference/arvo/iris/iris): an http client.
 - [Jael](/reference/arvo/jael/jael): storage for Azimuth information.
+- [Khan](/reference/arvo/khan/khan): control plane and thread runner.
 
 #### Applying your knowledge
 

content/reference/glossary/arvo.md

@@ -38,12 +38,14 @@ Here, [Vere](/reference/glossary/vere) is the virtual machine running Urbit.
 
 Arvo is located in `/base/sys/arvo.hoon` within your urbit.
 
-Arvo vanes include [Ames](/reference/glossary/ames) for networking,
+Arvo vanes are [Ames](/reference/glossary/ames) for networking,
 [Behn](/reference/glossary/behn) for timing, [Clay](/reference/glossary/clay)
 for the filesystem and build system, [Dill](/reference/glossary/dill) for
 terminal driving, [Eyre](/reference/glossary/eyre) for the web server,
-[Gall](/reference/glossary/gall) for application management, and
-[Iris](/reference/glossary/iris) for the HTTP client.
+[Gall](/reference/glossary/gall) for application management,
+[Iris](/reference/glossary/iris) for the HTTP client,
+[Jael](/reference/glossary/jael) for PKI management, and
+[Khan](/reference/glossary/khan) for external control and thread running.
 
 Vanes and other programs for Arvo are written in [Hoon](/reference/glossary/hoon).