Detailed Inner Fingerprint Calculation and Historical Context

The base-16 encoding uses lower-cased hex digits. ## Inner fingerprint - `inner-fingerprint` = one of the following based on `type`: - if `type` = `"text:" ...`: the string written to the resulting store path. - if `type` = `"source:" ...`: the [Nix Archive (NAR)] serialization of the [file system object](@docroot@/store/file-system-object.md) of the store object. - if `type` = `"output:" id`: - For input-addressed derivation outputs: the [ATerm](@docroot@/protocols/derivation-aterm.md) serialization of the derivation modulo fixed output derivations. - For content-addressed store paths: ```ebnf "fixed:out:" rec algo ":" hash ":" ``` where - `rec` = one of: - ```ebnf | "" ``` (empty string) for hashes of the flat (single file) serialization - ```ebnf | "r:" ``` hashes of the for [Nix Archive (NAR)] (arbitrary file system object) serialization - ```ebnf | "git:" ``` hashes of the [Git blob/tree](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects) [Merkel tree](https://en.wikipedia.org/wiki/Merkle_tree) format - ```ebnf algo = "md5" | "sha1" | "sha256" ``` - `hash` = base-16 representation of the path or flat hash of the contents of the path (or expected contents of the path for fixed-output derivations). Note that `id` = `"out"`, regardless of the name part of the store path. Also note that NAR + SHA-256 must not use this case, and instead must use the `type` = `"source:" ...` case. [Nix Archive (NAR)]: @docroot@/store/file-system-object/content-address.md#serial-nix-archive [SHA-256]: https://en.m.wikipedia.org/wiki/SHA-256 ### Historical Note The `type` = `"source:" ...` and `type` = `"output:out"` grammars technically overlap in purpose, in that both can represent data hashed by its SHA-256 NAR serialization. The original reason for this way of computing names was to prevent name collisions (for security). For instance, the thinking was that it shouldn't be feasible to come up with a derivation whose output path collides with the path for a copied source. The former would have an `inner-fingerprint` starting with `output:out:`, while the latter would have an `inner-fingerprint` starting with `source:`. Since `64519cfd657d024ae6e2bb74cb21ad21b886fd2a` (2008), however, it was decided that separating derivation-produced vs manually-hashed content-addressed data like this was not useful. Now, data that is content-addressed with SHA-256 + NAR-serialization always uses the `source:...` construction, regardless of how it was produced (manually or by derivation). This allows freely switching between using [fixed-output derivations](@docroot@/glossary.md#gloss-fixed-output-derivation) for fetching, and fetching out-of-band and then manually adding. It also removes the ambiguity from the grammar.

This section provides a comprehensive explanation of how the `inner-fingerprint` is calculated based on the `type` of the store object, covering 'text', 'source', and 'output' types. It details the serialization methods used for each type, including ATerm and Nix Archive (NAR). It also explains the 'fixed:out: rec algo : hash' format used for content-addressed store paths, outlining the meanings of 'rec', 'algo', and 'hash'. The section further includes a historical note on the evolution of naming conventions to prevent collisions, emphasizing the current preference for using the `source:...` construction for data content-addressed with SHA-256 + NAR-serialization, regardless of its origin.