update on Tahoe/Tor/Foolscap integration

[David Stainton]

First of all, we had several meetings, they take a long time, we talk
about a lot of stuff... it's work. Therefore it seems really unfair to
hear more quasi design discussion/complaining talk from people who
didn't attend the meeting; it disregards our efforts. Perhaps come to
the meetings? Offer solutions?

Secondly, I'm sure that the world's spying agencies would love for us
to deliberate writing this Tor integration even longer by having
confused cross talky design conversations so that we can't possibly
finish the integration before this upcoming Tor developer meeting:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2015SummerDevMeeting

Are you aware when ticket #517 was opened by Jake Appelbaum?
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517
Opened at 2008-09-18T20:52:23Z.... so yeah let's please not deliberate
for several more years!

In general Tahoe-LAFS storage nodes cannot serve traffic from coffee
shops because of NAT. This Tor integration at it's core is an
acknowledgement not only that people need anonymity guarantees but
that the Internet is fundamentally broken because of NAT; it violates
the end-to-end principal. We therefore need protocols like Tor onion
services to penetrate NAT via rendezvous points... in other words,
Tahoe-LAFS needs a p2p transport; Tahoe-LAFS isn't a NAT-penetrating
p2p protocol itself. Yawning Angel of the Tor project has said
publicly many times that these NAT devices have very unreliable
forwarding protocols like NAT-PMP:

https://lists.torproject.org/pipermail/tor-dev/2015-July/009155.html

We think that overcoming NAT by way of a rendezvous transport is going
to be way more reliable and widely useable than trying to make use of
things like NAT-PMP. Honestly, I'd rather see the internet just unfuck
itself by way of IPv6 (or whatever next general IP)... but that was
supposed to happen years ago... we aren't holding our breath and we
aren't pretending NAT isn't a problem.

> I don't like this idea for 1 main reason -> My IP address changes. I know

Your IP address of what changes? Of your laptop? Are you trying to
serve files from your laptop? If not then does it matter if your IP
address changes?

> that some people use/see Tahoe-lafs as a client/server protocol, but I see
> it as a p2p protocol. If I need to re-setup my node every time I take my

Not a matter of opinion here... see above; the Internet is broken. We
can write lots of p2p software that doesn't actually work if we don't
think about how to fix the end-to-end principal violations.

> laptop to a coffee shop, that would be very inconvenient. The thing that
> feels the most like a server to me is the introducer, but since I have been
> controlling the public test grid I know that the ip address has changed at
> least 4 times and I lost control of the DNS name at least once.

What do you mean by "feels like a server"?
You lost control of the introducer DNS name?
I'm not sure what point you are trying to make here.

> Final thought, in a p2p environment, auto detecting IP addresses locally
> doesn't work very well anyway because of NAT. As long as their is an
> introducer, I believe that the most accurate way to get your own IP address
> is to ask the introducer what it is.

Um these statements are a bit confusing. Storage servers announce
themselves to the introducer! and if a storage server is behind a NAT
device then it announces an RFC1918 address. Do you want it to remain
broken?

> (Don't get me wrong, I like the idea of supporting TOR and making TOR
> configuration easier.)

nit: Tor not TOR.

> On Mon, Aug 31, 2015 at 8:30 AM, Lukas Pirl <tahoe-dev at lukas-pirl.de> wrote:
>>
>> On 09/01/2015 12:22 AM, Daira Hopwood wrote:
>>>
>>> I am concerned about this being a significant usability regression.
>>
>>
>> I thought so too
>> (but didn't feel I am into that enough to note that).
>>
>> _______________________________________________
>> 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
>