Problem

In terms of design philosophy, Nix maintains a separation between the Nix language (a pure functional evaluation language) and the Nix store (a content-addressed storage system) as distinct layers. However, in practice, the Nix language holds a privileged position with respect to the store, and there is no explicit interface boundary between them.

Specific Manifestations of Language Privilege

• The Only Official Entry Point: The Nix language evaluator is effectively the sole pathway for generating derivations and registering them in the store. CLI tools such as nix build and nix develop internally invoke the Nix evaluator.
• Ecosystem Dependency: The entirety of nixpkgs is written in the Nix language, and the flake system presupposes the Nix evaluator. Alternative languages are always second-class citizens.
• Reliance on Purity Trust: The integrity of the store depends on the purity of the Nix language (no side effects, dependency tracking through string context, etc.). This is a fragile trust model that requires faith in the correctness of the language implementation.

Limitations of Existing Workaround Attempts

• Guix: Uses Guile as a frontend instead of the Nix language, but cannot reuse nixpkgs and had to rebuild the ecosystem from scratch.
• Tvix: Attempted to implement the store in a different way, but ultimately incurred significant costs in creating a compatible evaluator for the Nix language.
• Recursive Nix: Allows calling the Nix daemon from other languages at build time, but the top-level entry point remains controlled by the Nix language. An escape hatch exists, but the Nix language holds the key to that door.

Proposal: All Languages Inside the Sandbox

Core Idea: All frontend languages, including the Nix language evaluator, should interact with the store only through the Nix daemon socket mounted inside a Nix sandbox.

Structural Change

[Current]
Nix language evaluator ──(privileged access)──▶ Nix Store

[Proposed]
┌─── Sandbox ────────────────────┐
│  Nix language evaluator        │
│  Guile / Python / Rust / ...   │──(daemon socket)──▶ Nix Daemon ──▶ Nix Store
│  (no network, FS isolation)    │
└────────────────────────────────┘

Operation Mechanism

1. Frontend languages (including Nix) execute inside a sandbox. Network access is disabled, and the filesystem is isolated.
2. All store-related operations (derivation registration, store path queries, build requests, etc.) are performed only through the Nix daemon socket mounted inside the sandbox.
3. The daemon becomes the sole entity responsible for ensuring store integrity.

Benefits

1. Simplification of the Trust Model

There is no need to trust the purity of the language. Since the sandbox enforces isolation at the kernel level, the daemon guarantees store integrity regardless of what any language does inside the sandbox. Trust based on OS-level isolation is far more robust than trust dependent on language semantics.

2. Equal Standing Among Languages

Any language—Nix, Guile, Python, Rust, etc.—uses the daemon socket protocol in the same way inside the sandbox. The fact that nixpkgs is written in Nix becomes merely a historical choice of the ecosystem, not something enforced by the architecture.

3. Generalization of Existing Special Cases

• IFD (Import From Derivation): Rather than being a special case that triggers builds during evaluation, it becomes a general operation of requesting builds from the daemon inside the sandbox.
• Recursive Nix: It becomes a natural pattern rather than a separate feature.
• Even if the boundary between evaluation and building becomes blurred, the sandbox guarantees isolation, so it is not a problem.

Summary

The core of this proposal is to shift the security responsibilities currently handled by language-level purity down to OS-level isolation (sandbox + daemon protocol) in the current Nix architecture. Through this, the privileged position of the Nix language is eliminated, and all frontend languages can utilize the Nix store on equal terms.