Spec out some new tasks, re-organize old ones

tasks/README.md

@@ -4,9 +4,6 @@ This directory contains [busiless][busiless] task files. Each file corresponds
 to a task which must be done, unless it is located in a `drafts` directory in
 which case it is still under consideration.
 
-Tasks are organized according to when they are planned for, except for tasks in
-the `soon` directory which are only planned in the loosest sense of the word.
-
 ## Usage
 
 Creating new task files is as simple as creating a new markdown file with the

tasks/s3fs-fuse/global.md

@@ -0,0 +1,15 @@
+---
+type: task
+after:
+  - /secrets/propagation/*
+---
+
+We use the [s3fs-fuse](https://github.com/s3fs-fuse/s3fs-fuse) project to set up
+an easily usable global network file system for all hosts in the network.
+
+The global network filesystem is based out of its own bucket in garage, separate
+from all others.
+
+## To Figure Out
+
+Where does the filesystem get mounted? How does that get configured?

tasks/secrets/propagation/README.md

@@ -0,0 +1,29 @@
+# Secret Propagation
+
+Secrets are pieces of data which are not (necessarily) shared amongst all hosts
+in a network. There are three clases of secrets:
+
+* Secrets which are particular to a single host, and will never leave that host.
+  These values are not managed using the secrets manager, but rather are kept in
+  the bootstrap.
+
+* Secrets which only a subset of hosts have. These secrets may be propagated to
+  other hosts, either automatically or by request of a user.
+
+* Secrets which all hosts have. These are not really "secrets" from the
+  network's perspective, but are convenient to manage as such.
+
+Secret propagation is related to the second two cases. Secrets to be propagated
+are placed in a known sub-directory in the global bucket, destined either for a
+single host or all hosts. When destined for a single host they are encrypted
+using that host's public encryption key.
+
+The known sub-directory is `/secrets`.
+
+Secrets destined for all hosts are placed within that directory as-is, named for
+the ID, in plaintext. These are never deleted, even though new hosts will be
+given them as part of their initial bootstrap.
+
+Secrets destined for a particular host are placed under `/secrets/<hostname>`,
+named after the ID, encrypted using the destination host's public encryption
+key. Once the destination host grabs a secret it will be deleted.

tasks/secrets/propagation/polling.md

@@ -0,0 +1,8 @@
+---
+type: tasks
+---
+
+Secrets which are placed in the global bucket according to the
+[README.md](./README.md) should be periodically pulled down into each host. When
+secrets are destined only for the host they should be deleted after they've been
+pulled down.

tasks/secrets/propagation/putting.md

@@ -0,0 +1,8 @@
+---
+type: tasks
+after:
+  - ./polling.md
+---
+
+A mechanism should be created for secrets to be placed in the `/secrets`
+sub-directory of the global bucket, as laid out by the [README.md](./README.md). 

tasks/soon/misc/ipv6-support.md

@@ -4,6 +4,9 @@ type: task
 
 # IPv6 Support
 
+NOTE: this is actually blocked on nebula, which does not yet support IPv6
+overlay ranges. But they are working on it.
+
 It should be possible for nebula IP ranges to use designated private IPv6
 ranges. Depending on how wide these ranges are it might even be possible for
 CreateNetwork to automatically assign an IP range, with some hope that there's

tasks/soon/misc/omitempty-bootstrap.md

@@ -0,0 +1,7 @@
+---
+type: task
+---
+
+When marshaling bootstrap data to yaml/json, it would be good to be a bit more
+aggressive about `omitempty` tags. The bootstrap file is getting quite big
+already, even with just 5 hosts in the network.