about summary refs log tree commit diff
path: root/tvix/docs/src/TODO.md
diff options
context:
space:
mode:
Diffstat (limited to 'tvix/docs/src/TODO.md')
-rw-r--r--tvix/docs/src/TODO.md43
1 files changed, 43 insertions, 0 deletions
diff --git a/tvix/docs/src/TODO.md b/tvix/docs/src/TODO.md
index af558c9580fe..9f8feef9e3ac 100644
--- a/tvix/docs/src/TODO.md
+++ b/tvix/docs/src/TODO.md
@@ -136,6 +136,49 @@ Similarly, we also don't properly populate the build environment for
 `fetchClosure` yet. (Note there already is `ExportedPathInfo`, so once
 `structuredAttrs` is there this should be easy.
 
+### PathInfo Data types
+Similar to the refactors done in tvix-castore, we want a stricter type for
+PathInfo, and use the `tvix_castore::nodes::Node` type we now have as the root
+node.
+
+This allows removing some checks, conversions and handling for invalid data in
+many different places in different store implementations.
+
+Steps:
+
+ - Define the stricter `PathInfo` type
+ - Update the `PathInfoService` trait to use the stricter types
+ - Update the grpc client impl to convert from the proto types to the
+   stricter types (and reject invalid ones)
+ - Update the grpc server wrapper to convert to the proto types
+
+### PathInfo: include references by content
+In the PathInfo struct, we currently only store references by their names and
+store path hash. Getting the castore node for the content at that store path
+requires another lookup to the PathInfoService.
+
+Due to this information missing, this also means we currently cannot preserve
+information necessary to detect/prevent
+[Frankenbuilds](https://tvl.fyi/blog/tvix-update-february-24#builder-protocol-drv-builder).
+
+We should extend/change the `PathInfo` type to maintain references in a
+`BTreeMap` from store path basename to castore node. Should probably be done
+after PathInfo uses its own data type.
+
+The `NixHTTPPathInfoService` needs to get some more logic to populate the ca
+bits of the references:
+
+ - If the referenced store path if not present in our PathInfoService hierarchy,
+   it needs to be ingested too, and persisted.
+ - If the referenced store path is present, we can use the castore root from there.
+   In an optional mode, we should parse the .narinfo file for the reference, and
+   compare the nar hash with our local one, to detect Frankenbuilds in a binary
+cache.
+
+As `NixHTTPPathInfoService` now needs to interact with "the PathInfoService"
+hierarchy, we need to accept a pointer to a PathInfoService (hierarchy) that's
+used to check for presence, and PathInfos are inserted into.
+
 ### Builders
 Once builds are proven to work with real-world builds, and the corner cases
 there are ruled out, adding other types of builders might be interesting.