diff options
| -rw-r--r-- | README.md | 9 | ||||
| -rw-r--r-- | TODO | 33 |
2 files changed, 20 insertions, 22 deletions
@@ -22,6 +22,7 @@ it will eat-your-data! - [x] read data entries by index - [x] append data entries - [x] verify entire register (signatures and merkel tree) + - [ ] receive and insert data out of order - [ ] bitfields - [ ] Drive metadata and files - [x] read full history ("log") @@ -34,7 +35,10 @@ it will eat-your-data! - [ ] receive entire register from a known host - [ ] share (upload) register to a known host - [ ] bitfields - - [ ] lookup hosts in DHT swarm by discovery key +- [ ] Discovery + - [x] centralized DNS + - [ ] mDNS (local DNS) + - [ ] DHT (distributed hash table) - [ ] Wrapper commands - [ ] clone - [ ] share @@ -44,7 +48,7 @@ it will eat-your-data! ### Differences from dat -A few simplifications were made compared to the regular dat client: +Significant simplifications were made compared to the regular dat client: - Content data is always stored in the SLEEP directory (`content.data`), instead of just having the latest data in files in the working directory. @@ -54,7 +58,6 @@ A few simplifications were made compared to the regular dat client: - Tracking of remote node state (bitfields) is minimized as much as possible. - Almost everything is synchronous and single-threaded, so only a single remote node connection at a time is allowed. -- discovery (DHT, multicast-DNS, etc) is not implemented. ### Dependencies @@ -1,19 +1,14 @@ next: +- clean up node bitfield implementation +- "insert" API for HyperRegister - crude single-thread drive+network clone +- sparse register clone +- "needed data chunks" and progress function? - crude single-thread drive+network broadcast -- drive: checkout all latest files -- SLEEP bitfields stuff -- .latest and .ogd files -- sparse insert into SLEEP/drive -- secret_key-in-home helpers (read/write) -- multi-connection network sync (per-connection state, etc) -- duplicate file/chunk optimizations - 'geniza clone' command - 'geniza checkout' command - 'geniza init', 'geniza commit' commands -- 'geniza broadcast' command -- API to link and run from, eg, python specific tests: - drive children array: deep directory nesting (like 'tree' example) @@ -25,20 +20,20 @@ specific tests: - cloning with metadata pointing to relative or absolute paths ("dir/../../../../etc/passwd") -trivial performance: +performance: - cache SLEEP file length when opened (don't fstat all the time) - keep an LRU cache of SLEEP reads -APIs: -- trait: register -- trait: drive -- SLEEP file -- SLEEP register -- SLEEP drive -- peer (multiple transit types) -- synchronizer (register, peers, discovery) - Backburner: +- API to link and run from, eg, python +- uTP transport +- in-memory storage backend +- WASM +- multi-connection network sync (per-connection state, etc) +- duplicate file/chunk optimizations +- secret_key-in-home helpers (read/write) +- SLEEP bitfields stuff +- .latest and .ogd files - benchmarks! syscall counts (strace), timing, etc - test fault injection... with strace? - consider kafka (append performance) and sqlite (robustness) file I/O patterns |