This would be a nice-to-have, but not a priority for Tor. OTOH, that functionality is more vital for i2p, who are exploring the idea of integrating into Tor's PT system:
https://trac.torproject.org/projects/tor/ticket/10629 Also, right now, no PT servers can actually traverse NAT. In the future, we plan to add WebRTC capability to flashproxy, which will include NAT traversal: https://trac.torproject.org/projects/tor/ticket/5578 If you want to see it done faster, feel free to help us/them out, or find someone where I can apply for funding for it. X On 20/01/14 19:24, Juan Berner wrote: > Yes, but the point of flash proxies, is to use them as bridges, what I > meant is to allow OR's behind NAT to be relays or even exit nodes. > > > 2014/1/20 David Fifield <da...@bamsoftware.com> > >> On Mon, Jan 20, 2014 at 05:00:38PM -0200, Juan Berner wrote: >>> 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , >> this would >>> be done using a queue system, possibly in a hidden service but not >> necessary, >>> where nat relay nodes can query what tor clients want to connect to them >> and >>> initiate the connection. This would allow more nodes in the TOR network. >> >> This is how flash proxy works. Clients register themselves as needing a >> connection, and then proxies connect to the clients. (The problem is >> that many *clients* are also behind NAT, and then it doesn't work so >> well.) >> >> You can run a flash proxy just by going to a web page like >> http://crypto.stanford.edu/flashproxy/, and there is also code to run a >> proxy in the background without a browser: >> https://trac.torproject.org/projects/tor/ticket/7944. >> >> David Fifield >> -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev