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" ;) )

(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 :) )
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to