[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] Comments on pre-proposal
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 :
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
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.