Things that were underspecified in the spec/whitepaper: - nonce: 24 or 32 bytes? (impl is 24, spec says 32) - endianness of magic (big-endian) - uppercase/lowercase of algorithm name (inconsistent in one place) - what if there is only a single chunk/entry in a register tree? then a leaf acts as a root? - unclear where protobuf schema actually lives... - "append only" is mentioned many times, but need to write "back in" to merkel tree on many occasions - inconsistent message names between .proto and whitepaper - protocol extension stuff not in the whitepaper - whitepaper should be versioned/tagged, or marked as "work in progress" - encryption not really covered in whitepaper... seems to be XSalsa20 XOR'd with data "You can use the byteOffset property in the Stat meta- data object to seek into the right position in the content for the start of this chunk." => unnecessary, node.js specific? "If you are sharing multiple hypercores on the same port you can use this event to wait for the remote peer to indicate which hypercore they are interested inj" Clarify: appending to tree SLEEP results in writes into middle of file (for root nodes). This seems not-great for performance (can't bulk-write). Better to cache or work in RAM then batch commit? varint-encoded message prefix for network messages still feels sort of inefficient... fixed 32-bit length makes more sense to me, seems like efficiency gains would be pretty small. would need benchmarking. https://developers.google.com/protocol-buffers/docs/techniques#streaming