auto

notes/chordCFS.md

@@ -4,29 +4,69 @@
 Started the whole distributed hash tree (DHT) craze.
 
 This would be slow:
-<p>
-<img width=340 src=chord1.png>
-<p>
-&nbsp;
-<p>
+![1](chord1.png)
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
 
 Maybe these would help, finger tables w/ 7 entries for 256-bit space:
-<p>
-<img width=300 src=chord2.png>
-<p>
 
-&nbsp;
+![1](chord2.png)
+
+
+
 
-<p>
-&nbsp;
-<p>
 But finger <i>i</i> points to the <i>successor</i> of: n+2^(i-1):
-<p>
-<img width=300 src=chord3.png>
-
-<p>
-&nbsp;
-<p>
-Lookups take O(log(N)) hops:
-<p>
-<img width=300 src=chord4.png>
+
+![1](chord3.png)
+
+
+
+
+![1](chord4.png)
+
+
+![1](chord5.png)
+![1](chord6.png)
+![1](chord7.png)
+![1](chord8.png)
+![1](chord9.png)
+
+
+
+# CFS
+
+Layers
+- FS
+- DHash: Stores unstructured data blocks reliably
+- Chord: routing
+
+Key points
+- data named with *public keys* or content hashes
+- read-only, except by owner
+- virtual servers
+  - helps w/ uniformity
+  - differing-capacity servers
+- server selection: latency
+- replication
+
+Things missing:
+- privacy
+- security (malicious actors)
+  - sybil attack: grab many spots on ring, mis-route queries
+    - though node ID authentication helps
+  - privacy: though could encrypt files, anonymizers for queries
+  - lying about latencies in server selection
+- policies for deletion
+- paying for storage
+- read-write storage