Logical representation of a file chunk (a leaf node of the file DAG layout).
When large file is added to IPFS it gets chunked into smaller pieces
(according to the --chunker specified) and each chunk is encoded into this
representation (and linked from file DAG). Please note that in practice there
are many other representations for file chunks (leaf nodes) like Raw nodes
(deprecated in favor of this representation) and raw binary nodes (That is
0x55 multicodec) which are on a way to surpass this representation.
Please note that in protobuf representation there is only one file node
type with many optional fields, however different combination of fields
corresponds to a different semntaics and we represent each via different type.
Also note that some file nodes may also have mode and mtime fields,
which we represent via SimpleFile type, however in practice two are
indistinguishable & how to interpret will only depend node is encountered
in DAG root position or not. That is because one could take two SimpleFile
nodes and represent their concatination via AdvancedFile simply by linking
to them. In such scenario consumer SHOULD treat leaves as FileChunks and
ignoring their mode and mtime fileds. However if those leves are
encontured on their own consumer SHOULD treat them as SimpleFiles and
take mode and mtime fields into account.
Logical representation of a file chunk (a leaf node of the file DAG layout).
When large file is added to IPFS it gets chunked into smaller pieces (according to the
--chunker
specified) and each chunk is encoded into this representation (and linked from file DAG). Please note that in practice there are many other representations for file chunks (leaf nodes) likeRaw
nodes (deprecated in favor of this representation) and raw binary nodes (That is 0x55 multicodec) which are on a way to surpass this representation.Please note that in protobuf representation there is only one
file
node type with many optional fields, however different combination of fields corresponds to a different semntaics and we represent each via different type.Also note that some file nodes may also have
mode
andmtime
fields, which we represent viaSimpleFile
type, however in practice two are indistinguishable & how to interpret will only depend node is encountered in DAG root position or not. That is because one could take twoSimpleFile
nodes and represent their concatination viaAdvancedFile
simply by linking to them. In such scenario consumer SHOULD treat leaves asFileChunk
s and ignoring theirmode
andmtime
fileds. However if those leves are encontured on their own consumer SHOULD treat them asSimpleFile
s and takemode
andmtime
fields into account.