Updates to existing documentation

README.md

@@ -24,6 +24,9 @@ The core components of cryptic-net, currently, are:
   storage as they care to, if any. Stored data is sharded and replicated across
   all hosts that choose to provide storage.
 
+* A DNS server which provides automatic host and service (coming soon) discovery
+  within the network.
+
 These components are wrapped into a single binary, with all setup being
 automated. cryptic-net takes "just works" very seriously.
 
@@ -32,20 +35,12 @@ themselves and others. They can be assured that their communications are private
 and their storage is reliable, all with zero administrative overhead and zero
 third parties involved.
 
-[nebula]: https://github.com/slackhq/nebula
-[garage]: https://garagehq.deuxfleurs.fr/documentation/quick-start/
-
 ## Documentation
 
-_NOTE: There is currently only a single live cryptic-net which can be joined,
-though generalizing the bootstrap process so others can create their own network
-is [planned][roadmap]. If you do not know the admins of this cryptic-net then
-unfortunately there's not much you can do right now._
-
 cryptic-net users fall into different roles, depending on their level of
 involvement and expertise within their particular network. The documentation for
 cryptic-net is broken down by these categories, so that the reader can easily
-know which documents they need to care about.
+decide which documents they need to care about.
 
 ### User Docs
 
@@ -93,7 +88,7 @@ Documentation for admins:
 
 ### Dev Docs
 
-Dev may or may not be participants in any particular cryptic-net. They instead
+Devs may or may not be participants in any particular cryptic-net. They instead
 are those who work on the actual code for cryptic-net.
 
 Documentation for devs:

docs/admin/adding-a-host-to-the-network.md

@@ -29,17 +29,11 @@ conform to the following rules:
 
 * It should end with a letter or number.
 
-## Step 2: Add Host to Network
+## Step 2: Choose IP
 
 The admin should choose an IP for the host. The IP you choose for the new host
-should be one which is not yet used by any other host, and which is in the VPN's
-set of allowed IPs.
-
-The admin should perform the following command from their own host:
-
-```
-cryptic-net hosts add --name <name> --ip <ip>
-```
+should be one which is not yet used by any other host, and which is in subnet
+which was configured when creating the network.
 
 ## Step 3: Create a `bootstrap.tgz` File
 
@@ -51,6 +45,7 @@ following command from their own host:
 ```
 cryptic-net hosts make-bootstrap \
     --name <name> \
+    --ip <ip> \
     --admin-path <path to admin.tgz> \
     > bootstrap.tgz
 ```
@@ -73,6 +68,7 @@ generate a `bootstrap.tgz`:
 ```
 gpg -d <path to admin.tgz.gpg> | cryptic-net hosts make-boostrap \
     --name <name> \
+    --ip <ip> \
     --admin-path - \
     > bootstrap.tgz
 ```
@@ -90,5 +86,6 @@ nix-build --arg bootstrap <path to bootstrap.tgz> -A appImage
 ```
 
 The resulting binary can be found in the `result` directory which is created.
-Note that this binary should be treated like a `bootstrap.tgz` in terms of its
-uniqueness and sensitivity.
+
+This binary should be treated like a `bootstrap.tgz` in terms of its uniqueness
+and sensitivity.

docs/operator/contributing-storage.md

@@ -34,15 +34,11 @@ storage:
     - data_path: /mnt/drive1/cryptic-net/data
       meta_path: /mnt/drive1/cryptic-net/meta
       capacity: 1200
-      api_port: 3900
-      rpc_port: 3901
 
     # 100 GB (the minimum) are being shared from drive2
     - data_path: /mnt/drive2/cryptic-net/data
       meta_path: /mnt/drive2/cryptic-net/meta
       capacity: 100
-      api_port: 3910
-      rpc_port: 3911
 ```
 
 ## Setup Firewall

docs/roadmap.md

