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 <[email protected]> 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 >> [email protected] >> https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > > > > _______________________________________________ > tahoe-dev mailing list > [email protected] > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > _______________________________________________ tahoe-dev mailing list [email protected] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
