Re: How would * change Freenet's protocol?

Matthew Toseland <toad-EI5O+8PHWbJeeLb3ft/[email protected]> Tue, 29 Jun 2010 01:48:30 +0100
Newsgroups gmane.network.freenet.general,gmane.network.freenet.technical
Message-ID <[email protected]>
--===============1612655625==
Content-Type: multipart/signed;
  boundary="nextPart5004775.l6HJedscEM";
  protocol="application/pgp-signature";
  micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

--nextPart5004775.l6HJedscEM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Tuesday 29 June 2010 01:04:05 Tom Sparks wrote:
> --- On Tue, 29/6/10, Matthew Toseland <toad-EI5O+8PHWbJeeLb3ft/[email protected]> wrote:
> > On Monday 28 June 2010 05:39:23 Tom
> > Sparks wrote:
> > > How would a Delay-tolerant network and a Mobile ad hoc
> > network change freenet's protocol?
> >=20
> > This is really a question for the tech list.
> >=20
> > IMHO delay tolerant darknet is a potentially interesting
> > area for Freenet. This would involve sneakernet (exchanging
> > USB keys), short range high bandwidth transfers between
> > mobile devices etc. It would be routed (allowing access to a
> > wider range of data than what is on your direct friends'
> > nodes). It would rely heavily on passive requests /
> > subscriptions, as well as on requests being relayed over a
> > period of days, whenever friends connect.. It would likely
> > be rather slow, because each hop might take a day or more.
> > It could take advantage of fast links where they are
> > available however (e.g. underground wifi). It would be
> > deployable in places where the Internet is so locked down
> > that Freenet doesn't work. About half the devs think this is
> > not something Freenet should ever deal with because e.g. it
> > would need larger block sizes. But even if it is not Freenet
> > it might reuse a lot of Freenet code. And it would have to
> > be darknet: Data is only exchanged between people who have
> > been pre-established as Friends. That means it is not ad
> > hoc. If you are interested in ad hoc / opennet, have a look
> > at Haggle, which essentially relies on mobile devices being
> > able to broadcast requests for files to everyone in the
> > immediate vicinity, with some opportunistic forwarding iirc.
> > IMHO this is rather risky, which is why I suggest a delay
> > tolerant darknet Freenet system might be possible.
> >
> I am writing a book/game/role-playing game addon about a fictional networ=
k and freenet is the closes network to my idea, but there are a few differe=
nces
>=20
> * hash-based IP address

You mean you have an internal, quasi-traceable addressing system? Or that y=
our fictional network can relay TCP connections and other traffic to a hash=
=2Dbased endpoint? IMHO central but anonymous servers (like tor hidden serv=
ers) are a bit of advanced functionality that *may* happen eventually on Fr=
eenet but will be *SLOW* - and you can do a surprisingly large amount witho=
ut centralised anything, just with distributed storage, scalable indexes, d=
istributed revision control (git/mercurial), wikis, databases, etc. And the=
y don't make much sense with sneakernet/high latency networking; you have t=
o have an end-to-end network to have anything real time.

> * gateways between city network and city-to-city network

Agreed this would be needed. In the freenet darknet model, the assumption i=
s that there are a lot of short links and a small number of long links. Lon=
g links in an underground scenario (freenet illegal and the public networks=
 heavily restricted e.g. by preventing all p2p connections) might be people=
 commuting long distance and taking data with them, or sending data through=
 the post / a box of DVDs in a truck etc. So there is no single centralised=
 network design - meaning if there are enough of these long connections the=
re is always redundancy and it is not too vulnerable to attack. One difficu=
lty is that carrying data on planes is becoming increasingly hazardous, wit=
h customs people having the right to inspect your laptop, force you to give=
 them access, etc, and increasingly exercising this right in the name of co=
pyright (I believe ACTA talks about this, although historically speaking th=
ey could always refuse entry if you fail to cooperate).

> * underwater network and surface to air network

Meaning guerilla wifi, ronja's (home-made free space optical data links) et=
c? I.e. fixed, hidden, semi-permanent, directional links, and maybe disposa=
ble self contained open mesh boxes for mobile stuff - if they are cheap eno=
ugh; depends how much effort it is to lock down commonly available hardware=
, if you have to buy everything black market then disposable doesn't really=
 work ...

Another interesting possibility - some of the network might be real time bu=
t low bandwidth. Maybe even some over-the-regular-internet stuff e.g. stega=
nography faking VoIP calls, games etc. This can be combined with non-real-t=
ime links which are much higher bandwidth but also much higher latency, so =
the requests get relayed quickly but the data trickles back when possible.

If hardware isn't too expensive, there are a lot of possibilities, but rede=
ploying stuff even if it's cheap could potentially lead to people being bus=
ted.

Really it comes down to just how mad the state is. If they are prepared to =
spend 10% of their GDP having half the population spy on the other half (Ea=
st Germany), or boil people in oil on random suspicion (Iraq), there are se=
vere limits to what you can do even to keep lines of communication open... =
But in the short term, everyone uses opennet, which is hideously insecure. =
There is some reasonable hope IMHO that a huge opennet with some big improv=
ements to security might one day be more secure than some of the alternativ=
es, but we don't fully understand the theory yet (e.g. just how hard is mob=
ile attacker source tracing?) So you can make whatever assumptions you like=
 for the purposes of speculation, and check them in 10 years when it actual=
ly happens :) ... And as I've mentioned any hostile state can shut opennet =
=46reenet down rather easily, initially by targeting the seednodes, but als=
o by harvesting and blocking IPs.

On the other hand if you are talking about a friendly environment where you=
 can run Freenet openly across the Internet, the situation is completely di=
fferent. Then you get into more general discussions of throttling, charging=
 and deeper interference on commercial cell nets, mesh networking, user own=
ed infrastructure, the relatively poor scalability of current ad hoc networ=
king protocols (making centralised networks frequently the only practical s=
olution), the relatively low bandwidth of wireless in general, the high cos=
t and inconvenience of multiple directional antennas especially on rooftop =
mounted nodes, the reasonable hope that as processing power comes down the =
number of antennas will go up until you can have fourier arrays, and so on =
(see my blog post a few weeks back about disruptive hardware).

Another post you need to read, though it might be a bit technical:
[freenet-dev] Fast *and* secure Freenet: Secure bursting and long term requ=
ests was Re: Planned changes to keys and UI

--nextPart5004775.l6HJedscEM
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)

iEYEABEIAAYFAkwpQt4ACgkQYUNbc3WUHYjHGwCfc+m0LvP+fc+d86lIclCGP9zr
uikAnRqrQuhmePJMEwjdDJWkydLKbiZG
=os21
-----END PGP SIGNATURE-----

--nextPart5004775.l6HJedscEM--

--===============1612655625==
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
--===============1612655625==--