2025-05-06 developer sync notes

meeting-notes/2025-05-06 developer sync.md

@@ -0,0 +1,26 @@
+# 2025-05-06 developer sync
+
+- @niols
+  - got the full roundtrip of deploying with NixOps4 working in a NixOS test
+    - this was not obvious how to do efficiently, especially because the deploying node keeps rebuilding all of the dependencies within the test (or fails because it wants to download some source)
+    - there were some issues wiring up ACME for the reverse proxy
+- @fricklerhandwerk
+  - investigated https://selfprivacy.org/
+    - it's funded with a Fediversity subgrant, does something very similar for smaller-scale (self-hosted) deployments
+    - they have [their own notion of application](https://selfprivacy.org/docs/theory/selfprivacy_modules/) defined in terms a special flake output (seems not to be enforced by e.g. module system types?)
+    - very similar to what we're doing, and similar to ngi.nixos.org it tries to solve the problem that NixOS doesn't have its own notion of application, which is the main barrier to entry
+      - we should probably try to converge on an upstream RFC, because multiple groups seem to be duplicating (and doing slightly divergent) work
+  - investigated https://github.com/ibizaman/selfhostblocks
+    - it's not fully mature yet, but seems usable and would help us plug different e.g. auth, secrets, or storage backend if we adopt it
+    - will meet the developer at Zurich ZHF end of May
+  - all of this seems vaguely related with @roberth's [modular services](https://github.com/NixOS/nixpkgs/pull/372170)
+    - one could argue that modular services abide to "canonical" contracts (in terms of SelfHostBlocks), in the sense that they live in the NixOS options tree
+  - also investigated https://clan.lol/blog/vars/
+    - if viewed in terms of SelfHostBlocks and modular services, `vars` proposes a canonical contract for wiring up files at evaluation time and producing them (somehow, typically at activation time since it's aimed at secrets)
+    - they plan to build an interface for exchanging values at service runtime (which sounds reasonable)
+    - thanks @niols for helping with coming up with that clarification
+  - these similarities indicate that it's a worthwhile problem to solve
+    - when combining these ideas, we may e.g. have a canonical interface for applications
+- @kiara
+  - refactored the build setup, with reviews from @fricklerhandwerk
+  - kept iterating on the terraform deployment