<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Thanks, Landon, so you agree</div><div dir="ltr">that a Tor-ChatServer-Tor path is needed (which is the ReflecTor-Concept), rather than a hiddenserver-to-hiddenserver Tor-Messaging, as there 35-45 % of the messages are not working out and are lost. That is not acceptable and no model for the future.</div><div dir="ltr"><br></div><div dir="ltr">Reflect.Tors have the aim to add strong encryption, means security, to anonymity, means proxification.</div><div dir="ltr">(With ping-in and ping-out an encrypted hop or mirroring of packets was meant, not the classical ping.)</div><div dir="ltr"><br></div><div dir="ltr">The Echo of a ReflecTor provides also proxification (like Tor is doing, so they are familiar) and adds real end-to-end encryption - and not hop-wise.</div><div dir="ltr"><br></div><div dir="ltr">Sure you can add IRC or Matrix Servers in the middle, but this is a security risk, as they accept plaintext and must be administered. ReflecTors need no administration for the chat nor do they handle plaintext. This is why they could be regarded as just another hop in the secure tor-circuit.</div><div dir="ltr"><br></div><div dir="ltr">Exit-Nodes are already Entry-Nodes as the Internet-Webserver sends the data to the Exit-Node as well - where it finds its Entry.</div><div dir="ltr"><br></div><div dir="ltr">For the Tor-Messaging over ReflecTors the path is: Hiddenclient-Tor-ReflecTor-Tor-Hiddenclient, So this is very secure and very anonymous.</div><div dir="ltr"><br></div><div dir="ltr">[for sure there could be the rare case that one participant does not (want to) hide behind Tor and addresses directly to the Exit-Node as ReflecTor (while the receiver of the message is still behind Tor), then we have the same situation as for surfing, where the webserver sends the data to the Exit-Node as Entry-Node. Exit-Nodes are already Entry-Nodes. But this does not matter, as the Sender could be proxified also behind federated ReflecTors and then is also proxyfied]</div><div dir="ltr"><br></div><div dir="ltr">The system/architecture offers with the conditons</div><div dir="ltr">- no admin needs to look at the chat-server "ReflecTor"</div><div dir="ltr">- the chat-server ReflecTor is handling only encrypted packets</div><div dir="ltr"><br></div><div dir="ltr">the following benefits:</div><div dir="ltr">- strong encryption of the chatters</div><div dir="ltr">- bringing end-to-end encryption to the chatters</div><div dir="ltr">- offline messaing</div><div dir="ltr">- group messaging</div><div dir="ltr">- and overall, reliability and no latency in chat packet transfer, which is not given in the current architecture.</div><div dir="ltr">- less coding within three current Tor-Messaging projects like Rico, Cwtch & Quiet adding own servers for these goals by using the existing code for the serverpart, rather than developing the client and serverpart new (and also going away from the holy hiddenserver-to-hiddenserver approach, which is not workable). </div><div dir="ltr"><br></div><div dir="ltr">Some code for an Echo-Listener and how this Listener accepts a connected neighbor could be looked up here in these three Echo-Servers, which could lend code for a ReflectTor integration in Exit-Nodes:</div><div dir="ltr"><br></div><div dir="ltr">SIMPLE LITE-LISTENER (C++) as Deamon:</div><div dir="ltr"><a href="https://github.com/textbrowser/spot-on-lite/blob/master/Source/spot-on-lite-daemon-tcp-listener.cc">https://github.com/textbrowser/spot-on-lite/blob/master/Source/spot-on-lite-daemon-tcp-listener.cc</a></div><div dir="ltr"><br></div><div dir="ltr">JAVA-LISTENER & NEIGHBOR (Java) for Android:</div><div dir="ltr"><a href="https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/main/java/org/purple/smokestack/TcpListener.java">https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/main/java/org/purple/smokestack/TcpListener.java</a></div><div dir="ltr"><a href="https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/main/java/org/purple/smokestack/TcpNeighbor.java">https://github.com/textbrowser/smokestack/blob/master/SmokeStack/app/src/main/java/org/purple/smokestack/TcpNeighbor.java</a></div><div dir="ltr"><br></div><div dir="ltr">APPLICATION LISTENER & NEIGHBOR (C++) full features:</div><div dir="ltr"><a href="https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spot-on-listener.cc">https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spot-on-listener.cc</a></div><div dir="ltr"><a href="https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spot-on-neighbor-a.cc">https://github.com/textbrowser/spot-on/blob/master/branches/trunk/Kernel/spot-on-neighbor-a.cc</a></div><div dir="ltr"><br></div><div dir="ltr"><br></div><div dir="ltr">However, looking more into the future, it will come to the creation that friends on the Tor-Messaging-Friendslist might want to send you Tor-bootstrap-nodes and also Tor-bridges-Nodes to circumvent censorship.</div><div dir="ltr"><br></div><div dir="ltr">Boldsuck already wrote here on August 2, that " "services" are added to hidden servers" (in general).</div><div dir="ltr">Brings up the question: Could a bootstrap or snowflake server be loaded via a hidden server? No.</div><div dir="ltr">It is like in gnutellium or bearshare, if you run out of bootstrappers, you are done.</div><div dir="ltr"><br></div><div dir="ltr">It is like saying, oh, my car has no battery anymore and I need to find a gasoline station by asking the cars cockpit. You will discover all dead.</div><div dir="ltr">It works only, if hybrid, friends, allies help with a second but integrated system: E.g. ask your navigator in your smartphone, where the next gasoline station is. And make your machine equipped with a new battery and gasoline powering it, if not pure battery driven.</div><div dir="ltr"><br></div><div dir="ltr">That is the way, why ReflecTors and other servers of the Echo can provide Tor-Chatters bootstrappers and Relays and Snow-Smacks over the Tor-Messenger, which could fix Tor again, even if all Tor-Nodes have run out or are not working because of indexing all known nodes.</div><div dir="ltr"><br></div><div dir="ltr">In an even more far away future P2P and F2F loading of Websites might be in parity, cf. the old Psiphone version or the Websurfing over an echoing Tor-Messenger and its friends.</div><div dir="ltr"><br></div><div dir="ltr">Already now Google is blocking the requests by many Tor-Exit-Nodes. All Exit-nodes IP-Adresses are indexed in the meantime. If this mailing-list has 250 active people and 100 relay admins comming from ISP-background, there might be 300-500 Exit-Nodes. They are easily to index. </div><div dir="ltr"><br></div><div dir="ltr">ReflecTors in combination of Tor-Messaging cover many aspects of these processes and are healing Tor, providing perspectives and need to be welcomed in the bubble, which is mostly done by understanding, cappable and innovative developers with a view more on the architecture and environment rather than the own place to build.  </div><div dir="ltr">  </div></div><div>An idea could be to really test in practice - as all is there to install and to test out - the speed of incomming messages with ReflecTors in comparison of the Hidden-to-Hidden versions. </div><div dir="ltr"><br></div><div>Kind regards Sam</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 3. Aug. 2024 um 17:18 Uhr schrieb Landon <<a href="mailto:reply@mynetblog.com">reply@mynetblog.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>I am a bridge relay operator. </div></div>
</blockquote></div></div></div>