4.3 KiB
4.3 KiB
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
- got the full roundtrip of deploying with NixOps4 working in a NixOS test
- @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 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
- @kiara: i recently played with snowfallorg's GUIs nixos-software-center and nix-configuration-editor again. the former tries to do an app store for nixpkgs (including icons for some applications), but was based on a categorization no longer followed since RFC 140 (which introduced
pkgs/by-name/), tho it seems the more recent categorization effort (RFC 146) might revive such discoverability again. on efforts toward discoverability, we should also file flakehub there. if i look at ngi.nixos.org tho, i think what they do well there is discoverability of option modules / services - making me wonder what we mean when we say application here. if i were to then think about how to generalize that, i would look into using.packagedefaults to explicitly associate packages withprograms/servicesdefaulting to them, such that tools like search.nixos.org would link fromservices.nginxto packagenginxand the other way around. hopefully, that could achieve something like NGI's associations at nixpkgs scale. - @fricklerhandwerk: yes, leveraging the
.packageassociation would be an 80/20 shortcut to improve search.nixos.org, but ultimately it's a cludge until we have a proper data model for applications.
- @kiara: i recently played with snowfallorg's GUIs nixos-software-center and nix-configuration-editor again. the former tries to do an app store for nixpkgs (including icons for some applications), but was based on a categorization no longer followed since RFC 140 (which introduced
- 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
- @kiara: big fan here, already indicated to pierre i'd be down to help out as shepherd once he formally files the proposal as RFC
- will meet the developer at Zurich ZHF end of May
- 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
- all of this seems vaguely related with @roberth's modular services
- 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
- @kiara: this PR seems a prerequisite to doing their selfhostblocks' thing in nixpkgs, yeah
- 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,
varsproposes 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)
- @kiara: i'd be interested to read up on this plan - at Planet Nix they did mention theoretical integrations like with vault/openbao. i have been playing with their outstanding PR, which seems to heavily lean on backend implementation to do the heavy lifting. their monorepo seems to have more functionality already (including different modules), but unfortunately is fairly tightly coupled with the clan use-case, making it harder to play around with than their simpler PR-oriented flake.
- thanks @niols for helping with coming up with that clarification
- if viewed in terms of SelfHostBlocks and modular services,
- 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
- investigated https://selfprivacy.org/
- @kiara
- refactored the build setup, with reviews from @fricklerhandwerk
- kept iterating on the terraform deployment