On Monday 12 May 2008 23:56, Michael Rogers wrote: > Matthew Toseland wrote: > >> 1. The platform for this type of thing is a small mobile device, > >> getting Freenet to work well on an iPhone would be a world of pain - > >> and doesn't buy anything for us > > > > No, to do that requires a massive amount of short range bandwidth. Phones do > > not have this. > > Bluetooth?
Even less bandwidth than wifi, no? We need several gigabits (over a range measured in feet) for it to be viable. > > > Not true IMHO. A lot of existing Freenet apps deal with long term requests, > > which would work very nicely with sneakernet. > > Which apps do you have in mind? I can't think of any Freenet app that > would be useful with a ten-day delay between requesting a [KSU]SK and > finding out which CHK it redirects to, and then another ten days to > request the top block of the splitfile, and then another ten days for > the data. In the border case where the two nodes have a low-latency low-bandwidth connection as well, this would work well. If we are talking about pure high-latency: - Where did you get the USK from? Hopefully you, or somebody near you, were subscribed to it via passive requests. - There's a good chance the top few blocks will be cached relatively nearby - the top few blocks are for example probably in the freesite's USK container. - But maybe even with all this, there would still be too many round trips. In which case you need a high level tunnel of some kind, with different security tradeoffs... :< > > > I see it more as a long term, attack resistant, scalable solution for general > > communication in places where Freenet-over-UDP doesn't work. > > That would be a very valuable system, I just don't see what it's got to > do with Freenet. Ummm, the fact that it would be a routable small world darknet? That clients would be identical in terms of bulk downloads, and similar for other things? (E.g. FMS would work adequately with this, admittedly with an absolutely horrible latency, which would be cut to a moderately horrible latency with true passive requests). > > Cheers, > Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080513/b97f5db2/attachment.pgp>
