Re: Freenet on a Delay-tolerant network

--===============1472765339==
Content-Type: multipart/signed;
  boundary="nextPart7927916.Cbp2HdXXZp";
  protocol="application/pgp-signature";
  micalg=pgp-sha256
Content-Transfer-Encoding: 7bit

--nextPart7927916.Cbp2HdXXZp
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On Wednesday 01 Jun 2011 18:35:21 Tom Sparks wrote:
> How would Freenet work on a delay-tolerant network like Probabilistic Rou=
ting Protocol using History of Encounters and Transitivity (PRoPHET) [1] ?
>=20
>  [1] http://tools.ietf.org/html/draft-irtf-dtnrg-prophet

I don't have time to look into it in detail right now. However I will give =
you my standard view:
=2D This sounds a lot like Haggle. Opportunistic forwarding, local broadcas=
t and all that.
=2D It's equivalent to standing on a bus and asking if anyone has a copy of=
 your favourite illegal file. I hope it works but I don't see it as being c=
losely related to Freenet. However...
=2D Medium term, Freenet will be largely darknet - that is, friend to frien=
d - and will have support for hiding its traffic via simple steganography.
=2D Long term, in particularly hostile environments, even stego'ed darknet =
transports are detectable and/or blockable.
=2D Therefore, we would like to support high latency transports (which are =
still darknet), for instance exchanging USB keys with your friends regularl=
y (aka sneakernet), or automatically transferring data between your phone a=
nd his when you are physically in close proximity. We would also envisage u=
nderground wifi links etc making up some part of such a network, which theo=
retically could run even in places like North Korea or Cuba where the inter=
net is illegal, even if there is no outside world to tunnel to (or it is in=
feasible to tunnel to it) or more prosperous countries with heavy internet =
restrictions (e.g. blocking peer to peer in general, whitelists etc).
=2D To make any of this work we will need long-term requests (i.e. very hig=
h latency, can be forwarded when the originator is offline), which are prob=
ably necessary for practical darknets anyway in many cases, and publish/sub=
scribe or something similar (e.g. passive requests), which are very importa=
nt but on a system with high per hop latency are enormously important.=20
=2D However, we would retain the ability to request data which is many hops=
 away. It would just be very high latency (not necessarily low bandwidth th=
ough).=20
=2D Freenet is actually reasonably well set up to provide a user interface =
for high latency requests - e.g. downloads are queued and the user gets not=
ified later; even with freesites, you can bookmark them and be notified on =
an update, or when they fail to load you can queue them as a download.
=2D One technical challenge will be how to route on such a high latency dar=
knet. Currently we rely on swapping locations to make the network navigable.
=2D In the shorter term, we'd like to implement an easy means to move data =
from one darknet to another, without having to know the private keys for th=
e freesites being moved. This is called "binary blobs".

http://new-wiki.freenetproject.org/Steganography
http://wiki.freenetproject.org/HardStego

--nextPart7927916.Cbp2HdXXZp
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEABEIAAYFAk3vorkACgkQYUNbc3WUHYjUdwCghhm3/Pn6hVEHYdJGa5YD3li1
AsMAniv6a1gI1K9x50u7qKI5zCFEAC2l
=AQFh
-----END PGP SIGNATURE-----

--nextPart7927916.Cbp2HdXXZp--

--===============1472765339==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Tech mailing list
[email protected]
http://freenetproject.org/cgi-bin/mailman/listinfo/tech
--===============1472765339==--