diff --git a/meeting-notes/2025-03-03-progress-indicator-meeting.md b/meeting-notes/2025-03-03-progress-indicator-meeting.md
new file mode 100644
index 0000000..b45e498
--- /dev/null
+++ b/meeting-notes/2025-03-03-progress-indicator-meeting.md
@@ -0,0 +1,45 @@
+# Sync with Robert on NixOps4 dependencies for the MVP
+
+The current idea is to control Terraform from NixOps4 at the resource provider level and handle data flow in NixOps4
+
+While we could interface with Terraform as a whole and let it handle its own dataflow, we'd be programming three components, and the idea was to reduce the number of components we need to take care of
+
+Another option would be integrating terranix, but that's an entire different user story
+
+Arguably we can implement all the variability for an otherwise fixed set of resources (such as secrets, DNS, ...) with what we have already
+
+Nested deployments are only required if we have CLI-first use cases that operate directly on expressions
+
+For demo purposes until further notice, our parameters are a constant as far as NixOps4 is concerned, and its internal data dependencies can be resolved e.g. in the front end's data model
+
+More important for now is having TF provider wrappers for common use cases, because that is where the application value lives
+
+On progress indication: NixOps4 is using the tracing library underneath, which offers separate events and spans (with start and end)
+
+Adding JSON output is a quick fix
+
+The CLI progress indicator already uses this infrastructure
+
+There's no interface for providers yet, because so far the assumption is that they're short-lived
+
+Having that would be nice, but note that it would require substantial changes to NixOS build/activation logging
+
+Most of the value can already be provided by the NixOps4 core, given it knows which resource providers need to be run and which are done
+
+Could be follow OpenTelemetry in a creative way so NixOps4 doesn't have to own the schema
+
+Long term providers could talk via API servers using some IDL such as capnproto
+
+Conclusion: We will drop JSON into the nixops invocation for the MVP and use the basic JSON logging infrastructure for progress indication
+
+Mid term we'll want Terraform provider wrappers to do the resource provisioning
+
+We can continue discussing long-term architecture decisions (such as protocols, concurrency, scheduling) independent of near-term milestones
+
+
+Expression demonstrating the infinite recursion that would be resolved using [nested deployments](https://git.fediversity.eu/Fediversity/Fediversity/issues/170):
+
+```nix
+resources = { config = { ... }; } 
+// optionalAttrs (f resources.config) { vm = g resources; }
+```