Freenet on phones, sneakernet/long term

--===============0136106565==
Content-Type: multipart/signed;
  boundary="nextPart1513370.Itvt0OpFrA";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart1513370.Itvt0OpFrA
Content-Type: text/plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Some recent discussion about Freenet on phones (and routers, see my other m=
essage on tech). Clearly running a regular broadband based Freenet node on =
a cracked iPhone is unlikely because of cost and power issues (although it =
has 256MB of RAM and at least 8GB of storage). However, a smartphone with s=
ome fast short range networking would be ideal for 1) Haggle, and 2) Freene=
t darknet rendezvous.

Haggle is, roughly speaking, opennet sneakernet. It was originally conceive=
d for phones and is more or less ideal, on certain provisos. The basic oper=
ating principle is this:
=2D Shout at the top of your voice "Does anyone have a copy of [ censored ]=
" wherever you happen to be - on a bus, in a crowd - and if they have it th=
ey'll send you it.
=2D Hope that nobody has tracing equipment.
=2D I believe there is some level of opportunistic relaying of requests, bu=
t it's not really routed in a scalable sense we would recognise.
=2D One worry is that phones might not have untraceable wifi. Another is th=
at relatively cheap infrastructure or patrols with tracing equipment could =
bust a lot of users, if the law is sufficiently harsh. But really it *is* a=
n interesting system, it's just not Freenet.
This may be an out of date view of Haggle, see here:
http://www.haggleproject.org/index.php/Main_Page

=46reenet darknet rendezvous is essentially darknet sneakernet, but without=
 having to pass around USB keys.=20

 Your phone detects when your registered friends are nearby, and does a bur=
st transfer over UWB (wireless USB, 480Mbps over very short range) with the=
m. Modern phones are built to do the detection phase cheaply, but don't yet=
 have UWB; it is likely they will soon however. Host-side USB with a networ=
king cable would be another possibility. Thus any time you go for a pint wi=
th friends you automatically propagate data, requests, etc, without having =
to do anything. When you go home your phone will again automatically sync w=
ith your fixed node (PC/router), which then forwards stuff over your fixed =
connections - regular Freenet connections (possibly with the same friends, =
which gives some nice optimisations), stego connections over the internet, =
fixed wifi links, etc. Unlike Haggle, it is strictly limited to known frien=
ds (hence safer), and has a more freenet-like (and therefore probably slowe=
r, because less broadcasty) routing system. Publish/subscribe is essential,=
 but much of it is organised around global (and anonymous) streams. Routing=
 is also possible: although it may take days or weeks depending on the tran=
sports, popularity, etc, it should be possible to obtain a huge variety of =
content. So what we are talking about is a robust, anonymous, often slow me=
ta-internet capable of using whatever connectivity is available.=20

This is a natural evolution of current Freenet IMHO: Messaging and other ap=
plications require good publish/subscribe for efficiency in the medium term=
=2E Even now, Freenet's expectation that nodes will be online 24x7 is unrea=
sonable. Darknet (connecting only to friends) was introduced to make it pos=
sible to run Freenet in places where opennet may be harvested and blocked. =
Darknet networks composed of low-uptime systems are unlikely to have full e=
nd-to-end connectivity most of the time, which means we will need some form=
 of persistent requests. And any competent state trying to eliminate an und=
erground Freenet darknet (note Iran's recent communications crackdown) will=
 soon realise that looking for long-lived peer to peer UDP connections will=
 bust most nodes. Steganography can only go so far, traffic flow analysis w=
ill ultimately find all nodes - but even good stego will need to not exchan=
ge data continually, making the uptime issues even worse. Ultimately sneake=
rnet and rendezvous based transports become very attractive. And they can h=
ave pretty good bandwidth too, although latency is poor. All that routing r=
eally requires (provided we can figure out a way to assign locations), is t=
hat there be many short links (e.g. meeting up in a pub after work, fixed w=
ireless links), and a few long links (LUG/2600 meetings, mailing a box of d=
isks etc).

So I expect *before 1.0*, and largely on the basis of our present network b=
ehaviour (poor node uptime, messaging) we will have to implement:
=2D Good publish/subscribe (aka passive requests)
=2D Bloom filter sharing (awareness of data on friends' nodes, speeds up ro=
uting considerably but also has some nice impacts when you reconnect)
=2D Long-term requests (meaning they persist on the network, pick up data a=
s nodes come online, and forward it back to the originator)

Both of these tie in reasonably well with existing UI and APIs IMHO. After =
1.0, we should look very seriously into sneakernet, and non-real-time stega=
nographic transports (e.g. faking VoIP calls). With the above feature set, =
it becomes quite plausible. Obviously fetching rare content could take week=
s - but popular content should be faster, and popular publish/subscribe str=
eams should be reasonably responsive. Such a system might need some adjustm=
ents such as larger block sizes, but IMHO it would likely reuse a lot of Fr=
eenet technology, even if it was not Freenet itself. And I'd argue that eve=
n if it is incompatible with Freenet 1.0, it would be worthy of support fro=
m FPI, given its mission statement. Thoughts?

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

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

iQIcBAABCAAGBQJKoScVAAoJEHsvjZi+xPTDlTcP/09Km1StpaZxrOO+zcFdpwMY
E0a3Q+KMq6xehnBpNrmmgM3FxVHxJqGaP/n96VgrmScqZmHDqLlghHZkW8PVA3WA
8VrwSWN6h+gMLg3ZWH3lUS2+mVNdlvhDtRi07haCHxPK9aeKVglLopp5BSLXjxHu
8AQW/xMsSk4vX6uevpXUOu7bWqwJ2YlWfdFHwa6MTBO7lfRA6lFVsYteYx1ZZFr1
8NkRY/nuJvuUXrW/BPgYTfknZ8RDMjj6cZOzRdL8DAbR3bpQ+9tFIL3HANnrNs5e
bhdQOcdREHVq/j8Fu3eRNvPaRHa95zMDoVDfma7oXJ9ViAJuzxPw3iTRPUBYlV3C
/O3uwW8UAxlb4hgQVPBZ2uBaCr+4gDtxUS1kedYRIFN8S62N9vqoNjsTLawUlnxb
4YqtBaFlwiqPG02YBpQUCwvCWEyr5yiTiTSbmRLWP7hHadarQI09xg7S1Rku/B2j
H+ODVNIr+OWfH9DCDNa4P/B/Yh9CXMQ5cjVOtWXUoPkoSakTo9aCgASL4xAxt9ip
sVod2rfHFMns4sgexNWmw9/n3niUGjf+KqAHGaTzD2/lz3O+dDLu8zGzty2TCS5e
XRDXAcAeq57ANLRePd2yuq622FJl007kBcL1BsAQW3f4t57XZ7eZdR33wkE6AS78
6hBACpwAXUi9HAUA2a3T
=fy89
-----END PGP SIGNATURE-----

--nextPart1513370.Itvt0OpFrA--

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

_______________________________________________
chat mailing list
[email protected]
Archived: http://news.gmane.org/gmane.network.freenet.general
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat
Or mailto:[email protected]?subject=unsubscribe
--===============0136106565==--