diff options
| author | Bryan Newbold <bnewbold@robocracy.org> | 2017-10-26 00:16:41 -0700 |
|---|---|---|
| committer | Bryan Newbold <bnewbold@robocracy.org> | 2017-10-26 00:16:41 -0700 |
| commit | 8e13fc65e944b9741e3f8e0f3d45542d8090a99c (patch) | |
| tree | f445d1eb237345959e629ddf2b94a44bc01d65bc | |
| parent | 48a7a411c69de546a299486da1f2d7e939e1e0d8 (diff) | |
| download | geniza-8e13fc65e944b9741e3f8e0f3d45542d8090a99c.tar.gz geniza-8e13fc65e944b9741e3f8e0f3d45542d8090a99c.zip | |
notes about crypto and initialization
| -rw-r--r-- | README.md | 3 | ||||
| -rw-r--r-- | notes/crypto.txt | 9 | ||||
| -rw-r--r-- | notes/spec_todo.txt | 17 |
3 files changed, 29 insertions, 0 deletions
@@ -39,6 +39,9 @@ it will eat-your-data. ### Dependencies +While (temporarily?) using Cargo's `[patch]` feature to patch sodiumoxide, +builds require Rust 1.21 (stable circa Oct 2017). + Requires libsodium-dev system-wide (for now). Notable Rust Libraries: diff --git a/notes/crypto.txt b/notes/crypto.txt new file mode 100644 index 0000000..ea81a5f --- /dev/null +++ b/notes/crypto.txt @@ -0,0 +1,9 @@ + +Like many libsodium wrappers, and apparently *all* reasonable Rust bindings, +sodiumoxcide does not expose the `crypto_stream_xsalsa20_xor_ic` function, +necessary to use libsodium in an endless steam configuration. + +https://nacl.cr.yp.to/stream.html +https://github.com/maidsafe/rust_sodium +https://groups.google.com/forum/#!original/boring-crypto/BpUmNMXKMYQ/EEwAIeQdjacJ + diff --git a/notes/spec_todo.txt b/notes/spec_todo.txt index 9a953c4..40c59f5 100644 --- a/notes/spec_todo.txt +++ b/notes/spec_todo.txt @@ -14,6 +14,7 @@ Things that were underspecified in the spec/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, @@ -30,3 +31,19 @@ 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 + + +### Small Bugs + +hypercore: 'Request' without 'Have' crashes dat, despite whitepaper saying "You +should only send Have messages to peers who have expressed interest in this +region with Want messages.": + + /usr/lib/node_modules/dat/node_modules/hypercore/lib/replicate.js:119 + if (!self.remoteBitfield.set(request.index, true)) return + ^ + + TypeError: Cannot read property 'set' of null + at onvalue (/usr/lib/node_modules/dat/node_modules/hypercore/lib/replicate.js:119:33) + at onread (/usr/lib/node_modules/dat/node_modules/random-access-file/index.js:130:14) + at FSReqWrap.wrapper [as oncomplete] (fs.js:629:17) |