Re: [freehaven-dev] a few things

[Roger Dingledine <arma@mit.edu>]

On Mon, Feb 21, 2000 at 04:20:52AM -0500, Michael J. Freedman wrote:
[snip]
> However, your point brings a question to mind that I am uncertain if we
> have answered.  Let's say a server A takes a new node B but has yet to
> introduce it to friends (which is what we are doing when a node initially
> joins the servnet).  The server performs some trades with the new node B.
> 
> In the buddy paradigm, the buddy gets a message that it's counterpart has
> moved from A to B.  It can modify the share_db info to reflect B.  Without
> really thinking about this, it feels like this is fine even if the buddy's
> node (server C on which buddy resides) doesn't know about B.

Actually, this doesn't work in the 'buddy paradigm' unless the share knows
'how to get to' the server that is keeping its buddy. So that server needs
to be introduced. Or at least, the comm module needs to keep information
about it, which is close enough in my book.
 
[snip]
> 2.  We can rely that information dispersal algorithm is robust.  If we lose
> a few files this way, it's okay.   This "solution" is just bad.  It ignores
> the problem.  Enough said.

Well, we are going to lose a few files any way we do it, because the latency
of the mixnet may cause messages to be delayed or reordered enough that we
have timing problems with trading and requesting. But see below.
 
> here, if we trade with B, we need to introduce.  And some others -- I
> really just feel like an introduction carries some sign of respect:  if I
> bring a friend to a social occasion and he behaves poorly, it really does
> affect my social standing at that party.

I agree.

> I *think* I like this solution.  Disclaimer:  it's late and I'm tired...
> 4.  Until B reaches a certain level of trust (e.g., trust_to_introduce() ==
> true  (???)),  A is actually keeping a copy of everything it sends to B.
> Therefore, from A's perspective, initial trades are used really only to
> figure out B's trustworthiness.  

If we give B garbage:
We want to be certain that the things we give our prospective won't live
forever -- if he does his job, then eventually he'll get introduced to a
bunch of other nodes, and we can't exactly tell him "no, never mind those
things we gave you earlier, they were just to test you" (never ever ever
have anything about premature deleting in our protocols).

If we give B garbage:
how do we want buddies to work? if the garbage we give them doesn't have
a buddy, then they'll be suspicious that we're giving them garbage.
if it does, then we need to find somebody willing to be the buddy. (if we
are the buddy, then they'll know that and be suspicious that we're giving
them garbage.)

If we give B real shares:
do we keep the primary copy?
If we give them a copy and maintain 'primary' status on our copy, then if
they trade it away down the road, there will be two primary copies floating
around. If we give them a copy and don't maintain a 'primary' copy of our
own, then if they screw up we get blamed for it unless they've been
Introduced. And besides, how do they deal with sending buddy-updates to
places, if we haven't introduced the network to them? (I believe we don't
introduce places to them until we start introducing them to places.) I think
it's clear that if we give them real shares, then we need to introduce them
then too or the buddy system will turn into a mess.

Comments on how to make buddies plus garbage shares work?
 
> Still, as far as some sections of the system see it, this is a valid trade:
>  buddy should be updated to B (once A introduced B, it might start dropping
> it's copies); we don't really want A to trade this share away to another
> server. 
> 
> But, when D queries for a file, A can send back copy[share] that it is
> storing.  For file recovery, we really don't care about anyting like
> primary/secondary copies, etc.   If B has been introduced by this point,
> D's just receiving two identical shares, which seems fine (and A should
> know as soon as B is introduced, anyway).

Agreed.
 
> Thoughts?  I'm not sure that I haven't overlooked something...

Looks good to me. I still think we need to be more explicit on how the buddy
thing should be resolved...

Thanks!
--Roger