[freehaven-dev] Comments on pre-proposal

[dmolnar <dmolnar@hcs.harvard.edu>]

Hi, 

Comments on pre-proposal version 0.1  :

* Maybe have a section on the actors in the protocol, combined
  with a summary of what each of them want. By actors I mean the parties
  like "Owner", "Client", "Servnet Node", and so on. 

  This could save some definitions and parenthetical remarks later on.
  For example, the first time I see the word "owner" is in section 4.1.3 
  when you explain the concept of an owner reply block. "Client" is in
  the system summary, as is "server". 

  This might be a place to clearly state the responsibilities of each
  party, and an informal definition of what it means to be "good". 
  For example, you could state that an Owner is responsible for 
  keeping track of his own data...not the Servnet Nodes, not Clients,
  nor anybody else. Then say what criteria the Owner can use to 
  determine if the Node has failed him. 

* Maybe introduce some notation up front, in a separate "notation" 
  section? For example, you might introduce notation for encryption
  and signing. Then take a slightly more abstract approach and instead
  of just saying "We use Rabin IDA", say "We have these two primitives :
	DISPERSE(....) 
	REASSEMBLE(...) 
  which do [information dispersal stuff]."
   Or call them whatever you want and with whatever arguments make sense.
  Then later say something like "we can implement these primitives by 
  use of the Rabin IDA". 

  This could make protocol description easier in section 4. 


* What exactly is the difference between an "Owner" and a "Client"? 
  I know that the Owner is responsible for ensuring that "his" data
  is preserved in the network. Does he have any special privileges?
  Can he remove his own data?  How is he identified -  through the
  signature on each fragment?
  
  I know that the term "owner" isn't current anymore - but I would
  like to see something which sets out what its replacement can do
  and should do which a client can't/won't. 
  
* The explanation of garlic routing is kind of brief. Let me see if
  I get it  :
    "Garlic" packets are mix packets which contain other mix packets 
  ("onions"). When a server opens a garlic packet, it finds many packets
  and the appropriate instructions to send them on their respective ways. 
  These packets may be regular packets, or they may be special garlic
  packets. 

  We want to use garlic packets to do broadcast because then we can
  spread the load of delivering messages to all servers among several
  different servers. This is better than normal onion routing, because
  in that case we would have to send each server a message ourselves.

is this right? 

  
* Are directory services going to be discussed in the preproposal?
  or is that the responsibility of the mix-net layer? or is that
  included in the trust layer ? 

* At one point, having no central bank or currency was a priority. Is it
  still a priority? It's not listed under the "Community" design goal.
  Banks aren't mentioned in section 5 on trading. But it is mentioned
  as a flaw in the .cz implementation. 

  Speaking of this, maybe emphasize in wherever you bring up the 
  Community design goal that you will still issue scrip -- just that
  it's not exchangable for normal money. The first read through I
  was kind of confused by the currency popping up in section 5 after
  reading the design goals. 

* In trading, does the server know what "kind" of file fragment it has? 
  Can a server figure out which files other servers have or don't have
  by trying to trade with them over and over? (Shades of _Hacker_ ?)

* Maybe partition the related work by type - mixnets in one category,
  other Eternity type services in another, Intermemory type services
  which are availability w/o security in another, etc. etc.  
  Add Onion Routing to the mix-net category.

This is what I have for now. Please let me know if something's not right.
Am looking forward to reading the new proposal.

Thanks,
-David Molnar