Defining Freenet was Re: Darknet, uptime, and true passive requests

On Wednesday 16 July 2008 19:45, Michael Rogers wrote:
> Matthew Toseland wrote:
> > Most Freenet users are likely 
> > to be non-geeks who won't run their computers 24x7 for various good 
reasons:
> 
> You might well be right, but in that case we need to ask some difficult
> questions:
> 
> * Is it even possible to build a scalable, robust, distributed cache
> where most of the nodes are offline most of the time 

Yes. Opennet can do this. Although performance will start very slow after 
startup after a long downtime.

> and some of them 
> only connect to their friends?

Good question.
> 
> * If it is possible, do we have a clear idea of how to build it, or are
> we just piling systems on top of each other?

Well... I have some ideas, that's all. Nothing concrete, simulated in detail, 
mathematically modelled and guaranteed to work. :)
> 
> * What kind of applications can such a network support? 

Downloads. Uploads. Non-realtime chat. Web sites with offline fallback, 
similar to offline browsing: this page is not currently available, click here 
to queue it, we will tell you when it is found. (We already do this, it is 
useful for not-so-popular freesites that need some retrying to fetch).

> What kind of 
> applications should it not even try to support?

Real time chat. But even there, a large minority of the network - or some 
separate darknets - may have high enough uptimes. And opennet can support 
this.
> 
> > I'm not convinced. Freenet is not defined by its real-time behaviour, so 
much 
> > as by its goals (censorship resistant datastore), and its need to build a 
> > global f2f darknet to support those goals.
> 
> I think you've hit the nail on the head - Freenet has always been
> defined by the broad goal of censorship resistance rather than by
> concrete use cases, and as a result the means of achieving that goal
> keep changing.

Okay...
> 
> For example, should Freenet support real-time communication? 

To the extent that that is possible. IMHO Freenet's mission is to provide an 
uncensorable network that provides as much of the services which are no 
longer usable to those subject to censorship as possible. However, on a 
low-uptime darknet, real time communication is going to be difficult.

But on an opennet, or even a high-uptime darknet, should we actively 
discourage real-time communication? I'm not convinced, I don't see any 
problem with offering services which won't be feasible longer term, if they 
get people onto the network now. :)

> Long-term storage? 

If we could, it'd be great, wouldn't it? But we can't afaics. Well, there are 
a few ideas floating about ("inverse passive requests"), but that's really 
long term stuff and likely a big security risk, as well as of course not 
being completely reliable.

I do think that there is useful work to be done on improving data reachability 
however, the current network has some issues with this.

> Small, isolated darknets connected to the main network by camel 
> caravan? 

I would certainly like to support this if it is possible, and if the 
characteristics of the resulting network don't make it pointless. The main 
concerns afaik:
- The single connection is a point of attack. If the recipient is evil, he can 
both observe and control all traffic out of the small darknet.
- The single connection has limited capacity and may have high latency. It's 
essential that the two networks are aware of their separatedness, and that 
requests are tried on the small darknet before being forwarded to the wider 
network. Rationing of limited capacity may also be a big issue.

> A large darknet in China and a large darknet in the West joined 
> by a handful of cross-border links?

This is very similar to the last question. Given the limited interconnect 
capacity, and to some degree given the likely differences in 
content/interests between the networks, it is essential that requests be 
tried on the "local" network before the "remote" one. It's a question of 
(automatic? manual?) partitioning and then using that information.

Both of these last two cases, but especially the latter, follow directly from 
the darknet concept; IMHO they are important long-term. However, there is 
much to do in the short term, we need to be careful with allocating resources 
given the pressures on funds (immediate problem) and time 
(external/legal/legislative problem).
> 
> > And longer term it'd be great if we could have e.g. audio 
> > streams.
> 
> And a pony. ;-)

On opennet, or even on a high uptime darknet, low bitrate audio streaming 
implemented via passive requests should be feasible, with lag hopefully in 
minutes rather than tens of minutes. Of course this depends very much on load 
management; in theory it should have been feasible on 0.5, but I couldn't get 
sufficient performance out of it.
> 
> Cheers,
> Michael

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

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

iD8DBQBIfkjSA9rUluQ9pFARAgI+AJ9Xf6cLT8lkL3+pO5B8FjMGM+voAQCgi+wk
rUR+7MuRHEmAwu7nQn1Vvvo=
=7wsy
-----END PGP SIGNATURE-----