On Thursday 06 August 2009 16:33:04 Evan Daniel wrote:
> On Thu, Aug 6, 2009 at 8:09 AM, Matthew
> Toseland<[email protected]> wrote:
> > I propose that as a darknet value-add, and as an additional tool for those 
> > in hostile regimes who have friends on the outside, we implement a 
> > web-proxy-over-your-darknet-peers option. Your Friends would announce 
> > whether they are willing to proxy for you, and you could choose which 
> > friends to use, or allow it to use all of them (assuming people on the 
> > inside don't offer). You could then configure your browser to use Freenet 
> > as a proxy. This would not provide any anonymity but it would get you past 
> > network obstacles and/or out of Bad Place and into Happy Place. It's not a 
> > long term solution, but:
> > - We have expended considerable effort on making darknet viable: IP 
> > detection, ARKs etc.
> > - It could take advantage of future transport plugins, but even before 
> > that, FNP 0.7 is quite hard to block.
> > - Many people are in this situation.
> > - It is easy to implement. HTTP is complex but cache-less proxies can be 
> > very simple.
> > - It could be combined with longer term measures (growing the internal 
> > darknet), and just work for as long as it works. Most likely it would be 
> > throttled rather than blocked outright to start with, hopefully allowing 
> > for a smooth-ish migration of users to more robust mechanisms...
> > - We could allow recursive proxying to some depth - maybe friend of a 
> > friend. This would provide a further incentive to grow the internal 
> > darknet, which is what we want.
> > - The classic problem with proxies is that they are rare so hundreds of 
> > people connect to them, and the government finds out and blocks them. This 
> > does not apply here.
> 
> I like it.  Darknet features are a very good thing.  This probably
> also needs some care wrt bandwidth management (related to 3334 --
> similar considerations probably apply).
> 
> However, as I mentioned on IRC, there are several things I think
> should be higher priority.  Of course, I'm not the one implementing
> any of this, but here's my opinion anyway ;)  In no particular order:
> 
> - Documentation!  Both the plugins api and making sure that the FCP
> docs on the wiki are current and correct.

I will try to spend some time on this soon...

> - Bloom filter sharing.  (Probably? I have no idea what the relative
> work required is for these two.)

Agreed, this is a big one.

> - Freetalk and a blogging app of some sort (though these are probably
> mostly for someone other than toad?).

There are a number of things I can do to help p0s.

> - A few specific bugs: 3295 (percent encoding is horribly,
> embarrassingly broken -- in at least 5 different ways), 2931 (split
> blocks evenly between splitfile segments -- should help dramatically
> with availability), fixing top block healing on splitfiles (discussed
> in 3358).

Skeptical on priority re 3295, but I guess I should look into it. IMHO it is 
critical that the top block be redundant, hence MHKs. Dunno re relative 
priority with f2f web proxy though.

> - Low-latency inserts flag as per 3338.  (I know, most people probably
> don't care all that much, but I'd really like to see whether Freenet
> can hit near-real-time latencies for the messaging app I'm working
> on.)
> 
> Also, it's worth considering other ways to make darknet connections
> more useful (in addition to this, whether before or after I don't have
> a strong opinion on).  Enabling direct transfer of large files would
> be good (at a bare minimum, this shouldn't fail silently like it does
> right now).  

ljb is working on this as we speak. The problem is simply persistence - if the 
node restarts before you accept the transfer, it will break. But he will do 
some improvements to the UI as well e.g. showing the transfers on the downloads 
page.

> Improving messaging would be good; I should be able to 
> see recently sent / received messages (including timestamps), queue a
> message to be sent when a peer comes online, and tell whether a
> message I've sent arrived successfully.

I think most of this is within ljb's remit? ljb? vive?
> 
> Evan Daniel

Attachment: signature.asc
Description: This is a digitally signed message part.

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

Reply via email to