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:

JAVA-LISTENER & NEIGHBOR (Java) for Android:

APPLICATION LISTENER & NEIGHBOR (C++) full features:

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.