> Why are we avoiding allowing users to make this choice because of the > above reasons? If a user wants to run a relay or a bridge, we should > make it easy. We don't answer the above questions when it is hard - > are we really off the hook there? It just seems ridiculous.
Obviously NAT has destroyed the Internet by violating the end to end principal... however I'd like to remind the thread that many many other "distributed" software systems also run into this very same NAT issue. It sucks... and not just for Tor project but this has also prevented many users of say for example Tahoe-LAFS from deploying storage servers from their home behind a NAT device. >> But we have a gigantic userbase, and playing "consumer router support >> technician" for all of the ones that ship with broken uPnP/NAT-PMP >> implementations does not fill me with warm fuzzy feelings. > > I think this is a weird analysis. How many of those people even try to > be a relay or a bridge? Do we have numbers on that? Does the support > team object or are you objecting on their behalf? It just seems too > hand wavy for too many years to punt on dealing with NAT properly. If I understand things correctly the uPnP/NAT-PMP is in fact not the proper way to solve this problem because of the reasons Yawning mentioned. IPFS (interplanetary filesystem) currently solves this problem via some complicated protocol with the selection of a rendezvous server... similar to Tor hidden services. Clearly this is the correct way to solve the NAT problem. Am I wrong about this? _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
