Le vendredi 07 août 2009 00:38:50, Matthew Toseland a écrit : > On Thursday 06 August 2009 22:18:59 Clément wrote: > > Le jeudi 06 août 2009 21:27:41, Matthew Toseland a écrit : > > > 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 > > > > Is there any defined roadmap for 0.8 yet ? If not, it might be good to > > clear things up, and decides which features are must have and which > > aren't. For instance, a F2F proxy is a great idea, but it's another > > feature plan on top of an already good filled list. It gives the > > impression of unconsistency (I said "impression" ;) ) > > Well, it is low cost and high impact IMHO... > RIght. > > (Also, I'm not on irc since a while, so I don't know what's really > > happening, so if this question has already been answered, just ignore me > > :) ) > > Okay, this is my current view, but other people may have different views... > > What is definitely in: (I will be very unhappy about releasing if these are > not resolved) - Work so far. > - Bloom filter sharing. > - Freetalk and/or WoT. I will assist p0s to break any blockages, but at the > moment it is still essentially his project. - Workarounds for the recent > AES issues. > - Means to download the latest installer from a Freenet node. > > What is definitely out: (postponed to 0.9 or later) > - Transport plugins. > - Encrypted tunnels. > - Passive requests. > > GSoC stuff: > - sashee's work on dynamic UI should be part of 0.8 hopefully. > - mikeb's work on XMLLibrarian is already part of it to some degree, more > will be. - ljb's work on f2f stuff is partly merged and more will be. Will that be sufficient to change the friends ui ? I was thinking of that : http://doc-fr.freenetproject.org/Fproxy_mockup#My_Friends_.21 in particular. And, if not, wouldn't worth it to put that in the feature list for 0.8, since I think it would be rather high impact (facebook is the 4th world most visited site (when is not DOSed ;) )). I don't know how much work it would need, but I don't think it requires network-level changes (maybe a few rework on N2N? ). > - kurmi's work so far on filters (BMP, new CSS, ATOM, ...) will be merged, > and hopefully there will be more. - infinity0's work on distributed > searching is probably longer-term. > > What will hopefully be in: > - Better segment splitting. > - Opennet peers limit scaling by bandwidth. > - MHKs (redundant top block). > - Trivial plugin update over Freenet. > - System tray icon for Win, Mac and Linux (native, native, java, > respectively; I would have to implement the last one but have example code > to base it on). - Various minor UI stuff. > - LOTS OF BUG FIXES, especially in db4o and the connection layer. > > What might be in: > - Means to prioritise a single node (e.g. a darknet peer on a low bandwidth > connection). - Ogg vorbis/theora filtering and embedding support. > - Easy freesite upload wizard plugin. If not, seriously consider bundling > jSite. - Easy blog creator plugin. If not, seriously consider bundling > Thingamablog. - Revocable SSKs. > - Proxy over darknet peers. > - saces' multi-container freesite insertion code. This works but needs > debugging, de-leaking etc. - Low profile/pause mode. > - Better USKs (e.g. hierarchical DBR hints).
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
