Although ToReticulum and ReticuLoki are good solutions for anonymization, they had a weakness: altough your reticulum clients were anonymized, you had to connect to a clearnet propagation node. Due to the wraith-like, moving target nature of the gateways, some propagation nodes were hard to connect to (timeouts, path-related problems), or were outright unreachable this way.

To deal with these difficulties and find a solution for an extra-anonmyized propagation node that can be always reachable for the gateway users and clearnet gateway users alike, the concept for the ToReticuLoKargo was born - a simple, Tor/Lokinet-encapsulated propagation node designed to operate without any direct clearnet exposure.

The ToReticuLoKargo (or simply 'Kargo) is placed in the so-called "limbo" between the lokinetified/torified inbound interfaces and the torified outbound socksclientinterfaces to reach the clearnet gateways. So it doesn't have any clearnet exposure, and it was never exposed to clearnet in any way.

The result is a black-hole network presence: invisible and impenetrable from the outside, yet fully functional as a message distribution hub.

A. If you are connected to ToReticuLoki Gateways, you simply choose the propagation node - especially if you use meshchat, sideband, or nomadnet. After you do this, you don't have to hunt for other propagation nodes, causing a lot of headaches if you get timeouts and slow messages when The Shuffler (a randomized, outbound backbone/gateway-changer script the ToReticuLoki Gateways use for an extra-layer of anonymity as a moving target-like solution) takes action, as - unlike in the case of other propagation nodes - you will always reach it. It will be faster, more stable, and always reachable than any propagation node out there.

B. If you are connected to a clearnet gateway, you can use it as well! You don't need to connect to ToReticuLoki Gateways to use this propagation node - in fact, you don't even need Tor or Lokinet on your side. Thanks to the SocksClientInterface, it can seamlessly bridge and reach the clearnet, as even the outbound connections are two-way. And in the case you know of a person who uses the ToReticuLoki Gateways, and the user is offline, if you want to make sure that your message will reach him/her fast, you should use this propagation node.

If you are a gateway-user, it is simply a more viable solution for you: if you send a message to someone, especially when he or she is offline, you will have difficulties, as you will have one and only connection to the reticulum network: the ToReticuLoki Gateway. Because the Gateway has the Wiper and the Resurrector protocols (timed tor/lokinet restarts and reticulum shutdown and restarts with wipe of the reticulum storage folder) it is possible that your message will bounce endlessly or not even arrive if you send at this moment - with the 'Kargo in action, it won't happen, especially that the Gateways are working 24/7, so it will find a path to your destination faster.

Using ToReticuLoKargo from the clearnet is like a postman coming into your neighbor's house to deliver mail. You didn't go to the post office, and you didn't call him to your house. But because the postman is already standing in the hallway with an open bag (an active, outbound bi-directional connection opened by the 'Kargo), you simply leverage the opportunity and sneakily drop your secret letter into the bottom of his bag before he turns back toward his hidden fortress. You won't know exactly when or through which continent the postman arrived—but your message is guaranteed to be collected and safely buffered.

To make sure that the network will show the updated path to the propagation node, it uses an aggressive, frequent announce interval, so none of the anonymization (Sneaker/Shuffler/Wiper/Resurrector/Rebirth) protocols will make it become a phantom on the network.

If you are a propagation node owner using clearnet gateways, it can be tempting to add Kargo as a static peer - but due to the wraithlike nature of ToReticuLoki: the paths, routes and the connected gateways will always change, so I don't recommend it but feel free to try, and contact me to give some feedback.

Capabilities:

Message Store = 1000MB

Open for 50 peers

Stamp Cost Target = 13

Flexibility = 13

Peering Cost = 4

Remote Peering Cost Max = 64

Message Max Accepted Size = 55.60MB

Sync Max Accepted Size = 202.40MB

Although it is not much, LXMF can cause major CPU-spikes. Due to its periodic high computing time, I would need to upgrade my config, as it is quite limited right now.

If you want this to happen, throw some coins in the name of (r)evolution to march onto the next stage of progression:

*This page is hosted in a hybrid lokinet/tor-encapsulated instance.*