Hello,
> Similar to Briar, even developers of such clients above tell the loss of > messages and low reliability of the hidden to hidden path. Some of you might > know, that there were use cases with missing messages in a range of 35-45 %. Sorry, but this is just not the case from my experience - it may take a while to fetch the descriptor of the hidden service, but once a TCP connection is established, aka. the ACK packet has been received, there should be no problems with packet-loss, this is one of the core features of TCP: Retransmission on various conditions. I also hosted a hidden IRC server, as well as a Tor hidden service on my grandmothers laptop, to be able to SSH in through Tor and troubleshoot problems. Experienced no packet loss, unless a relay in the circuit suddenly went offline. If you want, I can measure packet loss from various locations (Northern Europe, East Europe, and New York, USA). Also, to improve latency and throughput, you could make the server a one hop hidden server by enabling: > HiddenServiceSingleHopMode This way the looking up the server is faster, but clients remain anonymous using a normal 3-hop circuit. I don't think we need extra code for this, you could just build your app using the programming language of your desire and use the existing network. That's what I was doing with my ~200 user IRC server, and it worked fine, even while being hosted at home at a limited uplink of 15 Mbps, which now got upgraded to 30 Mbps. Unfortunately fiber is not an option, so we have to rely on 60+ years old copper wires maintained by Telecom, I have a quite fancy industrial router with modem software and capabilities, and we still use VDSL2 17a G.Vector (ITU G.993.5). I do however own a virtual machine machine on my friends colocated server at DataWagon, they are very exit friendly, zero abuse so far, I believe they just redirect abuse mails to /dev/null or something.. lol. Anyway, point is that I never encountered packet loss, and even if, the protocol would compensate for it. This became kind of a rant while I'm at work, so if it's not that useful, Im sorry. Regards, George On Wednesday, August 14th, 2024 at 9:12 AM, Sam <[email protected]> wrote: > System wrote via Tor Project <[email protected]>: > ============================================================ > > Feedback: Please submit the proposal also to tor-dev: tor-dev Info Page > ======================================================================= > > Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay > | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes > > ============================================================================================================================================= > > https://www.reddit.com/r/TOR/comments/1e4te8m/introducing_discussing_reflectors_as_concept/ > > ============================================================================================ > > > > ======================== > > ============================================================== > ============================================================== > > Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay > | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes > ============================================================================================================================================ > > > > Tor-Messaging: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay > as Entry-Relay | > > Hello, > > I think this belongs to this core, general, relay topic-forum, as it is also > a development & community issue, request and efford, I post it here into the > reddit forum for your core discussion: > > The idea is to add next to Bridges, Relays and Exit-Nodes also "Entry-Nodes" > as "Reflec-Tor"(s) to the point of Exit-Nodes. Hence: Exit-Nodes are > developed futher to be also an Entry-Node. > > Some may remember when gnutella got hybrid with edonkey and then also with > torrent, Mike Stokes from Shareaza did that. > > The idea today, 20 years later, is to add some Echo-capabilities to Tor in > regard of the servers for Exit and Entry. > > Vision: Every (updated) Exit-Node is an Echo-Server - For a better > Tor-Messaging. > > What does that mean? > > An Echo-Server is a server for chat-messaging to send an incomming message > packet again out to all connected clients at the moment. Ping-in and Ping-Out > to all. That simple, that's why it is called the Echo. Like a shout in front > of a forrest, all connected users can hear and get the (encrypted) shout or > message or packet back from the tree wall. > > There are 3 software applications for Echo-Servers: > > - https://github.com/textbrowser/spot-on (Desktop, sercer in the Listener > Tab) > > - https://github.com/textbrowser/smokestack (java for Android) > > - https://github.com/textbrowser/spot-on-lite (headless deamon for Linux) > > > Now, the Listener function with ping in and ping out should be implemented > within a Tor-Exit-Node. > > When it comes to Tor-Messaging, there are some pathes possible: > > `A) Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - > Tor-Chat-Client-Bob (Tor-proxied Chat-Server, which only accepts encrypted > packets)` > > `B) Tor-Chat-Client-Alice - Echo - Tor - Tor - Echo - Tor-Chat-Client-Bob > (Echo Tor-tunneled)` > > `C) Tor-Chat-Client-Alice - Echo-Server - Tor-Chat-Client-Bob (direct > connection to Echo-Server with only encypted packets)` > > The request here is to build and develop option A. > > That is just right now also possible, by an Exit-Node of Tor running the > Echo-Server-Software on the same machine in parallel. Just the port is > different. > > This is an idea for some might be new, but thinking Tor Messaging a bit, it > comes quickly to this ideas and better soluttion. > > The way to connect > > `D) Tor-Chat-Client-Alice - Hidden Onion Server v3 - Tor - Tor - Hidden Onion > Server v3 - Tor-Chat-Client-Bob` > > is the current given way for clientes like RicoChet Refresh, Quiet or Cwtch. > > Similar to Briar, even developers of such clients above tell the loss of > messages and low reliability of the hidden to hidden path. Some of you might > know, that there were use cases with missing messages in a range of 35-45 %. > Don't quote me on that, but as core developers and community members you > might be in contact with those who experience this. > > Furthermore the Messaging clients are not advanced in functionality, nor > advanced in strong encryption. > > It would be third a long development way to got that route. > > It is cost effective and needs cappable developers. > > Some project have stamped on and made a workable client, but does that unite > all our power in the sense of Tor-Messaging? > > Messaging needs a Vision and Statement from the Tor-Core-Developer team with > a discussion in the community in that regard with honor to the individual > projects and also with support for their chosen path (Model D). At the same > time we have to state that it is as it is, a HTTP-Server in the middle like > in Model A is faster than Model D. > > In the graph-path the Echo-Server in the middle handles only encrypted > traffic, so it is just like another Relay. We can call it "Reflec-Tor". The > only sense it to multiply incomming encrypted packets from one node to all > connected nodes. > > With that Idea, the Messenger Spot-On could be used as a Tor-Messenger. > > This Messenger has stong encryption and is full of feature for messaging and > also cryptography. > > it is like adding Firefox to Tor-Browsing, when Spot-On is added to > Tor-Messaging. > > Something to read at the community forum: > > https://www.reddit.com/r/Spot_On_Encryption/ > > Also there is a Mobile Client for Android, which also connects to > Reflec-Tors, find "Smoke" Messenger at F-Droid.org. > > Please, get this right, it is not about a technical view on slow and failing > chat-packets to hidden servers, and it is not about those start-up clients > using this inside technology, some do a good project. It is about the idea, > that an Reflec-Tor mirroring and pinging back packets on the Exit-Node this > hop within the path of tor is not outside, it is always fully encryted for > the messaging packets and should be seen as one Tor-Path, especially if the > Listener-Ping-Back function (the Echo capabilities) is build in the > Exit-Node-Tor Software. > > Spot-On is already a Tor-Messenger - as it uses also HTTPs and it sends only > encrypted packets. > > A test is easy to make: > > `(1) Start the Tor-Browser, which has always the Port 9051 to Tor, Tor is > running.` > > `Next to Surfing with Tor-Browser Firefox the Chat with Tor-Messenger Spot-On > can start.` > > `(2) Start Spot-On on a webserver and create in the Listeners Tab a Listener > on Port 4710.` > > `(3) Start two Spot-On Instances Alice and Bob on two Laptops, in the > Neighbors Tab you connect the Webserver via Tor: Add the IP and Port 4710 to > the neighbor and choose Proxy:` 127.0.0.1 `Port 4710.` > > You get the the Path: > > `Tor-Chat-Client-Alice - Tor - Internet - Echo-Server - Internet - Tor - > Tor-Chat-Client-Bob` > > The idea is now to integrate this a bit more: > > `Tor-Chat-Client-Spot-On-Alice - Tor - [Tor-Exit-Node also Reflec-Tor > (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob` > > You see, the way stays all within the Tor-Family. > > For sure, in case Alice does not want to use Tor, she also can message to > Bob, who is behind Tor. > > `Tor-Chat-Client-Spot-On-Alice --> [Tor-Exit-Node as Entry-Node also > Reflec-Tor (Echo-Server)] - Tor - Tor-Chat-Client-Spot-On-Bob` > > The IP of an Entry-Node is shown in the Tor-Browser and can get a port added. > Then two user can simply cata over that node. > > We need in times of surveillance, data retention, chat control and for sake > of the needs of whistleblowser and people who want to chat privat and > anonymously more decentral and open source chat server. > > The mission is: Every Tor-Exit Node is an Entry-Node for Chat. > > It should be not a lot of code to be added to the ports of an Exit-Node and > displaying the Port of the Exit-Node in the Tor-Browser path icon. > > This makes sense in several effects to be discussed and developed further: > > - Taking the next Development Step for Tor-Messaging: BTW, A Forum about > Tor-Messaging could be made as a category here in the forum please. > > - directly support Tor-based Messaging for the Spot-On Messaging client > > > To be developed and discussed is, if this infra-structure could help to > > - support bootstrapping of Tor > > - support Censorship circumvention of Tor Reflec-Tors as SnowFlakes over > the Messenger with EPKS > > - Accept, that some routing to an HTTPS internet server at the Tor-Node is > faster than to an hidden onion server at the Tor Node. > > > Well, to add some "ping-in-and-out" for an packet is what every netcat and > socat under linux can do. It is a small development step to make each > Tor-Exit node a free chat server for messaging, which is a big step for > mankind to have a network of free messaging chat servers. > > Lets also see, how users and community will test and develop this messaging. > So it is not only a discussion for developers, it is also a step forward the > needs of the communities for a free internet: > > - for chat and their discussions. > > > A few code lines to exit nodes make them a Reflec-Tor and messaging over Tor > can start really decentral and open source and free. > > What do you think? does this privacy-concept bring more privacy and > reliability in packet delivery to messaging with Tor? > > Regards
publickey - [email protected] - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
