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
-------------- 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/tech/attachments/20080716/a24c9839/attachment.pgp>