@@ -14,12 +14,6 @@ Currently the only supported OS/CPU is Linux/amd64. This can be expanded
 _theoretically_ quite easily, using nix's cross compilation tools. First target
 should be OSX/arm64, but windows would also be quite the get.
 
-### Bootstrap
-
-This will be difficult. There's currently no way to bootstrap a new cryptic-net
-network from scratch, only the currently existing one is supported. Support for
-IPv6 internal CIDR should also be a part of this effort.
-
 ### Testing
 
 Once bootstrap is generalized, we'll be able to write some automated tests.

docs/user/creating-a-daemonyml-file.md

@@ -1,8 +1,8 @@
 # Creating a daemon.yml File
 
 The `cryptic-net daemon` process has generally sane defaults and does not need
-to be configured for most users. However, in some cases it does, so this
-document describes how to use the `daemon.yml` file to handle those cases.
+to be configured for most users. This document describes how to use the
+`daemon.yml` file to handle those cases where configuration is necessary.
 
 ## Create daemon.yml
 
@@ -28,5 +28,5 @@ sudo cryptic-net daemon -c /path/to/daemon.yml
 
 If you are an operator then your host should be running its `cryptic-net daemon`
 process in systemd (see [Getting Started](getting-started.md) if
-not), and you will need to modify the `cryptic-net.service` accordingly.
+not), and you will need to modify the service file accordingly.
 

docs/user/getting-started.md

@@ -13,7 +13,7 @@ host embedded directly into it. Such binaries require no extra configuration by
 the user to use, and have no dependencies on anything else in the user's system.
 
 The process of obtaining a custom binary for your host is quite simple: ask an
-admin of the network you'd like to join to give you one!
+admin of your network to give you one!
 
 Note that if you'd like to join the network on multiple devices, each device
 will needs its own binary, so be sure to tell your admin how many you want to

docs/user/using-dns.md

@@ -4,14 +4,13 @@ Every `cryptic-net daemon` process ships with a DNS server which runs
 automatically. This server will listen on port 53 on the VPN IP of that
 particular host.
 
-The server will serve requests for `<hostname>.hosts.cryptic.io` hostnames,
-where `<hostname>` is any host's name in the `bootstrap/nebula/hosts` directory.
-The returned IP will be the corresponding IP for the host, as listed in the
-host's `bootstrap/nebula/hosts` file.
-
-If a request for a non `.cryptic.io` hostname is received then the server will
-forward the request to a pre-configured public resolver. The set of public
-resolvers used can be configured using the
+The server will serve requests for `<hostname>.hosts.<domain>` hostnames,
+where `<hostname>` is the name of any host in the network, and `<domain`> is the
+network's domain name.
+
+If a request for a hostname not within the network's domain is received then the
+server will forward the request to a pre-configured public resolver. The set of
+public resolvers used can be configured using the
 [daemon.yml](creating-a-daemonyml-file.md) file.
 
 This DNS server is an optional feature of cryptic-net, and not required in
@@ -20,8 +19,9 @@ general for making use of the network.
 ## Example
 
 As an example of how to make use of this DNS server, let's say my host's IP on
-the network is `10.10.1.1`. In order to configure the host to use the
-cryptic-net DNS server for all DNS requests, I could do something like this:
+the network is `10.10.1.1`, and my network's domain is `cool.internal`.
+In order to configure the host to use the cryptic-net DNS server for all DNS
+requests, I could do something like this:
 
 ```
 sudo su
@@ -29,8 +29,8 @@ echo "nameserver 10.10.1.1" > /etc/resolv.conf
 ```
 
 From that point, all DNS requests on my host would hit the cryptic-net DNS
-server. If I request `my-host.cryptic.io`, it would respond with the appropriate
-private IP.
+server. If I request `my-host.hosts.cool.internal`, it would respond with the
+appropriate private IP.
 
 NOTE that configuration of dns resolvers is very OS-specific, even amongst Linux
 distributions, so ensure you know how your resolver configuration works before