• this is a work in progress

bfs uses public key crypto and key-based RBAC to authenticate peers and control access to data repos. in tomo the mesh will be able to use a few different types of keys to authenticate peers.

   1 {
   2   "content": {
   3     "type": "bfs-link",
   4     "cjdnsKey": "<publicKey>", // hash maybe? you can fetch the actual key as a blob
   5     "dir": {
   6       ".": "<topHash>",
   7       "<name>": "<hash>",
   8       "<path>": {
   9         "<name>": "<hash>"
  10       }
  11     }
  12   }
  13 }

peers who replicate a link will also publish a copy of this link object, analogous to seeding in the BitTorrent protocol. each peer keeps an index of the bfs-link objects within their FOAF range. individual files may be fetched on-demand as long as an active peer can be found. private sharing can be accomplished by publishing private links. bfs doesn't make any assumptions about the target files, which may be encrypted or chunked using another tool.

the "hashed-directory-tree" allows clients to verify the integrity of their downloads progressively. a more strict, chunked merkle-dag might be more efficient, but unless that can be accomplished without altering or copying the source files we will have to make do.

files are transferred using rsync. partial files are always cached so that downloads can be resumed. because files are content addressed, a client can resume downloads from any peer that has a given hash. bfs-links can be downloaded and validated in parallel by fetching multiple files at a time from one or more peers.

how to have editable resources? could work like pub/sub, but for changes to a filesystem. what about having multiple agents edit the same resource?

references


CategoryPaper

projects/bfs (last edited 2018-01-23 07:12:33 by xj9)