DDosSmallNumberOfBSNodes.md

DDosSmallNumberOfBSNodes.md

@@ -1,10 +1,59 @@
 Previous: [[SecurityVulnerabilities]]
 
-By design, Tox relies on a small number of BS nodes.
+By design, Tox relies on a small number of BS nodes.  As the network
+is now, the number of nodes is very small, and all well known.  So Tox
+is vulnerable to being completely taken down by blocking a small
+number of nodes.
+
+The same problem, to a lesser extent affects Tor, although they have a
+few thousand nodes. Doing the best we can with what we have, we can
+take advantage of something from libtoxcore: the ```tcp_server slot```.
+It is supported by most clients like toxic or toxygen.
+
+So this is what is proposed:
+
+1. Fix libtoxcore to be able to accept .onion addresses for BS nodes,
+or test the workarounds: see [[ToxAndTorInChinaAndIran]].
+
+2. All BS node operators are asked to also run a Tor client (not exit node),
+in addition to running their node. We put together easy-to-follow instructions
+on how to download/configure/run Tor. There are no risks to the BS operator
+from running a Tor client (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.
+Your service is on the opennet anyway so an onion is just another access method.
+So we get dozens of  Tor onion nodes running quickly.
+
+3. All Tor Tox client users are asked to also configure their Tox client to
+use ```--tcp_server``` with a random port, and configure their Tor client
+(not exit node) to provide that ```tcp_server``` as an onion accessible relay,
+in addition to running the normal Tor. We put together easy-to-follow
+instructions on how to configure Tor to serve that ```tcp_server``` as an onion.
+There are no risks to the user as he's already running a Tor client
+(not exit node), and the overhead in the Tox client in negligible.
+The tcp_server is a 127.0.0.1 service, so cannot be seen by your ISP.
+So we get a tcp_server extra for every Tor user. That scales well.
+
+4. Modify Tox clients to detect if they are behind Tor and on their homepage
+or splash screen ask them to run a ```tcp_server```.
+
+5. Improve the client documentation on how to run Tox over Tor,
+particularly for Android users: how to download Orbot from
+<https://f-droid.org> (preferred over Srewgle Play) and configure them.
+Tell them to try first running Orbot and a browser that works with it,
+and test out if their mobile to see if they can run Tor. The Tor devs are actively
+playing cat and mouse with Iran and have other tricks if regular Tor fails.
+
+6. Improve our ability to monitor network performance, including TCP relays,
+so we can detect if anyone is attacking the network.
+
+PS: Trying make it easy to package and run a BS node in places like
+Iran is going about it in the wrong way; I doubt running a BS node in
+Iran is healthy thing to do. Get them onto Tor, and improve service over Tor.
+Much better to get all of our BS nodes to run an onion service so
+there is good availability and redundancy, and fix the minor problems
+needed for Tox to work with onion BS nodes.
+
+
 
-As the network is now, the number of nodes is very small, and all well known.
 
-So Tox is vulnerable to being completely taken down by blocking a
-small number of nodes.
 
-See: [[ToxAndTorInChinaAndIran]]

GroupOfDevicesPOC.md

@@ -7,5 +7,6 @@ One way to address the multi-device problem is to add the multiple devices of a
 It may not scale well because messaging is sent to all devices of all users;
 a single active user approach would be more efficient.
 
-And it wouldn't work for groups very well as a group-of-devices can not be a member of an NGC group.
+And it wouldn't work for groups very well as a group-of-devices can
+not be a member of an NGC group.