[freehaven-dev] meeting sunday 2pm

[Roger R Dingledine <arma@mit.edu>]

So, we had a meeting last Sunday, and I think that it went very well.
We figured out which parts of the design still seemed a bit weird or
unsolved, and we debated about some solutions. We introduced each other
(so now we have some faces to associate with all these names on the list).

And we agreed that meeting on Sundays is reasonable. I'd also like to meet
Wednesday afternoons (4pm til sometime, please let me know your schedule)
for the next little while, because I think the next big step is to actually
hash out some APIs and some protocols, and to do this we need to sit down
and brainstorm for a while as a group.

The names that I put down next to modules are not "who will do that
module" so much as "who is in charge of making sure that module gets done
correctly". The difference is that I don't envision people going off and
working by themselves on their own part. I think we can get a lot of
design work done as a group, and things will move a lot more quickly and
smoothly that way. That said, of course there will come a time where we're
not designing so much as implementing, and at that point the meetings will
be pretty short and we'll probably be down to one per week.

Anyway, here's what I'd like to cover in the next meeting. Expect it to
be a long one, because I want us to have a good idea of where to go from
it.

Trading protocol [from the 'main skeleton' module]:
  I see this as a three-way handshake:
    a) 'here's a share, here's a description of what I want back'
    b) 'nice share. ya want this one?'
    c) 'yes.'
  where b or c can be replaced with 'yuck, I'd rather have something
  more like foo or bar.' What precisely should be in each of the
  messages? David will like this: is there a way of doing an
  'oblivious commit' or some such, so both sides commit to doing a
  trade for a given type of share (size, duration) without actually
  seeing the share? This idea was spawned off of Michael's comment
  "can't you just keep refusing trades with somebody (or refusing at
  step c) and get a good idea of what shares somebody has?" Realistically,
  I don't think it's worth it to actually use a protocol like this unless
  we can get it down to 3 messages similar to the one I proposed above --
  it will just be a headache for us.
  Speaking of having multiple variants of the protocols, we should bear
  in mind that we want to have these things backward-compatible once we
  upgrade. This means that the steps above should have a "protocol version"
  or name or something associated with them, so each side knows how to
  behave. We should bear this in mind with all our protocols.

Mixnet:
  sendmail? rewebber? It should be modular (read "black box"), but are
  we sure there's stuff we can use? Is it robust enough? Can we limit
  or reduce the latency? How much work needs to be done to make it work?
  The answers to these will influence how much effort we have to put into
  the other modules to compensate.

Trust:
  I would like to hash explicit lists for:
    a) the types of broadcasts that the trust system will want to be
       doing. how frequent will this be really?
    b) the list of boolean functions which we want the trust system to
       be able to answer. things like "should we do this trade (large
       pile of arguments)?"
    c) the list of events which the trust system wants to be informed
       of, and how much detail it wants for each event.
  I realize that these lists can't be complete at this point because
  there are things we'll find in the future that change them. But I want
  to get started on them asap.

Buddy shares [from the 'main skeleton' module]:
  We need to actually decide how to do moving. My personal vote is to
  let the shares move whenever they want, and to require nodes to keep
  "forwarding information" about places they recently gave shares to.
  The duration that they'll keep the forwarding information is related
  to the frequency that they trade shares, and where they are in the
  spectrum of robust vs paranoid. Another related point here is that
  when a share is doing a 'check' on its buddy, it really shouldn't
  move until it's gotten a good idea of whether it's still there.

  So once a share decides that its buddy is lost, what does it do?
  Does it tell the world? What exactly does it tell the world? Is there
  anything it can do to prove that it's right, or is it really just
  basing the plausibility of its claim on that node's reputation? Are
  there attacks that involve waiting til your buddy is on a dumb (not
  very well trusted) node, and then dying? Is there anything we can do
  about these? This idea still needs some work.

People that I see spearheading each module:
UI: Todd?
Mixnet: David with help from Michael
Trust network: Brian with help from Seph
Main skeleton: Gerald with help from Michael and the rest of us

Please take a particularly close look at the topics above that are in
your module, and be prepared to offer a rough answer to the above
questions (and whatever other questions you think should be asked), as
well as lead a discussion towards a more concrete answer.

Thanks!
--Roger

(Yes, I realize I didn't tell you where the meeting is. I'll, uhm,
tell you in a couple days.)