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 reality, the Nix language holds a privileged status over the store, and there is no explicit interface boundary between the two.

Concrete Manifestations of Privileged Status

• Sole Official Entry Point: The Nix language evaluator is effectively the only path for creating derivations and registering them in the store. CLI tools such as nix build and nix develop internally invoke the Nix evaluator.
• Ecosystem Dependency: The entire nixpkgs is written in the Nix language, and the flake system presupposes the Nix evaluator. Alternative languages are always second-class citizens.
• Reliance on Trust in Purity: 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 Workarounds

• 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 incurs 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 is still held by the Nix language. An escape hatch exists, but the key to open that door remains with the Nix language.

Proposal: All Languages Inside the Sandbox

Core Idea: Ensure that all frontend languages, including the Nix language evaluator, interact with the store only through the Nix daemon socket mounted inside the Nix sandbox.

Structural Changes

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

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

How It Works

1. Frontend languages (including Nix) are executed inside the sandbox. Network access is unavailable, 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 the integrity of the store.

Benefits

1. Simplification of the Trust Model

There is no need to trust in the purity of languages. Since the sandbox enforces isolation at the kernel level, the daemon guarantees the integrity of the store 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 Status Among Languages

Any language—whether Nix, Guile, Python, Rust, etc.—uses the same daemon socket protocol 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): Instead of 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: Instead of being a separate feature, it becomes a natural pattern.
• Even if the boundary between evaluation and building becomes blurred, the sandbox guarantees isolation, so it poses no problem.

Summary

The core of this proposal is to shift the security role currently handled by language-level purity to OS-level isolation (sandbox + daemon protocol) in the current Nix architecture. Through this, the privileged status of the Nix language is removed, and all frontend languages can utilize the Nix store under equal conditions.