GSoC 2015 to overcome NAT limitations?

[David Stainton]

Your comment about leeching bandwidth is judgmental and incorrect. I
store very small files on our Tahoe-LAFS onion grid. I recently was at
the Tor developer meeting in Valencia, Spain and we (me and Leif Ryge)
explained to some of the core Tor developers how this Tahoe-LAFS onion
grid works... and none of them raised this concern.

Furthermore, if my Foolscap Twisted endpoints patch is merge then
we'll be able to host heterogeneous Tahoe-LAFS grid; that is a storage
grid accessible by more than one transport protocol.

You might have also pointed out (but maybe you forgot?) that
Tahoe-LAFS uploads duplicate shares... therefore to not "leech" Tor
network bandwidth one could upload via TCP and download via Tor... if
using a heterogeneous grid and this behavior was approved by your
threat model.


Sincerely,

David

On Fri, Feb 27, 2015 at 7:06 AM, Chris Kerr <chris.kerr at mykolab.ch> wrote:
> Using Tahoe-LAFS over Tor will drastically reduce data transfer speeds
> versus a direct connection, not to mention leeching bandwidth from other Tor
> users.
>
>
>
> For me, usability from behind a NAT is an essential feature. I have had
> moderate success using PageKite but things would be much easier if there was
> only one package to install and configure. If this is not something that
> Tahoe-LAFS can do itself then integrating with external tools would also
> help. Also, if NAT piercing turns out to be too difficult, connection
> forwarding "super-helper-nodes" would also help, albeit with increased
> bandwidth costs.
>
>
>
> On Wednesday 25 Feb 2015 15:51:14 David Stainton wrote:
>
>> Hi Lukas,
>
>>
>
>> I'm very interested to see what the tahoe-devs say to this idea of
>
>> participating in GSoC.
>
>>
>
>> With regards to NAT... it seems that they decided a while back that
>
>> this problem was outside the scope of what Tahoe-LAFS should solve...
>
>> but maybe they are interested? I can tell you that there are various
>
>> people such as myself who use Tahoe-LAFS with Tor and Tor hidden
>
>> services... we therefore get NAT penetration for free. I don't know
>
>> much about I2p but I think they may have NAT penetration as well.
>
>>
>
>> Cheers,
>
>>
>
>> David
>
>>
>
>> On Wed, Feb 25, 2015 at 4:20 PM, Lukas Pirl <tahoe-dev at lukas-pirl.de>
>> wrote:
>
>> > Hello Tahoe-People!
>
>> >
>
>> > What if I'd be interested in contributing to Tahoe-LAFS in the context
>
>> > of this year's Google Summer of Code¹?
>
>> >
>
>> > What is interesting for me is the firewall/NAT/hole punching topic. From
>
>> > what I recognize, running Tahoe behind some NAT is relatively popular
>
>> > (e.g. at home). From my own experiences, I can say that the peer-to-peer
>
>> > idea is somewhat destroyed if one runs most of the nodes behind a NAT.
>
>> >
>
>> > Well, there are five days left for you as an organization to apply for
>
>> > this year's Summer of Code. Tahoe can definitely profit!
>
>> >
>
>> > Further, I have a (early) question about the mentoring. Do you want the
>
>> > mentor to be a Tahoe core developer (what definitely would make perfect
>
>> > sense) or am I supposed/can I ask one of my folks in preference? And if
>
>> > so, is it sufficient for mentors to be wizards in Python and to have
>
>> > joined the GSoC already or should they have made contributions to Tahoe
>
>> > already?
>
>> >
>
>> > I'd be happy to hear from you!
>
>> >
>
>> > Kind regards,
>
>> >
>
>> > Lukas
>
>> >
>
>> > ¹ https://www.google-melange.com/gsoc/homepage/google/gsoc2015
>
>> > _______________________________________________
>
>> > tahoe-dev mailing list
>
>> > tahoe-dev at tahoe-lafs.org
>
>> > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>>
>
>> _______________________________________________
>
>> tahoe-dev mailing list
>
>> tahoe-dev at tahoe-lafs.org
>
>> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at tahoe-lafs.org
> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
>