Re: [freehaven-dev] sketching accountability requirements/solutions in FH

[Michael J Freedman <mfreed@MIT.EDU>]

Flute,

Good to hear from you.  We've spoken with Branden about this topic
before, both at a Berkeley conference this past summer, and in writing
for the upcoming O'Reilly book on P2P systems.

The time-lapse in the current FreeHaven design is largely due to the
delay of the anonymous communication channel, not with the actual
FreeHaven design.  This delay has been implemented in systems like the
Mixmaster remailer in order to make traffic analysis timing attacks more
difficult.

What actually are the time requirements of the Freenet architecture?
I'm familiar with the TTL of your request packets, but does this hop
life you refer to correspond to some other number, after which the
requestor ignores answers?

A possibly is to make Freenet routes able to gateway into FreeHaven, in
the following manner.  If a document exists in Freenet, get it there.
If it isn't available, query FreeHaven and hope for the best
(intermediate nodes could do this, not only terminal requesting ones.)
Although the Freenet user might experience some long delay and give up
before they get the document, the document still have been retrieved
into the Freenet system.  That user might be unhappy, but later users
will find the desired file already in the Freenet system.  This fits
into the data popularity model of caching systems such as Freenet.

Obviously, there are clearly many other ways to think about this
problem.  I think Branden writes about some in his chapter.

--mike


P.S. I don't know if you are aware that we have not, as of yet,
implemented the Free Haven design to even alpha form, as we are still
concerned with anonymity and resource management issues.