gpg: Signature made Fri May 9 00:43:38 2008 UTC using DSA key ID E43DA450
gpg: Good signature from "Matthew John Toseland <toad@amphibian.dyndns.org>"
On Friday 09 May 2008 01:23, Daniel Cheng wrote:
> On Fri, May 9, 2008 at 2:58 AM, Matthew Toseland
> <toad@???> wrote:
> > On Thursday 08 May 2008 01:41, Matthew Toseland wrote:
> >> https://bugs.freenetproject.org/view.php?id=2345
> >>
> >> ---
> >> A typical domestic internet connection has at most 1Mbps uplink. In some
> >> megacities 100Mbps or even 1Gbps is available (symmetric), however it is
> >> unlikely that the bandwidth available in most homes will exceed a few
> >> megabits in the near future.
> >>
> >> We could implement darknet sneakernet connections by exchanging USB
sticks.
> >> E.g. if you meet somebody every day (e.g. a coworker), you could exchange
> >> (cheap) 8G sticks, plug them in overnight, and then do the same again the
> >> next day. This would produce approx 100K/sec (1Mbps) each way for each
> > person
> >> you did it with.
> >>
> >> The performance here imho isn't world-shattering, but nonetheless it's
> >> interesting. And it would build the darknet, some of it completely
off-grid,
> >> work in many places where nothing else does safely, and get us some great
> >> headlines.
> >> ---
> >>
> >> IMHO this is something we should seriously consider, if not this year,
then
> > at
> >> least next year during the 0.8 cycle. The main technical prerequisite is
> >> token passing load management, unless we implement a completely different
> >> load management system for it. True passive requests would help in that
> >> they'd make publish/subscribe work much better on this. Even if it's not
> >> perfect, it'd be a very interesting way to get people in, and far from
being
> >> a publicity stunt, it would be of immense long-term value.
> >>
> >
> > Ian is of the view that this should be a separate application based on
similar
> > principles to Freenet. I'm not. We agree that there are some significant
> > issues to deal with. I am of the view that these networks are mutually
> > complementary and therefore should talk to each other: Darknet over UDP
isn't
> > safe in hostile environments, and off-grid darknets a) work much better if
> > parts of them are online (certainly we could expect some covert wireless
> > links in places, but being able to link to a functional on-grid darknet
would
> > surely be a benefit; long links are going to be rare on a pure off-grid
> > darknet), and b) would be much easier to bootstrap from a working on-grid
> > darknet.
> >
> > W.r.t. code (and to some degree protocol), IMHO most of Freenet's code
would
> > be useful to a darknet sneakernet implementation:
> > - The entire client layer could be reused. The queue is by definition a
long
> > term structure, Fproxy offers to download stuff in the background and
tells
> > you when it's done etc. FCP could be reused, although on a
> > pure-off-grid-darknet node, clearly they would have to use it in a
different
> > way to what they do now.
> > - Full passive requests would be virtually identical for the two
> > implementations. ULPRs could be adapted without too much difficulty. This
> > makes FMS etc somewhat feasible, if slow, and anything that can be seen as
> > publish/subscribe (e.g. getting new editions of freesites) possible. Full
> > passive requests are a long term goal as they would have some interesting
> > advantages, but even ULPRs, with sufficient tweaking, may be sufficient to
> > make this usable.
> > - The link layer would obviously be worthless, except in the IMHO
interesting
> > case where you have both a darknet connection *and* exchange of flash
cards
> > going on with a peer. Thus low latency requests such as Frost traffic can
go
> > over the link, and when you queue a big splitfile, it would fetch the top
> > blocks of the pyramid over the link, and then queue the rest to come back
> > over the following day's card exchange.
> > - Request priorities would be necessary.
> > - We probably couldn't reuse the current load limiting/management code. We
> > would in all likelihood need token passing. This is something we will need
> > long term anyway, of course.
> > - Swapping: This is probably the hardest part. Our current strategy
involves a
> > commit/reveal protocol (4 round trips). This clearly won't work well on a
> > pure off-grid darknet. Doing a large part of the work offline will be
> > necessary, and to do that a lot of topology may need to be exposed...
which
> > is bad because it makes life easier for a well-resourced attacker. Also,
the
> > off-grid network may have to be partially separate in routing terms
through
> > some sort of tiered routing (look at the network labelling code for
something
> > related).
> > - User interface to transport: We want users to be able to just plug in a
> > bunch of USB sticks to a mini-hub, and have Freenet auto-detect that they
are
> > formatted for it, download from them, and then upload to them, all ready
for
> > the next day for them to be swapped back. I don't know what native support
> > this would require.
>
> Binary Blobs (.fblob)?
>
> > Based on the above, IMHO this *might* be feasible, it becomes a lot more
> > interesting after some of the features we have planned for 0.7.1/0.8 have
> > been implemented, but even then there are some major problems to solve,
such
> > as swapping.
>
> I think something like Freenet over HTTP should have higher priority.
> There are lots of user behind HTTP/HTTPS-only proxy.
Mostly using it at work when they shouldn't be. :) Well I suppose some
students too...
But Freenet over HTTP is a conventional application of transport plugins, so
shouldn't be too much of a problem once we have them.
