blob: 7630a68eefff98338e59908fad2f0f16686d2a40 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
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
- "ping" mechanism: sending a 0 byte
"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
|
