On 7/23/15, David Stainton dstainton415@gmail.com wrote:
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.
It would be nice if by using Tor, we solved the end-to-end problem two different ways - by offering .onions and by assisting with any possible automated NAT punching.
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?
I think that will never work for a relay or a bridge. Reachability for systems like IPFS has different considerations. In that sense, we've already solved it with hidden services.
All the best, Jacob