On Thu, 6 Aug 2009 20:27:41 +0100 Matthew Toseland <[email protected]> wrote:
> 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? I can work on this if no one else is interested. I can start working with it when I'm finished with imporoving the file transfers. Hopefully will be done within one week. > > > > Evan Daniel
signature.asc
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
