From f408bc51bf27ed3ba3a531676c354915a2de4775 Mon Sep 17 00:00:00 2001
From: fricklerhandwerk <valentin.gagarin@tweag.io>
Date: Wed, 16 Apr 2025 19:51:58 +0200
Subject: [PATCH] 2025-04-16 development notes

---
 meeting-notes/2025-04-16_development-notes.md | 75 +++++++++++++++++++
 1 file changed, 75 insertions(+)
 create mode 100644 meeting-notes/2025-04-16_development-notes.md

diff --git a/meeting-notes/2025-04-16_development-notes.md b/meeting-notes/2025-04-16_development-notes.md
new file mode 100644
index 0000000..f4dfc60
--- /dev/null
+++ b/meeting-notes/2025-04-16_development-notes.md
@@ -0,0 +1,75 @@
+Attendees: @kiara @fricklerhandwerk
+
+- adapted semantics of JSON schema conversion to the module system: https://git.clan.lol/clan/clan-core/pulls/3335
+- fixed some build issues in https://git.fediversity.eu/Fediversity/Fediversity/pulls/307
+- got form rendering to work again in https://git.fediversity.eu/Fediversity/Fediversity/pulls/285
+  - also minor cleanups on the way to getting it mergeable
+- discussed considerations of mapping NixOS modules to UI elements
+  - problem: NixOS modules don't have a notion of field label (important for forms) and the best we can currently do is derive it from the attribute name (meh)
+  - related work by @hsjobeki:
+    - https://discourse.nixos.org/t/zurich-24-11-zhf-hackathon-report/59250#p-197228-on-user-interfaces-for-nixos-configurations-6
+    - https://github.com/NixOS/nixpkgs/pull/341199
+  - @fricklerhandwerk: not convinced that adding more hard-coded fields to module options is the right way
+    - it's ad hoc, where does it end?
+    - the problem statement is relevant though, we need to somehow annotate presentation aspects
+  - @kiara: https://rjsf-team.github.io/react-jsonschema-form/ implements these annotations
+    - @fricklerhandwerk: textual references are a maintenance burden; opportunity for human error
+- sketched an idea for structural annotations using a module system wrapper:
+
+```nix
+let
+  fancy-wrapper = go-wild (
+    { lib, ... }:
+    let
+      inherit (lib) mkOption types;
+    in
+    {
+      options = {
+        initialUser = mkOption {
+          type = types.submodule {
+            options = {
+            displayName = mkOption {
+                type = types.str;
+                description = "Display name of the user";
+                meta.ui = lib.mkOptionMeta {
+                  type = types.uiSchema;
+                  value = {
+                    title = "Display name";
+                  };
+                };
+            };
+      };
+    });
+in
+{
+  module-options = fancy-wrapper.module;
+  annotations = fancy-wrapper.annotations;
+}
+```
+
+The `fancy-wrapper` would inject a custom `lib` where module-system-related functions will essentially act as `id` to preserve the information passed to them. On its outputs it will
+- reconstruct the module specification, throwing away the `meta` annotations
+- splice out the `meta` annotations and convert them to regular modules with the appropriate fields
+
+Then, the value of `fancy-wrapper.annotations` would mirror the stuctrue of the module in the example be equivalent to something along the lines of:
+
+```nix
+{ lib, ... }
+let
+  inherit (lib) mkOption types;
+in
+{
+  options = {
+    initialUser = {
+      displayName = mkOption {
+        type = types.uiSchema;
+        default = {
+          label = "Display name";
+        };
+      };
+    };
+  };
+}
+```
+
+Matching up the string identifiers could then be done programmatically by a function (supplied with the fancy wrapper library for use within the Nix language), so humans would be out of the loop. 
\ No newline at end of file