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 <alleestrasse100@gmail.com> wrote:

System wrote via Tor Project <noreply@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:

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