|
| 1 | +"$schema": "http://json-schema.org/draft-04/schema" |
| 2 | +"$id": "https://nix.dev/manual/nix/latest/protocols/json/schema/content-address-v1.json" |
| 3 | +title: Content Address |
| 4 | +description: | |
| 5 | + This schema describes the JSON representation of Nix's `ContentAddress` type, which conveys information about [content-addressing store objects](@docroot@/store/store-object/content-address.md). |
| 6 | +
|
| 7 | + > **Note** |
| 8 | + > |
| 9 | + > For current methods of content addressing, this data type is a bit suspicious, because it is neither simply a content address of a file system object (the `method` is richer), nor simply a content address of a store object (the `hash` doesn't account for the references). |
| 10 | + > It should thus only be used in contexts where the references are also known / otherwise made tamper-resistant. |
| 11 | +
|
| 12 | + <!-- |
| 13 | + TODO currently `ContentAddress` is used in both of these, and so same rationale applies, but actually in both cases the JSON is currently ad-hoc. |
| 14 | + That will be fixed, and as each is fixed, the example (along with a more precise link to the field in question) should be become part of the above note, so what is is saying is more clear. |
| 15 | +
|
| 16 | + > For example: |
| 17 | +
|
| 18 | + > - Fixed outputs of derivations are not allowed to have any references, so an empty reference set is statically known by assumption. |
| 19 | +
|
| 20 | + > - [Store object info](./store-object-info.md) includes the set of references along side the (optional) content address. |
| 21 | +
|
| 22 | + > This data type is thus safely used in both of these contexts. |
| 23 | +
|
| 24 | + --> |
| 25 | +
|
| 26 | +type: object |
| 27 | +properties: |
| 28 | + method: |
| 29 | + "$ref": "#/$defs/method" |
| 30 | + hash: |
| 31 | + title: Content Address |
| 32 | + description: | |
| 33 | + This would be the content-address itself. |
| 34 | +
|
| 35 | + For all current methods, this is just a content address of the file system object of the store object, [as described in the store chapter](@docroot@/store/file-system-object/content-address.md), and not of the store object as a whole. |
| 36 | + In particular, the references of the store object are *not* taken into account with this hash (and currently-supported methods). |
| 37 | + "$ref": "./hash-v1.yaml" |
| 38 | +required: |
| 39 | +- method |
| 40 | +- hash |
| 41 | +additionalProperties: false |
| 42 | +"$defs": |
| 43 | + method: |
| 44 | + type: string |
| 45 | + enum: [flat, nar, text, git] |
| 46 | + title: Content-Addressing Method |
| 47 | + description: | |
| 48 | + A string representing the [method](@docroot@/store/store-object/content-address.md) of content addressing that is chosen. |
| 49 | +
|
| 50 | + Valid method strings are: |
| 51 | +
|
| 52 | + - [`flat`](@docroot@/store/store-object/content-address.md#method-flat) (provided the contents are a single file) |
| 53 | + - [`nar`](@docroot@/store/store-object/content-address.md#method-nix-archive) |
| 54 | + - [`text`](@docroot@/store/store-object/content-address.md#method-text) |
| 55 | + - [`git`](@docroot@/store/store-object/content-address.md#method-git) |
0 commit comments