[tor-relays] Fwd: Introducing & Discussing "Reflec-Tor"s as concept | Exit-Relay as Entry-Relay | Tor & Echo | Adding Entry-Relays as Reflec-Tor to Exit-Nodes

[Sam]

Thanks, Landon, so you agree
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.

Reflect.Tors have the aim to add strong encryption, means security, to
anonymity, means proxification.
(With ping-in and ping-out an encrypted hop or mirroring of packets was
meant, not the classical ping.)

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.

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.

Exit-Nodes are already Entry-Nodes as the Internet-Webserver sends the data
to the Exit-Node as well - where it finds its Entry.

For the Tor-Messaging over ReflecTors the path is:
Hiddenclient-Tor-ReflecTor-Tor-Hiddenclient, So this is very secure and
very anonymous.

[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]

The system/architecture offers with the conditons
- no admin needs to look at the chat-server "ReflecTor"
- the chat-server ReflecTor is handling only encrypted packets

the following benefits:
- strong encryption of the chatters
- bringing end-to-end encryption to the chatters
- offline messaing
- group messaging
- and overall, reliability and no latency in chat packet transfer, which is
not given in the current architecture.
- 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).

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:

SIMPLE LITE-LISTENER (C++) as Deamon:
https://github.com/textbrowser/spot-on-lite/blob/master/Source/spot-on-lite-daemon-tcp-listener.cc

JAVA-LISTENER & NEIGHBOR (Java) for Android:
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/TcpNeighbor.java

APPLICATION LISTENER & NEIGHBOR (C++) full features:
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-neighbor-a.cc


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.

Boldsuck already wrote here on August 2, that " "services" are added to
hidden servers" (in general).
Brings up the question: Could a bootstrap or snowflake server be loaded via
a hidden server? No.
It is like in gnutellium or bearshare, if you run out of bootstrappers, you
are done.

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.
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.

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.

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.

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.

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.

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.

Kind regards Sam

Am Sa., 3. Aug. 2024 um 17:18 Uhr schrieb Landon <reply at mynetblog.com>:

> Hello,
>
> I am a bridge relay operator.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20240803/8e343c0b/attachment.htm>