@Dominic

what are the advantages of your way of doing integers over CBOR's?

CBOR does not represent negative integers as two's complement, but rather in a way such that any value of major type 1 is negative. This makes it impossible to send a positive number as a signed integer type. In hsdt, it should be possible to send e.g. the integer 5 but declaring its type as a signed 32 bit integer. That would be encoded as the tag with major type 1 and additional type 26, followed by the bytes 0x00000005.

Put another way: Cbor does not care about preserving type information beyond "its an integer", using the different additional types only to minimize the encoding size. Hsdt uses them to preserve the exact type instead.

Not having to convert unsigned integers into the machine representation (endianess aside) is also a plus.

All I really care about is having in-place access to fields. Such that pointer = seekPath(record, key) returns a pointer to where the value associated with key is inside the record. I think this is the key to having a high performance database

Yup, that should be mostly possible. You can't do binary search on sets/maps though, since you don't know where new values begin without scanning through things linearly. But at least you can skip across primitives (null, bool, integers, floats, both strings, multifeeds, multihashes) after looking at the first byte (or first few bytes for variable-length primitives).

So really efficient access still needs some sort of indices, but a naive linear scan should be pretty fast (and as a corollary, generating indices should be pretty fast).

what does hsdt stand for again?

Hypothetical SSB Data Format, with the "t" being a two-in-the-morning typo. But I decided to roll with it, celebrating the magic of immutable append-only logs. A possible backronym is Hermie's Shiny Data Treasure.

I'm not attached to that name at all, feel free to suggest a better name/backronym.