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
--chunkerspecified) 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) likeRawnodes (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
filenode 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
modeandmtimefields, which we represent viaSimpleFiletype, 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 twoSimpleFilenodes and represent their concatination viaAdvancedFilesimply by linking to them. In such scenario consumer SHOULD treat leaves asFileChunks and ignoring theirmodeandmtimefileds. However if those leves are encontured on their own consumer SHOULD treat them asSimpleFiles and takemodeandmtimefields into account.