Skip to content

Commit 3205ce5

Browse files
committed
Address several comments
1 parent f993894 commit 3205ce5

File tree

1 file changed

+16
-8
lines changed

1 file changed

+16
-8
lines changed

UNIXFS.md

Lines changed: 16 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -61,23 +61,16 @@ message Data {
6161
optional uint64 hashType = 5;
6262
optional uint64 fanout = 6;
6363
optional uint32 mode = 7;
64-
optional TimSpec mtime = 8;
64+
optional TimeSpec mtime = 8;
6565
}
6666
6767
message Metadata {
6868
optional string MimeType = 1;
6969
}
7070
7171
message TimeSpec {
72-
// Use of int64 is deliberate - negative epoch is super unlikely
73-
// Using sint64 would introduce zig-zag encoding ( harder to eyeball )
74-
// The varint representing the time of writing this is 5 bytes long
75-
// It will remain so until October 26, 3058 ( 34,359,738,367 )
7672
required int64 EpochSeconds = 1;
7773
78-
// fixed32 ( always 4 bytes, no varint ), as nanosecs are often > 2^28
79-
// https://developers.google.com/protocol-buffers/docs/proto#scalar
80-
// NOTE: on the wire this value will be *little* endian
8174
optional fixed32 EpochNanoseconds = 2;
8275
}
8376
```
@@ -207,6 +200,21 @@ This scheme would see metadata stored in an external database.
207200

208201
The downsides to this are that metadata would not be transferred from one node to another when syncing as [Bitswap] is not aware of the database, and in-tree metadata
209202

203+
### TimeSpec protobuf datatype rationale
204+
205+
#### EpochSeconds
206+
207+
The integer portion of the epoch is represented on the wire using a varint encoding. While this is inefficient for
208+
negative values, it avoids introducing zig-zag encoding. Negative epoch values will be exceedingly rare, and there
209+
could very well be value in having such cases stand out, while at the same keeping the "usual" positive values easy
210+
to eyeball. The varint representing the time of writing this text is 5 bytes long. It will remain so until
211+
October 26, 3058 ( 34,359,738,367 )
212+
213+
#### EpichNanoseconds
214+
Since fractional values will very often be > 2^28 nanoseconds, that part is represented as a 4-byte `fixed32`,
215+
[as per google's recommendation](https://developers.google.com/protocol-buffers/docs/proto#scalar).
216+
217+
210218
[multihash]: https://tools.ietf.org/html/draft-multiformats-multihash-00
211219
[CID]: https://docs.ipfs.io/guides/concepts/cid/
212220
[Bitswap]: https://github.com/ipfs/specs/blob/master/BITSWAP.md

0 commit comments

Comments
 (0)