You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PAPI is a self-describing person document that already publishes machine-consumable facts — notably ssh-authorized-keys, which hosts pull to provision login access. Explore extending that model so a person's PAPI document can express home-manager module configuration (or pointers to it), letting a person's machines fetch their home-manager setup from PAPI the same way they already fetch authorized keys.
Concrete first candidate: the nix-cache watch-store uploader home-manager module (circus FDR-0008 §1). A host could learn "this person wants the uploader enabled, pointing at cache URL X" from their PAPI document rather than from per-host local config.
Questions to explore
Scope: what subset of home-manager config is appropriate to express in PAPI — declarative module references + parameters (e.g. { module: "nix-cache-uploader", to: "<cache-url>" }), vs. anything resembling full Nix? PAPI is a wire-format/person-document spec, not a Nix evaluator, so likely the former.
Wire format: how a home-manager-modules (or similar) block fits the existing PAPI document schema and introspection/validation tooling.
Trust: PAPI is public read. What can safely be expressed (capability toggles + public parameters) vs. what must stay host-local (secrets, private cache URLs)? How does this relate to the existing ssh-authorized-keys trust model?
Idea
PAPI is a self-describing person document that already publishes machine-consumable facts — notably
ssh-authorized-keys, which hosts pull to provision login access. Explore extending that model so a person's PAPI document can express home-manager module configuration (or pointers to it), letting a person's machines fetch their home-manager setup from PAPI the same way they already fetch authorized keys.Concrete first candidate: the nix-cache watch-store uploader home-manager module (circus FDR-0008 §1). A host could learn "this person wants the uploader enabled, pointing at cache URL X" from their PAPI document rather than from per-host local config.
Questions to explore
{ module: "nix-cache-uploader", to: "<cache-url>" }), vs. anything resembling full Nix? PAPI is a wire-format/person-document spec, not a Nix evaluator, so likely the former.home-manager-modules(or similar) block fits the existing PAPI document schema and introspection/validation tooling.ssh-authorized-keystrust model?identity.toml) would consume the PAPI-expressed modules. The local-config path is being tracked separately in Incorporate the nix-cache watch-store uploader (home-manager module) via identity.toml eng#198 — PAPI-expressed modules would be the network-sourced evolution of that.Reference
identity.toml)amarbel-llc/circusFDR-0008 —nix-cache.homeManagerModules.uploaderExploratory; likely warrants a PAPI spec proposal if it has legs.