I just typed up a huge reply and it did not get saved for some reason. Okay, let's do it this way then: 1.) I don't think we need to re-invent the wheel, (q)Tox can be used over Tor, that is likely one of the messengers you mentioned. 2.) I am currently not receiving the medication I really need for adult ADD (Lisdexamphetamine), so my attention span is very short. 3.) I'd rather be honest and tell you now that I am not particularly interested in your project, and move on, than coming up with not so helpful replies.
I have one good doctor specialized on ADD near me, but I keep forgetting to make an appointment, but not until after my mental illness problems are solved, I won't be able to fully commit to any task long term. So, if you want to ask me questions about Tor operations, especially regarding Guard/Exit nodes, and hidden services, I will help to my best extent. If you want to get into the nitty gritty side of things, the source code repository and this site: https://spec.torproject.org are probably your best bet. Greetings, George P.S: I have accidentally replied to the wrong message, making you probably unaware that I replied at all. I am now replying to your e-mail directly, having your e-mail and the mailing lists as recipients. Sorry for any inconvenience caused. And since you seem to be German: Alles gute mein Freund :) On Wednesday, August 14th, 2024 at 9:05 PM, Sam <alleestrasse...@gmail.com> wrote: > Hello, > many thanks, George, for your response, feedback and sharing experience with > servers within Tor. > Sharing experiences and measuring might be individual cases and conditions. > After it has been reported, we all need to make up our mind to find > solutions. So one result as a contribution is the Reflec.Tor concept. > I tried to test all the Tor-Messaging apps and yes, some had packet-loss and > latency problems and others were quite workable for a 1:1 chat, all probably > depending on the circumstances. Though, it is like with your GSM cat-tracker, > it must work, if it is needed, that is when the cat was jumping in a foreign > cellar because of bad weather, and a neigbour closing the door, not knowing > the cat, and the tracker gets no signal there. Then we are lost. > > So we need to focus the problem and find optimizations. > Some might have an absolutely approach to have strong anonymity. So I guess > the single-hop mode with just one intermediary respective in total a 3 hop > circuit might be not or never be acceptable. > Other might want strong encryption. > > For the Reflec.Tor concept I judge the needs and requests as very balanced > and acceptable. As the Reflec.Tor accepts only encrypted packets, these > packets are multi-encrypted, are transmitted over HTTP or HTTPS and do not > contain any IP-Information, the hop from an Exit-Node to a Reflec-Tor and > back to another Tor-Exit-Node is just considered as super-secure and just > another hop as it would be within Tor - as one more circuit. > So the approach of some projects, we MUST stay within Tor to provide > anonymity is short thought. The opposite is the case, you have 3 hops to the > Reflec.Tor which is the 4th Hop, and then again 3 hops back to the friend in > Tor-Messaging. That are seven hops and you come with the idea of just ONE > intermediary. > Again, all is multiple strong encrypted and every exit node as a Reflec.tor > would in total provide many Reflec.Tors as chat servers. > Probably thouse voting against it do not want Tor-Messaging or encrypted Chat > via Tor-Messaging for certain reasons, so the identity of Tor might decide on > the idea on Tor-Messaging: Having a Free Internet for Surfing and Chat. > > Those who want absolutely anonymous chat, should be keen on the ReflecTors > and implement it with priority. Not shortening the graph to one intermediary. > But beeing very reliabyl and working with seven hops, even if the middle node > as Reflec.Tor is the space between two Tor Circuit-Graphs. > > I have to ask for your IRC server to get that architecture right understood. > I am and was not aware of an IRC server addressable by an Onion-Address? > Which IRC-Client uses onion addresses as they are used by e.g. > RicoChet-Refreshed, is it onion service v2 or onion service v3 your IRC > server has implemented? > > So I guess with your server experience we speak from the same graph as a > Reflec.Tor would have, > > IRC-Client bound over lokalhost => to Tor => Tor-Entryguard => Tor => > Tor-Exit-Node => Internet => Your IRC Server => Internet => Tor-Exit-Node => > Tor => Tor-Entry-Guard => Tor => localhost sends to your friends IRC-Client > > Now you can replace the IRC Server with the Echo-Server, on which the > Reflec.Tor is based on. > So pretty good results, fast and reliably, and that is why we speak of the > same architecture. > > The bad results in messaging are comming over this architecture: > > Chat Client on Hidden Server => to Tor => Tor-Entryguard => Tor => .. some > Tor Bridges and Relays => Tor => Tor => Tor-Entry-Guard => Tor => Hidden > Server with Chat Client > > For sure, you can discuss any "Exit-Internet-Server-Internet-Exit"-Path - > Server, it could be an IRC server, it could be a Matrix server and it could > be an Echo-Server. > > The Echo-Server was chosen, as this server is very simple, probably also > simply to implement, it sends every incomming packet out to every connected > chat node, it handles only encrypted packets, plaintext is not handled. It > has no IP-Address in the packets, it is strong encryption. Others do not > offer this. > > So the desired path and architecture is: > > Tor-Messenger bound over lokalhost => to Tor => Tor-Entryguard => Tor => > Tor-Exit-Node => Internet => Echo-Server that is an Reflec-Tor => Internet => > Tor-Exit-Node => Tor => Tor-Entry-Guard => Tor => localhost sends to your > friends Tor-Messenger > > As all the software is there, it has been tested and works fine and fast. If > an Exit-Node would host it, the middle part "Tor-Internet-Reflec.Tor- > Internet-Tor" > would be shortend to "Tor--Reflec.Tor--Tor" which makes it even more secure > next to the encypted extra hop. With the existing installation in a parallel > run just another port for the Reflec.Tor needs to be addressed, and the idea > is now simply to use the same port as the exit-node uses for http/s and > browsing. > > If you look at the Tor-Metrics page there is a symbol for "Running", the > infinite arrows in a circle, that could be a symbol for a Reflec.Tor too, > I would not recomend a new extra symbol. > Because: As far as I see the relays do not have a version information for the > software used, if all update to a new Tor-Software in which each running exit > node has a Reflec.Tor implemented, then the world gets 2500 Chat Servers all > over the world. > The Tor Metrics currently show the stable Top 250, but if you click on the > symbol for running, you get all relays, also probably a security risk for > those who want to block or observe all IP adresses of Exit nodes?! > However, I dont see a risk in that, the problem is more the missing version > number, to see in the end, which Exit-Node has then the new release with the > Reflec.Tor Echo-Chat-Server updated or not. You need to inform all relay > admins to use the update. In the other case you have a new extra symbol for > those adding the chat feature, but this will be not successful. That's why a > statement is needed from the board to integrate Tor Messaging. > > For the implementation you speak of the hope of "no extra code". > I dont think this is a valid strategic option, to promise an effortless > approach of No-Extra Code with Zero Work while at the same time several > messengers evolve. > As said, the echo server is there, run it parallel on your exit-node IP and > you just need a different port. Instead of looking the port up in the shown > exit node of the TorBrowser, you can make an extra website or integrate it > into the Relay Metrics page. As said, this will be not successful, as no one > will install a piece or plug in parallel. It must be intergrated into the > Tor-Exit-Port for all to be successful. > > However, the problem is, that the Clients for Tor-Messaging like RicoChat > Refreshed and Quiet and Cwtch need to implement servers anyway, they need > these for groupchat and they need it for chat to offline friends. The Tor > Messenger Spot-On has that given with the use of a Reflec.Tor (Echo-Server). > The Chat over OnionShare is a bit different as there only one hidden server > as one common chat room seems to be given (correct me if wrong), and it makes > the connections not better. > > So now the mentioned three main projects start to code each their own server? > > And that server is also in the Internet as your IRC server is to be > functional? > > Why then not once coding in the Echo-Server - and all four Tor-Messaging > Clients use the Echo-Server for Groupchat. That is based on AES and would > also enable compatibility of the main clients to address a groupchat. In no > case we want a competition of these three clients to have "proprietary" > groupchats which means different own groupchat-servers. We can sum up the > coding and forces to just implement the GroupChat of the Spot-on Client in > RicoChat Refreshed and Quiet and Cwtch "with" or "and" ONE implementation of > a Reflec.Tor at each Exit-Node with one update. That would save much > individual hours of work. > > That is why a common discussion is needed and a statement of the board to > support Tor-Messaging, otherwise every one makes an own soup and is > struggling alone, but then we need not a board and no strategic discussions. > > Sure, supporting Tor-Messaging with Reflec.Tors by the board is a strong > input. > > But, as all three Messengers have not coded yet a groupchat server, that is > now possible to announce, or in case one individual developer provides a > patch for Exits, then it is immediately there. > > At the same time, the three Messengers need not to feel offended, as they get > a service by a common initiative. Maybe they make their own soup anway: > Cwtch switchted to flutter and seems to be quite rigid in own developmend > speed and style, Quiet is also a cooperable project and seeks for and > provides a professional GUI, which probably under the hood creates also own > coding styles. Ricochat Refresh seems to be tied very close to the Tor > development in total and make successive steps to improve. As the oldest > client it seems to be the most solid one, but also slow one in coding and as > all three depending on motivation and fund. > So for any three cases a common decision and adressing is helpful for the > groupchat server - but overall for the better graph architecture for more > reliabiliy and no packet loss. Even if not a development towards a Reflec.Tor > is started, the board needs to define a standard for the Chat-Hash whether it > is ricochet://39098203498 or Opion://1832761923 or Tor://9238798734 or > Quiet://928397 and how they can be compatible. > > However, that Reflec-Tor could be an initial model for a groupchat > implementation. BTW: That Spot-On Buzz Tab can also be used for 1:1 chat, so > the three clients could start with the groupchat and make thier clients at > the same time optional hybrid in 1:1 chats based on Buzz (sym, AES) **and** > their traditional way (hidden to hidden). Or even implement the Chat-Key for > the Echo and real (asym) 1:1 Messaging too. > Also a codebase swich could be discussed for RicoChat Refreshed R3 (with > Refec.Tor rather than Onion Service V3) as at the project discussed. Open > Source code needs always to be revised. > > So the best is doing nothing and not deciding?, then we have all our own > soup. The Reflec.Tor in Exit.Nodes makes immediately a strong code basis a > Tor-Messenger - and everyone can overtake it or implement it in the own > client. > > As a groupchat server is not coded yet in these three clients, there is no > offence and in the opposite it is a gift to have a common sense how to > implement groupchat and offline chat and also to have with a Reflec.Tor a > Server already provided by Tor-Developers. As said, ieven f five or more > exit-operators alreay provide/install an Echo Server on their Exit-IP, then > we just have a different port, but in the same minute Tor-Messaging is > working reliable with the Spot-On Tor-Messenger and the new standard for a > better graph architecture is set. > > Why then not implementing it for all the exit-nodes and provide also the > basis for groupchat for the three hidden-server based Messengers? > > So the model is less coding (and probably using less funding) by joined > forces. > Kind regards, Sam > > Am Mi., 14. Aug. 2024 um 16:04 Uhr schrieb George Hartley via tor-relays > <tor-relays@lists.torproject.org>: > > > 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 <alleestrasse...@gmail.com> > > wrote: > > > > > System wrote via Tor Project <nore...@forum.torproject.org>: > > > ============================================================ > > > > > > 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 > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
publickey - hartley_george@proton.me - 0xAEE8E00F.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
