emdee/tox_profile
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

UpdateTor

emdee 2022-10-28 20:19:59 +00:00
parent dc5f8688ef
commit 8b31d77071
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
AddingAnOnionService.md

@ -10,12 +10,12 @@ It would help if all the BS node operators could also run a Tor client
risks from running a Tor client as it's not exit node, and the
overhead in negligible. The onion server is a 127.0.0.1 service, so
cannot be seen by your ISP. The BS service is on the opennet anyway
so an onion is just another access method. So we get dozens of Tor
onion nodes running quickly, we could test out running Tox *in* Tor
using Hidden Services. If the Tox nodebase was improved to serve BS
nodes, it would be much more resilient. I'm assuming the adversaries
cannot block .onion addresses within Tor, which I think is a valid
assumption for now.
so an onion is just another access method. The BS operator does not
have to *use* Tor; just run it.
So we get dozens of Tor onion nodes running quickly, we could test out
running Tox *in* Tor using Hidden Services. If the Tox nodebase was
improved to serve BS nodes, it would be much more resilient.
There are [simple instructions](https://community.torproject.org/onion-services/setup/)
to get Tor up and running, and it's distributed in all Linux distributions.
@ -125,7 +125,7 @@ onions in the mailing list or an NGC group.
A person that is already using Tor as a client, and Tox over Tor,
only needs to add the first section in the ```/etc/tor/torrc```
described above, and the MapAddress lines. We could have our update
utility read the DHTnodes file and look for onions slot, and
script read the DHTnodes file and look for onions slots, and
print out the MapAddress lines to be added to the ```torrc```.
Then they'll be using Tox *in* Tor with no vulnerabilities to the