Merge pull request #177 from jurij-jukic/section-2-4

Section 2.4. Http Server and Client

src/http_server_and_client.md

@@ -6,16 +6,25 @@ This enables Kinode apps to read data from the web (and other Kinodes), and also
 The HTTP server is how most processes in the Kinode OS present their interface to the user, through an authenticated web browser.
 
 The specification for the [server](./apis/http_server.md) and [client](./apis/http_client.md) APIs are available in the API reference.
-These APIs are accessible via messaging the `http_server:distro:sys` and `http_client:distro:sys` runtime extensions, respectively.
+These APIs are accessible via messaging the [`http_server:distro:sys`](https://github.com/kinode-dao/kinode/blob/main/kinode/src/http/server.rs) and [`http_client:distro:sys`](https://github.com/kinode-dao/kinode/blob/main/kinode/src/http/client.rs) runtime modules, respectively.
 The only [capability](./process/capabilities.md) required to use either process is the one to message it, granted by the kernel.
 
 WebSocket server/client functionality is presented alongside HTTP.
 
-At startup, the server task finds an open port, starting its search at 8080, to bind at and listen for HTTP and WebSocket requests.
-All server functionality can be either authenticated or public.
-If a given functionality is public, it is presented open to the world.
-Note that the configuration of the Kinode will still determine whether it is accessible over IPv4/IPv6 – Kinode OS does also not provide any DNS management for nodes.
-Since direct nodes are expected to be accessible over IP, their HTTP server is likely to work, if the bound port is accessible.
-However, indirect nodes are not expected to be accessible over IP, so in the near future, the HTTP server will include a proxying feature to allow indirect nodes to serve HTTP requests.
+At startup, the server either:
+1. Binds to the port given at the commandline, or
+2. Searches for an open port (starting at 8080, if not, then 8081, etc.).
 
+The server then binds this port, listening for HTTP and WebSocket requests.
 
+## Private and Public Serving
+
+All server functionality can be either private (authenticated) or public.
+If a given functionality is public, the Kinode serves HTTP openly to the world; if it is authenticated, you need your node's password so that your node can generate a cookie that grants you access. 
+
+## Direct and Indirect Nodes
+
+Since direct nodes are expected to be accessible over IP, their HTTP server is likely to work if the bound port is accessible.
+Note that direct nodes will need to do their own IP/DNS configuration, as Kinode doesn't provide any DNS management.
+
+However, Kinode provides indirect nodes for users who don't want to do this config, as indirect nodes are not expected to be accessible over IP. For more, see [Domain Resolution](https://book.kinode.org/identity_system.html#domain-resolution).