From 8b31d77071c30a6d27d0d07c6be865ddce2ff178 Mon Sep 17 00:00:00 2001 From: emdee Date: Fri, 28 Oct 2022 20:19:59 +0000 Subject: [PATCH] UpdateTor --- AddingAnOnionService.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/AddingAnOnionService.md b/AddingAnOnionService.md index 085dc97..050001b 100644 --- a/AddingAnOnionService.md +++ b/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