feat(web/website): init

This adds a new Website/Docs for Snix, using Thulite / Doks, which is
mostly hugo and a bit of npm.

Change-Id: Iea10d4068fa783ec0ddd6bcaba5c8d92b1a1168f

web/content/docs/components/build/_index.md

@@ -0,0 +1,13 @@
+---
+title: "Builder"
+description: ""
+summary: ""
+date: 2023-09-07T16:12:37+02:00
+lastmod: 2023-09-07T16:12:37+02:00
+draft: false
+weight: 40
+toc: true
+sidebar:
+  collapsed: true
+---
+

web/content/docs/components/build/oci.md

@@ -0,0 +1,17 @@
+---
+title: "OCI Builder"
+slug: oci
+description: ""
+summary: ""
+date: 2023-09-07T16:12:37+02:00
+lastmod: 2023-09-07T16:12:37+02:00
+draft: false
+weight: 42
+toc: true
+sidebar:
+  collapsed: true
+---
+
+The OCI builder creates a OCI Runtime specification out of the received
+`BuildRequest`, then mounts the specified inputs using snix-castore, and then
+invokes `runc`.

web/content/docs/components/build/protocol.md

@@ -0,0 +1,35 @@
+---
+title: "Protocol"
+slug: protocol
+description: ""
+summary: ""
+date: 2025-03-14T14:14:35+01:00
+lastmod: 2025-03-14T14:14:35+01:00
+draft: false
+weight: 41
+toc: true
+---
+
+One goal of the builder protocol is to not be too tied to the Nix implementation
+itself, allowing it to be used for other builds/workloads in the future.
+
+This means the builder protocol is versatile enough to express the environment a
+Nix build expects, while not being aware of "what any of this means".
+
+For example, it is not aware of how certain environment variables are set in a
+nix build, but allows specifying environment variables that should be set.
+
+It's also not aware of what nix store paths are. Instead, it allows:
+
+ - specifying a list of paths expected to be produced during the build
+ - specifying a list of castore root nodes to be present in a specified
+   `inputs_dir`.
+ - specifying which paths are write-able during build.
+
+In case all specified paths are produced, and the command specified in
+`command_args` succeeds, the build is considered to be successful.
+
+This happens to be sufficient to *also* express how Nix builds works.
+
+Check `build/protos/build.proto` for a detailed description of the individual
+fields, and the tests in `glue/src/tvix_build.rs` for some examples.

web/content/docs/components/build/reference-scanning.md

@@ -0,0 +1,45 @@
+---
+title: "Reference Scanning"
+summary: ""
+date: 2025-03-14T14:14:35+01:00
+lastmod: 2025-03-14T14:14:35+01:00
+draft: false
+weight: 45
+toc: true
+---
+
+At the end of a build, Nix does scan a store path for references to other store
+paths (*out of the set of all store paths present during the build*).
+It does do this by (only) looking for a list of nixbase32-encoded hashes in
+filenames (?), symlink targets and blob contents.
+
+As outlined in the [Builder Protocol]({{< relref "protocol" >}}) page, we
+don't want to introduce Nix specifics to the builder protocol, but if we simply
+do refscanning on the coordinator side, that side would need to download the
+produced inputs and scan them locally.
+
+This is undesireable, as the builder already has all produced
+outputs locally, and it'd make more sense for it do do it.
+
+Instead, we want to describe reference scanning in a generic, non-Nix-specific
+fashion.
+
+## Proposal
+
+One way to do this is to add an additional field `refscan_needles` to the
+`BuildRequest` message.
+If this is an non-empty list, all `outputs` are scanned for these.
+
+The `Build` response message would then be extended with an `outputs_needles`
+field, containing the same number of elements as the existing `outputs` field,
+describing which `refscan_needles` are found for each output.
+
+If there's needles found, they will be a list of indexes into the
+`refscan_needles` field specified in the `BuildRequest` field.
+
+For Nix, `refscan_needles` would be populated with the nixbase32 hash parts of
+every input store path and output store path. The latter is necessary to scan
+for references between multi-output derivations.
+
+This is sufficient to construct the referred store paths in each build output on
+the build client.